[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LMP & neighbor discovery
Hello Jonathan,
Let me start with a general question:
Does this working group think it is useful to extend LMP with neighbor
discovery (at the transmission layer) yes or no ?
If 'no', where do you want to get it defined ?
Specific reactions to your email:
> 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.
Why is the term "Neighbor Discovery" confusing ? Neighbor discovery simply
discovers the other end of the data link.
(data link = component link = linkConnection)
I'm discussing neighbor discovery at the transmission layer on the levels I
mentioned in my first email in this thread:
STM-N, OC-N, STS-1/3/.../VC-3/4/...,VT-1.5/VC-11/12.
My proposal that started this thread allows the same procedure to be used,
regardless of the transmission layer. E.g. (using LMP terminology):
- by using J0 to encode the 'Local_Node_Id' and 'Local_Interface_Id',
it is possible to discover OC-n data links.
- similarly: by using J1 to encode the 'Local_Node_Id' and 'Local_Interface_Id',
it is possible to discover STS-1 data links.
- similarly: by using J2 to encode the 'Local_Node_Id' and 'Local_Interface_Id',
it is possible to discover VT-1.5 data links.
> 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.
OK. So you agree that link correlation (the linkSummary message) can be used
to reveal the locally discovered mapping
<Local_Node_Id, Local_Interface_Id, Remote_Node_Id, Remote_Interface_Id>
to the remote node. Correct ?
> 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.
Could you please be specific on what is wrong with the proposal that started
this thread ? In this proposal, I don't use the verification mechanism, yet
I don't have to configure the neighbor information 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.
Can we please focus on the mechanism for discovering switching neighbors
first ?
If you don't agree, please be specific on the problems you foresee.
Personally, I don't see a problem to extend the discovery mechanism as
I proposed to discover adjacency between a switching node and a
multiplexing node.
> > 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.
Earlier in this thread you stated that I can turn off the LMP Hellos...
so in this case 'Config' 'ConfigAck' and 'ConfigNack' are useless ?
Are normal network layer Hellos not good enough ?
Are you aware that the DCN network layer can be extended with MPLS ?
Are you aware that MS/line failure indications (e.g. MS-TSF or line-TSF)
can be used to 'rapidly detect failures' in DCC channels. ?
Are LMP Hellos faster than normal network layer Hellos ?
Repeating my earlier questions:
- Why is 'control channel management' mandatory ?
- Why are normal (i.e. not LMP specific) network layer mechanisms not
sufficient ?
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 |
> > > >
> > +------------------------------------------------------------------+
> > > >
> >