[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LMP & neighbor discovery
hi, the "discovery" process is perfectly coverable by LMP
if one allows for some specific enhancements such as the
ones proposed in this thread ... the important point is
that even at oif the "merge between the config and the
in-band" discovery is not in perfect alignment w/ the
strong demand we have today as such i would suggest that
the ccamp community solves this "decoupling" issue once
for all - since in the absolute this decoupling is com-
pletely independent of the transport plane technology -
Hint: "decoupling" simply means discover your neighbour
interfaces ID independently of the control channel trans-
port mechanisms; and as far as i understand it the scope
is to be capable to cover two non-negotiated verification
1) TTP: send test messages continuously (no interrupt)
2) CTP: send test messages continuously until receive a
link summary message.
the test message being: <flags> <node_id> <interface_id>
...is it really infeasible ? i don't think so, we have
already specific i-d for technology specific lmp exten-
sions and an ongoing gmpls profile for g.ason so i don't
think there is no room for such enhancement within the
ccamp community effort.
- dimitri.
"Bernstein, Greg" wrote:
>
> Hi Martin and Zhi, I was thinking about a little overall perspective on the
> general LMP topic and some recent agreements concerning LMP-WDM.
> As someone presently very interested in SDH and OTN functionality I found
> the motivation for LMP understandable but out of scope for the problem I was
> interested in solving.
>
> LMP is good for transparent optical switches that do not terminate either
> "in-band" overhead such as BIP-8 (error monitoring), J0 (section trace), DCC
> (SDH data communication channels -- MS and RS), or GCC (G.709 equivalent),
> etc.; or optical support channels such as those commonly used in DWDM
> systems and described in the overall OTN architecture.
>
> As such this leaves a few gaps which LMP fills in the transparent optical
> case:
> (a) Fault isolation -- in SDH, OTN we've got extremely fast mechanisms built
> in for AIS (Alarm Indication Signals -- for upstream to tell downstream of
> problems) and RDI (remote defect indication -- for bidirectional signals to
> indicate a far end receive problem). In transparent optical this is not the
> case.
> (b) Performance monitoring -- in SDH at the RS (regenerator section), MS
> (multiplex section) and path (higher and lower order) we've got the B1, B2,
> MS-M0/M1, and B3 overhead that lets one accurately ascertain the received
> signal quality and also in some cases the far end receive quality.
> (c) Communication Channels for Control -- in SDH we've got the RS and MS DCC
> channels and in G.709 the GCC.
>
> Now for SDH and G.709, per standards and customer requirements, I must
> provide this overhead processing simultaneously for each and every line
> (some leeway on how much DCC). With transparent optical switches this is
> not the case. In particular, we are always transmitting and receiving this
> overhead on every line.
>
> Hence for SDH and G.709, I don't really have a need for the bulk of LMP
> functionality and won't use it since I already have mechanisms that deliver
> this functionality (and more) that I'm required to furnish. In the area of
> "discovery", there is a strong demand to provide discovery per the
> definition in G.7714, i.e., without requiring any pre-configuration of
> adjacent node information. This was reflected in the modifications to LMP
> for the "in-band" case that appear in the OIF's UNI 1.0.
>
> Hence, I'd recommend, that LMP be applied to the pre-OTN transparent optical
> case similar to the agreement reached on LMP-WDM. For existing optical
> technologies it doesn't really make any sense to use it. For efforts
> concerned with discovery applied to SDH and G.709 ITU and OIF have projects
> with these particular technology specific focuses.
>
> Greg B.
> ***********************************
> Dr. Greg M. Bernstein
> Senior Technology Director, Ciena Corporation
>
> -----Original Message-----
> From: Martin Dubuc [mailto:Martin.Dubuc@meriton.com]
> Sent: Thursday, May 09, 2002 6:44 AM
> To: Zhi-Wei Lin
> Cc: Michiel van Everdingen; ccamp@ops.ietf.org
> Subject: RE: LMP & neighbor discovery
>
> Zhi-Wei,
>
> We have to be aware that LMP is a generic protocol not tailored specifically
> for SONET/SDH. It is very dangerous to start adding protocol specific
> concepts in the spec.
>
> To represent TTPs and CTPs, one can use the generic concepts of ports and
> component links (see Introduction for a definition of port and component
> link). There are already a number of Internet drafts that use these
> concepts.
>
> Switching to CTPs and TTPs at this point would be very dangerous in that it
> would require changes in several drafts and would also alienate
> implementations that are not SONET centric.
>
> LMP is very closely linked with GMPLS. I am not sure why you single-handedly
> discard the GMPLS argument for adequacy.
>
> I still believe that the current draft allows vendors to implement automatic
> discovery. The link connectivity verification described in the draft can be
> used to fulfill this requirement. There is no need for extension of the
> messages to support this.
>
> Martin
>
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
> Sent: Tuesday, May 07, 2002 5:16 PM
> To: Martin Dubuc
> Cc: Michiel van Everdingen; ccamp@ops.ietf.org
> Subject: Re: LMP & neighbor discovery
>
> Hi Martin,
>
> Given the discussions thus far on this thread, there seems to be (from
> my reading) a need for auto discovery as the LMP as is currently do not
> support this capability. If you see otherwise, maybe you can point to
> the section and text that suggests this?
>
> As for the language of ITU-T vs. IETF, let's not get into turf war here
> but simply state why you think it's not necessary. If IETF has a set of
> language that describes it the same way and it's equivalent then that's
> fine, but if it's not equivalent then we obviously should look at it
> more carefully instead of making some general statement. Since you think
> the IETF document's language are adequate, then may I ask how IETF
> differentiates some of the aspects expressed by a TTP and a CTP, because
> clearly if we look at the SONET/SDH MIBS, TCP and CTP are used for its
> info model (and since we are applying these to a SDH network, I'm
> assuming you are also using these info models??). Of course this applies
> to the OTN network as well...so the same argument is relevant...
>
> The fact that GMPLS may not use CTP and TTP is because GMPLS is looking
> at these from the control plane perspective, while the LMP is actually
> involved with tracking of the actual transport plane resources (so not
> the same scope as GMPLS in terms of resource description), so can't
> really use the GMPLS argument for adequacy...
>
> Your comments (as well as from others) are greatly appreciated. But
> let's NOT get into turf battles, and stay strictly technical...
>
> Zhi
>
> Martin Dubuc wrote:
>
> >We don't need any update to the LMP draft to address automatic discovery.
> It is possible to implement automatic discovery with the current draft.
> >
> >I would also like to warn CCAMP that the TTP and CTP concepts used in ITU-T
> specs are very complex and I do not see a reason to change any IETF
> documents to comply with this terminology/framework.
> >
> >Martin
> >
> >-----Original Message-----
> >From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com]
> >Sent: Tuesday, May 07, 2002 11:42 AM
> >To: ccamp@ops.ietf.org
> >Subject: Re: LMP & neighbor discovery
> >
> >
> >Hello all,
> >
> >Please find below two proposed updates of the LMP draft. These
> >updates are based on the thoughts expressed in emails
> >http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html
> >http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00651.html
> >
> >Your comments are appreciated !
> >
> >Thanks,
> >
> >Michiel
> >
> >
> >1. Insert an additional section on "Automatic neighbor discovery"
> > ==============================================================
> >In this section, an optional LMP procedure is described to automatically
> >detect the identification of the other end of the data link. Basically,
> >automatic neighbor discovery is implemented by reading the incoming
> >'access point identifier' [ITU-T G.707].
> >
> >A Sub-Network Point (TTP or CTP) that implements the automatic neighbor
> >discovery procedure MUST send its identification in the access point
> >identifier. The identification SHOULD be formatted into 16 bytes as
> >follows ([OIF 2000.159.01]):
> >
> >+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> >| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16|
> >+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> >|CRC|Typ|Dis| Node Identifier | Port Identifier |
> >+---+---+---+-------------------------------+-------------------+
> > Figure 1: format of the access point identifier
> > to enable automatic neighbor discovery
> >
> >The format as specified in figure 1 is in line with the specification
> >in [ITU-T G707]. This SDH standard places the most stringent constraints
> >on the contents of the access point identifiers.
> >
> >All entries in the access point identifier, except for the CRC
> >field, are printable 7 bit encoded ASCII characters [ITU-T T.50].
> >
> >CRC
> > The CRC-7 code of the previous frame as specified in G.707.
> >
> >Typ
> > The "type indicator" informs the receiver of the sender's role.
> > values are:
> > "T": Trail Termination Point
> > "C": Connection Termination Point
> >
> >Dis
> > The "distinguishing identifier" avoids the proposed format to be
> > confused with some other optional format, e.g. the format specified
> > in G.831, Appendix I.
> > value:
> > "@"
> >
> >Node Identifier
> > The "node identifier" is the IPv4 address that identifies the
> > sending Node_Id. The IPv4 address is encoded in 8 hex characters.
> >
> >Port Identifier
> > The "Port Identifier" identifies the sender's Interface_Id in hex
> > format. This gives port numbers 0-FFFFF (1,048,575) which should
> > be enough for all types of Network Elements.
> >
> >
> >As an example, a node with IP address 192.168.2.23 would sent out
> >the following access point identifier (excluding the CRC) from a TTP
> >with local interface id 421:
> > T@C0A802170001A5
> >
> >A sending TTP that implements the automatic neighbor discovery scheme
> >will continuously send out its own identification. This is according to
> >ITU-T G.831, "the access point identifier should not change while the
> >access point remains in existence".
> >
> >A sending CTP that implements the automatic neighbor discovery scheme
> >MUST send its identification as long as it has not received a
> >linkSummary message indicating that the associated receiver has
> >discovered this sending CTP. The CTP MAY send its identification
> >continuously, until it is discovered. The CTP MAY also send its
> >identification in intervals, until it is discovered.
> >
> >
> >Example: figure 2 shows 4 network elements (NEs) and a single data
> >link between these NEs. Two NEs terminate the data link on interfaces
> >marked with 'T' (TTP). Two other NEs are transparent to the data link
> >on interfaces marked with 'C' (CTP). E.g. NE-1 and NE-4 are SONET/SDH
> >multiplexers; NE-2 and NE-3 are transparent optical cross connects;
> >the data link is STM-N/OC-N.
> >
> >Note that neighbor discovery is defined per datalink, so the actual
> >number of datalinks per NE is not relevant.
> >
> >+------+ +------+ +------+ +------+
> >| T-|--->--|-C C-|--->--|-C C-|--->--|-T |
> >| | A | | B | | C | |
> >| | | | | | | |
> >| NE-1 | | NE-2 | | NE-3 | | NE-4 |
> >+------+ +------+ +------+ +------+
> > Figure 2: automatic discovery example - 1
> >
> >NE-2 should, when it wants to discover data link B, connect
> >a test-set that sends an access point identifier to identify
> >the sending connection point C in NE-2. This test-signal should
> >be send long enough for NE-3 to detect and read the test-signal.
> >NE-3 will continuously scan all its not discovered input ports
> >for a discovery signal.
> >
> >At some point, NE-3 will detect the test-signal on data link B.
> >See figure 3.
> >
> >+------+ +------+ +------+ +------+
> >| T-|--->--|-C C-|--->--|-C C-|--->--|-T |
> >| | A | / | B | \ | C | |
> >| | | T | | T | | |
> >| NE-1 | | NE-2 | | NE-3 | | NE-4 |
> >+------+ +------+ +------+ +------+
> > Figure 3: automatic discovery example - 2
> >
> >When NE-3 has read the access point identifier in the test signal,
> >data link B is discovered. Subsequent link property correlation can
> >then be invoked.
> >
> >Discovery of data link A is similar, except that the access point
> >identifier is continuously sent. Discovery of data link C is also
> >similar, except that the access point identifier is continuously
> >monitored. In other words, there is no need for a sending respectively
> >monitoring 'test-set' in NE-1 and NE-4.
> >
> >Data link type Access point identifier to be used
> >-------------- ----------------------------------
> >STM-N, OC-N J0
> >STS-1/3/.../VC-3/4/... J1
> >VT-1.5/VC-11/12 J2
> >
> >
> >
> >A Sub-Network Point (TTP or CTP) MAY also use an alternative format
> >for the access point identifier, e.g. the one specified in
> >G.831, Appendix I. In this case, discovery of the address of the
> >sending access point will need involvement of a 'name server'. Using
> >an alternative format is, for example, needed in case the address
> >of the access point can not be encoded in the limited length of
> >the access point identifier, e.g. because IPv6 is used in
> >the control plane.
> >
> >
> >2. Add Additional text to section 4, "Link Property Correlation"
> > =============================================================
> >Note that the verify procedure is only applicable for CTP-->--CTP
> >and CTP-->--TTP dataLinks. The verify procedure is not applicable
> >for TTP-->--CTP and TTP-->--TTP dataLinks. TTPs constantly send
> >out their identification; the receiver can therefore at any time
> >verify the connectivity of the dataLink.
> >
> >
> >
> >
--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
Website: http://www.rc.bel.alcatel.be/~papadimd/index.html
Address: Alcatel - Optical NA, Fr. Wellesplein, 1
B-2018 Antwerpen, Belgium
Phone: Work: +32 3 2408491 - Home: +32 2 3434361