RE: [IP-Optical] LMP: Link verification procedure suggestions.

[Fugui Wang <fwang@axiowave.com>]

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
>