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