[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LMP & neighbor discovery (verify_id)
Martin,
See below.
Carmine
Martin Dubuc wrote:
>
> Michiel,
>
> Current LMP draft allows implementors to:
>
> - Automatically associate control channels with interfaces.
[CD]Could you please explain how this is done automatically (not just for a
point-to-point control network, but any control network)?
> - Automatically bring up control channels over the control network between node pairs.
[CD]Could you please explain how this is done automatically (not just for a
point-to-point control network, but any control network)?
>
> Control channel management is an important aspect of LMP. It is is one of the tools that is required to discover the connectivity of the data ports.
>
> I don't see a need for change in messages to enhance the discovery aspects of LMP.
>
> Martin
>
> -----Original Message-----
> From: Michiel van Everdingen [mailto:MvanEverdingen@lucent.com]
> Sent: Friday, May 10, 2002 4:34 AM
> To: Jonathan Lang
> Cc: ccamp@ops.ietf.org
> Subject: Re: LMP & neighbor discovery (verify_id)
>
> Hello Jonathan,
>
> It seems that the whole control channel concept is *only* useful for this
> new description to "discover the connectivity of the data ports". By means
> of the control channel, the node knows where to send the beginVerify message
> to.
>
> Please let me know if the control channel is needed for other things as
> well.
>
> The described approach for neighbor discovery seems quite manual to me.
> - The operator needs to manually "associate control channels with
> interfaces" (see http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00609.html)
> - The operator needs to manually provision control channels over the control
> network between node pairs.
>
> In case above tasks can be done automatically, please let me know how.
>
> To my opinion, things get much simpler if we would
> - remove the concept of "control channel" and accept that signalling
> messages are carried over the "control network".
> - include a section on neighbor discovery; see the proposal in
> http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00750.html
> - keep initial discovery and subsequent verification separate.
>
> Best regards,
>
> Michiel
>
> Jonathan Lang wrote:
> >
> > Yanguang,
> >
> > To clarify things, we've added a few lines of text to the example of Section
> > 5.1 explaining how VerifyId is bound to the remote node.
> >
> > Thanks,
> > Jonathan
> >
> > 5.1. Example of Link Connectivity Verification
> >
> > Figure 1 shows an example of the link verification scenario that is
> > executed when a link between Node A and Node B is added. In this
> > example, the TE link consists of three free ports (each transmitted
> > along a separate fiber) and is associated with a bi-directional
> > control channel (indicated by a "c"). The verification process is as
> > follows:
> > o A sends a BeginVerify message over the control channel to B
> > indicating it will begin verifying the ports that form the TE link.
> > The LOCAL_LINK_ID object carried in the BeginVerify message
> > carries the identifier (IP address or interface index) that A
> > assigns to the link.
> > o Upon receipt of the BeginVerify message, B creates a VerifyId and
> > binds it to the TE Link from A. This binding is used later when B
> > receives the Test messages from A, and these messages carry the
> > VerifyId. B discovers the identifier (IP address or interface index)
> > that A assigns to the TE link by examining the LOCAL_LINK_ID object
> > carried in the received BeginVerify message. (If the data ports are
> > not yet assigned to the TE Link, the binding is limited to the Node Id
> > of A.) In response to the BeginVerify message, B sends to A the
> > BeginVerifyAck message. The LOCAL_LINK_ID object carried in the
> > BeginVerifyAck message is used to carry the identifier (IP address or
> > interface index) that B assigns to the TE link. The REMOTE_LINK_ID
> > object
> > carried in the BeginVerifyAck message is used to bind the TE link Ids
> > assigned by both A and B. The VerifyId is returned to A in the
> > BeginVerifyAck message over the control channel.
> > o When A receives the BeginVerifyAck message, it begins transmitting
> > periodic Test messages over the first port (Interface Id=1). The Test
> > message includes the Interface Id for the port and the VerifyId that
> > was
> > assigned by B.
> > o When B receives the Test messages, it maps the received Interface Id
> > to its own local Interface Id = 10 and transmits a TestStatusSuccess
> > message over the control channel back to PXC A. The TestStatusSuccess
> > message includes both the local and received Interface Ids for the
> > port
> > as well as the VerifyId. The VerifyId is used to determine the
> > local/remote
> > TE link identifiers (IP addresses or interface indices) for which the
> > data
> > links belong.
> > o A will send a TestStatusAck message over the control channel back to
> > B indicating it received the TestStatusSuccess message.
> > o The process is repeated until all of the ports are verified.
> > o At this point, A will send an EndVerify message over the control
> > channel to B to indicate that testing is complete.
> > o B will respond by sending an EndVerifyAck message over the control
> > channel back to A.
> > Note that this procedure can be used to "discover" the connectivity of
> > the data
> > ports.
> >
> > <...snip...>
>
> --
> +------------------------------------------------------------------+
> | 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 |
> +------------------------------------------------------------------+