Network Working Group Wei. Cao Internet Draft Huawei Technologies Expires: April 2007 October 16, 2006 IEEE 802.1ah Mode for Ethernet Over MPLS draft-cao-pwe3-802-1ah-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. This document may only be posted in an Internet-Draft. 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 16, 2007. Cao Expires April 16, 2007 [Page 1] Internet-Draft draft-cao-pwe3-eth-802.1ah-00 October 2006 Abstract Ethernet has been widely deployed in metro-networks, and there are more and more customers select Ethernet PW services. With the deployment of IEEE 802.1ah network, there is a need to support 802.1ah attachment circuit. Based on the two modes defined in RFC 4448, this document introduces a new Ethernet encapsulation mode to support the new AC type. This document also describes some scenarios and procedures pertaining to the new mode. Some considerations relating to multi-segment PW are also discussed. Table of Contents 1. Specification of Requirements................................2 2. Introduction.................................................2 2.1. Terminology.............................................3 3. Scenario and Operations for Ethernet PW IEEE 802.3 Mode......4 3.1. Ethernet PW Connection between Two PBBNs................4 4. Details for Ethernet PW 802.1ah Mode.........................5 4.1. Applicability Statement.................................5 4.2. Ethernet PW 802.1ah Mode................................5 4.3. Ethernet-Specific Interface Parameter LDP Sub-TLV.......6 4.4. Encapsulations and Procedures...........................7 5. Security Considerations......................................7 6. IANA Considerations..........................................7 7. Acknowledgments..............................................7 8. References...................................................7 8.1. Normative References....................................7 8.2. Informative References..................................8 Author's Addresses..............................................9 Intellectual Property Statement.................................9 Disclaimer of Validity..........................................9 Copyright Statement............................................10 1. Specification of Requirements 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 [RFC2119]. 2. Introduction Ethernet is widely deployed in metro-networks, where 802.1ah is a conspicuous new technology. Ethernet PW plays an important role in PWE3, but currently only 802.1q/ad Ethernet ACs are considered. There Cao Expires April 16, 2007 [Page 2] Internet-Draft draft-cao-pwe3-eth-802.1ah-00 October 2006 are two modes defined for Ethernet PW in RFC 4448: "raw mode" and "tagged mode", corresponding to transparent frame tunnel and forwarding with extra tag-process. Although 802.1ah frame can be carried with these two modes, if SP wants to support the new emerged service "Provider Backbone Bridges" well, introducing new mode is necessary. 802.1ah adds some fields to the 802.1q frame: B-MAC, B-VID and I- SID. In Provider Backbone Bridge Network (PBBN), forwarding decision is based on B-MAC and B-VID, while I-SID can be used as a service delimiter. When two PBBNs are connected through a PW, it may require PE's NSP inspect 802.1ah frame's B-TAG and I-TAG rather than outmost tag only. In such cases, PW with 802.1ah mode is suitable. Also 802.1ah mode will be helpful if an Ethernet service wants to span PBN, MPLS and PBBN. By introducing 802.1ah mode, frames carried by an Ethernet PW can have more tags in the encapsulation. Similar to the application method of the tags in PBT network, one can try to use these extra tags in PW as below. - PW multiplex: Currently a PW is identified by a pair of PW labels allocated by the two end PEs. Since the PW labels are per-platform MPLS label, if there are many PWs created, PEs have to use a lot of MPLS labels. In 802.1ah mode, B-TAG/I-TAG can be used to identify the PW, so multiple Ethernet PWs may be multiplexed through one pair of PW labels to reduce the number of MPLS label required. - MS-PW switching: MS-PW may span multi-domains, and at each S-PE the PW label will be switched. With 802.1ah mode and more tags in the encapsulation, one could map BVID into PW label for each domain, or may use I-SID for PW label switching. The details of the new application should be further studied. The new mode will not change the PWE3 Ethernet encapsulation defined in RFC 4448. It assumes in the remainder of this document the readers are familiar with RFC 3985 and RFC 4448. 2.1. Terminology The terminology specified in RFC 3985 and RFC 4026 applies. In addition, we introduce some terms related to IEEE 802.1ah: - PBN: Provider Bridge Network Cao Expires April 16, 2007 [Page 3] Internet-Draft draft-cao-pwe3-eth-802.1ah-00 October 2006 - PBB: Provider Bridge Backbone - PBBN: Provider Backbone Bridge Network, often referred as an 802.1ah domain. - B-VID: Backbone Vlan ID - I-SID: Service Instance ID - B-TAG: Backbone TAG field - I-TAG: Service Instance Tag 3. Scenario and Operations for Ethernet PW IEEE 802.3 Mode The objective of PWE3 is providing point-to-point connectivity between two ACs at the edge of a provider network. Considering 802.1ah, the models of linking two PBBNs are described. 3.1. Ethernet PW Connection between Two PBBNs The following figure shows the typical working context. As shown in Fig.1, there are two split Mac-in-Mac domains and one MPLS/IP core networks. Customer's devices are attached to UPE1 and UPE2. Since there is no direct connection between the two Mac-in-Mac domains, if the customer needs Ethernet service from UPE1 to UPE2, an Ethernet PW should be created to provide the connectivity. <---PWE3 Services ---> --- --------- ----- / \ / \ / \ +----+ |802 +----+ +----+802 | +----+ ---|UPE |MAC-in |--- |NPE | MPLS |NPE |----| MAC-in |UPE |--- | 1 | MAC |.1ah| 1 |network| 2 |.1ah| -MAC | 2 | +----+Domain1| +----+ +----+ \Domain2+----+ \ / \ / \ / ----- -------- ----- Figure 1. PBBN connected by Ethernet PW Cao Expires April 16, 2007 [Page 4] Internet-Draft draft-cao-pwe3-eth-802.1ah-00 October 2006 The PWE3 service is terminated in NPE1 and NPE2. If only transparent transmission is needed, then there is no extra operation of the Native Service Processing (NSP) and Ethernet "raw mode" is enough. However, if the two Mac-in-Mac domains have different understanding of the B-TAG or I-TAG, some translation work may be required. For example, the NPE should have to recognize the 802.1ah encapsulation and has the ability to rewrite B-TAG/I-TAG. RFC 4448 defines two Ethernet PW modes: "raw mode" and "tagged mode". Since "tagged mode" only inspects the outermost tag, in this scenario if NPE needs to rewrite I-TAG, then neither "raw mode" nor "tagged mode" can satisfy it. So here we introduce a new mode and call it "802.1ah" mode. It should be noticed that the NPE process such as rewriting B- TAG/I-TAG belongs to NSP, and NSP is outside the scope of PWE3. But it is useful to provide necessary information to PE to identify what service is been carried and denote the NSP difference. 4. Details for Ethernet PW 802.1ah Mode 4.1. Applicability Statement The Ethernet PW emulation with 802.1ah mode should allow an "Provider Backbone Bridges" based service across an MPLS network. It has the following characteristics in relation to the respective native services: - An Ethernet PW connects two PBBN domains, supporting bidirectional transport of variable length Ethernet frames. It SHOULD be assured by administrators that both ends of the PW support IEEE 802.1ah. - An Ethernet PW connects PBN and PBBN, and if B-TAG/I-TAG insert/remove action should be taken at one side of the PW, at least the ends to do the process MUST support IEEE 802.1ah. - For an 802.1ah Ethernet Frame transmitted by an Ethernet PW, B-TAG or I-TAG or both may be process by NSP at the Ingress or Egress. The detail function is outside the scope of this document. - FCS retention, sequencing are the same as defined in RFC4448. 4.2. Ethernet PW 802.1ah Mode With 802.1ah mode, plus two modes defined in RFC4448, there are three Ethernet PW modes: Cao Expires April 16, 2007 [Page 5] Internet-Draft draft-cao-pwe3-eth-802.1ah-00 October 2006 - Ethernet Tagged Mode, it corresponds to PW type 0x0004. - Ethernet Raw Mode, it corresponds to PW type 0x0005. - Ethernet 802.1ah Mode, it corresponds to PW type 0x001A (TBD). In Ethernet 802.1ah mode, it requires PE have the ability to recognize 802.1ah frame. The PE may re-write B-TAG/I-TAG content, or insert/remove B-TAG/I-TAG when needed. If the PE detects a frame in wrong encapsulation format, PE must discard the frame. It should be noted that if customer requires Ethernet frames be transmitted unchanged, PE should use "raw mode" rather than 802.1ah mode even the frames are encapsulated in 802.1ah format. 4.3. Ethernet-Specific Interface Parameter LDP Sub-TLV This LDP Sub-Type Length Value [LDP] specifies interface-specific parameters. When applicable, it MUST be used to validate that the PEs, and the ingress and egress ports at the edges of the circuit, have the necessary capabilities to interoperate with each other. The Interface parameter TLV is defined in [PWE3-CTRL]. RFC 4448 defines Requested VLAN ID Sub-TLV. Here new Sub-TLVs are specified as follows: - 0x0D(TBD) Requested PBB I-TAG Sub-TLV An optional 24-bits value indicates the requested I-TAG. This parameter MUST be used by a PE that is incapable of rewriting the IEEE 802.1ah I-TAG on output. If the ingress PE receives this request, it MUST process the I-TAG correctly at the input to match the requested I-TAG. If this is not applicable, the PW MUST not be enabled. - 0x0E(TBD) Requested PBB B-TAG/I-TAG Sub-TLV An optional 36-bits value indicates the requested B-TAG and I-TAG. The 36 bits value is composed of 12 bits B-TAG value and 24 bits I- TAG value. This parameter MUST be used by a PE that is incapable of inserting/removing 802.1ah I-TAG on output. If this is no applicable, the PW MUST not be enabled. - 0x0F(TBD) Requested I-TAG Filter Sub-TLV An optional multi-24-bits value indicates the request of filtering specific I-TAG. In some scenarios, there are more than one I-TAGs corresponding to one B-TAG in one Ethernet stream that should be carried by an Ethernet PW. PE can use Requested I-TAG Filter Sub- Cao Expires April 16, 2007 [Page 6] Internet-Draft draft-cao-pwe3-eth-802.1ah-00 October 2006 TLV to request remote PE to filter the frames with those specific I-TAG. These parameters are applicable only to 802.1ah PW type. The first two TLVs can not be used together, while they can be used with the last one. 4.4. Encapsulations and Procedures The encapsulation specification defined in RFC4448 applies for 802.1ah mode. As described in section 4.6 of RFC4448, the control word may or may not be needed in different cases. But it is suggested in this document to use the control word for 802.1ah mode to reduce the risk brought by ECMP path. 802.1ah mode complies with the procedures described in RFC 4448, including MTU management, Frame Ordering, Frame Error Processing, etc. 5. Security Considerations 802.1ah mode does not introduce new security problems to Ethernet pseudowire type. 6. IANA Considerations The value of new PW type and LDP sub-TLV should be defined. 7. Acknowledgments I would like to thank Yu Delei for his help on IEEE specifications. I also wish to acknowledge Yaakov Stein for his suggestions. 8. References 8.1. Normative References [PWE3-CW] Bryant, S., Swallow, G., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006. [IANA] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006. [PWE3-CTRL] Martini, L., El-Aawar, N., Heron, G., Rosen, E., Tappan, D., and T. Smith, "Pseudowire Setup and Maintenance using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. Cao Expires April 16, 2007 [Page 7] Internet-Draft draft-cao-pwe3-eth-802.1ah-00 October 2006 [MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon, Multiprotocol Label Switching Architecture, RFC 3031, January 2001. [802.3] IEEE802.3-2005, ISO/IEC 8802-3: 2000 (E), "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", 2005. [802.1Q] ANSI/IEEE Standard 802.1Q-2005, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", 2005. [802.1ah/D2.20] IEEE P802.1ah/D2.20 Draft Standard for Local and Metropolitan Area Networks-Virtual Bridged Local Area Networks- Amendment 6: Provider Backbone Bridges, April, 2006. 8.2. Informative References [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture", RFC 3985, March 2005. [PWE3-REQ] Xiao, X., McPherson, D., and P. Pate, "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004. [LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001. [FRAG] Malis, A. and W. Townsley, "PWE3 Fragmentation and Reassembly", Work in Progress, February 2005. [FCS] Malis, A., Allan, D., and N. Del Regno, "PWE3 Frame Check Sequence Retention", Work in Progress, September 2005. [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, November 2000. [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026,March 2005. Cao Expires April 16, 2007 [Page 8] Internet-Draft draft-cao-pwe3-eth-802.1ah-00 October 2006 Author's Addresses Cao Wei Huawei Technologies Room 1201, Kuike Bld., No.6 Xinxi Rd., Shang-di Information Industry Base, Hai-Dian District Beijing, China Email: caowayne@huawei.com 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. Cao Expires April 16, 2007 [Page 9] Internet-Draft draft-cao-pwe3-eth-802.1ah-00 October 2006 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. Cao Expires April 16, 2007 [Page 10]