Network Working Group R. Aggarwal Internet Draft Juniper Networks Category: Standards Track Expiration Date: September 2010 F. Jounay France Telecom March 08, 2010 Point-to-Multipoint Pseudo-Wire Encapsulation draft-raggarwa-pwe3-p2mp-pw-encaps-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 and License Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Raggarwa [Page 1] Internet Draft draft-raggarwa-pwe3-p2mp-pw-encaps-01.txt March 2010 This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Abstract A Point-to-Multipoint (P2MP) Pseudowire (PW) is a mechanism that emulates the essential attributes of a P2MP Telecommunications service such as P2MP ATM over a Packet Switched Network (PSN). This document describes the encapsulation and data plane procedures for a P2MP PW. These procedures are meant to be independent of the control plane used to signal a P2MP PW. Raggarwa [Page 2] Internet Draft draft-raggarwa-pwe3-p2mp-pw-encaps-01.txt March 2010 Table of Contents 1 Specification of requirements ......................... 3 2 Introduction .......................................... 3 3 P2MP PW Semantics ..................................... 4 4 P2MP PW Encapsulation ................................. 4 5 P2MP PW Encapsulation Type ............................ 5 6 Data Forwarding ....................................... 5 6.1 MPLS Tree Encapsulation ............................... 5 6.2 Demultiplexing P2MP PW Traffic ........................ 6 6.2.1 One P-Multicast Tree - One P2MP PW Mapping ............ 6 6.2.2 One P-Multicast Tree - Many P2MP PW Mapping ........... 6 6.3 Layer 2 MTU ........................................... 7 7 Security Considerations ............................... 7 8 IANA Considerations ................................... 7 9 Acknowledgments ....................................... 8 10 References ............................................ 8 10.1 Normative References .................................. 8 10.2 Informative References ................................ 8 11 Author's Address ...................................... 9 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 [RFC2119]. 2. Introduction A Point-to-Multipoint (P2MP) Pseudowire (PW) is a mechanism that emulates the essential attributes of a P2MP Telecommunications service such as P2MP ATM over a Packet Switched Network (PSN). One of the applicabilities of a P2MP PW is to deliver a Layer 2 multicast service, that carries multicast frames (encoded using Layer 2 or IP mechanisms) from a multicast source to one or more multicast receivers. The required functions of P2MP PWs include encapsulating service- Raggarwa [Page 3] Internet Draft draft-raggarwa-pwe3-p2mp-pw-encaps-01.txt March 2010 specific PDUs arriving at an ingress Attachment Circuit (AC), and carrying them across a tunnel to one or more egress ACs, managing their timing and order, and any other operations required to emulate the behavior and characteristics of the service as faithfully as possible. P2MP PWs extend the PWE3 architecture [RFC3985] to offer a P2MP Telecommunications service. They follow the PWE3 architecture as described in [RFC3985] with modifications as outlined in this document. One notable difference between point-to-point (P2P) PWs as outlined in [RFC3985] and P2MP PWs is that the former emulate a bidirectional service whereas the latter emulate a unidirectional service. This document describes the encapsulation and data plane procedures for a P2MP PW. These procedures are meant to be independent of the control plane used to signal a P2MP PW. 3. P2MP PW Semantics A P2MP PW provides a mechanism for the root CE to send traffic to one or more leaf CEs over a PSN. A root CE in a sender site sends traffic on one or more ACs to the root PE. The root PE delivers this traffic over a P2MP PW to one or more leaf PEs. Each leaf PE in turn delivers this traffic to one or more leaf CEs in a receiver site. A particular leaf CE MUST receive this traffic over a single AC. A particular leaf CE may receive traffic from multiple sender CEs. Traffic from different sender CEs is received by a leaf PE over unique P2MP PWs. The leaf PE must use unique ACs to send traffic received over unique P2MP PW, to the same leaf CE or different leaf CEs. 4. P2MP PW Encapsulation An architectural building block of P2MP PWs is that routers not directly connected to VPN customers should carry no VPN state, or at minimum this state should not grow linearly with the number of individual connections provisioned on the edge devices. In order to achieve this traffic belonging to different P2MP PWs, which may be in different L2VPNs, may be carried over the same PSN tunnel. The PSN tunnels MUST be based on P2MP MPLS LSPs signaled Raggarwa [Page 4] Internet Draft draft-raggarwa-pwe3-p2mp-pw-encaps-01.txt March 2010 using either RSVP-TE [RFC4875] or P2MP LDP [mLDP]. Penultimate-hop- popping MUST be disabled. The egress PEs MUST NOT advertise IMPLICIT NULL or EXPLICIT NULL for P2MP PSN Tunnels that are used to carry P2MP PW traffic. This document uses the terms P-Multicast Tree and P2MP PSN Tunnel inter-changeably. When multiple P2MP PWs are carried over the same P2MP MPLS PSN tunnel there is a need to identify at the leaf PE the P2MP PW the packet belongs to. This is done by using a P2MP PW demultiplexor that allows an egress PE to determine in the data plane, the P2MP PW for which the packet is intended. A MPLS label is used as the P2MP PW demultiplexor. The root PE MUST use this label as the bottom-most label while encapsulating a customer data packet in a P2MP PW. Each of the leaf PEs must be able to associate this inner label with the same P2MP PW and use it to demultimplex the traffic received over the P2MP PSN tunnel. This document requires the use of an upstream assigned MPLS label [RFC5331] as the P2MP PW demultiplexor. The MPLS upstream assigned label that is used as the P2MP PW demultiplexor MUST be assigned by the root PE i.e. the PE connected to the root CE. It MUST be distributed by the root PE to the leaf PEs i.e. the PEs connected to the receiver CEs via a control plane mechanism or via provisioning. The control plane mechanisms used to achieve this are outside the scope of this document. 5. P2MP PW Encapsulation Type The PW encapsulation types specified in [RFC4446] MUST be used for P2MP PWs. 6. Data Forwarding 6.1. MPLS Tree Encapsulation The following diagram shows the progression of a L2 multicast packet as it enters and leaves the SP network when MPLS trees are being used. RSVP-TE P2MP LSPs are examples of such trees. The modification to the Layer 2 frame, by the root PE, depends on the Layer 2 encapsulation type. This document requires that the encapsulation methods used in transporting of Layer 2 frames over tunnels be the same as described in [RFC4448], [RFC4618], [RFC4619], and [RFC4717]. Note that these encapsulation methods may result in inserting a control-word in the P2MP PW encapsulation as shown in the figure below. Raggarwa [Page 5] Internet Draft draft-raggarwa-pwe3-p2mp-pw-encaps-01.txt March 2010 Packets received Packets in transit Packets forwarded at root PE in the service by leaf PEs provider network +---------------+ |P2MP LSP Label | +---------------+ | P2MP PW Label | +---------------+ | Optional CW | ++=============++ ++=============++ ++=============++ ||C-L2 Hdr || || C-L2 Hdr || || C-L2 Hdr || ++=============++ >>>>> ++=============++ >>>>> ++=============++ || C-Payload || || C-Payload || || C-Payload || ++=============++ ++=============++ ++=============++ 6.2. Demultiplexing P2MP PW Traffic Demultiplexing P2MP PW traffic on an egress PE requires the receiving PE to determine the P2MP PW the packet belongs to. 6.2.1. One P-Multicast Tree - One P2MP PW Mapping When a P-Multicast tree is mapped to only one P2MP PW, determining the tree on which the packet is received is sufficient to determine the P2MP PW on which the packet is received. The tree is determined based on the tree encapsulation. When MPLS encapsulation is used, eg: RSVP-TE P2MP LSPs, the outer MPLS label is used to determine the tree. Penultimate-hop-popping MUST be disabled on the MPLS LSP (RSVP- TE P2MP LSP or LDP P2MP LSP). 6.2.2. One P-Multicast Tree - Many P2MP PW Mapping When traffic belonging to multiple P2MP PWs is carried over the same tree, the P2MP PW that the packet belongs to is identified by using an inner label. This label determines the P2MP PW for which the packet is intended. The root PE uses this label as the inner label while encapsulating a customer multicast data packet. Each of the leaf PEs must be able to associate this inner label with the same P2MP PW and use it to demultimplex the traffic received over the P2MP LSP. Raggarwa [Page 6] Internet Draft draft-raggarwa-pwe3-p2mp-pw-encaps-01.txt March 2010 This document requires the use of upstream label assignment by the root PE [RFC5331]. Hence the inner label is assigned by the root PE. When the egress PE receives a packet over a P2MP LSP, the outer encapsulation [in the case of MPLS P2MP LSPs, the outer MPLS label] specifies the label space to perform the inner label lookup. The same label space MUST be used by the egress PE for all P-Multicast trees that have the same root [RFC5331]. If the tree uses MPLS encapsulation, as in RSVP-TE P2MP LSPs, the outer MPLS label and the incoming interface provides the label space of the label beneath it. This assumes that penultimate-hop-popping is disabled. The egress PE MUST NOT advertise IMPLICIT NULL or EXPLICIT NULL for that tree. Once the label representing the tree is popped off the MPLS label stack, the next label is the demultiplexing information that allows the proper P2MP PW to be determined. This determines the set of egress CE ACs that the packet needs to be forwarded to. The egress PE then strips the inner MPLS label and sends the packet to this set of egress CEs. 6.3. Layer 2 MTU This document requires that the Layer 2 MTU configured on all the access circuits connecting the CEs to PEs, for a given P2MP PW be the same. The P2MP PW signaling mechanisms must provide a means for ensuring this. The MTU on the Layer 2 access links MUST be chosen such that the size of the L2 frames plus the P2MP PW header does not exceed the MTU of the SP network. Layer 2 frames that exceed the MTU after encapsulation MUST be dropped. 7. Security Considerations TBD 8. IANA Considerations TBD Raggarwa [Page 7] Internet Draft draft-raggarwa-pwe3-p2mp-pw-encaps-01.txt March 2010 9. Acknowledgments Thanks to Yakov Rekhter and Kireeti Kompella for the discussions that lead to this document. 10. References 10.1. Normative References [VPLS-MCAST] R. Aggarwal et. al., "Multicast in VPLS", draft-ietf- l2vpn-vpls-mcast, work in progress. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label Assignment and Context Specific Label Space", RFC 5331 10.2. Informative References [VPMS-REQ] Y. Kamite, F. Jounay, "Framework and Requirements for Virtual Private Multicast Service (VPMS)", draft-ietf-l2vpn-vpms- frmwk-requirements, work in progress [RFC3985] S. Bryant et. al., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. [RFC4664] L. Andersson etl. al,, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006. [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007. [RFC4875] R. Aggarwal et. al, "Extensions to RSVP-TE for Point to Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp-07.txt [MLDP] I. Minei et. al, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp-02.txt [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006. [RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis, Raggarwa [Page 8] Internet Draft draft-raggarwa-pwe3-p2mp-pw-encaps-01.txt March 2010 "Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks", RFC 4618, September 2006. [RFC4619] Martini, L., Kawa, C., and A. Malis, "Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks", RFC 4619, September 2006. [RFC4717] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., Brayley, J., and G. Koleyni, "Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks", RFC 4717, December 2006. 11. Author's Address Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: rahul@juniper.net Frederic Jounay France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: frederic.jounay@orange-ftgroup.com Raggarwa [Page 9]