PWE3 Working Group Haiyan Zhang Internet Draft Jixiong Dong Yang Yang Huawei Expires: August 2006 February 21, 2006 Pseudowire for Supporting Multicast traffic draft-zhang-pwe3-pw-mcast-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 August 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract This document describes the solution for supporting the efficient transport of multicast-based services and the corresponding Label Distribution Protocol (LDP) protocol extensions and procedures. Zhang Expires August 21, 2006 [Page 1] Internet-Draft draft-zhang-pwe3-pw-mcast-00.txt February 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. Table of Contents 1. Introduction................................................2 2. Terminology.................................................3 3. Overview of Solution.........................................3 4. Reference Model for P2MP PW..................................4 5. Signaling Procedures.........................................6 5.1. Setup..................................................6 5.2. Teardown...............................................6 6. Capability Negotiation Procedures............................7 6.1. PW Status..............................................7 6.2. Control Word...........................................7 7. Potential Issues............................................8 8. LDP Extensions..............................................8 8.1. FEC Element............................................8 8.2. Status TLV............................................10 9. Sequencing Considerations...................................10 10. Security Considerations....................................10 11. IANA Considerations........................................10 12. Acknowledgments...........................................11 13. References................................................11 13.1. Normative References..................................11 13.2. Informative References................................11 14. Author's Addresses........................................12 15. Intellectual Property Statement............................12 Disclaimer of Validity........................................13 Copyright Statement...........................................13 Acknowledgment................................................13 1. Introduction With a growing need for transmitting the multicast-based services such as IP TV, DVB etc., it is necessary to support the efficient transport of the multicast-based services in networks. The Working Groups, such as MPLS and L2VPN, has begun to discuss the requirements and solutions for multicast. In the same way, the solutions are needed to support the multicast traffic over PW. The purpose of this document is to propose procedures to transmit the multicast traffic using the unidirectional Pseudowires (PWs), and Zhang Expires August 21, 2006 [Page 2] Internet-Draft draft-zhang-pwe3-pw-mcast-00.txt February 2006 describe the corresponding extensions to Label Distribution Protocol (LDP). 2. Terminology The document defines the following additional terms: - Point-to-Point Pseudo Wire (P2P PW). A PW that is bidirectional and carries the essential elements of an emulated service from one PE to the other PE over a PSN. - Point-to-Multipoint Pseudo Wire (P2MP PW). A PW that has one ROOT PE and one or more LEAF PEs, is a unidirectional tree and carries the essential elements of an emulated service from ROOT PE to one or more LEAF PEs over a PSN. - P2MP PW ROOT Provider Edge (ROOT PE). Source of a P2MP PW, maps multicast traffic into P2MP PW, also referred to as ingress PE of multicast traffic. - P2MP PW LEAF Provider Edge (LEAF PE). One of many potential destinations of a P2MP PW, initiates the signaling message that setup and tear-down P2MP PW, also referred to as egress PE of multicast traffic. 3. Overview of Solution The current procedures for establishing a PW is described in [PWE3- CTRL], where typically an LDP session is established between two PEs handling the point-to-point Pseudowire (P2P PW) End Service. A solution to support multicast traffic may use the point-to-point PWs across the provider network and the existing signaling procedures. In this case, the ingress PE simply replicates and sends the multicast packet for each egress PE over all corresponding PWs. The solution has the advantage in ensuring the P and PE devices isolated from the multicast issues. But this is not clearly optimal. The replication is implemented on the PE, so it wastes bandwidth and is only applicable to transmit the multicast traffic with the low bandwidth and the small egresses. Thus the other mechanisms are required to efficiently support the multicast-based services. The point-to-multipoint unidirectional PWs similar to the multicast tree may be constructed to transmit the multicast-based services. It may overcome the limitation of the above-mentioned solution and need to extend the existing LDP protocol. Zhang Expires August 21, 2006 [Page 3] Internet-Draft draft-zhang-pwe3-pw-mcast-00.txt February 2006 In this instance, the PSN tunnel used to carry the point-to- multipoint PW (P2MP PW) may consist of a P2MP LSP, or multiple P2P and P2MP LSPs, and may be pre-provisioned or dynamically established by LDP[P2MP-LDP] or RSVP[P2MP-RSVP] signaling. A PSN tunnel may carry one or more P2MP PWs. A P2MP PW consists of a single ROOT PE, and one or more LEAF PEs. The ROOT PE must have a targeted LDP session with each of LEAF PEs. The LEAF PEs initiate P2MP PW setup and tear-down. The ROOT PE installs forwarding state to map traffic into the P2MP PW. A P2MP PW emulates a unidirectional service from the ROOT PE to the LEAF PEs. For multicast-based service, only a single copy of packet needs to be transmitted, and can only carry one PW label. So the all LEAF PEs should assign the same PW label for the same P2MP PW. Upstream label allocation is proposed in [MCAST-OVER-P2MP] and [LDP- UPSTREAM]. The ROOT (upstream) PE is responsible for coordinating, allocating, and distributing the labels used by the LEAF PEs so that a single copy of the labeled packet may be sent to all LEAF PEs. In this document, the solution proposed use the upstream label allocation for establishing P2MP PWs cross a single domain, and the PSN tunnel is a pre-provisioned or dynamically established P2MP LSP. The P2MP PWs cross the multiple domains and a PSN tunnel consisting of multiple P2P and P2MP LSPs, will be discussed in the next version. 4. Reference Model for P2MP PW The following figure describes P2MP PW reference model. Zhang Expires August 21, 2006 [Page 4] Internet-Draft draft-zhang-pwe3-pw-mcast-00.txt February 2006 |<---- P2MP Pseudo Wire ---->| | | | |<--- PSN P2MP --->| | V V Tunnel V V +----+ +----+ | |==================| PE2| +-----+ |............PW1.............|----------| | | | | | | CE2 | |............PW2.............|----------| | | |==================| | +-----+ | | +----+ Customer | | Provider Edge 2 Edge 2 | | +----+ +-----+ | PE1|==================| PE3| +-----+ | |----------|............PW1.............|----------| | | CE1 | | | | | | CE3 | | |----------|............PW2.............|----------| | +-----+ ^ | |==================| | +-----+ Customer^ | | | +----+ Customer Edge 1 | | | | Provider Edge 3 Edge 3 | | | | +----+ | | | |==================| PE4| +-----+ | | |............PW1.............|----------| CE4 | | | | |==================| | ^ +-----+ | | +----+ +----+ | ^Customer | | Provider Edge 1 Provider Edge 4 | | Edge 4 | | | | | Attachment Attachment| | Circuit Circuit | | | |<-------------- Emulated Service ---------------->| Figure 1 P2MP PW Reference Model PE1, PE2, PE3 and PE4 provide multicast-based service, i.e.PW1, to CE1, CE2, CE3 and CE4. These PEs reside in same PSN domain. A PSN P2MP tunnel is used to connect the attachment circuits (ACs) attached to PE1 to the corresponding ACs attached to PE2, PE3 and PE4. PE1 is ROOT PE, and PE2, PE3, PE4 are LEAF PEs. Another multicast-based service is also carried in the same PSN P2MP tunnel, i.e.PW2. PE1 is ROOT PE, and PE2, PE3 are LEAF PEs. Zhang Expires August 21, 2006 [Page 5] Internet-Draft draft-zhang-pwe3-pw-mcast-00.txt February 2006 5. Signaling Procedures For the upstream label allocation, the ROOT PE allocates and advertises the labels for a P2MP PW, and it solves the issue of coordination of labels between the LEAF PEs for a P2MP PW. 5.1. Setup The setup procedures for upstream label allocation are shown in Figure 2. A LEAF PE wishing to join to a P2MP PW sends a Label Request message to request upstream label allocation. The message contains the multicast FEC TLV identifying a P2MP PW and the Upstream-Assigned Label Request TLV indicating to request upstream label allocation. The ROOT PE receiving such Label Request message verifies the multicast FEC TLV and responds a Label Mapping message with an allocated label in the Upstream-Assigned Label TLV for the multicast FEC TLV. The ROOT PE will allocate the same label for the LEAF PEs sending Label Request message with the same multicast FEC TLV. If the LEAF PE, receiving a Label Mapping message with an Upstream- Assigned Label TLV, does not recognize the TLV, it MUST respond a Notification message with a status code "Unknown TLV" [RFC3036]. If it does recognize the TLV but is unable to process the allocated label, it MUST respond a Notification message with a status code of "No Label Resources". ROOT PE LEAF PEs | | | Label Request (Request TLV) | |<--------------------------------| | Label Mapping (allocate Label) | |-------------------------------->| | | Figure 2 Upstream label allocation 5.2. Teardown When the ROOT PE receives a Label Withdraw message with a multicast FEC TLV from a LEAF PE, it snips off the LEAF PE from the corresponding P2MP PW. Zhang Expires August 21, 2006 [Page 6] Internet-Draft draft-zhang-pwe3-pw-mcast-00.txt February 2006 Until the ROOT PE removes the final LEAF PE, the P2MP PW is tore down. The ROOT PE releases the label and removes the forwarding state to map traffic into the P2MP PW. 6. Capability Negotiation Procedures During P2MP PW setup process, the PEs need to exchange some information and learn each other's capability, e.g. the usage of PW status TLV and control word and so on. For a P2MP PW, all LEAF PE and ROOT PE must agree on the capability. For upstream label allocation, the ROOT PE decides the capability of the P2MP PW, i.e., if the LEAF PE does not support the capability the ROOT PE does, it will be unable to join to the corresponding P2MP PW. 6.1. PW Status If a PW Status TLV is contained in a message (Label Request for LEAF PEs, Label Mapping for ROOT PE), it indicates that the PE supports the PW Status TLV. If the ROOT PE supports the PW Status TLV, and receives the Label Request message not including a PW Status TLV, then the ROOT PE responds with the Label Release message including the new defined status code "Using PW Status TLV not consistent". The LEAF PE will be unable to join to the P2MP PW. If the ROOT PE does not support the PW Status TLV, and receives the Label Request message including a PW Status TLV, then the ROOT PE responds with the Label Mapping message not including the PW Status TLV. The P2MP PW will revert to the label withdraw method of signaling PW status. The ROOT PE will automatically ignore the PW Status TLV in which the U bit (Unknown message bit) is set. The LEAF PE may join to the P2MP PW. 6.2. Control Word If the C-bit (Control Word bit) of multicast FEC TLV in message is set, i.e. C=1, it indicates that the PE sending message supports the control word. - The control word is REQUIRED for the PW type. If the ROOT PE, that receives the Label Request message of a LEAF PE with C=0, MUST respond a Label Release message with an "Illegal C-bit" status code. And the LEAF PE will be unable to join to the P2MP PW. - The control word is NOT mandatory for the PW type. Zhang Expires August 21, 2006 [Page 7] Internet-Draft draft-zhang-pwe3-pw-mcast-00.txt February 2006 If the ROOT PE, that supports the use of the control word, receives the Label Request message of a LEAF PE with C=0, then the ROOT PE sends a Label Release message with a "Wrong C-bit" status code. And the LEAF PE will be unable to join to the P2MP PW. If the ROOT PE, that does not support the use of the control word, receives the Label Request message of a LEAF PE with C=1, it responds a Label Mapping message with C=0. The LEAF PE receiving such message sends a Label Withdraw message with a "Wrong C-bit" status code, and may initiate a Label Request message with C=0 over again. And the LEAF PE will be accepted. 7. Potential Issues Upstream label allocation may be used only when both the ROOT PE and the LEAF PE support it, i.e. the ROOT PE need negotiate the capability supporting upstream label allocation with the LEAF PEs. If some of LEAF PEs support upstream label allocation and some of LEAF PEs do not, a P2MP PW will be established between the ROOT PE and all those LEAF PEs that can support upstream label allocation, and the individual P2P PWs will be established from the ROOT PE to each of the LEAF PEs that do not support it. The signaling mode of the "Upstream label allocation" differs from the existing P2P PW that uses LDP in its "downstream unsolicited" mode. 8. LDP Extensions The solutions described above require several protocol extensions to LDP. 8.1. FEC Element The multicast FEC TLV includes a P2MP PW FEC Element to identify a P2MP PW. The two new FEC Element types, P2MP PWid FEC Element and P2MP Generalized PWid FEC Element, are defined corresponding to PWid FEC Element and Generalized PWid FEC Element in [PWE3-CTRL]. A P2MP PW may be identified using alternative FEC Elements. Zhang Expires August 21, 2006 [Page 8] Internet-Draft draft-zhang-pwe3-pw-mcast-00.txt February 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P2MP PWid (TBD)|C| P2MP PW Type |PW info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Parameter Sub-TLV (Variable Length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LEAF PEs must be provisioned with the same 32-bit PW identifier to the same P2MP PW for using P2MP PWid FEC element. Each of LEAF PEs independently initiates message with the corresponding PW ID to join to a P2MP PW. The LEAF PEs with the same PW ID belongs to a single P2MP PW, and are allocated the same label. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P2MP GPWid(TBD)|C| P2MP PW Type |PW info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI Type | Length | AGI Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI Value (contd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | Length | SAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SAII Value (contd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | Length | TAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TAII Value (contd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LEAF PE must know the address of the ROOT PE and a TAI by manually configured or dynamically learned for using P2MP PW Generalized PWid FEC element. When the ROOT PE receives an originating message (Label Request) from a LEAF PE, it will verify the multicast FEC TLV in such message. If it can not map the TAI in multicast FEC TLV to one of its Forwarders, then it sends a Label Release message to the LEAF PE with Zhang Expires August 21, 2006 [Page 9] Internet-Draft draft-zhang-pwe3-pw-mcast-00.txt February 2006 a status code "Unassigned/Unrecognized TAI". The LEAF PE will be unable to join to the P2MP PW. If it can map the TAI to one of its Forwarders, the establishment procedures of the P2MP PW will continue. In nature, a TAI of the ROOT PE may uniquely identify a P2MP PW. 8.2. Status TLV The Label Request message may include the PW Status TLV. A new LDP status code is defined for "Using PW Status TLV not consistent", and it needs to be assigned by [IANA]. 9. Sequencing Considerations Support for sequencing depends on the PW type, and implemented by the sequence number field in the control word. It may be omitted if not needed. In case of supporting sequencing, it must be assured to wait a sufficient interval before re-using the released label. Otherwise the residual packets will be intermixed with the new starting packets, and the LEAF PEs will receive the packets with orderless sequencing numbers. Some packets will be rejected. 10. Security Considerations A PSN tunnel consisting of a pre-provisioned P2MP LSP may carry one or more P2MP PWs, but these P2MP PWs may include the different sets of LEAF PEs. This means that the traffic for a P2MP PW will be delivered to the LEAF PEs of the other P2MP PWs. This issue will be discussed in the future. 11. IANA Considerations This document requires IANA to define the following new FEC element types. FEC element Type Description TBD P2MP PWid FEC Element TBD P2MP Generalized PWid FEC Element Zhang Expires August 21, 2006 [Page 10] Internet-Draft draft-zhang-pwe3-pw-mcast-00.txt February 2006 A new Status Code appears in section 4.2.1, 5.2.1, and 6.2.1, which needs assignment by IANA. Status Code Description TBD "Using PW Status TLV not consistent" 12. Acknowledgments 13. References 13.1. Normative References [PWE3-CTRL] Luca Martini (ED), Toby Smith, "Pseudowire Setup and Maintenance using the Label Distribution Protocol", draft- ietf-pwe3-control-protocol-17.txt, June 2005. [P2MP-LDP] I. Minei (ED), K. Kompella, I. Wijnandset (ED), B. Thomas, "Label Distribution Protocol Extensions for Point-to- Multipoint and Multipoint-to-Multipoint Label Switched Paths", draft-minei-wijnands-mpls-ldp-p2mp-00, October 2005. [P2MP-RSVP] R. Aggarwal (ED), D. Papadimitriou (ED), S. Yasukawa (ED), "Extensions to RSVP-TE for Point to Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp-03, October 2005. [MCAST-OVER-P2MP] Seisho Yasukawa, Adrian Farrel, "Support of LDP Multicast Label Switched Paths over Point-to-Multipoint Label Switched Path Tunnels and on Multi-Access Links", draft-yasukawa-mpls-ldp-mcast-over-p2mp-lsps-01, October 2005. [LDP-UPSTREAM] R. Aggarwal, J. L. Le Roux, "MPLS Upstream Label Assignment for LDP", draft-raggarwa-mpls-ldp-upstream-00, October 2005. [RFC3036] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, "LDP Specification", RFC3036, January 2001. 13.2. Informative References [PWE3-ARCH] Bryant, S., Pate, P., "PWE3 Architecture", RFC 3985,March 2005. Zhang Expires August 21, 2006 [Page 11] Internet-Draft draft-zhang-pwe3-pw-mcast-00.txt February 2006 [PWE3-REQ] Xiao, X., McPherson, D., Pate, P., "Requirements for Pseudo Wire Emulation Edge to-Edge (PWE3)", RFC 3916, September 2004. [IANA] Luca Martini, "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-15, November 2005. 14. Author's Addresses Haiyan Zhang Huawei Technologies Co., Ltd. Bantian industry base, Longgang district Shenzhen, China Email: zhanghaiyan@huawei.com Jixiong Dong Huawei Technologies Co., Ltd. Bantian industry base, Longgang district Shenzhen, China Email: dongjixiong@huawei.com Yang Yang Huawei Technologies Co., Ltd. Bantian industry base, Longgang district Shenzhen, China Email: healthinghearts@huawei.com 15. 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. Zhang Expires August 21, 2006 [Page 12] Internet-Draft draft-zhang-pwe3-pw-mcast-00.txt February 2006 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Zhang Expires August 21, 2006 [Page 13]