[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: LMP & neighbor discovery
Michiel,
<snip>
>
> Repeating my earlier questions:
> - Why is 'control channel management' mandatory ?
> - Why are normal (i.e. not LMP specific) network layer mechanisms not
> sufficient ?
Why do you think they are sufficient?
Thanks,
Jonathan
>
>
>
> Thanks,
>
> Michiel
>
> Jonathan Lang wrote:
> >
> > Michiel,
> > Please see inline.
> >
> > Thanks,
> > Jonathan
> >
> > > -----Original Message-----
> > > From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com]
> > > Sent: Thursday, April 11, 2002 9:03 AM
> > > To: Jonathan Lang
> > > Cc: ccamp@ops.ietf.org
> > > Subject: 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.
> > Sending the BeginVerify assumes you know where to send
> control messages.
> > This is separate from discovering the data interfaces. This
> is why using the
> > term Neighbor Discovery can often be confusing. You
> actually have discovery
> > at various levels. G.7714 talks about this in a little more detail.
> >
> > >
> > > Please note that I'm discussing initial discovery. I
> don't question the
> > use
> > > of subsequent test messages verifying the connectivity.
> > Noted.
> >
> > >
> > >
> > > > 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".
> > Link correlation procedure also provides the local/remote
> mapping for all
> > data links. The Ack message provides this mapping (in
> addition to Test
> > message Ack) for each data channel individually.
> >
> > >
> > >
> > > > 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 :-)
> > Verification mechanism is used for data link discovery.
> Without exchanging
> > this parameter, you'd have to configure it on both nodes
> for each port/node
> > pair. Furthermore, if run LMP-WDM, you may have to
> configure yet another
> > mechanism for your wdm neighbor if the termination capabilities are
> > different.
> >
> > >
> > >
> > > > 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 ?
> > These are used to configure the LMP Hellos that are used to
> rapidly detect
> > failures along the control channel.
> >
> > >
> > >
> > > 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 |
> > > > >
> > >
> +------------------------------------------------------------------+
> > > > >
> > >
>