[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on draft-rbradfor-ccamp-lmp-lol-00.txt
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
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
verification that is independent of
the data encoding
>> need to say that this is for use in
verifying optical 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
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
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
interfaces, a capability that is
simpler, does not
require optical/electrical conversion cheaper,
and is
>> add ", is"
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
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?
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?
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"
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" :-)
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
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"
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
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
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.
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'.
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"? :-)
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?
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?
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"
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.
>> 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?
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.
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
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
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.
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
[SNIP]