[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LMP & neighbor discovery
Zhi, all,
Let's try to have a more structured way to see this
pending issue:
Preliminaire: the document to which you refer tends to
clearly separate the control channel issues from the
discovery function(s) - this is not so obvious to be
understood through the e-mails sent by your colleague
for CCAMP'ers not following the G.ASON activities (and
in particular having a detailed knowledge of G.7714).
Please take this into account (terminology and moreover
semantic in standards is much more important than what
i can infer from your last e-mail)
So i suggest also that people that want to have the
corresponding concerns addressed provides the right
input in order for our community to provide the right
answer (a good example would be for instance to provide
a clear explanation of what CTP and TTP means from this
perspective)
From my side, i have also tried to see how we can more
effectively proceed with this issue using the following
approach:
1) What's currently defined in LMP
In LMP the VERIFY ID object seems to correspond to the
Node ID that you require; in fact from its definition:
"The VERIFY_ID object contains a node-unique value that is
assigned by the generator of the BeginVerifyAck message.
This value is used to uniquely identify the Verification
process from multiple LMP neighbors and/or parallel Test
procedures between the same LMP neighbors."
This i-d can be used for the purpose you have mentioned.
p54 of the same document gives also you more information
on this.
2) What can be expected as enhancement/update ?
All the other policing usage it's up to the configuration
of the LMP controller as such there are two elements that
have to be clarified (1) provide content telling that in
some particular circumstances the "verification" procedure
can be performed without verification negotiation as such
this is inline with the neighbor discovery (2) that two
(optional) fields (T and D) when using in-band transport
see again page 54 since there is some reserved space there
so i believe it shouldn't be so dramatic to include these
changes; Typ=T meaning send continuously. Also the CRC is
there by definition of the pattern.
Last is there something else to be expected from the 1)
the last version of G.7714 and 2) last ITU-T plenary
meeting discussions (i would expect a liaison statement
here that would help us).
3) How does it affect the current LMP i-d ?
What's the impact of these updates on the current LMP
document ? A careful analysis must be performed in order
to keep the global consistency of the protocol, in most
cases it doesn't just suffice to say add two objects and
one sentence to achieve the expected objective.
4) Last question how to deliver these updates:
Do we have to include these updates into the current LMP
document or into a specific GMPLS Profile document ? The
question is clear but the response is not so obvious because
it might very helpful to have all the ASON specifics into
the same document but on the other side one should also
keep some consistency ?
Best regards,
- dimitri.
Zhi-Wei Lin wrote:
>
> 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