[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [IP-Optical] LMP: Link verification procedure suggestions.
Fugui,
Please see my response to Murugan.
Thanks,
jonathan
> -----Original Message-----
> From: Fugui Wang [mailto:fwang@axiowave.com]
> Sent: Thursday, December 06, 2001 7:13 AM
> To: 'Murugan .A'; Jonathan Lang; ccamp@ops.ietf.org
> Subject: RE: [IP-Optical] LMP: Link verification procedure
> suggestions.
>
>
> I also noticed the problem as Murugan described below.
> Even worse, the TE link ID mapping could be unknown in
> the BeginVerify (according to the LMP draft, Remote Link
> ID is an optional object for BeginVerify). In such case,
> if the receiver can receive test messages sequentially
> ONLY, then it has to listen all of the data bearing links
> between the neighboring nodes one by one (each for Verify
> Dead Interval) to determine whether it is a TestStatusSuccess
> or a TestStatusFailure.
>
> Fugui
>
> -----Original Message-----
> From: Murugan .A [mailto:mamirtha@npd.hcltech.com]
> Sent: Thursday, December 06, 2001 2:11 AM
> To: Jonathan Lang; ccamp@ops.ietf.org
> Subject: Re: [IP-Optical] LMP: Link verification procedure
> suggestions.
>
>
> Hi Jonathan Lang,
> When mappings are not known, the procedure to find
> mappings are not that straight forward.
> Some other pocedure over the LMP procedure is needed to
> find the mappings, which are not
> efficient and straight forward(this i have discussed in
> "IETF:" section of my earlier mail).
> Hence i have proposed some changes to LMP procedure
> itself(this i have discussed in
> "My suggestion:" section in my earlier mail).
>
> Let me take an example where LMP procedure fails.
> Both sender and receiver are capable of sending and
> receiving test messages sequentially ONLY.
> Let us have 4 interfaces in each side. Both the nodes
> dont know the interface mappings.
>
> The internal order in which the sender is going to send
> test messages is as follows
> S_interface_1 (using prefix S to denote sender)
> S_interface_2
> S_interface_3
> S_interface_4
>
> The internal order in which the reciver is going to wait
> for receiving test messages is as follows
> R_interface_4 (using prefix R to denote Receiver)
> R_interface_3
> R_interface_2
> R_interface_1
>
> The physical connection is as follows( in both
> directions)
> S_interface_1 <-> R_interface_1
> S_interface_2 <-> R_interface_2
> S_interface_3 <-> R_interface_3
> S_interface_4 <-> R_interface_4
>
> Now let us see what happens when testing is started with
> "Number of Data Links" set to 4.
> Receiver is waiting in R_interface_4 upto
> VerifyDeadInterval, but the sender sends test messages in
> S_interface_1 repearedly.
> The physical connection is between "S_interface_1 <->
> R_interface_1"
> At the end of VerifyDeadInterval the receriver sends
> TestStatusFailure, now the sender will send
> estStatusAck( and move to the second link)..
> The Recever receives TestStatusAck( and move to the next
> link to listen)
>
> Now The Sender moves to S_interface_2, the receiver moves to
> R_interface_3.
> But the physical conenction is between "S_interface_2
> <-> R_interface_2".
> Hence this also fails.
>
> Now The Sender moves to S_interface_3, the receiver moves to
> R_interface_2.
> But the physical conenction is between "S_interface_3
> <-> R_interface_3".
> Hence this also fails.
>
> Now The Sender moves to S_interface_4, the receiver moves to
> R_interface_1.
> But the physical conenction is between "S_interface_4
> <-> R_interface_4".
> Hence this also fails.
>
> The sender has received TestStatusFailure for all its four
> interfaces. Similarly the receiver has not received
> test messages in any of the interfaces as per the internal
> ordering in which it waited.
> Mapping is not found for any of the interfaces and the links
> state is down.
>
> If the internal ordering of sending and receiving test
> messages are configured as per the physical
> connection then the above procedure succeeds. But this is
> eqivalent to user/"any one" configuring the interface
> mapping.
> The LMP procedure doesnot find the interface mappings, it
> only check if the interface mappings provided by the user
> is correct or not
>
> Let me know if i have missed some thing.
>
> Thanks,
> Murugan
> Ramesh
>
> > >Hi,
> > > Giving below the test procedures followed by the IETF
> draft and my
> > suggestions for them.
> > > Both nodes exchange their testing
> capabilites(sequential/simultaneous)
> > through BeginVerify
> > > and BeginVerifyAck.
> > There is no notion of exchanging sequential/simultaneous
> testing
> > capabilities. The protocol is designed to support both
> capabilities without
> > negotiation.
> >
> > >
> > > The local node also sends if it has the interface
> mappings(not know
> > intially) in BeginVerify.
> > > When the mappings are known, if both nodes support's
> simultaneous testing,
> > simultaneous
> > > testing is done.
> > >
> > >If only one node support's simultaneous testing, then
> both nodes do
> > sequential testing with
> > >the know ordering.
> > >
> > >
> > >1) sender testing capability:sequential, receiver testing
> > capability:simultaneous, mappings
> > > are not known.
> > > IETF:
> > > Verification procedure is started with number of links
> to be tested equal
> > to all links in
> > > the TE/data set. Sender sends test message in one of the
> links(as per its
> > internal ordering).
> > > Receiver waits in all the links.
> > >
> > > Receiver may receive test message in just one of the
> links, for all other
> > links it will not
> > > receive test message within VerifyDeadInterval. At the
> end of
> > VerifyDeadInterval the remtoe
> > > node would have send TestStatusSuccess or
> TestStatusFailure for all the
> > links.
> > >
> > > The sender sends TestStatusAck for all the links. The
> verification
> > procedure is completed.
> > >
> > > At the end of this verification procedure mapping is
> found out for only
> > one link(provided
> > > beginVeryAck is received).
> > > The above procedure has to be repeated again and again
> unitl mapping is
> > found for all links.
> > No. The VerifyDeadInterval is set for *each* Test message.
> This is
> > configured at the receiving node and indicates that if a
> Test message is not
> > seen within the VerifyDeadInterval, the Test procedure has
> failed for that
> > data link. In your above example, once the receiver sees a
> Test message, it
> > sends a TestStatusSuccess message to the sender. If
> instead, the
> > VerifyDeadInterval is reached without receiving a Test
> message, A
> > TestStatusFailure message is sent. At this point, the
> sender can transmit a
> > new Test message down the next data link.
> >
> > >
> > >My suggestion:
> > > The sender informs the receiving side that it is capable
> of testing
> > sequentially only. It also
> > > informs the remote node that it doesnot have interface
> mappings. Receiver
> > sends BeginVerifyAck,
> > > with VerifyDeadInterval set to "locally configured
> VerifyDeadInterval for
> > single data link"
> > > * "no of links to be tested".
> > > The local node will send test messages in a interface
> sequentially for
> > every verify interval
> > > and the number of retries for an interface will be
> stopped based on local
> > configuration
> > >( retransmission count or timer).
> > >
> > > Remote node is waiting for "VerifyDeadInterval for
> single data link" * "no
> > of links to be
> > > tested" for all interfaces. This time is enough to
> receive test message
> > send in any order
> > > over the links.
> > >
> > > 2) sender testing capability:sequential, receiver
> testing
> > capability:sequential, mappings are
> > > not known.
> > >
> > >IETF:
> > > Not clear how testing is done in this case. Since sender
> follows its own
> > ordering for sending
> > > test messages over different interfaces, where as the
> receiver follows its
> > own ordering
> > > waiting to receive test messages over interfaces. There
> is no correllation
> > of the ordering
> > > between the two.
> > The LMP procedure is the same as I described above.
> >
> > >
> > >My suggestion:
> > > The sender informs the receiving side that it is capable
> of testing
> > sequentially only. It also
> > > informs the remote node that it doesnot have interface
> mappings.
> > >
> > > The receiver also informs the sender that it is capable
> of doing testing
> > sequentially and sets
> > > VerifyDeadInterval to "locally configured
> VerifyDeadInterval for single
> > data link" * "no of
> > > links to be tested".
> > >
> > > Remote node is waiting for "VerifyDeadInterval for
> single data link" * "no
> > of links to be
> > > tested" for one interface. After the end of this period
> it waits in the
> > next interface.
> > >
> > > The local node will send test messages in a interface
> sequentially for
> > every verify interval
> > > and the number of retries for an interface will be
> stopped based on local
> > configuration
> > > ( retransmission count or timer). At the end of this
> period it may know
> > mapping for just
> > > one link. Since the local node know that the remote node
> is only capable
> > of sequential testing
> > > the above procedure has to be repated.
> > >
> > >Thanks,
> > >Murugan
> > >Ramesh
> >
>