[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: LMP & neighbor discovery (verify_id)
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.
> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be
> [mailto:Dimitri.Papadimitriou@alcatel.be]
> Sent: Wednesday, May 08, 2002 7:46 AM
> To: Yangguang Xu
> Cc: ccamp@ops.ietf.org
> Subject: Re: LMP & neighbor discovery (verify_id)
>
>
> Yangguang,
>
> That's seems more than clear from the definition of the VERIFY_ID
> object but Michiel mentioned he wants a node ID as indicated in
> the frame format he provided (for "discovery" purposes):
>
> > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> > | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16|
> > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
> > |CRC|Typ|Dis| Node Identifier | Port Identifier |
> > +---+---+---+-------------------------------+-------------------+
>
> If this is not the case (ie the node id is not a node unique
> value), then please provide more information on how the node
> id is defined in the above frame this from the definition we
> have received from him:
>
> > Node Identifier
> > The "node identifier" is the IPv4 address that identifies the
> > sending Node_Id. The IPv4 address is encoded in 8 hex characters.
>
> Link Property Correlation message related exchanges are not
> coupled with the above information exchange - this also part
> of the global request as far as i understand it - so i don't
> clearly see your point with respect to "discovery" (moreover
> nothing precludes the subsequent usage of the Verify ID as
> currently defined when TE Links are build up and wanted to be
> verified).
>
> thanks,
> - dimitri.
>
> Yangguang Xu wrote:
> >
> > Dimitri,
> >
> > > 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.
> >
> > I thought about this, yet, it doesn't seem to work. Indeed,
> both Michiel and
> > Jonathan pointed me the case that when two NEs have
> parallel TE links, you need
> > different verify IDs.
> >
> > Yangguang
>
> --
> 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
>