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: ::= 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. ::= 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]