Network Working Group S. Bryant Editor Internet Draft Cisco Systems Expires: April 2007 October 13, 2006 Application of PWE3 to MPLS Transport Networks draft-bryant-pwe3-mpls-transport-00 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 13, 2007. Abstract A need has been identified to identify a strict subset of the PWE3 over MPLS pseudowire functionality suitable for the construction of transport networks. This draft describes the IETF recommended profile for such cases. This document describes the IETF-recommended profile for such a configuration. In particular the profile of an RFC4448 PWE3 Ethernet pseudowire that can be used to address these requirements is described. Bryant et al Expires April 13, 2007 [Page 1] Internet-Draft App'n of PWE3 to MPLS Transport Networks October 2006 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 [RFC2119]. Table of Contents 1. Introduction...................................................2 2. PWE3 Configuration.............................................3 3. OAM............................................................4 3.1. VCCV profile 1: BFD without IP/UDP Headers................4 3.2. VCCV profile 2: BFD with IP/UDP Headers...................4 4. MPLS Layer.....................................................4 4.1. External Configuration....................................5 4.2. Control Plane Configuration...............................5 5. Congestion Considerations......................................6 6. Security Considerations........................................6 7. IANA Considerations............................................6 8. Acknowledgments................................................6 APPENDIX A: Requirements..........................................7 9. References.....................................................9 9.1. Normative References......................................9 9.2. Informative References...................................10 Author's Addresses...............................................10 Intellectual Property Statement..................................12 Disclaimer of Validity...........................................12 Copyright Statement..............................................12 Acknowledgment...................................................13 1. Introduction A requirement has been identified to identify a restricted subset of the Pseudowire Emulation Edge-to-Edge (PWE3) [RFC 3985] over Multi- Protocol Label Switching (MPLS) [RFC3031] pseudowire functionality suitable for the construction of transport networks. This document describes the IETF-recommended profile for such a configuration. In particular, it describes a profile of an RFC4448 PWE3 Ethernet pseudowire [RFC4448] that can be used to address these requirements. The scope of the initial version of this profile is restricted to transporting client Ethernet over an MPLS Packet Switched Network (PSN). The architecture required for this configuration is illustrated in Figure 1 below. It is based on requirements described in the Requirements below. Bryant et al Expires April 13, 2007 [Page 2] Internet-Draft App'n of PWE3 to MPLS Transport Networks October 2006 +----------------------------------------------------------------+ | | | IP/MPLS PSN (PHP may be enabled) | | | | +---------------------------+ | | | | | | | MPLS PSN (No PHP) | | | | | | | CE1 |PE1 PE2| CE2 | | +-----+ +-----+ +-----+ +-----+ | | | | | | | | | | | | | | | | | | | | | | | +------+ | | | | | | +------+ | | | | | | | | | 802.3| | | | | | | | 802.3| | | | | | +-----+ +-----+ +-----+ +-----+ | | | | | | | | | | | | | | +-- ---------------------- -+ | | | +----- --- -------- -- ---------------------- - -------- --- ----+ | | | |<--MPLS PSN (no PHP)->| | | | | | | | | | | | |<------------PW----------->| | | | | | | | |<-------------802.3 (Ethernet)-------------->| | | | |<---------IP/MPLS LSP (PHP may be supported)-------->| Figure 1: Application PWE3 to MPLS Transport Networks An IP or an MPLS Label Switched Path (LSP) must be established between CE1 and CE2. This MPLS PSN may be utilize Penultimate-Hop Popping (PHP). This LSP is to be carried over Ethernet. An Ethernet PW is provisioned between PE1 and PE2 and used to carry the Ethernet from PE1 to PE2. The Ethernet PW is carried over an MPLS PSN, but this PSN MUST NOT be configured with PHP. 2. PWE3 Configuration The only PWE3 encapsulation that is supported in this version of the profile is Ethernet [RFC4448]. This is used in "raw" mode. The Control Word MUST be used. The Sequence number MUST be zero. The use of the Pseudowire Setup and Maintenance Label Distribution Protocol [RFC4447] is not supported in this version of the profile. The Pseudowire Label is statically provisioned. Bryant et al Expires April 13, 2007 [Page 3] Internet-Draft App'n of PWE3 to MPLS Transport Networks October 2006 3. OAM The OAM mechanism is VCCV [VCCV]. One of the following VCCV profiles MUST be used. Once one is provisioned and the operational status of the PW is UP, no other profile SHOULD be used until such time as the PW's operational status is set to DOWN. 3.1. VCCV profile 1: BFD without IP/UDP Headers As specified in [VCCV], the first nibble is set to 0001b to indicate a channel associated with a pseudowire [RFC4385][RFC4446]. The Version and the Reserved fields are set to 0, the Version is 0, and the Channel Type is set to 0x07 to indicate that the payload carried in BFD without IP/UDP headers, as is defined in section 4.1.1 of [VCCV]. The connection verification method used by VCCV is BFD with diagnostics as defined in 4.1 of [VCCV]. 3.2. VCCV profile 2: BFD with IP/UDP Headers When PE1 and PE1 are IP capable and have been configured with IP addresses, the following VCCV mechanism MAY be used. As specified in [VCCV], the first nibble is set to 0001b to indicate a channel associated with a pseudowire [RFC4385][RFC4446]. The Version and the Reserved fields are set to 0, the Version is 0, and the Channel Type is set to 0x21 for IPv4 and 0x56 for IPv6 payloads. The connection verification method used by VCCV is BFD with diagnostics as defined in 4.1 of [VCCV]. 4. MPLS Layer This section describes the profile of the MPLS PSN [RFC3031]. The requirements are based on the requirements communicated to the IETF and included in Appendix 1. The profile considers two cases: 1. The case where external configuration is used 2. The case where a control plane is available Bryant et al Expires April 13, 2007 [Page 4] Internet-Draft App'n of PWE3 to MPLS Transport Networks October 2006 4.1. External Configuration All MPLS labels [RFC3032] used by the transport LSPs utilized by the PWs described in sections 2 and 3 MUST be statically provisioned. Labels may be selected from the per-platform or per-interface label space. All LSPs for the transport LSPs utilized by the PWs described in sections 2 MUST support both unidirectional and bi-directional point- to-point connections. The transport LSPs SHOULD support unidirectional point-to-multipoint connections. The forward and backward directions of a bi-directional connection should follow the same path along the transport LSP. Equal cost multi-path (ECMP) load balancing MUST NOT be configured on the transport LSPs utilized by the PWs described in sections 2 and 3. The Merging of label switched paths is prohibited and MUST NOT be configured the transport LSPs utilized by the PWs described in sections 2 and 3. Penultimate hop popping by the LSRs MUST be disabled on LSPs providing PWE3 transport network functionality. Both E-LSP and L-LSP MUST be supported as defined in RFC3270 [RFC3270]. The MPLS EXP field is supported according to RFC3270 for only when the pipe and short-pipe models are utilized. 4.2. Control Plane Configuration In this section we describe the profile when RSVP-TE [] or the bi- directional support in GMPLS [] are used to configure the MPLS PSN used to provide the transport LSPs. When these protocols are used to provide the control plane the following are automatically provided: 1. There is no label merging unless it is deliberately enabled to support Fast Re-route (FRR)[]. 2. A single path is provided end-to-end (There is no ECMP). 3. Paths may be unidirectional or bidirectional as required. Bryant et al Expires April 13, 2007 [Page 5] Internet-Draft App'n of PWE3 to MPLS Transport Networks October 2006 Additionally the following configurations restrictions required to support external configuration MUST be applied: Penultimate hop popping by the LSRs MUST be disabled on LSPs providing PWE3 transport network functionality. Both E-LSP and L-LSP MUST be supported as defined in RFC3270 [RFC3270]. The MPLS EXP field is supported according to RFC3270 for only when the pipe and short-pipe models are utilized. 5. Congestion Considerations This draft is a profile of an RFC4448 PWE3 Ethernet pseudowire. The security considerations associated with that pseudowire and all subsequent work on congestion considerations regarding Ethernet pseudowires is applicable to this draft. 6. Security Considerations PWE3 security considerations are described in RFC3985 [RFC3985]. This draft is a profile of existing IETF proposed standards and raises no new security issues. 7. IANA Considerations There are no IANA actions required by this draft. 8. Acknowledgments Bryant et al Expires April 13, 2007 [Page 6] Internet-Draft App'n of PWE3 to MPLS Transport Networks October 2006 APPENDIX A: Requirements This appendix is NOT normative. The following are the requirements for a transport pseudowire and are based on inputs from ITU SG15 [ITU1]. These in turn are the result of ITU studies on Transport MPLS [ITU2]. 1. A transport pseudowire shall be based on a connection-oriented packet switched technology. Transport networks can also support circuit switched transport technologies (e.g. SDH, OTH or WDM) 2. A transport pseudowire shall operate under a common operation, control and management paradigm with respect to other transport technologies (e.g. SDH, OTN or WDM) 3. A transport pseudowire network shall support multiple layer network instances; e.g. a TRANSPORT PSEUDOWIRE transport network "service layer" instance in which the connections carry the customer's (individual or bundled) service, a TRANSPORT PSEUDOWIRE transport network "trunk layer" instance in which the connections carry aggregates of the network "service layer" connections and a transmission media layer instance in which the connections carry the aggregate of network trunk or network service connections. 4. The identification of each connection within its aggregate shall be based on labels. Connections can be aggregated into trunks by pushing and de-aggregated by popping labels. TRANSPORT PSEUDOWIRE labels may be swapped within a connection in a layer network instance when the traffic is forwarded from one TRANSPORT PSEUDOWIRE link connection to another TRANSPORT PSEUDOWIRE link connection. TRANSPORT PSEUDOWIRE pop, push, and swap label operations should be performed as defined by the relevant IETF RFCs. 5. Labeling shall make use of the MPLS label and label stack entry as defined in RFC3032. 6. A transport pseudowire layer network shall support TRANSPORT PSEUDOWIRE and non TRANSPORT PSEUDOWIRE client layer networks and shall be able to be carried over TRANSPORT PSEUDOWIRE and non TRANSPORT PSEUDOWIRE server layer networks. 7. A transport pseudowire transport plane shall be able to operate without any IP functionality present. Bryant et al Expires April 13, 2007 [Page 7] Internet-Draft App'n of PWE3 to MPLS Transport Networks October 2006 8. A transport pseudowire network shall be able to be operated with a centralized NMS system 9. A transport pseudowire network should be able to be operated by a centralized NMS system with the support of a distributed control plane 10. A transport pseudowire shall support both unidirectional and bi-directional point-to-point connections 11. A transport pseudowire should support unidirectional point-to- multipoint connections 12. The forward and backward directions of a bi-directional connection should follow the same path along the TRANSPORT PSEUDOWIRE network. 13. The intermediate nodes should be aware about the binding of the forward and the backward directions belonging to the same bi- directional connection. 14. A transport pseudowire shall support traffic-engineering capabilities with traffic- and/or resource-oriented performance objectives. 15. A transport pseudowire shall support a method to offer packet loss objectives comparable to those in TDM transport networks (only due to bit errors) 16. A transport pseudowire should support transport and QoS mechanisms that can deliver statistical multiplexing gain. Packets exceeding the agreed traffic profile are however not allowed to enter into the TRANSPORT PSEUDOWIRE network (i.e. they are discarded by the traffic conditioning at the ingress of the network) 17. A transport pseudowire layer network shall operate independently of other layer networks (either TRANSPORT PSEUDOWIRE or non TRANSPORT PSEUDOWIRE). 18. A transport pseudowire shall support connections through a single domain 19. A transport pseudowire should support connections through multiple domains Bryant et al Expires April 13, 2007 [Page 8] Internet-Draft App'n of PWE3 to MPLS Transport Networks October 2006 20. A transport pseudowire shall offer as much commonality as possible with the MPLS user plane as defined by IETF. When MPLS offers multiple options in this respect, TRANSPORT PSEUDOWIRE should select the minimum sub-set (necessary and sufficient subset) applicable to a transport network application. OAM Requirements: 21. A transport pseudowire should support transport network connection and performance monitoring mechanisms 22. A transport pseudowire OAM shall support fault management, performance management and protection switching mechanisms 23. A transport pseudowire OAM shall be able to operate without any IP functionality present. 24. Survivability Requirements 25. A transport pseudowire should support transport network-style protection switching mechanisms (sub-network connection protection and trail protection) 26. A transport pseudowire should support transport network restoration mechanisms 27. A transport pseudowire protection switching shall be able to operate without any IP functionality present. Control Plane Requirements: Control plane requirements are for further study. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3031] E. Rosen, A. Viswanathan, R. Callon., "Multiprotocol Label Switching Architecture", RFC 3031,January 2001. Bryant et al Expires April 13, 2007 [Page 9] Internet-Draft App'n of PWE3 to MPLS Transport Networks October 2006 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [RFC3270] F. Le Faucheur, Editor "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC3270, May 2002 [RFC4385] S. Bryant, G. Swallow, L. Martini, D. McPherson, "Control Word for Use over an MPLS PSN", RFC 4385, February 2006. [RFC4446] L. Martini, "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)" RFC4446, April 2006. [RFC4447] L. Martini, Ed. "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC4447, April 2006. [RFC4448] L. Martini, Ed., E. Rosen, N. El-Aawar, G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006 [VCCV] T. Nadeau (Ed), "Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv-11.txt (work in progress), October 2006. 9.2. Informative References [ITU1] https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=265 [ITU2] http://ties.itu.int/u/tsg15/sg15/xchange/wp3/q12/0609_sophia/wd/wd09r 3_editor_g8110.1v1_0909.doc [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC3985, March 2005. Bryant et al Expires April 13, 2007 [Page 10] Internet-Draft App'n of PWE3 to MPLS Transport Networks October 2006 Author's Addresses Stewart Bryant Cisco Systems 250, Longwater, Green Park, Reading, RG2 6GB, UK Email: stbryant@cisco.com Monique Morrow Cisco Systems, Inc. Glatt-com CH-8301 Glattzentrum Switzerland Email: mmorrow@cisco.com Rao Cherukuri Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 Thomas D. Nadeau Cisco Systems 300 Beaver Brook Drive Boxborough, MA USA Email: tnadeau@cisco.com George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 Email: swallow@cisco.com Bryant et al Expires April 13, 2007 [Page 11] Internet-Draft App'n of PWE3 to MPLS Transport Networks October 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 (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. Bryant et al Expires April 13, 2007 [Page 12] Internet-Draft App'n of PWE3 to MPLS Transport Networks October 2006 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bryant et al Expires April 13, 2007 [Page 13]