[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
(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.
>
>
>
>