[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LMP & neighbor discovery
Hello Jonathan,
Your answer raises some questions in my mind:
> This is what the Link Verification procedure provides. As part of the
> BeginVerify message exchange, certain Test parameters (such as
> Verify_Interval, Verify_Dead_Interval, and Verify_Transport_Mechanism) are
> exchanged.
How do you start this link Verification procedure ? The 'beginVerify' message
seems to assume that the neighbor is already known.
Please note that I'm discussing initial discovery. I don't question the use
of subsequent test messages verifying the connectivity.
> As part of this discovery, NE-3 sends an acknowledgment message carrying the
> local (near-end) identity of link B.
Yes, agreed.
In my proposal this acknowledgement is in the link correlation procedure.
The DATA_LINK object in the linkSummary message (which is sent upon detection
of the neighbor) gives the association between "Local_Interface_Id" and
"Remote_Interface_Id".
> This assumes that NE-1 and NE-2 (and NE-3 and NE-4) have agreed on the
> verification mechanism in advance.
I'm not discussing verification but initial discovery.
If we could align on the used procedure for this initial discovery,
the neighboring NEs don't have to negotiate the mechanism :-)
> You could certainly create an LMP control channel through a DCN network. In
> fact, this is probably the preferred configuration.
>
> > Is implementation of the LMP's 'control channel management' mandatory ?
> yes, however you can choose not to run the Hellos by setting the
> HelloInterval and HelloDeadInterval equal to zero.
I don't understand why the normal network-layer mechanisms (defined in e.g.
OSPF or I-ISIS) are not sufficient ?
Why do we need the LMP specific 'Config' 'ConfigAck' and 'ConfigNack'
messages ?
Thanks !
Michiel
Jonathan Lang wrote:
>
> Michiel,
> Please see inline.
>
> Thanks,
> Jonathan
>
> > -----Original Message-----
> > From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com]
> > Sent: Tuesday, April 09, 2002 12:41 AM
> > To: ccamp@ops.ietf.org
> > Subject: LMP & neighbor discovery
> >
> >
> > Hello all,
> >
> > I found the concept of neighbor discovery mentioned several times in
> > previous discussions on this list. However, I did not find a final
> > conclusion on how this neighbor discovery is done. Correct ?
> >
> > Could you please check my understanding below ?
> >
> > In my mind, reading the incoming 'access point identifier' [ITU-G.707]
> > and subsequent LMP 'link property correlation' form a perfect fit. By
> > simply encoding the sending node's IP address and local access point
> > number in the access point identifier (see e.g. [OIF.2000.159.01]), the
> > receiver can discover the data link (linkConnection in ITU terminology).
> > Subsequent 'link property correlation' could then a.o. check on bi-
> > directional fibering, matching data link properties and grouping of data
> > links into TE links.
> >
> > Example: the following figure shows 4 network elements of which 2
> terminate
> > the data link (TTPs, T) and two are transparent to the data link (CTPs,
> C).
> > E.g. NE-1 and NE-4 are SONET/SDH multiplexers; NE-2 and NE-3 are
> transparent
> > optical cross connects. The data link in this example is STM-N/OC-N.
> >
> > +------+ +------+ +------+ +------+
> > | T-|--->--|-C C-|--->--|-C C-|--->--|-T |
> > | | A | | B | | C | |
> > | | | | | | | |
> > | NE-1 | | NE-2 | | NE-3 | | NE-4 |
> > +------+ +------+ +------+ +------+
> >
> > 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 (a fixed, agreed upon timer is needed). NE-3 will
> > continuously scan all its not discovered input ports for a discovery
> signal.
> > At some point, it will detect the test-signal on data link B.
> This is what the Link Verification procedure provides. As part of the
> BeginVerify message exchange, certain Test parameters (such as
> Verify_Interval, Verify_Dead_Interval, and Verify_Transport_Mechanism) are
> exchanged.
>
> >
> > +------+ +------+ +------+ +------+
> > | T-|--->--|-C C-|--->--|-C C-|--->--|-T |
> > | | A | / | B | \ | C | |
> > | | | T | | T | | |
> > | NE-1 | | NE-2 | | NE-3 | | NE-4 |
> > +------+ +------+ +------+ +------+
> >
> > 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.
> As part of this discovery, NE-3 sends an acknowledgment message carrying the
> local (near-end) identity of link B.
>
> >
> > 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.
> This assumes that NE-1 and NE-2 (and NE-3 and NE-4) have agreed on the
> verification mechanism in advance.
>
> >
> > 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
> >
> >
> > Notes:
> > - I understand that LMP's link verification procedure is more efficient
> for
> > *already discovered* data links. It does not need the continuous
> scanning
> > on received access point identifiers in undiscovered CTPs (in the
> example:
> > in NE-3).
> > - Discovering the address of the sending access point might also go via a
> 'name
> > server'. This can, for example, be useful in case the address of this
> access
> > point can not be encoded in the limited length of the access point
> identifier.
> >
> > B.t.w., could you please explain why the linkSummary and linkSummaryAck
> messages
> > have to go over a point-to-point control channel ?
> All LMP messages are sent over the LMP control channel; the health of which
> is monitored using LMP Hello messages.
>
> > Is it also possible to
> > use the generic DCN network (MCN/SCN, can be IP-based, see ITU-G.7712) ?
> > In the latter case, we could simply use the normal UDP service of that
> network
> > to transport the linkSummary and linkSummaryAck messages ?
> You could certainly create an LMP control channel through a DCN network. In
> fact, this is probably the preferred configuration.
>
> > Is implementation of the LMP's 'control channel management' mandatory ?
> yes, however you can choose not to run the Hellos by setting the
> HelloInterval and HelloDeadInterval equal to zero.
>
> >
> >
> > Thanks !
> >
> > Michiel
> >
> > --
> > +------------------------------------------------------------------+
> > | Michiel van Everdingen |
> > | Systems Engineer |
> > | Lucent Technologies - Optical Networking Group |
> > | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 |
> > | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 |
> > | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com |
> > +------------------------------------------------------------------+
> >