Network Working Group F. Jounay Internet Draft J.L. Le Roux Category: Standards Track P. Niger Expires: January 2011 France Telecom Orange L.Jin Y. Kamite ZTE NTT Communications July 12, 2010 LDP Extensions for Leaf-initiated Point-to-Multipoint Pseudowire draft-jounay-pwe3-leaf-initiated-p2mp-pw-02.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. This Internet-Draft will expire on January, 2011. Abstract This document provides a solution to extend LDP signaling to set up and maintain Point-to-Multipoint MultiSegment Pseudowire (P2MP MS- PW). The P2MP PW described in this draft is constructed by multiple unidirectional PW segments. Such an extension of existing point to point Pseudowire is made necessary by new applications. The document only deals with the leaf-initiated P2MP PW setup and maintenance. The Jounay et al. Expires April, 2009 [Page 1] Internet Draft Leaf-initiated P2MP MS-PW Setup July 2010 processing for setting up a P2MP MS-PW is based on the same as MLDP for P2MP LSP setup. 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 [RFC2119]. Table of Contents 1. Terminology.....................................................3 2. Preliminary Notes...............................................3 3. Introduction....................................................3 4. P2MP MS-PW Reference Model......................................3 5. MPLS-PW to MPLS-PW Replication..................................5 6. Overview of the P2MP MS-PW Setup................................5 7. LDP S-PE TLV....................................................5 8. Configuration...................................................6 9. Capability Negotiation Procedure................................6 10. Signaling for P2MP MS-PW with dynamic S-PE routing.............6 10.1. Label Map....................................................7 10.1.1. Determining one's 'upstream PE'............................7 10.1.2. Egress T-PE Operation......................................7 10.1.3. Branch S-PE Operation......................................7 10.1.4. Ingress T-PE Operation.....................................7 10.2. Label Withdraw...............................................8 10.2.1. Egress T-PE Operation......................................8 10.2.2. Branch S-PE Operation......................................8 10.2.3. Ingress T-PE Operation.....................................8 10.2.4. Upstream PE Change.........................................8 11. Security Considerations........................................8 12. IANA Considerations............................................9 13. Acknowledgments................................................9 14. References.....................................................9 14.1. Normative References.........................................9 14.2. Informative References.......................................9 Copyright Notice..................................................10 Authors's Addresses.. ............................................11 Intellectual Property and Copyright Statements....................12 Jounay et al. Expires January, 2011 [Page 2] Internet Draft Leaf-initiated P2MP MS-PW Setup July 2010 1. Terminology This document uses acronyms and terminologies defined in [RFC5036], [RFC3985], [P2MP PW REQ] and [RFC5254]. 2. Preliminary Notes The current version of the document does not cover: - The mechanism for the leaves to discover the P2MP PW FEC identifying the P2MP MS-PW, out of the scope of this document. - The P2MP PW Upstream Label Assignment required when the underlying layer is a P2MP LSP. This document describes LDP extensions for setting up P2MP MS-PW where the PW segments are supported over P2P PSN tunnels. 3. Introduction [P2MP PW REQ] describes a set of requirements for setting up a P2MP PW setup. In the MS-PW architecture, the underlying layer which supports a PW segment belonging to the PW tree may be either a unidirectional P2P or a P2MP PSN tunnel. Note that a P2MP PW is optionally bidirectional [P2MP PW REQ]. This version of the document does dot cover the return path from leaf to root, this point will be addressed in a next version. This document describes LDP extensions for setting up P2MP MS-PW where the PW segments are supported over P2P PSN tunnels. For that purpose the P2MP PW FEC element is reused from [ROOT INIT P2MP PW] to encode MS-PW parameters. The procedures for setting up a P2MP MS-PW are very similar with LDP mechanisms for setting P2MP LSP [MLDP], where hops are here S-PEs and T-PEs. Therefore a leaf can join the tree by sending a Label Map associated to this FEC towards the root. 4. P2MP MS-PW Reference Model Figure 1 describes the P2MP MS-PW reference model which is derived from [P2MP PW REQ] to support P2MP emulated services. Jounay et al. Expires January, 2011 [Page 3] Internet Draft Leaf-initiated P2MP MS-PW Setup July 2010 |<-----------P2MP MS-PW------------>| Native | P2P P2P | Native Service | |<-PSN1-->| |<-PSN2-->| | Service (AC) V V tunnels V V tunnels V V (AC) | +----+ +-----+ +----+ | | |T-PE| |S-PE1|=========|T-PE| | +----+ | | 1 | | .......PW3......2.|-----------|CE2 | | | |=========| . |=========| | | +----+ | | .......PW1....... | +----+ | | | . |=========| . | +----+ | | | . | | . |=========|T-PE| | +----+ | | . | | .......PW4......3.|-----------|CE3 | +----+ | | . | | |=========| | | +----+ |CE1 |---------|.. | +-----+ +----+ | +----+ | | . | +-----+ +----+ | | | . | |S-PE2|=========|T-PE| | +----+ | | . | | .......PW5......4.|-----------|CE4 | | | . | | . |=========| | | +----+ | | . |=========| . | +----+ | | | .......PW2....... +----+ | | | |=========| . |=========|T-PE| | +----+ | | | | .......PW6......5.|-----------|CE5 | | | | | |=========| | | +----+ | +----+ +-----+ +----+ | Figure 1 P2MP MS-PW over P2P PSN tunnels Reference Model Figure 1 describes the P2MP MS-PW reference model which is derived from [P2MP PW REQ] where the PW segments are supported over individual P2P PSN tunnels. Here in a P2MP MS-PW configuration the S- PE is responsible for switching a MS-PW from one input unidirectional P2P segment to one or several output unidirectional P2P segments at PW layer level. Referring to Figure 1, T-PE1 is the Ingress T-PE and T-PE2, T-PE3, T- PE4 and T-PE5 are the Egress T-PEs. The S-PE S-PE1 and S-PE2 play the role of branch S-PE since they are in charge of switching the input unidirectional P2P PW1 and the unidirectional P2P PW2 segment to respectively the output unidirectional P2P PW3,4 and the output unidirectional P2P PW5,6 segments. For example, packets received from unidirectional P2P PW1 will replicate to unidirectional P2P PW3 and PW4 at PW layer level. Note that a P2MP MS-PW may obviously transit through more than one S- PE along its path. Jounay et al. Expires January, 2011 [Page 4] Internet Draft Leaf-initiated P2MP MS-PW Setup July 2010 5. MPLS-PW to MPLS-PW Replication Referencing Figure 1, PDUs are replicated to the Pseudowire segments at the PW label level. Hence the data plane does not need any special knowledge of the specific PW type. A simple standard MPLS label swap operation is sufficient to connect the PW segments. However when pushing a new PSN label the TTL SHOULD be set to 255, or some other locally configured fixed value. This process can be repeated as many times as necessary, the only limitation to the number of S-PEs traversed is imposed by the TTL field of the PW MPLS Label. The setting of the TTL of the PW MPLS label is a matter of local policy on the originating PE, but SHOULD be set to 255 except OAM packet. 6. Overview of the P2MP MS-PW Setup The P2MP MS-PW setup relies on the use of the P2MP PW FEC Element defined also in [ROOT INIT P2MP PW]. The solution aims at setting up a unidirectional P2MP MS-PW. The principle proposed here relies on a leaf-initiated P2MP MS-PW setup. In the proposed approach the leaf is assumed to know the P2MP PW FEC which contains the source AII address and the VPN ID (AGI). The procedure used for the P2MP PW FEC discovery by the leaves is out of scope of this document. The document describes the solution to setup the P2MP MS-PW in the case the PW segments are supported individually over a P2P PSN tunnel. After a negotiation procedure between Ingress T-PE/S-PE and S-PE/Egress T-PEs to verify their P2MP PW FEC capability, the Egress T-PE sends a Label Map to its upstream PE selected to reach the SAII specified in the P2MP PW FEC. At turn the S-PE carries on the signalling procedure by sending if required a new Label Map towards its next hop to reach the source SAII. In the MS-PW architecture, the hop consists either in a branch S-PE or the Ingress T-PE. Each PE receiving the P2MP FEC installs a forwarding state to map traffic into the P2MP MS-PW. The definition of PW Type, C bit, PW Info Length, AGI, SAII, and Optional Parameters are same as defined in [ROOT INIT P2MP PW]. 7. LDP S-PE TLV The S-PE TLV defined in [SEGMENT MS-PW] can also be applied for P2MP MS-PW. PW loop detection will be performed by S-PE which is same as [SEGMENT MS-PW], by using Sub-TLV of Local IP address of S-PE. When egress PE sends notification to ingress PE to indicate PW status, each S-PE on the path to ingress PE SHOULD append S-PE TLV with local IP address to LDP notification message, which allows the Root T-PE to build the P2MP MS-PW topology. Jounay et al. Expires January, 2011 [Page 5] Internet Draft Leaf-initiated P2MP MS-PW Setup July 2010 8. Configuration After configuring on each T-PE the attached AIIs, it is assumed that all the PEs (Ingress/Egress T-PEs and all S-PEs) maintain an AII PW routing table which gives for each AII as entry the "next hop" to reach that AII. This AII routing table can be filled manually or updated dynamically by means of some extended routing protocol like proposed in [DYN MS-PW]. The construction of the table is out of scope of the present document. Each PE relies on its AII PW routing table to select the next hop PE (S-PE or T-PE) to reach a given AII. The target-LDP session between T-PE and S-PE, or two S-PEs should be configured automatically or manually. The P2MP MS-PW signaling message should be transmitted over this target-LDP session. 9. Capability Negotiation Procedure For the dynamic LDP protocol, the capability negotiation the solution MUST follow the PW Status Capability advertisement mechanism described in [ROOT INIT P2MP PW]. The PEs belonging to a given P2MP MS-PW MUST support the P2MP PW FEC Element used by LDP to setup the P2MP MS-PW. 10. Signaling for P2MP MS-PW with dynamic S-PE routing The following defines the rules for the processing and propagation of the P2MP FEC Element for the Leaf-initiated P2MP MS-PW setup. The following notation is derived from [MLDP] and is used in the processing rules: 1. P2MP PW FEC Element : a FEC Element with SAII X, AGI Y. 2. P2MP PW Label Map : a Label Map message with a FEC TLV with a single P2MP PW FEC Element and Label TLV with label L. 3. P2MP PW Label Withdraw : a Label Withdraw message with a FEC TLV with a single P2MP PW FEC Element and Label TLV with label L. 4. P2MP MS-PW (or simply ): a P2MP MS-PW with SAII X and AGI Y. 5. The notation L' -> { ..., } on branch S- PE S means that on receiving a packet with label L', S makes n copies Jounay et al. Expires January, 2011 [Page 6] Internet Draft Leaf-initiated P2MP MS-PW Setup July 2010 of the packet. For copy i of the packet, S swaps L' with Li and sends it out over interface Ii. The procedures below are organized by the role which the PE plays in the P2MP MS-PW. T-PE Z knows that it is an Egress T-PE by a discovery process which is outside the scope of this document. A T-PE is defined as an Egress T-PE if one or several leaf AIIs are configured. During the course of protocol operation, the Ingress T-PE recognizes its role because it owns the SAII of the PW tree. 10.1. Label Map The following lists procedures for generating and processing P2MP Label Map messages for PEs participating in a P2MP MS-PW. For the approach described here we use downstream assigned labels. 10.1.1. Determining one's 'upstream PE' For the case of P2MP MS-PW with dynamic S-PE routing, a a PE Z that is part of P2MP MS-PW determines the T-LDP peer U which lies on the best path from Z to the SAII. The path selection is achieved by means of looking up the AII PW routing table. U is Z's "Upstream PE" for . 10.1.2. Egress T-PE Operation An Egress T-PE Z of P2MP MS-PW determines its upstream PE U for , allocates a label L, and sends a P2MP PW Label Map to U. 10.1.3. Branch S-PE Operation Suppose a branch S-PE Z receives a P2MP PW Label Map from LDP peer T. Z checks whether it already has state for . If not, Z allocates a label L', and installs state to swap L' with L over interface I associated with peer T. Z also determines its upstream PE U for and sends a P2MP PW Label Map to U. If Z already has state for , then Z does not send a Label Map message for P2MP MS-PW . All that Z needs to do in this case is to update its forwarding state. Assuming its old forwarding state was L'-> { ..., }, its new forwarding state becomes L'-> { ..., , }. 10.1.4. Ingress T-PE Operation Suppose the Ingress T-PE Z receives a P2MP Label Map from peer T. Z checks whether it already has forwarding state for . Jounay et al. Expires January, 2011 [Page 7] Internet Draft Leaf-initiated P2MP MS-PW Setup July 2010 If not, Z creates forwarding state to push label L onto the traffic that Z wants to forward over the P2MP MS-PW. If Z already has forwarding state for , then Z adds "push label L, send over interface I" to the nexthop, where I is the interface associated with peer T. 10.2. Label Withdraw The following lists procedures for generating and processing P2MP PW Label Withdraw messages for PEs that participate in a P2MP MS-PW. 10.2.1. Egress T-PE Operation If an Egress T-PE Z discovers that it has no longer leaves AII belonging to the P2MP MS-PW, it SHOULD send a P2MP PW Label Withdraw to its upstream PE U for , where L is the label it had previously advertised to U for . 10.2.2. Branch S-PE Operation If a branch S-PE Z receives a P2MP PW Label Withdraw message from a node W, it deletes label L from its forwarding state, and sends a P2MP PW Label Release message with label L to W. If deleting L from Z's forwarding state for P2MP MS-PW results in no state remaining for , then Z propagates the P2MP PW Label Withdraw for , to its upstream T, by sending a P2MP PW Label Withdraw where L1 is the label Z had previously advertised to T for . 10.2.3. Ingress T-PE Operation The procedure when the Ingress T-PE of a P2MP MS-PW receives a P2MP PW Label Withdraw message are the same as for branch S-PE, except that it would not propagate the P2MP PW Label Withdraw upstream (as it has no upstream). 10.2.4. Upstream PE Change If, for a given PE Z participating in a P2MP MS-PW , the upstream PE changes, say from U to U', then Z MUST update its forwarding state by deleting the state for label L, allocating a new label, L', for , and installing the forwarding state for L'. In addition Z MUST send a P2MP PW Label Map to U' and send a P2MP PW Label Withdraw to U. 11. Security Considerations This section will be added in a future version. Jounay et al. Expires January, 2011 [Page 8] Internet Draft Leaf-initiated P2MP MS-PW Setup July 2010 12. IANA Considerations This draft does not define any new protocol element, and hence does not require any IANA action. 13. Acknowledgments 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, March 1997. [RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., Thomas, B., "LDP Specification", October 2007. [RFC3985] Bryant, S., Pate, P. "PWE3 Architecture", March 2005 [RFC5254] Bitar, N., Bocci, M., and Martini, L., "Requirements for inter domain Pseudo-Wires", October 2008 14.2. Informative References [P2MP PW REQ] Jounay, F., Niger, P., Kamite, Y., Martini, L., Heron, G., Wang, L., Delord, .S, "Use Cases and signaling requirements for Point-to-Multipoint PW", Internet Draft, draft-ietf-pwe3-p2mp-pw- requirements-02.txt, January 2010 [DYN MS-PW] Balus, F., Bocci, M., Martini. L, "Dynamic Placement of Multi Segment Pseudo Wires", Internet Draft, draft-ietf-pwe3-dynamic-ms-pw- 10.txt, October 2009 [SEGMENT MS-PW] Martini, L, &all, "Segmented Pseudowire", Internet Draft, draft-ietf-pwe3-segmented-pw- 15.txt, June 2010 [MLDP] Minei, I., Kompella, K., Thomas, B., Wijnands, I. "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Internet Draft, draft- ietf-mpls-ldp-p2mp-10, July 2010 Jounay et al. Expires January, 2011 [Page 9] Internet Draft Leaf-initiated P2MP MS-PW Setup July 2010 [ROOT INIT P2MP PW] Martini, L., Jounay, &all , "Signaling Root-Initiated Point-to-Multipoint Pseudowires using LDP", draft-martini- pwe3-p2mp-pw-01, October, 2009 Author's Addresses Frederic Jounay France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: frederic.jounay@orange-ftgroup.com Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: jeanlouis.leroux@orange-ftgroup.com Philippe Niger France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: philippe.niger@orange-ftgroup.com Yuji Kamite NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku Tokyo 163-1421 Japan Email: y.kamite@ntt.com Lizhong Jin ZTE Corporation 889, Bibo Road Shanghai, 201203, China Email: lizhong.jin@zte.com.cn Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Jounay et al. Expires January, 2011 [Page 10] Internet Draft Leaf-initiated P2MP MS-PW Setup July 2010 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. 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. Jounay et al. Expires January, 2011 [Page 11]