[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-rbradfor-ccamp-lmp-lol-00.txt
At 02:21 PM 11/18/2002 -0500, Adrian Farrel wrote:
Richard,
This looks like a useful
draft.
I have a few comments and nits in line
(look for >>).
Please let me know if you'd like me to
clarify any of my points or provide text.
Cheers,
Adrian
CCAMP Working
Group
Richard Bradford
Internet
Draft
Dimitri Papadimitriou
Expires: April
2003
Dan Tappan
October 2002
LMP Extensions for
Link discovery Using Loss of Light
>> I think you'll get asked to expand the acronym in the
title
>>>Changed.
draft-rbradfor-ccamp-lmp-lol-00.txt
[SNIP]
Abstract
This document proposes an
enhanced mechanism for LMP link
>> I think you'll get asked to
expand the acronym in the
abstract
>>>Changed.
verification that is
independent of the data encoding
>> need to say that this is for
use in verifying optical links
>>>I've added:
"It can be used for any
point-to-point link, including both Optical Links and SONET/SDH
Links."
type. The general
proposal is to use the transmission of
light by the sender and recognition of the presence or
absence of light by the receiver to identify port
mapping. The proposal includes minor extensions to
the
existing messages to implement this extension to the
link
verification procedure.
Bradford et
al
[Page 1]
Internet Draft
draft-rbradfor-ccamp-lmp-lol-00.txt September
2002
1.
Introduction
>> I'd suggest that section 1 is
too long and the bulk of the
text should be moved to a new "Overview" section
between
the current sections 2 and 3
>>>Changed. the Introduction now focuses on current limitations
and the second section focuses on the overview.
Optical networks are
being developed to include optical
cross-connects, routers and DWDMs that are configured
with control channels and data links. LMP was created
to
provide, among other features, link discovery
between
>> and link
verification
>>>changed.
these devices.
Currently, LMP requires the ability to
terminate data in these links in order to perform this
link discovery. Many of these devices, such as DWDMs,
do
not currently have these capabilities and the addition
of
these capabilities could be expensive or even
technically
unfeasible. This memo defines extensions to the LMP
Link
Verification Procedure to allow neighbors to determine
their interface mappings using the presence and
absence
(a.k.a loss of light or LoL)loss of light on
those
>> /re-write
Verification Procedure to allow neighbors to determine
their interface mappings using the presence or absence
of received light on those
>> /re-write off
>>>changed.
interfaces, a capability
that is simpler, does not
require optical/electrical conversion cheaper, and
is
>> add ",
is"
>>>removed cheaper
require optical/electrical conversion, is cheaper, and
is
within the existing
functional requirements of many of
these devices. A common name for the signal
indicating
presence and absence of light is Loss-of-Light, (LOL),
so
that name is used throughout this document. The
proposed
mechanism provides a more scalable solution than the
existing link verification
mechanisms.
1.1. Current
Limitations
[LMP] Link Verification
requires optical devices to
provide link termination of each port and provides a
wide
variety of transport mechanisms for possible
termination.
This requirement leads to several challengeshe LMP
link
>>
typo
>>>changed
This
requirement leads to several challenges. The LMP
link
termination requirement
prevents adoption on devices
which do not already electrically terminate links and
presents difficult engineering challenges for
incorporation in many other devices. Another
limitation
is the scalability of the current link verification
procedure. These are discussed in detail
below.
1.1.1 Link Termination.
Issues
This section raises issues of possible additional
complexity, performance impacts, reliability impacts
and potentially prohibitive cost issues which could
limit the applicability of LMP for certain devices.
Many
of the issues are implementation specific and not all
issues affect all types of optical
devices.
1) First,
X-transparent devices have no reason, other
than
>> do you need to explain
x-transparent and X-aspect?
>>>I think the
altered DWDM example at the end of the paragraph should make it clear
enough. I'll pass it by a few more eyes.
supporting
LMP link verification, to terminate the X-aspect
of the data link. Support for such termination
can greatly
increase the complexity, and cost, and power
consumption of
some devices and the additional components could
affect such
important aspects of a device as MTBF. A DWDM
that is
Bradford et
al
[Page 2]
Internet Draft
draft-rbradfor-ccamp-lmp-lol-00.txt September 2002
electrically transparent, for example, would
need to add the
>> do you mean
"optically" transparent?
>>>Yes. I've reworded the entire paragraph. Let me know if this
seems clearer.
>>>First,
X-transparent devices have no reason, other than supporting LMP link
verification, to terminate the X-aspect of the data link. Support for
such termination can greatly increase the complexity, and cost, and power
consumption of some devices and the additional components could affect
such important aspects of a device as MTBF.. For example, an optically
transparent DWDM does not need the ability to decode the light signal,
except to support LMP Link Verification.
ability to switch
every port between its operational pass-
through mode and its termination
mode.
2) Second, the
addition of link termination can increase
the signal loss through certain devices even
when the link
is not terminated, due to the additional
switching
requirement. An example of this is a DWDM, which
normally
does not need to switch the incoming light to an
internal
termination module. While this is very
implementation
dependent, the ability to losslessly add this
cabability
>>
typo
"capability"
>>>changed.
could present a roadblock to support for link verification.
3) Third, an electrically transparent OXC would need to
add
one or more termination modules and could and
would lose the
switching capacity required for those
termination modules
(e.g. a 16x16 port fabric mightwould need to
have at least
>> "mightwould"
:-)
>>>changed
one of those
ports connected to the link termination module,
preventing its connection to an external
interface).
4) Fourth, is the problem of supporting the
"right" set of
termination capabilities. For example, a
electrically
>> "an"
electrically
>>>changed
but,
again, do you mean optically transparent?
Actually, I think you
mean that the data plane is transparent
to the control plane.
That is, the control plane cannot
extract packets or
overhead information from the data plane.
This is a superset of
optically transparent.
transparent
switch may be able to support connections
carrying SONET or Gigabit Ethernet. In addition,
that switch
may be able to switch wavelengths, which are
carrying
anything from OC483 through OC768 and beyond. It
would be
costly and difficult to provide termination
capabilities for
even a small subset of these transport
mechanisms.
1.1.2 Link Verification
Scalability
1) In addition to
the above, the many of theexisting
>> typo "the
existing"
changed.
mechanisms
for LMP LV calls for the link verification
initiator to send in-band messages from each
port. If the
link-verification target switch is incapable
of
simultaneously terminating all its ports, it
must then cycle
through termination of its ports to find the
interface
connected to each source. This does not scale
well for large
switches. If a group of 512 port OXCs is
connected together,
then each target switch will need to cycle
through an
average of 256 ports before finding its mate.
This requires
an average of 131,072 (256x512) combinations to
try, a large
number, especially if the combinations must be
tested
serially(i.e. one termination at a
time).
>> FWIW the average is less than
this for point-to-point connectivity
in stable systems because you don't need to scan ports that
are
already known to be
connected
>>>Yes, adding a single port is
simpler. the worst case is the startup with a lot of ports, which should
only happen once, (unless the node and its neighbors get hit by the same
event, like a power hit).
The solution proposed in
this document limits the
excessive link termination costs, both in terms of
added
hardware and the potentially increased reduce optical
lossbudgets to support that hardware. It also provides
a
mechanism that scales much better for large numbers of
interconnects.
Bradford et
al
[Page 3]
Internet Draft
draft-rbradfor-ccamp-lmp-lol-00.txt September 2002
1.2. Proposed Solution Overview and
Benefits.
The solution must address
the issue of link termination
compatibility as well as the scalability limitation of
the existing LMP link verification
procedure.
The ability to switch
light on for the transmit side of
an interface and the ability to detect the presence of
light on the receive side of an interface is already
present in many optical devices, regardless of the
optical encoding mechanisms used. A link verification
mechanism based on LOL puts a minimal requirement on
an
interface and provides universal
compatibility.
For scalability, the
enhanced procedure allows testing of
all ports in parallel and without terminating the
line.
This avoids the limitation of testing ports serially,
which requires terminating one source port at a time,
then the destination will need to terminate a line,
wait
some interval which is greater than the inter-message
arrival time, and move to the next. This requires the
source to send on the order of n-squared messages. The
method described in this document reduces this to a
number on the order of ln(n) for large numbers of
interconnects. Note that the scalability problem is
only
an issue for devices which cannot terminate multiple
ports simultaneously.
Here is an overview of
the procedure. For brevity, the
initiator of link verification will be referred to as
LV-
src and the destination node accepting the link
verification request will be referred to as
LV-dst.
>> You need to clarify
"pattern". I think you should say
something like...
The LV-Src may set some of its ports to transmit light
and others to not transmit light. Given a well-known
ordering of ports, the ports may be represented as a
bit sequence with a zero bit representing no light and
a one representing a port transmitting light. The
resultant bit sequence represents the 'pattern' of
enabled interfaces.
>> /end suggested text
>>Added suggested text.
LV-Src sets the
interfaces it is verifying to emit light
in a particular pattern and then sends that pattern to
LV-
Dst over the control channel. LV-Dst looks for light
on
all its available interfaces and reports back over the
control channel. Initially every one of LV-dst's
interfaces can be "possibly-connected" to all of
LV-src's
interfaces, since no possibilities have yet been
eliminated. However, each time LV-Src changes the
combination light on its interfaces, some of LV-dst's
interfaces will not see the corresponding change, and
connectivity between those two ports will be
eliminated
as a possibility.
>> I would suggest moving all
example material out to a new section
at the end of the draft. I don't think that you need to give
the
comparison with port-by-port scalability again - you have
already
covered this.
Using this mechanism, the
port connectivity can be
established through a series of
interface/light-emission
patterns. For an eight port example, the pattern 0xF0,
0x0F, 0xCC, and 0xAA, would be more than sufficient to
provide the mapping of eight ports to eight ports.
These
4 messages will actually each require an
acknowledgement,
totaling 8 messages. To verify eight-port
connectivity
Bradford et
al
[Page 4]
Internet Draft
draft-rbradfor-ccamp-lmp-lol-00.txt September
2002
using the existing LMP
Link verification procedure
requires the source to terminate each source port in
turn. For each source port, the destination must
terminate each potential destination until a test
message
is received. On average, half the ports will need to
be
tested before discovering the right one. This requires
a
minimum of 8*4= 32 test messages, on average, and
probably many more, perhaps 64, since port termination
and waiting for a packet will typically require
waiting
for more than a single packet transmission interval.
For
eight ports, the number of test messages is reduced
from
between 32 and 63 messages, to just 8. For 64 ports,
this
method reduces the number of test messages from
(64*63)/2=2016 (or twice that), to 6+2=8 (or 16
including
acknowledgments..
Once LV-Src has completed
its entire pattern, LV-Dst will
report which interfaces, if any, map to its local
interfaces.
The pattern of lights
emissions must cause each interface
to change and must uniquely differentiate between all
the
ports. The algorithm used in the above sequences is as
follows. For N ports. Pattern 1 = first N/2 ports on,
second N/2 ports off. Pattern 2 = First N/2 ports off
second N/2 on. Patterns 3-maximium, (where M= pattern
#)
= Alternate on and off in groups of
N/(2**(M-1)).
>> You should stress that this
is an example, but that the
behavior is entirely an implementation matter for the
LV-Src.
>>Added
2.
Terminology
This document uses
terminology from the MPLS architecture
document [MPLSArch] and the LMP Draft
[LMP].
>> if you move the bulk of the
text in section 1 downwards, you
can add terminology for
'pattern' and for 'transparent'.
>>> Moved Terminology section up.
3. Link
Verification Extensions.
The following extensions
are needed to support this
method of Link Verification:
. A new
flag is defined to identify LOL in the Verify
Transport Mechanism field of
the BEGIN_VERIFY object and the
Verify Transport Response
field of the BEGIN_VERIFY_ACK
object. This field is defined
across all LSP encoding types
and does not interfere with
specification of the existing
transport mechanisms.
. Extension of the Test Message to include
the LOL Status.
. Extension of the TestStatusSuccess
message, which is
similar to the modified Test
Message.
>> "similar"?
:-)
>>>fixed
see
my note in message format below
there is an asymmetry
between the messages
.
Addition of a LOL_TEST_STATUS Object.
>> Assume this is the object included in the previous two
bullets?
>>>move it before the reference.
Bradford et
al
[Page 5]
Internet Draft
draft-rbradfor-ccamp-lmp-lol-00.txt September
2002
3.1. LOL Link Verification
Walkthrough
Here is a walkthrough of
the procedure. LV-src sends a
BeginVerify message indicating LOL as the transport
mechanism. LV-dst responds with a BeginVerifyAck
message, selecting LOL as the transport
mechanism.
LV-src sets its
interfaces to emit light in pattern 1.
For example, where 8 ports are being verified, and
where
a one represents "transmit light", the pattern of
light
emissions could be represented by the eight bit number
0xF0. LV-src then creates a test message, which
includes
the light emission status and local-interface-id for
every interface being tested.
>> So I have a question...
Can I do link verification without impacting existing
traffic?
>>>No the link must be idle. turning off the light source will
disrupt traffic.
I
don't suppose I can verify in-use links in this way, but what
if I want to do verification on those links that are
not
currently active? Can I do this?
I think the text below for "stuck" ports handles
this but we
should expose it explicitly.
Note discovery and verification are different in this
question.
LV-dst, on receipt of a
test message, records the status
of light for every port and if at least one port has
light it replies with a TestStatusSuccess message,
containing the the local Interface_ID for each port
that
>> typo "the
the"
>>>Fixed.
has light. Otherwise, it
sends a TestStatusFailure
message indicating that no light was seen on any
ports.
On receipt of a
TestStatusSuccess message, the LV-src
sends a TestStatusAck message and changes the light
emission to the next pattern and continues the
process.
When the LV-src has
completed its test patterns and
received the TestStatusSucccess messages for those
Test
Messages, it will send an EndVerify message to end the
process.
Using this mechanism, the
port connectivity can be
established through a series of interface
light-emission
patterns.
>> Should we handle the case
where the LV-Src believes it has collected
sufficient information to resolve the links but the LV-Dst
believes
it needs more information?
This would probably reflect an implementation issue at Src
or Dst,
but could be addressed in the EndVerify response allowing
the Dst
to refuse EndVerify and to request a specific
pattern.
>>>Interesting. If we added a feature like that I think we'd
have to add another mechanism, since an EndVerify is the LV-src has to
end the process. It might want to use that under several circumstances.
for example, if it was in the periodic re-verification of an idle port
and a request to set up an LSP came in.
>> Move example
out?
For an eight port
example, the pattern 0xF0,
0x0F, 0xCC, and 0xAA, would be sufficient to provide
the
mapping of eight ports to eight ports using only four
patterns. For a switch with 64 ports the bitmap would
have to be enlarged to eight bytes, and could use the
patterns 0xFFFFFFFF00000000, 0x00000000FFFFFFFF,
0xFFFF0000FFFF0000, 0xFF00FF00FF00FF00,
0xF0F0F0F0F0F0F0F0, 0xCCCCCCCCCCCCCCCC,
0xAAAAAAAAAAAAAAAA - performing the mapping using only
seven patterns.
[BIG SNIP]
3.2 LOL support for multiple
neighbors
A weakness in the LOL mechanism occurs when (a)
multiple
neighbors simultaneously use the mechanism to verify their
ports and (b) multiple links between a pair of nodes are
verified simultaneously. This section describes the first
weakness and an enhanced algorithm that can overcome
this
>> and the second weakness is
described where?
>>>Actually, both weaknesses are actually variations of the same
problem. I'll fix the text.
weakness. Note that any given
node may only be performing
LOL link verification with one neighbor at a time.
The
[SNIP]
4. LMP LOL Message
Definitions
4.1. Test Message (Msg Type =
10)
The LOL Test message is
transmitted over the control
channel and not the data link and is used to verify its
physical connectivity. This is transmitted in the standard
LMP UDP/IP packet with payload format as
follows:
<Test
Message> ::= <Common Header> <VERIFY_ID>
<MESSAGE_ID>
<LOL_TEST_STATUS>
4.2. TestStatusSuccess Message
(Msg Type = 11)
The TestStatusSuccess message is transmitted over the
control channel and is used to transmit the mapping
between the local Interface Id and the Interface Id
that
was received in the Test messageTest Message once the
exchange of Test and TestStatusSuccess messages is
complete.
<TestStatusSuccess
Message> ::= <Common Header>
<LOCAL_LINK_ID> <MESSAGE_ID> <VERIFY_ID>
<LOCAL_INTERFACE_ID1>
<LOCAL_INTERFACE_ID2>. . .
<LOCAL_INTERFACE_IDn>
>> Why two different
mechanisms?
If you put LOL_TEST_STATUS in this message you have
symmetry
and don't have to worry about ordering of the
LOCAL_INTERFACE_ID
objects.
>>>Actually, that would
be simpler. I don't recall exactly why they were different, perhaps to
make the message shorter. Simplicity seems a better choice.
The above transmission
order SHOULD be followed, but the
location of the VERIFY_ID in the message is
unimportant.
>> Surely the order of
LOCAL_INTERFACE_IDs is very important
>>>Yes, but I like the idea of using LO_TEST_STATUS.
Bradford et
al
[Page 10]
Internet Draft
draft-rbradfor-ccamp-lmp-lol-00.txt September
2002
5. LMP Object
Definitions
5.1. BEGIN_VERIFY Class
modifications.
Verify Transport
Mechanism: 16 bits
This
defines the transport mechanism for the Test
Messages. The scope of this bit mask is
restricted to
each link encoding type. The local node
will set the
bits corresponding to the various
mechanisms it can
support for transmitting LMP
test
0x100
LOL: Loss Of Light and out-of-band Test
messages
>> Why this choice of value?
LMP-07 only defines 0x8000
>>>It was based on
an earlier draft. 0x4000?
Capable of supporting link verification
through the Presence and Loss of Light. In
this case, the Test messageTest Messages are
exchanged over the same IP control channel as
standard LMP control messages. The Test
messageTest Messages identify the Data
Link(s) where Light is being emitted.
TestStatusSuccess messages identify the Data
Link(s) where Light has been detected.
>> The following paragraph is
duplicate information.
Just refer to section 4.1
The format of the Test message is as
follows:
<Test Message> ::= <Common Header>
<MESSAGE_ID> <VERIFY_ID>
<LOL_TEST_STATUS>
5.2. LOL_TEST_STATUS
Class
Class =
21
Bradford et
al
[Page 11]
Internet Draft
draft-rbradfor-ccamp-lmp-lol-00.txt September
2002
o IPv4, C-Type
= 1
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Interface Id (4
bytes)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
LOL
Status
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
:
|
//
:
//
|
:
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Interface Id (4
bytes)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
LOL
Status
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[SNIP]
LOL_Status: 32
bits
This indicates the status
condition of a data channel. The
following values are defined. All other values are
reserved.
1 Signal Okay (OK):
Interface Sent or Detected Light
2 Signal Inconsistent: The Interface did
sometimes
detected light, sometimes did
not
This Object contains one or more Interface Ids followed by an
LOL_Status field.
>> Given that so few values are
defined and that they are used as
counting integers not flags can we reduce the size of the
field
and have some reserved bits?
I suggest that we don't need more than one byte for
LOL_status.
Two if you are *really*
pessimistic.
>>>Good Idea.8 bits is plenty.
Bradford et
al
[Page 13]
Internet Draft
draft-rbradfor-ccamp-lmp-lol-00.txt September
2002
6.
Acknowledgments
7.
References
>> Need to split into Normative
and Informational references
>>>done
[SNIP]