Network Working Group Roger Lapuh Dinesh Mohan Internet Draft: draft-lapuh-network-smlt-06.txt Richard Mcgovern Category: Informational Nortel Expiration Date: July 2006 January 2006 Split Multi-link Trunking (SMLT) Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract This document describes Split Multi-link Trunking (SMLT) for bridged and routed networks. SMLT enables topologies with upstream node redundancy for increased reliability of Layer 2 link aggregation subnetworks based on [IEEE 802.3ad] and router redundancy based on VRRP [RFC 2338]. Lapuh, et. al Informational [Page 1] Internet Draft draft-lapuh-network-smlt-06.txt January 2006 SMLT is an improvement over Multi-Link Trunking (MLT), a method of link aggregation that allows multiple Ethernet links to be aggregated together, and handled as a single logical trunk. MLT can be realized via many different link aggregation mechanisms. Several methods of MLT are in use today; one example is [IEEE 802.3ad]. SMLT is MLT with links of a link-aggregation group connected to ports on two different devices (e.g. SMLT client and aggregation device). Unlike MLT, at least one end of a link-aggregated group is dual-homed to two different SMLT aggregation devices. In many cases those devices act as bridges (switches) as well as L3 routers (Routing Switches). These two redundant SMLT aggregation devices can share one or more VRRP routing instances; for that SMLT-VRRP extends the VRRP functionality to an active-active router concept, where both SMLT aggregation device route traffic for a common VRRP-ID, thus load balancing traffic not only for L2 but also for L3. Table of Contents: Status of this Memo................................................1 Copyright Notice...................................................1 Abstract...........................................................1 1. Introduction....................................................3 1.1 Rationale for SMLT.............................................3 2. Definitions.....................................................4 3. SMLT Operation..................................................5 3.1 IST Protocol...................................................7 3.2 SMLT and VRRP active-active....................................8 4. Problems Solved.................................................8 4.1 Layer-2 Traffic Load Sharing...................................9 4.2 Layer-3 Traffic Load Sharing...................................9 4.3 SMLT Configuration Protection in Core of the Network...........9 4.4 No single point of failure....................................11 5. Failure Scenarios..............................................11 5.1 Loss of a SMLT Link...........................................11 5.2 Loss of an SMLT aggregation device............................11 5.3 Loss of IST Link..............................................11 5.4 Loss of All IST Links between an SMLT aggregation device Pair.12 6. SMLT In Relation To Other OSI Reference Model Layers...........12 7. Security Considerations........................................13 8. Intellectual Property Considerations...........................13 9. Normative References...........................................14 10. Acknowledgments...............................................14 11. Authors' Addresses............................................14 IPR Notice........................................................15 Full Copyright Statement..........................................15 Lapuh, et. al Informational [Page 2] Internet Draft draft-lapuh-network-smlt-06.txt January 2006 1. Introduction When building redundant networks, Multi-Link Trunking (MLT) offers link redundancy as a protective measure against link failures. Multi-Link Trunking is a means of providing physical layer protection against the failure of a single link, while enabling the use of the bandwidth of all aggregated links (within MLT) in normal conditions. Split Multi-Link Trunking (SMLT) is a means of providing an additional level of protection against failures. SMLT enables node redundancy by allowing MLT links of link-aggregated groups to be dual-homed across a pair of aggregating devices, herein referred to as a pair of SMLT aggregation devices. Dual-homing can create looped topologies within subnetworks. To avoid traffic looping in Layer 2 subnetworks, Spanning Tree Protocol [IEEE 802.1D/w] acts to logically block redundant network paths to a given traffic flow. In SMLT networks, dual-homing is not a problem, because loops in subnetwork topologies are logically blocked. SMLT may be introduced into existing subnetworks to provide node redundancy without upgrading already installed equipment. SMLT improves network bandwidth availability and network resiliency by allowing all aggregation paths in a dual-homed configuration to be active and forwarding traffic simultaneously as well as providing very fast traffic fail-over in the event of a link failure. An SMLT aggregation device pair uses an Inter-Switch Trunk (IST) between them to exchange information, so as to appear as a single logical path aggregation end point to dual-homed devices. IST signaling also protects against single points of failure (e.g. link outages and single node failures) by detecting and modifying information about forwarding data paths in sub-second intervals. 1.1 Rationale for SMLT Redundancy in mission-critical network topologies is normally achieved by engineering multiple paths in order to eliminate all single points of failure. In addition to ensuring that there is no permanent loss of connectivity because of a single failure, the goal is recovery from most failures in the sub-second range. Ideally, because unused capacity is expensive, any additional paths introduced to achieve redundancy should also be available to carry traffic during normal conditions. SMLT is simple to implement and can be introduced transparently into existing networks. It is interoperable with the majority of existing wiring closet/CPE/edge devices, and provides for both link and node Lapuh, et. al Informational [Page 3] Internet Draft draft-lapuh-network-smlt-06.txt January 2006 redundancy. SMLT supports utilization of link bandwidth across all of the aggregated links of multi-link trunks. 2. Definitions Before describing SMLT in detail it is necessary to define the following terms: SMLT aggregation device: An SMLT aggregation device is a device that provides connectivity to one or more "SMLT Clients" (see below for definition), and is connected in a peering manner with at least one other SMLT aggregation device using an Inter-Switch Trunk (IST). SMLT aggregation devices are often utilized for enterprise networking, but have applications in service provider networks as well. As such they may be owned by an enterprise, or by a service provider. SMLT Client: An SMLT client is a device (e.g. bridge, host, server) that is typically connected to one or more Local Area Networks (LANs), and is itself directly connected to one or more SMLT aggregation devices. Note: An "SMLT client" is a literary construct for the purposes of describing the operation of SMLT in this document. In practice, this does not require the implementation of any SMLT functionality in a device described as an SMLT client herein. An example of a typical SMLT client is a link aggregating device which implements MLT or IEEE 802.3ad link aggregation. SMLT Link: The connection between an SMLT aggregation device and an SMLT client is an SMLT link. IST (Inter-Switch Trunk): An IST is an aggregated point-to-point link that connects two SMLT aggregation devices to each other. An IST is used by two SMLT aggregation devices to exchange status and control information with each other, so as "look" like (i.e. to appear to operate like) a single device to any SMLT client. This enables the introduction of SMLT into existing networks without requiring upgrades to equipment already deployed. MLT (Multi-Link Trunking): MLT is a method of link aggregation that allows multiple Ethernet links to be aggregated together, and handled as a single logical trunk. MLT provides physical layer protection against the failure of any single link and enables the full use of the combined bandwidth of the multiple links in non-failure mode conditions. MLT can be realized via many different link aggregation mechanisms. Several methods of MLT are in use today; one example is [IEEE 802.3ad]. SMLT (Split Multi-Link Trunking): SMLT is MLT with each link of a link-aggregation group connecting a pair of ports on two different Lapuh, et. al Informational [Page 4] Internet Draft draft-lapuh-network-smlt-06.txt January 2006 devices (e.g. SMLT client and SMLT Aggregation device). Unlike MLT, at least one end of a link-aggregated group is dual-homed to two different SMLT aggregation devices. 3. SMLT Operation Figure 1 illustrates a reference network configuration for SMLT. The topology consists of the following elements: . Two peered SMLT aggregation devices, namely E and F . Four LAN bridges (A, B, C, D) which are SMLT clients because they home into one or both of the SMLT aggregation devices . Eight end stations: a1, b1, b2, c1, c2, d1 (all hosts), and e1 and f1 (which may be hosts, servers or routers) +-----+ +-----+ e1 -----| E |====| F |------- f1 /+-----+ +-----+ / / || \ // | \ / / || \// | \ / / || /\ | \ / / || // \ | \ / / || // \ | \ / / || // \ | \ 2/ / 2||//2 1\|1 \1 +---+/ +---+ +---+ +---+ | A | | B | | C | | D | +---+ +---+ +---+ +---+ | | | | | | | | | | | | a1 b1 b2 c1 c2 d1 Figure 2: Reference Network for SMLT SMLT clients B and C use dual-homing to connect to both of the SMLT aggregation devices. B uses a link-aggregated group containing four links; two of them connect B to E, and the other two connect B to F. C uses a smaller link-aggregated group with two links; one link connects C to E, and the other connects C to F. SMLT client A also uses link-aggregation, but not for dual-homing. It has a link-aggregation group with two links, and both links are used to connect A to E. SMLT client D is single-homed and uses one link to connect with F. Lapuh, et. al Informational [Page 5] Internet Draft draft-lapuh-network-smlt-06.txt January 2006 In figure 2, SMLT clients A and D do not benefit from the added reliability that SMLT provides for dual-homed SMLT clients. Conversely, A and D are not disadvantaged either, as they are not required to implement any new functionality to participate in this SMLT network. Dual-homed SMLT clients B and C also do not require any new functionality to be networked using SMLT. SMLT intelligence and functionality is implemented entirely within the SMLT aggregation devices. The behavior of the paired SMLT aggregation devices (E and F) appears identical to the behavior of a single path aggregation bridge from the perspective of B and C. The SMLT aggregation devices (E and F) are interconnected using an Inter-Switch Trunk (IST). The IST is engineered to be reliable and not be a single point of failure. An IST has three functions: . To enable E and F to exchange status information about each other, and to share learned MAC address information. . To forward flooded packets, packets destined for non-SMLT connected subnetworks, and packets destined to end stations reachable via the other SMLT aggregation device (e.g. traffic from e1 destined for d1). . To forward traffic to/from dual-homed SMLT clients during failure conditions (e.g. traffic from a1 to b1 during a failure of the direct connection from E to B). SMLT clients B and C can use different methods to assign traffic to the links within their MLTs as long as the choice of link remains fixed for a given flow. This ensures that all traffic is delivered in-sequence between any pair of communicating end stations. SMLT aggregation devices normally send traffic directly to an SMLT client, and uses IST bandwidth only for traffic that cannot be forwarded using a direct link. The examples below explain this in more detail. SMLT client A is single-homed to SMLT aggregation device E. All traffic from a1 destined for any other end station must flow through E. For example, to reach b1 and/or b2 traffic flows from a1 to A and then to E. E forwards the traffic directly to B, to reach b1 and/or b2. Traffic in the reverse direction (i.e. from b1 or b2 destined for a1) flows from B to E, and then to A for delivery to a1. Traffic from b1 or b2 destined for c1 or c2 is always forwarded by B over one of its dual-homed MLT paths to either E or F. No matter which of E or F receives incoming traffic from B, the traffic is directly forwarded to C without traversing an IST. This aspect of SMLT operation tends to minimize traffic flows across ISTs. It also means that a single IST failure (in scenarios where there is only Lapuh, et. al Informational [Page 6] Internet Draft draft-lapuh-network-smlt-06.txt January 2006 one IST) will not cause a traffic interruption for dual-homed SMLT clients. Traffic from a1 to d1 and vice-versa is forwarded across an IST because it is the shortest path between E and F. For this type of traffic, an IST emulates an MLT link (with no account taken of SMLT) as far as A and D are concerned. Traffic from f1 to c1/c2 is sent directly via F to C. Return traffic from c1/c2 to f1 may traverse an IST if C sends it to E rather than to F. 3.1 IST Protocol An IST connecting two SMLT aggregation devices in figure 2 runs a protocol that allows the messages to be exchanged between E and F as follows: . IST Hello E and F periodically transmit and receive IST Hello messages on IST ports. (IST ports are ports used for ISTs.) IST Hello messages accomplish the following: - They distinguish ISTs from MLTs. Any port sending IST Hello messages is an IST port. - They verify continuity and communication across ISTs. Under normal conditions, every port sending IST Hello messages should expect to receive incoming IST Hello messages from the other end. - They help to identify abnormal conditions, by establishing a normal time interval between incoming IST Hello messages. . SMLT Status E and F exchange SMLT status information with each other about SMLT client links as follows: - SMLT ID: This is a provisioned value used by E and F to uniquely identify links to the same SMLT client. - SMLT Status: This can be either "in-service," meaning that the SMLT client is reachable (i.e., one or more of the SMLT links to that SMLT client are operating); or "out-of-service," indicating that the SMLT client is not reachable. (All links between the SMLT aggregation device reporting this status and the SMLT client are not operating.) . Learned or Migrated MAC Addresses Whenever E or F learns a new MAC address on any of its ports, it shares this information with its peer. The learned MAC address value and the port type of the port at which the address was learned is communicated across an IST. When the address is learned against an SMLT client port, SMLT ID is also passed. . MAC Address Aged Out When the age expires for a MAC address learned against a non-SMLT port, the SMLT aggregation device deletes the MAC address record and Lapuh, et. al Informational [Page 7] Internet Draft draft-lapuh-network-smlt-06.txt January 2006 sends a message to inform its peer of this action, and to trigger the deletion of that Mac address from the address table of other SMLT aggregation device. . SMLT Address Aged Out When the age expires for a MAC address learned against an SMLT port, the SMLT aggregation device does not delete the MAC address record. It marks the address as having expired locally, and sends a message with this information to its peer. When the peer SMLT aggregation device receives this message, it marks the address as having expired remotely, takes no further action until its own MAC address record expires locally. . Local Bridge ID This message is sent by an SMLT aggregation device to notify its peer of the value of its own Bridge Identifier. This permits each of E and F to compare their own ID with the others, and to decide which is the Root Bridge, as well as the values of BPDU parameters used in SMLT. 3.2 SMLT and VRRP active-active In many cases, SMLT aggregation devices are Layer-3 routing switches and perform the default gateway functionality for the hosts which are part of the attached IP subnets. The SMLT aggregation device pair can therefore share their default gateway routing functionality with the VRRP protocol [RFC 2338]. The VRRP active-standby operation can be optimized to an active-active concept due to the following reason: . Traffic flowing from an SMLT client to an SMLT aggregation device is always carried on one of the available links of MLT and ends up at exactly one of the SMLT aggregation devices. For that reason both SMLT aggregation switches can be enabled as routers for IP traffic designed to the VRRP destination MAC address. Both SMLT aggregation devices must be full members of the routing domain and have routing entries which allow them to reach the IP destination networks. The active-active functionality is achieved without changing any VRRP state machine, but activating the routing function in the forwarding plane of the VRRP backup system (similar to the VRRP master). The above operation allows traffic forwarding in Layer-2 and Layer-3 to be fully redundant, leveraging all available link bandwidth. All routers forward traffic and thus load share routed traffic. 4. Problems Solved Lapuh, et. al Informational [Page 8] Internet Draft draft-lapuh-network-smlt-06.txt January 2006 4.1 Layer-2 Traffic Load Sharing Load sharing from the SMLT client perspective is achieved by the MLT path selection algorithm used on the edge SMLT client switch. Usually this path selection is done on a SRC/DST MAC address basis, but other techniques can be used. Load sharing from the SMLT aggregation device perspective is achieved by sending all traffic destined to an SMLT client directly across available links and not over the IST trunk. The IST trunk is normally not used to send/receive traffic to/from an SMLT dual-homed SMLT client. Traffic received on the IST by an SMLT aggregation device is not forwarded on SMLT because the other SMLT aggregation device will have forwarded the traffic, thus eliminating the possibility of a loop in the network. The only exception to this rule is if the SMLT links on the peer aggregation device are down, then traffic received over IST will be forwarded to the corresponding SMLT client. 4.2 Layer-3 Traffic Load Sharing With the SMLT VRRP active-active concept, the router redundancy operation allows forwarding of routed traffic simultaneously on both SMLT aggregation devices, thus doubling the router forwarding capacity. It also decreases Layer-3 failover time since the VRRP standby router already forwards traffic and does not wait for the VRRP-hello message from the VRRP master device to expire. 4.3 SMLT Configuration Protection in Core of the Network SMLT is not limited to use in triangle topologies as shown in figure 2. Several combinations of SMLT designs are feasible, including: . Bridge using link aggregation dual-homed to an SMLT aggregation device pair (i.e. an SMLT triangle); . SMLT aggregation device pair multi-homed to a different SMLT aggregation device pair, allowing up to four bridges to form a combined aggregation group SMLT (i.e. an SMLT square). SMLT can also be used within the core of a network. SMLT groups can be configured in a square or full mesh scenario. The following illustration depicts an SMLT square with two SMLT aggregation device pairs (E/F and G/H) facing each other. Lapuh, et. al Informational [Page 9] Internet Draft draft-lapuh-network-smlt-06.txt January 2006 +-----+ +-----+ | E |====| F | +-----+ +-----+ || | || | || | || | || | || | || | +---+ +---+ | G |======| H | +---+ +---+ The following illustration depicts an SMLT full mesh with two SMLT aggregation device pairs facing each other. +-----+ +-----+ | E |====| F | +-----+ +-----+ || \ / | || \/ | || /\ | || / \ | || / \ | || / \ | ||/ \| +---+ +---+ | G |======| H | +---+ +---+ These configurations are possible because no state information is passed across MLT links, so that both devices terminating a MLT believe that the other end is a single bridge. The result is no logical looping in this network topology. Any of E, F, G, or H or any of the connecting links between them can fail and the surviving elements of this network continue to forward traffic without interruption. It is also possible to scale SMLT groups to achieve hierarchical network designs by connecting SMLT groups together. This allows building redundant loop-free L2 domains without an additional protocol while still fully using all network links. Lapuh, et. al Informational [Page 10] Internet Draft draft-lapuh-network-smlt-06.txt January 2006 4.4 No single point of failure Any single link or any SMLT aggregation device can fail and recovery will take place in less than 1 second. Note that this number is conservative depending on the implementation and link loss detection mechanisms. See the analysis in section 5 for further details. 5. Failure Scenarios 5.1 Loss of a SMLT Link When an SMLT client detects a link failure, it sends traffic on other SMLT link(s) per the normal algorithms of MLT. Detection and fail-over depends on the speed at which the SMLT client device detects link failures. If the link is not the only one between the SMLT client and an SMLT aggregation device, then the SMLT aggregation device uses standard MLT detection and re-routing to move traffic to the remaining links. If the failed link is the only one to an SMLT aggregation device, then on failure detection the SMLT aggregation device informs the other SMLT aggregation device of the SMLT link failure. The other SMLT aggregation device then treats the SMLT link as a regular MLT trunk. When the link is re-established, both SMLT aggregation devices detect this, and put the recovered link back into regular SMLT operation. 5.2 Loss of an SMLT aggregation device The SMLT client switch detects link failure and sends traffic on the other SMLT link(s) just as with standard MLT. The surviving SMLT aggregation device detects the loss of its peer (via IST events such as "link down" or "IST Hello timeout") and treats all SMLT trunks as regular MLT trunks. When the peer SMLT aggregation device returns to service, the operational SMLT aggregation device detects this (by virtue of the IST becoming active) and then restores all trunks to regular SMLT operation. 5.3 Loss of IST Link The SMLT clients do not detect or notice the failure on an IST, so they continue to operate as usual. In normal use, there is more than one link in an IST; an IST is typically an aggregated link itself. Upon the failure of one IST link, traffic flows over the remaining links in the IST. Lapuh, et. al Informational [Page 11] Internet Draft draft-lapuh-network-smlt-06.txt January 2006 5.4 Loss of All IST Links between an SMLT aggregation device Pair In the event that all links in an IST fail, the SMLT aggregation devices do not see each other (IST keep alive is lost) and both assume that their peer is dead. However, for the most part there are no ill effects in the network if all SMLT clients are dual-homed to the SMLT aggregation devices. 6. SMLT In Relation To Other OSI Reference Model Layers SMLT fits into the datalink layer as it is described in the OSI reference model. The datalink layer is above the physical layer and below the network layer. [IEEE 802.3] defines in the datalink layer the MAC layer below the optional MAC control layer which is again below the optional link aggregation sublayer. The MAC client is on top of this forming the interface to the higher layers such as bridge relay entities for [IEEE 802.1w] Rapid Spanning Tree and similar protocols. SMLT is now an optional additional sublayer that is above the link aggregation sublayer and below the MAC client. +-----------------------------+ | MAC client | +-----------------------------+ +-----------------------------+ | SMLT (optional) | +-----------------------------+ +-----------------------------+ | link aggreg. sublayer (opt) | +-----------------------------+ +-----------------------------+ | MAC control (optional) | +-----------------------------+ +-----------------------------+ | MAC | +-----------------------------+ IEEE protocols such as the [IEEE 802.1w] Rapid Spanning Tree Protocol (RSTP) operate on top of the MAC client. SMLT is transparent to such protocols. Lapuh, et. al Informational [Page 12] Internet Draft draft-lapuh-network-smlt-06.txt January 2006 Link failures will not trigger any STP re-convergence because the logical link remains intact as long as one SMLT link out of a group is active. SMLT as an underlying path aggregation architecture underneath a RSTP design has following advantages: . SMLT does not have any blocking links. Therefore all configured bandwidth is available for traffic forwarding. . IST protocol of SMLT is used only on a set of two devices, the aggregation pair. The protocol, therefore, does not have any inherent delays because the two are directly connected. . SMLT convergence targets are sub-second in every failure scenario. There is no root bridge election and therefore long re-election processes are not an issue. In IEEE 802.1D (Spanning Tree) network status changes such as "link down" events are propagated throughout the network using a message called Topology Change Notification (TCN). Through these messages all members of the Spanning Tree network are made aware of the topology change and all bridges begin reducing to a low value their aging timers for the learned MAC port relationships in order to ensure network convergence within a reasonable time window. Whenever MAC address caches are cleared, packet flooding occurs as part of the re-learning process. SMLT link failures do not trigger Spanning Tree to generate network- wide TCN packets as long as one logical link out of an SMLT group is still active. Therefore flooding due to aging timer changes is limited to an SMLT aggregation device pair. 7. Security Considerations This document does not introduce any new security issues. From a customer point of view, the SMLT looks the same as [IEEE 802.3ad] link aggregation. From the service provider point of view, no security issues are expected, since the IST communication occurs between aggregation devices located inside the same autonomous service provider network. When the two aggregation devices are located in two different autonomous networks, there may be some security issues, e.g. sharing of bridging information. However, it is not expected that the aggregation devices will be deployed in two SP networks. 8. Intellectual Property Considerations Nortel Networks may pursue, or is pursuing, patent protection on technology described in this document. If this document becomes, in Lapuh, et. al Informational [Page 13] Internet Draft draft-lapuh-network-smlt-06.txt January 2006 part or whole, an IETF Standard, and if such patented technology is essential for practice of an IETF Standard incorporating in whole or part this document, Nortel Networks is willing to make available nonexclusive licenses on fair, reasonable, and non-discriminatory terms and conditions, to such patent rights it owns, solely to the extent such technology is essential to practice with such IETF standard. Also, in the event that a Nortel Networks patent is subsequently identified as essential to an IETF Standard incorporating in whole or part this document, Nortel Networks is willing to make available a nonexclusive license under such patent(s), on fair, reasonable, and non-discriminatory terms and conditions. The terms apply to those patents for which Nortel Networks has the right to grant licenses. 9. Normative References [802.1Q] "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", IEEE Std 802.1Q-1998. [802.1w] "IEEE Standard for Local and metropolitan area networks. Common specifications Part 3: Media Access Control (MAC) Bridges. Amendment 2: Rapid Reconfiguration", IEEE Std 802.1w-2001. [802.1D] "Information technology. Telecommunications and information exchange between systems. Local and metropolitan area networks. Common specifications. Part 3: Media Access Control (MAC) Bridges", ANSI/IEEE Std 802.1D-1998. [802.3] "IEEE Standard for Information technology. Telecommunications and information exchange between systems. Local and metropolitan area networks Specific requirements. Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE Std 802.3-2002. [RFC 2338] "Virtual Router Redundancy Protocol", IETF Standard, April 1998. 10. Acknowledgments The authors would like to thank Joe Regan, David Head, Wassim Tawbi, Vasant Sahay, Yili Zhao and Ed Juskevicius for their contributions and furthering the content of SMLT. 11. Authors' Addresses Roger Lapuh Nortel Wilstrasse 11 Building U95 Switzerland 8610 Lapuh, et. al Informational [Page 14] Internet Draft draft-lapuh-network-smlt-06.txt January 2006 Phone: +1 (408) 495 1599 Email: rlapuh@nortel.com Dinesh Mohan Nortel P O Box 3511 Station C Ottawa ON K1Y 4H7 Canada Phone: +1 (613) 763 4794 Email: mohand@nortel.com IPR Notice The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.