[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [IP-Optical] LMP: Link verification procedure suggestions.
Murugan,
Please see inline.
Thanks,
Jonathan
> -----Original Message-----
> From: Murugan .A [mailto:mamirtha@npd.hcltech.com]
> Sent: Wednesday, December 05, 2001 11:11 PM
> 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.
This is where you are misunderstanding the process. If you can only receive
over one interface at a time, then you need to cycle through your interfaces
before declaring the test failed. Hence, the VerifyDeadInterval must be
long enough for you to check all potential data links. This is why the
receiver determines the VerifyDeadInterval.
> 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
> >
>
>