CCAMP Daegun Kim Internet Draft Korea Telecom Expires: April 2006 Jaihyung Cho ETRI October 2005 Label Switched Ethernet (LSE) Architecture draft-jaihyung-ccamp-lse-architecture-00.txt 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. This Internet-Draft will expire on April, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. J.Cho, et.al. Expires - April 2006 [Page 1] Label Switched Ethernet Architecture April 2006 Abstract A solution for GMPLS implementation over Ethernet based on label encoding method using 48bits of Ethernet address is proposed. Ethernet switches supporting this approach control L2-LSP using source & destination MAC addresses. The format of GMPLS label encoding on Ethernet header is described. GMPLS bridge model and three implementation models over bridged core network are presented. The purpose of this draft is not to define new bridge architecture but to help understanding some aspects of this approach, and identify requirements for potential extension to current GMPLS protocols and bridge. Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................3 3. MAC Label Format...............................................3 4. GMPLS Bridge Models............................................5 4.1. Simple GMPLS Bridge Model................................ 5 4.2. Extended GMPLS Bridge Model.............................. 7 5. GMPLS Implementation Models....................................8 5.1. Straightforward GMPLS Implementation..................... 8 5.2. MAC Address Swapping..................................... 9 5.3. MAC-in-MAC Bridge Tunnel................................ 11 Security Considerations..........................................13 References.......................................................13 Author's Addresses...............................................13 1. Introduction GMPLS control over Ethernet as specified in GMPLS RFCs has been identified within the scope of the CCAMP working group. Framework architecture proposed in [FRA] presents some deployment scenarios and requirements. However the framework does not include solution involved in each scenario. Depending on the choice of solution, in particular issues related in Ethernet label field, some scenario may not feasible as other proposed scenarios. Defining a label encoding method is an important issue because performance of bridged GMPLS network, impact to legacy bridge design may significantly be different according to the choice. Furthermore, some approach seriously limits the scope of potential area of application only within the core part of provider network that the solution may not be suitable in full extent of Ethernet deployment. Thus any proposed approach must be carefully examined in the aspect J.Cho, et.al. Expires - April 2006 [Page 2] Label Switched Ethernet Architecture April 2006 of potential extension to diverse Ethernet application before any fundamental choice is made. This document proposes a solution based on technology encoding GMPLS label on 48bits of Ethernet address fields. Ethernet switches supporting this approach control LSP using MAC addresses. Implementation models on bridged network are presented in section 5. The purpose of this document is to provide necessary information for discussion on various implementation options and comparison between them. Some features proposed in this document may not exactly fit in current scope of CCAMP working group. However it is included in this document in order to help understanding potential area of application and identifying requirements for acceptable extension in current bridge architecture. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [i]. 3. MAC Label Format IEEE 802.1 Ethernet bridges forward frames based on 48bits of MAC address, and additionally using VLAN tag [802.1Q]. When the GMPLS implementation over Ethernet is considered based on current deployment of bridge architecture, some feasible options to encode layer-2 label in MAC header would be either using VLAN ID (12bit) field or destination MAC address (48bit) and source MAC address (48bit) fields. Use of VLAN ID for label encoding may automate VLAN configuration using IP protocols. However weaknesses are the size of VLAN ID is too small (12bit=4096), and it may cause conflict with existing use of VLAN if GMPLS modifies semantics of VLAN ID. This document proposes MAC address fields for encoding of Ethernet label. Figure 1 shows the format of Ethernet header that GMPLS labels are encoded in the destination address and source address fields. In current IEEE policy for MAC address allocation, IEEE is designated by the ISO Council to act as the registration authority for the higher three-octet of OUI number in the MAC address to be used by manufacturer. Ethernet manufacturer may generate global unique MAC address using the OUI prefix and address block of lower three-octet J.Cho, et.al. Expires - April 2006 [Page 3] Label Switched Ethernet Architecture April 2006 (24bit). The idea here is that GMPLS may use the lower three-octet space exclusively if a unique OUI number is reserved for the protocol. +-------+-------+-------+-------+-------+-------+ | 1byte | 2byte | 3byte | 4byte | 5byte | 6byte | +-------+-------+-------+-------+-------+-------+ +-----------------------+-----------------------+ | OUI Prefix (=GMPLS) | DA-label (24bit) | +-----------------------+-----------------------+ | OUI Prefix (=GMPLS) | SA-label (24bit) | +---------------+-------+-----------------------+ | Length/Type | | +---------------+ | | | | Payload | | | +-----------------------------------------------+ | FCS | +-----------------------------------------------+ Figure 1. GMPLS Frame Format With this labeling scheme, all Ethernet frames controlled by GMPLS will have identical OUI number that they can easily be distinguished from other Ethernet frames, if separate dataplane processing is required. However this does not necessarily mean that separate hardware is needed. Since the label structure and MAC address format are identical, GMPLS labeled frames and Ethernet frames may share common hardware part for table lookup and forwarding operation. Another good point of this labeling scheme is that it allows sufficient number of label space (2^24 = 16,777,216). Since the space is far enough (even bigger than MPLS label) that in some scale of network, the label can be used globally within the boundary of network. The other advantage is that GMPLS implemented bridges are perfectly interoperable with legacy Ethernet bridges that GMPLS bridges may function as normal Ethernet bridge, and at the same time, as label switching node to GMPLS frames. The GMPLS header shown in Figure 1 contains both DA-label and SA- label. The SA-label indicates LSP of backward direction. The reason for including backward label in the GMPLS header is to reduce broadcast of unknown GMPLS frames in normal MAC learning bridges. Legacy Ethernet bridges may exist between GMPLS bridges. When a GMPLS frame is transmitted initially via the legacy bridges, legacy bridges J.Cho, et.al. Expires - April 2006 [Page 4] Label Switched Ethernet Architecture April 2006 broadcast the GMPLS frame as unknown Ethernet frame. The source address (i.e. SA-label) is also learned by the bridges. When a GMPLS frame is replied back along the same path, the legacy bridges do not broadcast the frame because the destination address was learned before. The bridges also learn the source address of the frame. As a result, legacy bridges may learn the DA-label and SA-label after initial exchange of GMPLS frames. Since GMPLS LSP is bi-directional, this also facilitates correct learning of both labels in legacy bridges. Another good point for enclosing bi-directional label is that dataplane of intermediate GMPLS nodes may send error message directly back to ingress node, without consulting control plane, if something is wrong. Note that the proposed label encoding method is transparent to the use of Ethernet Length/Type field and VLAN tag. Network manager may configure VLAN without regarding GMPLS deployment. GMPLS frames may include VLAN tag if they follow the VLAN configuration, or they may work independently to the VLAN policy. When the priority field of VLAN tag is used, consistent TE policy can be imposed in both legacy bridges and GMPLS bridges. 4. GMPLS Bridge Models 4.1 Simple GMPLS Bridge Model GMPLS can be implemented in different level of sophistication according to service model provided by bridged GMPLS network. Figure 2 below shows the simplistic implementation model of GMPLS Bridge. In this case, GMPLS control entity may co-exist with 802.1 bridge control entities and bridge management entity. The underlying MAC relay and E-ISS (Enhanced Internal Service Sub-layer) are as defined in IEEE 802.1D and 802.1Q. The control plane entities configure Filtering Database (i.e. MAC Table) and physical port state. 802.1 bridge control entities and GMPLS entity may share common Filtering Database. MAC table entries of native Ethernet frames are learned in dataplane, however MAC entries for GMPLS frames are configured by GMPLS control entity. Native Ethernet frames are forwarded via active ports which constitute spanning tree, however GMPLS frames may be forwarded through non-disabled ports via shortest path established using GMPLS protocols. The IP box described in control plane denotes that IP forwarding layer may use MAC service primitives when IP terminal or router includes L2SC interface. This model is applicable to both edge node and intermediate node in simple GMPLS forwarding model presented in section 5.1. J.Cho, et.al. Expires - April 2006 [Page 5] Label Switched Ethernet Architecture April 2006 +-----------------------------------------+ | Bridge Control & IP Forwarding Layer | | | | +-------+ +-------+ +-------+ | | | 802.1 | | GMPLS | | IP | | | +-------+ +-------+ +-------+ | | | MAC Table | | v Setup | +---+-----------+---------+-----------+---+ | | VLAN \ L2 / VLAN | | | | Untagging \Relay/ Tagging | | | +--------------+---+--------------+ | | | | | | MAC Dependant | | MAC Dependant | +------------------+ +------------------+ || || || || -------------------+ +------------------- LAN | | LAN -------------------+ +------------------- Figure 2. Simple GMPLS Bridge Architecture 4.2 Extended GMPLS Bridge Model Figure 3 below shows an extended model of GMPLS bridge providing sophisticated L2 service, such as label swapping and MAC-in-MAC encapsulation. The model includes three internal sub-layers - L2 - L2 Relay Sub-layer, G-Label Swapping Sub-layer, and Inner-MAC Relay Sub- layer - in MAC relay subpart. The L2 Relay Sub-layer (bottom level of MAC relay subpart in Figure 3) is as defined in IEEE 802.1D and 802.1Q. Native Ethernet frames are relayed via this sub-layer and forwarded only through spanning tree. The G-Label Swapping Sub-layer (middle level of MAC relay subpart in Figure 3) classifies GMPLS frames using first three octet of OUI number. The layer may replace DA-label and SA-label of input frames after label lookup operation. The L2 Relay Sub-layer and G-Label Swapping Sub-layer may share common Filtering Database because MAC address block for GMPLS frames is split from native Ethernet address block. The GMPLS frames may be forwarded through any non-disabled port via shortest path established using GMPLS protocols. The Inner-MAC Relay Sub-layer (top level of MAC relay subpart in Figure 3) encapsulate/decapsulate outer MAC header and forward frames J.Cho, et.al. Expires - April 2006 [Page 6] Label Switched Ethernet Architecture April 2006 according to inner MAC information. Only the MAC-in-MAC encapsulated GMPLS frames are passed up to this layer. The outer MAC header is a provider assigned GMPLS header and inner MAC header is usually a customer assigned MAC header. The extended bridge model presented here mainly applies to edge node of which typical role in MPLS network is adaptation of user flows into label switching domain. In the advanced forwarding models explained in section 5.2 and 5.3, such role of LER (Label Switching Edge Router) is performed in layer-2 bridge level. Note that an edge bridge may not include all three sub-layers. For example, when the MAC-in-MAC encapsulation is not required, the Inner-MAC Relay Sub-layer is not necessary. +-----------------------------------------+ | Bridge Control & IP Forwarding Layer | | | | +-------+ +-------+ +-------+ | | | 802.1 | | GMPLS | | IP | | | +-------+ +-------+ +-------+ | | | MAC Table | | v Setup | +---+-----+---------------------+-----+---+ | | \ Inner-MAC / | | | | (1) \ Relay / (2) | | | +--------+---------------+--------+ | | | G-Label \ G-Label / | | | | Classify \ Swapping / | | | +-----------+---------+-----------+ | | | VLAN \ L2 / VLAN | | | | Untagging \Relay/ Tagging | | | +--------------+---+--------------+ | | | | | | MAC Dependant | | MAC Dependant | +------------------+ +------------------+ || || || || -------------------+ +------------------- LAN | | LAN -------------------+ +------------------- (1) MAC-in-MAC Decapsulation (2) MAC-in-MAC Encapsulation Figure 3. GMPLS Edge Bridge Architecture J.Cho, et.al. Expires - April 2006 [Page 7] Label Switched Ethernet Architecture April 2006 5. GMPLS Implementation Models 5.1 Straightforward GMPLS Implementation A straightforward implementation method of GMPLS over Ethernet bridged core network, using the simple GMPLS bridge model as described in Figure 2, is shown in Figure 4. The 'L2SC' boxes in the figure denote bridge layer with the simple GMPLS implementation. The ingress edge node (R1) in Figure 4 is assumed providing encapsulation of service specific data unit into Ethernet payload, and transmission of Ethernet frame across the core network. An example is IP router encapsulating IP packet in Ethernet payload and transmitting to egress IP router. The 'IP' box at egress edge node (R2) illustrates that Ethernet header is striped off and the payload is forwarded using service specific interface. Detail of the edge function in this model is out of scope. GMPLS is responsible for distributing MAC addresses (i.e. GMPLS labels) between GMPLS implemented nodes and providing efficient and reliable Ethernet data path. | | | <........ Core Network ..........> | | | +------+ +------+ | IP | R1 S1 R2 | IP | +------+ +------+ +------+ | L2SC | | L2SC | | L2SC | +-+--+-+ +-+--+-+ +-+--+-+ | | L2-LSP | | L2-LSP | | -------->| |==============>| |==============>| |-------> [Data][IP] [Data][IP][s1:d1] [Data][IP][s1:d1] [Data][IP] Figure 4. GMPLS Controlled Bridge Network Model The simple GMPLS bridge model presented in section 4.1 does not change GMPLS label when the bridges relay frames. As a result, an ingress/egress assigned GMPLS label must be configured constantly along the path of L2-LSP. It is depicted in Figure 4 that egress (R2) assigned DA-label (='d1') and ingress (R1) assigned SA-label (='s1') are not changed at intermediate GMPLS bridge (S1). Therefore, the MAC addresses (GMPLS labels) must be assigned globally within the boundary of core network, and not exposed beyond the edge nodes. All edge nodes of a bridged GMPLS network must share common pool of available labels. This requires additional mechanism for coordinating J.Cho, et.al. Expires - April 2006 [Page 8] Label Switched Ethernet Architecture April 2006 label allocation of edges, or pre-allocation of label space for each node. This weakness can be overcome when the simple bridge model is enhanced with MAC address swapping capability presented in section 5.2. This straightforward model utilizes Ethernet dataplane as defined in IEEE 802.1D/Q. A clear advantage is that service providers are able to build relatively low-cost network because Ethernet bridges are cost-effective than sophisticated core routers. It is also noted that GMPLS controlled Ethernet is able to provide better scalability, reliability, path efficiency and traffic engineering than legacy bridged network. 5.2 MAC Address Swapping The problem of straightforward implementation of GMPLS without modifying current bridge architecture is scalability, i.e. the need for global coordination of label allocation. The solution for global label allocation may not be obvious in large network, however enhancement to legacy bridge architecture with address swapping capability is relatively simple solution. Figure 5 below shows this forwarding model of Ethernet label-swapping. In Figure 5, DA-label and SA-label of GMPLS frames are changed at the label-swapping bridges (S2, S3). There can be a number of non-label swapping bridges, either 802.1 Ethernet or GMPLS implemented, between the label-swapping bridges. The input labels and output labels are allocated only by label-swapping capable bridges. Non-label swapping bridges must configure the labels determined by the label-swapping bridges. S2 S3 +------+ +------+ | Swap | | Swap | +-+--+-+ +-+--+-+ L2-LSP | | L2-LSP | | L2-LSP =============>| |=============>| |===========> [Data][s1:d1] [Data][s2:d2] [Data][s3:d3] Figure 5. Label Swapped Frame Forwarding Conceptually, the label-swapping bridges partition a bridged GMPLS network according to label-space sharing unit. GMPLS label is allocated locally at each partition surrounded by label-swapping J.Cho, et.al. Expires - April 2006 [Page 9] Label Switched Ethernet Architecture April 2006 bridges. As the size of partition smaller, label space apportioned to each node become larger. For example in simple implementation model of Figure 4, each GMPLS edge node may use 2^24/M labels in average, where M is the number of edge nodes. When the network is partitioned to N, the average label space available for each node is increased to 2^24*N/M. If all bridges become label- swapping capable (i.e. N=M), each node is free to use entire 2^24 label space, hence removes the need for global allocation of labels. +----------------------------------+ | | | +-------+ +-------+ +------+ | | | 802.1 | | GMPLS | | IP | | | +-------+ +-------+ +------+ | | | MAC Table | | v Setup | +---+-----+---------------+----+---+ | | +--> \ G-Label /---+ | | | | | \ Swapping / | | | | +-|------+---------+-----|-+ | | | | \ L2 / | | | | | | +->\Relay/-+ | | | | +-|-----|---+---+--|-----|-+ | | | | | | | | | | | | | | | | | +-----|-----|---+ +--|-----|-----+ | | | | | | | | (L2-LSP)| | | | (L2-LSP) ---------+ | | +---------> GMPLS Frames | | GMPLS Frames | | ---------------+ +---------------> Ethernet Frames (Spanning Tree) Figure 6. Label Swapping Bridge Model Figure 6 above shows a bridge model of label-swapping capability. The bridge model includes G-Label Swapping Sub-layer. GMPLS frames are classified using the unique OUI number and passed to the G-Label Swapping Relay. The relay may replace DA-label and SA-label after MAC table lookup operation. Other native Ethernet frames are relayed via underlying L2 Relay. Note that this layering model only describes conceptual separation of the two sub-layers, and there can be no J.Cho, et.al. Expires - April 2006 [Page 10] Label Switched Ethernet Architecture April 2006 physical distinction in actual implementation. The two sub-layers may share common Filtering Database. 5.3 MAC-in-MAC Bridge Tunnel The bridge model presented above is further extended in this section in order to provide application service of L2-LSP, such as Layer-2 VPN [L2VPN]. Figure 7 below illustrates an Ethernet service model providing transmission of user frame via L2-LSP tunnel. In the figure, ingress edge bridge (S4) encapsulates user frame '[s1:d1]' into GMPLS frame '[s2:d2]'. The encapsulated user frame is transmitted via MAC- in-MAC tunnel. The GMPLS header is removed at the egress bridge (S5), and the user frame is forwarded in bridge level. | | Customer ...> | <.... Provider ....> | <... Customer Network A | Network | Network B | | +------+ S4 S5 +------+ |Encap.| |Decap.| +-+--+-+ +-+--+-+ User L2 | | L2-LSP Tunnel | | User L2 ------------->| |===================>| |------------> [Data][s1:d1] [Data][s1:d1][s2:d2] [Data][s1:d1] ^ ^ | | User MAC ---+ +--- Provider MAC Figure 7. MAC-in-MAC Tunnel Service using L2-LSP The enhanced bridge model of MAC-in-MAC encapsulation is described in Figure 8. In Figure 8 below, the bridge model includes Inner-MAC Relay Sub-layer on top of MAC relay subpart. Major function of this sub-layer is decapsulating outer MAC header (i.e. GMPLS frame header) and forward inner MAC frame (i.e. user frame) according to information of inner Filtering Database. The output user frame of this sub-layer is encapsulated in a GMPLS frame corresponding to output L2-LSP tunnel. GMPLS protocol is responsible for controlling the L2-LSP tunnel, and some entries in inner Filtering Database. The input & output L2-LSP tunnels are viewed as virtual ports in Inner-MAC Relay Sub-layer. The user frame given to Inner-MAC relay J.Cho, et.al. Expires - April 2006 [Page 11] Label Switched Ethernet Architecture April 2006 may either be VLAN tagged/untagged. An internal VLAN may also be configured between the virtual ports. The behavior of Inner-MAC relay may not exactly as defined in IEEE 802.1D/Q because default action of inner MAC relay is not always broadcasting of unknown frame. This is because there can be millions of virtual ports (i.e. L2-LSP tunnels) in the sub-layer that broadcasting to all virtual ports is unrealistic. However the Inner-MAC Relay may learn source MAC addresses from user frames and optimize broadcasting. +--------------------------------------+ | | | +-------+ +-------+ +-------+ | | | 802.1 | | GMPLS | | IP | | | +-------+ +-------+ +-------+ | | | MAC Table | | v Setup | +---+----+---------------------+---+---+ | | +->\ Inner-MAC /-+ | | | | | \ Relay / | | | | +-|:|---+---------------+--|:|-+ | | | |:| \ G-Label / |:| | | | | |:| \ Swapping / |:| | | | +-|:|------+---------+-----|:|-+ | | | |:| \ L2 / |:| | | | | |:| \Relay/ |:| | | | +-|:|---------+---+--------|:|-+ | | |:| | | |:| | | |:| | | |:| | +-----|:|---------+ +--------|:|-----+ |:| |:| |:| L2-LSP |:| L2-LSP |:| Tunnel |:| Tunnel | | | | -------+ +------> User Frames User Frames Figure 8. MAC-in-MAC Encapsulation Bridge Model The L2-LSP tunnel described in user side may not actually exist if the user is not L2SC capable. Users connected via native Ethernet link may transmit/receive Ethernet frames with/without VLAN tag. In this case, null L2-LSP tunnel associates internally per user VLAN or per physical port. The Inner-MAC Relay treats null L2-LSP tunnels as other virtual ports, however forwards frames without MAC-in-MAC encapsulation in user side. J.Cho, et.al. Expires - April 2006 [Page 12] Label Switched Ethernet Architecture April 2006 Security Considerations The Inner-MAC Relay Sub-layer must have some protection from user MAC explosion. Configuration error in user network or malicious manipulation of source MAC address may cause such explosion. Care must be taken when control message is to be accepted from user frames at the Inner-MAC Sub-layer. Treatment of user ping for L2 connection or pause message are issues requiring some discussion. References [FRA] Papadimitriou, D. and Cho, J. "A Framework for Generalized MPLS (GMPLS) Ethernet", draft-papadimitriou-ccamp-gmpls-ethernet-framework-00 (work in progress), July 2005. [802.1D] IEEE, "Media Access Control (MAC) Bridges",802.1D, ANSI/IEEE Standard Document, 1998 [802.1Q] IEEE, "Virtual Bridged Local Area Network", 802.1Q, ANSI/IEEE Standard Document, 2003 [L2VPN] Loa Andersson, Eric C. Rosen, "L2VPN Framework", draft-ietf-l2vpn-l2-framework-05.txt, Jun. 2004 Author's Addresses Daegun Kim(Korea Telecom) Email: dkim@kt.co.kr Jaihyung Cho (ETRI) 161 Gajung Dong, Yuseong Gu, Daejeon, Korea Phone: +82 42 860 5514 Email: jaihyung@chol.com J.Cho, et.al. Expires - April 2006 [Page 13] Label Switched Ethernet Architecture April 2006 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Full Copyright Statement Copyright (C) The Internet Society (2004). 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. J.Cho, et.al. Expires - April 2006 [Page 14] Label Switched Ethernet Architecture April 2006 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. J.Cho, et.al. Expires - April 2006 [Page 15]