[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: LMP & neighbor discovery
Hello Greg,
Not wishing to disagree with you, please see comment below.
Regards,
George R. Young
Meriton Networks Inc.
3026 Solandt Rd., Ottawa, ON, Canada, K2K 2A5
phone: +1 613-270-9279 Ext 287
fax: +1 613-270-9628
email: george.young@meriton.com
>-----Original Message-----
>From: Bernstein, Greg [mailto:GregB@ciena.com]
>Sent: Thursday, May 09, 2002 1:53 PM
>To: Martin Dubuc; Zhi-Wei Lin; ccamp@ops.ietf.org
>Cc: Michiel van Everdingen; Bernstein, Greg
>Subject: RE: LMP & neighbor discovery
>
>
>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.
I agree that, by itself, LMP does not have such a mechanism. But in cooperation with
RSVP, there is a mechanism, namely the RSVP NOTIFY message. What we need is a
way to quantify it's speediness. FYI, I've submitted an internet draft
http://www.ietf.org/internet-drafts/draft-young-optical-prot-ext-rsvp-00.txt
proposing an RSVP-TE extension which addresses this shortcoming.
>(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.
>>
>>
>>
>>
>
>
>
>
>