Internet Draft draft-rbradfor-ccamp-lmp-lol-01.txt April 2003
CCAMP Working Group Richard Bradford
Internet Draft Dimitri Papadimitriou
Expires: April 2003 Dan Tappan
Link Management Protocol Extensions for Link discovery Using Loss of
Light
draft-rbradfor-ccamp-lmp-lol-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document proposes an enhanced mechanism for Link Management
ProtocolÆs Link Verification procedure that is independent of the
data encoding type. It can be used for any point-to-point link,
including both Optical Links and SONET/SDH Links. 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 of 1]
Internet Draft draft-rbradfor-ccamp-lmp-lol.txt April 2003
1. Introduction
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 and link verification between 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 or absence of received light
on those interfaces, a capability that is simpler, does not require
optical/electrical conversion, 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.
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. 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.
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, 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.
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
Bradford et al [Page 2 of 2]
Internet Draft draft-rbradfor-ccamp-lmp-lol.txt April 2003
dependent, the ability to losslessly add this capability could
present a roadblock to support for link verification.
Third, a transparent OXC would need to add one or more
termination modules and could lose the switching capacity required
for those termination modules (e.g. a 16x16 port fabric might need
to have at least one of those ports connected to the link
termination module, preventing its connection to an external
interface).
Fourth, is the problem of supporting the "right" set of
termination capabilities. For example, an electrically 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 OC48 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
In addition to the above, many of the 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).
The solution proposed in this document limits the excessive link
termination costs, both in terms of added hardware and the
potentially increased optical loss to support that hardware. It
also provides a mechanism that scales much better for large numbers
of interconnects.
2. Terminology
This document uses terminology from the MPLS architecture
document [MPLSArch] and the LMP Draft [LMP].
Pattern: 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.
Bradford et al [Page 3 of 3]
Internet Draft draft-rbradfor-ccamp-lmp-lol.txt April 2003
3. Proposed Solution Overview
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. The LV-Src may set some of its ports to
transmit light and others to not transmit light.
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.
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 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
Bradford et al [Page 4 of 4]
Internet Draft draft-rbradfor-ccamp-lmp-lol.txt April 2003
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)). Note
that this is an example and the behavior is entirely
an implementation matter for the LV-Src.
4. Link Verification Extensions.
The following extensions are needed to support this method of
Link Verification:
4.1 LOL support for multiple neighbors
A weakness in the LOL mechanism occurs when multiple neighbors
simultaneously use the mechanism to verify their ports. This section
describes the weakness and an enhanced algorithm that can overcome
this weakness. Note that any given node may only be performing LOL
link verification with one neighbor at a time. The weakness is
uncovered when a node has several neighbors as shown in Figure 1.
+--------+ +--------+
| Node A |--A1------B1-| Node B |
| |--A2------B2-| |
| |--A3------B3-| |
| |-A4 B4-| |
+--------+ \ / +--------+
\ /
\ /
\ /
\ /
X
/ \
/ \
/ \
/ \
+--------+ / \ +--------+
| |-C4 D4-| |
| Node C |-C3-------D3-| Node D |
| |-C2-------D2-| |
| |-C1-------D1-| |
+--------+ +--------+
Bradford et al [Page 5 of 5]
Internet Draft draft-rbradfor-ccamp-lmp-lol.txt April 2003
|Figure 1, Simultaneous use of LOL
In the above example, the weakness occurs when Node A initiates LOL
Link Verification at the same time as Node C initiates LOL Link
Verification to Node D. LetÆs focus on what Node D sees. It gets a
message from Node C saying the light pattern is 0x0F (this is also
what Node A sends Node C). It appears that D4 matches the light
pattern sent by node C for port C4. In fact, it Node A and C march
through the same algorithm, it is possible the Node D will see all
the correct patterns on port D4 to suggest that it is connected to
Node C port C4. This is incorrect. As unlikely as this type of
synchronization is, it is possible, especially when a large number
of nodes restart simultaneously, as happens following a power
outage.
There are several ways to address this weakness.
First, each source node could randomly choose the sequence of
patterns it sends as it executes the LOL procedure. This makes it
very unlikely that two pairs of nodes would synchronize in this way.
Second, each source node could create a series of random patterns
and send those following the basic LOL link verification. For
example, Node A would randomly choose to send 0x23, 0x97 and then
0x1F while Node B would randomly choose to send 0x49, 0x17, and
0x77. This quickly reduces the likelihood of accidental overlap to a
vanishingly small probability.
Finally, if even the remote possibility of a random number
overlap is desired, then the source node could send its node ID as a
light pattern. For a typical 32-bit node ID, this would add an
additional 32 pairs of message exchanges, but would eliminate
accidental overlap.
The LV-src MAY implement such an algorithm.
Note that the sequence and choice of bit patterns by the LV-src
does not affect require any changes to the LOL procedure. The LOL
procedure allows the LV-src to send a long or short sequence of LOL
patterns.
5. LMP LOL Message Definitions
5.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>
Bradford et al [Page 6 of 6]
Internet Draft draft-rbradfor-ccamp-lmp-lol.txt April 2003
5.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
Message once the exchange of Test and TestStatusSuccess messages
is complete.
<TestStatusSuccess Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <VERIFY_ID> <LOL_TEST_STATUS>
The above transmission order SHOULD be followed, but the location
of the VERIFY_ID in the message is unimportant.
6. LMP Object Definitions
6.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
0x4000 LOL: Loss Of Light and out-of-band Test messages
Capable of supporting link verification through the
Presence and Loss of Light. In this case, the Test
Messages are exchanged over the same IP control
channel as standard LMP control messages. The Test
Messages identify the Data Link(s) where Light is
being emitted. TestStatusSuccess messages identify
the Data Link(s) where Light has been detected.
6.2. LOL_TEST_STATUS Class
Class = 21
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) |
Bradford et al [Page 7 of 7]
Internet Draft draft-rbradfor-ccamp-lmp-lol.txt April 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOL Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOL Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o IPv6, C-Type = 2
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 (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOL Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOL Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Unnumbered, C-Type = 3
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bradford et al [Page 8 of 8]
Internet Draft draft-rbradfor-ccamp-lmp-lol.txt April 2003
| LOL Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LOL_Status: 8 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.
7. 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.
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 local Interface_ID
for each port that 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. 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,
Bradford et al [Page 9 of 9]
Internet Draft draft-rbradfor-ccamp-lmp-lol.txt April 2003
0xCCCCCCCCCCCCCCCC, 0xAAAAAAAAAAAAAAAA - performing the mapping
using only seven patterns.
In order to quickly eliminate ports that cannot possibly be
involved in the exchange, the LV-Src first activates light on
half the ports and then activates light on the other half of the
ports (patterns 0xF0 and 0X0F). This quickly eliminates ports
which remain lit, remain dark, and any which cannot possible be
connected because the light patterns did not match. This will
help reduce the size of the test messages.
Here is a walkthrough of the case where we will focus on LV-src
interface 1 (LV-src.1) is connected to LV-dst interface 4,
LVdst.4):
1. At the start of LV-LOL, LV-dst.4Æs connectivity is unknown.
LV-src has eight interfaces, so it assumes that LV-dst
could have interfaces connected to any of its interfaces.
LV-src sets interfaces 1-4 off, and interfaces 5-8 on
sending pattern 0xF0 in the Test Message.
2. On receipt of the first test message, LV-dst notes that it
sees no light on LV-dst.4., LV-dst eliminates interfaces 5-
8. LV-dst sends a TestStatusSuccess indicating that it sees
no light on LV-dst.4.
3. Next LV-src sends light in a pattern 0x0F, which means LV-
src.1 will be lit. The Test Message contains pattern 0x0F.
4. LV-dst sees light on LV-dst.4. This leaves LV-dst with
remote interfaces 1,2,3,4 as possible matches, since they
were transmitting light. LV-dst sends a TestStatusSuccess
indicating light on LV-dst.4.
5. Next LV-src sends light in the pattern 0xCC and sends the
pattern in a Test Message.
6. LV-dst sees no light on LV-dst.4, leaving possible remote
interfaces 1,2. LV-dst sends a TestStatusSuccess indicating
no light on LV-dst.4.
7. LV-src sends light in the pattern 0xAA and includes the
pattern in a Test Message.
8. LV-dst sees no light on LV-dst.4, leaving only one possible
remote interface, LV-src.1. LV-dst sends TestStatusSuccess
indicating light on LV-dst.4. Next LV-src sends an empty
Test Message indicating itÆs done. LV-dst sends a
TestStatusSuccess indicating that local LV-dst.4 is
connected to remote LV-src.1, along with any other ports
whose mapping it was able to determine in parallel.
The LOL Test Message includes a Message-ID. Since each Test
Message must be acked and either the Test Message or
TestStatusSuccess message could be lost or delayed, each Test
Message will include a Message ID that must be returned in the
Bradford et al [Page 10 of 10]
Internet Draft draft-rbradfor-ccamp-lmp-lol.txt April 2003
TestStatusSuccess Message. This will allow the LV-Src to
correlate the TestStatusSuccess Message with the state of light
emissions. Before receiving the TestStatusSuccess, the LV-Src
must not alter the state of light emissions on the interfaces,
i.e. it must keep the interface emitting or not emitting light
until the LV-Dst has responded. If the TestStatusSuccess message
is not received within a specified time, the Test Message should
be retransmitted, incrementing the MessageID. TestStatusSuccess
Messages with stale MessageIDs must be discarded.
For this walkthrough, LV-src has eight ports. LV-dst has 4 ports.
LV-dst ports 1,2, and 3 are not connected to LV-src, so they will
not see light change. LetÆs assume that LV-dst ports 1 and 2
always see light during the test and port 3 never sees light.
Here is what the procedure would show:
LV-Src LV-Dst
BeginVerify(LOL)---------------->
<------------------------BeginVerifyAck(LOL)
Test(Pattern = 0xF0)---------------->
<------------------------
TestStatusSuccess(LVdst.1=on,2=on,3=off,4=Off)
Test(Pattern = 0x0F)---------------->
<------------------------TestStatusSuccess(LVdst4=On)
(Note - - LVdst.1,2, and 3 were eliminated from consideration
because they did not change status)
Test(Pattern = 0xCC)---------------->
<------------------------TestStatusSuccess(LVdst.4=Off)
Test(Pattern = 0xAA)---------------->
<------------------------TestStatusSuccess(LVdst.4=Off)
Test(Done)---------------->
<------------------------TestStatusAck(LVdst.4==LVsrc.1)
EndVerify---------------->
<------------------------EndVerifyAck
Bradford et al [Page 11 of 11]
Internet Draft draft-rbradfor-ccamp-lmp-lol.txt April 2003
8. Acknowledgments
We wish to thank xxx for their comments on this draft.
9. References
9.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -
Revision 3," BCP 9, RFC 2026, October 1996.
[LMP] Lang, J., et al, "Link Management Protocol (LMP)",
draft-ietf-ccamp-lmp-06.txt, September, 2002
[LMP-DWDM] Fredette, A., Lang, J. P., editors, Link Management
Protocol (LMP) for WDM Transmission Systems,
Internet Draft, draft-fredette-lmp-wdm-03.txt,
(work in progress), November 2001.
[LSP-HIER] Kompella, K. and Rekhter, Y., LSP Hierarchy with
MPLS TE, Internet Draft, draft-ietf-mpls-lsp-
hierarchy-02.txt, (work in progress), February
2001.
9.2. Informative References
10. Applicability
The LOL-LV procedure provides an alternate mechanism that has
tradeoffs relative to the existing LMP LV procedure and it is up
to the implementation to decide when to use each. While LOL will
often more quickly determine that two interfaces are connected,
it provides no determination that the interfaces are compatible.
In this regard, it is able to provide a determination of improper
interface connectivity that is not possible with the standard
algorithm. For example, if a Gigabit Ethernet Interface on one
node is connected to an OC-48 interface on another node, then the
standard LV procedure will never attempt to verify the
connectivity of the two ports, since their transport mechanisms
are incompatible. The LOL procedure can be used to discover this
connectivity. It is beyond the scope of this document to specify
how such connectivity should be brought to the users attention.
11. Authors' Addresses
Richard Bradford
Cisco Systems, Inc.
300 Apollo Drive
Chelmsford, MA 01824
Phone: +1-978-497-3079
Email: rbradfor@cisco.com
Bradford et al [Page 12 of 12]
Internet Draft draft-rbradfor-ccamp-lmp-lol.txt April 2003
Dimitri Papadimitriou
Alcatel
Francis Wellesplein 1
B-2018 Antwerpen, Belgium
Email: dimitri.Papadimitriou@alcatel.be
Dan Tappan
Cisco Systems, Inc.
300 Apollo Drive
Chelmsford, MA 01824
Phone: +1-978-497-8136
Email: tappan@cisco.com
12. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to
the Internet Society or other Internet organizations, except as
needed for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate
it into languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
13. Intellectual Property Considerations
Cisco Systems may seek patent or other intellectual property
protection for some of all of the technologies disclosed in this
document. If any standards arising from this document are or
become protected by one or more patents assigned to Cisco
Systems, Cisco intends to disclose those patents and license them
on reasonable and non-discriminatory terms.
Bradford et al [Page 13 of 13]