Network Working Group Yiqun Cai Internet Draft Eric C. Rosen (Editor) Intended Status: Proposed Standard IJsbrand Wijnands Expires: August 2, 2010 Cisco Systems, Inc. Arjen Boers February 2, 2010 MVPN: Using Bidirectional P-Tunnels draft-rosen-l3vpn-mvpn-bidir-00.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 Rosen, et al. [Page 1] Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010 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. Abstract The documents specifying multicast support for BGP/MPLS IP VPNs allow customer multicast data to be transported through a service provider's network through a set multicast tunnels. Such tunnels are advertised by BGP in a BGP attribute known as the "Provider Multicast Service Interface (PMSI) Tunnel Attribute". The base specifications allow the PMSI Tunnel Attribute to advertise bidirectional multicast distribution trees as "PMSI Tunnels"; however, those document do not provide all the necessary details for doing so. Those details are provided in this document. These additional details are also applicable when bidirectional PMSI Tunnels are advertised in the datagram messages known as "S-PMSI Join Messages". This document also specifies the procedures for assigning customer multicast flows to specific bidirectional PMSI tunnels. Rosen, et al. [Page 2] Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010 Table of Contents 1 Specification of requirements ......................... 3 2 Introduction .......................................... 4 3 Advertising Bidirectional P-tunnels ................... 5 3.1 BIDIR-PIM P-Tunnels with GRE Encapsulation ............ 5 3.2 MP2MP LSPs ............................................ 6 3.2.1 MP2MP LSPs without PE Distinguisher Labels ............ 6 3.2.2 MP2MP LSPs with PE Distinguisher Labels ............... 6 3.2.3 Default Tunnel Identifier for MP2MP LSPs .............. 7 4 Associating Received Packets with VRFs ................ 7 5 Data Transmission and Reception ....................... 8 5.1 Without PE Distinguisher Labels ....................... 8 5.1.1 Binding (C-S,C-G) to Bidirectional P-tunnels .......... 8 5.1.2 Binding (C-*,C-G) Flows from Unidirectional C-trees ... 8 5.1.3 Binding (C-*,C-G) Flows from Bidirectional C-trees .... 9 5.1.4 Binding (C-*,C-*) ..................................... 9 5.2 With PE Distinguisher Labels .......................... 11 6 IANA Considerations ................................... 12 7 Security Considerations ............................... 12 8 Authors' Addresses .................................... 12 9 Normative References .................................. 13 10 Informative References ................................ 13 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]. Rosen, et al. [Page 3] Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010 2. Introduction The base documents for MVPN, [MVPN] and [MVPN-BGP], define a "PMSI Tunnel Attribute" (PTA) that may be carried in the BGP I-PMSI A-D routes and BGP S-PMSI A-D routes that are defined therein. However, those documents do not contain the full set of specifications governing the use of the PTA to advertise bidirectional P-Tunnels. Those specifications are provided in this document. The base documents do define the way that bidirectional P-tunnels are identified in the PTA, and the way in which the identifier of a bidirectional P-tunnel is encoded in the PTA. The corresponding encodings used in "S-PMSI Join Messages" [MVPN] are defined in [MVPN_SPMSI_JOINS]. Those identifiers and encodings are not changed by this specification. This document also specifies the procedures for assigning customer multicast flows to specific bidirectional PMSI tunnels. Two kinds of bidirectional P-tunnels are discussed in this document: - Multicast distribution trees that are created through the use of BIDIR-PIM [BIDIR-PIM], and that use GRE to encapsulate packets transmitted on the tunnels - Multipoint-to-multipoint Label Switched Paths (MP2MP LSPs), created by Label Distribution Protocol (LSP) Multipoint-to- Multipoint extensions [mLDP]. This document also specifies two different methods for using MP2MP LSPs as P-tunnels: - MP2MP LSPs with PE Distinguisher Labels - MP2MP LSPs without PE Distinguisher Labels. In the following, we will sometimes talk of a PE receiving traffic from a PMSI and then discarding it. If PIM [PIM] is being used as the multicast control protocol between PEs, this always implies that the discarded traffic will not be seen by PIM on the receiving PE, and thus will not cause PIM state changes on that PE. In the following, we will sometimes speak of an S-PMSI A-D route being "ignored". When we say the route is "ignored", we do not mean that it's normal BGP processing is not done, but that the route is not considered when determining which P-tunnel to use when sending multicast data, and that the MPLS label values it conveys are not used. We will generally use "ignore" in quotes to indicate this Rosen, et al. [Page 4] Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010 meaning. 3. Advertising Bidirectional P-tunnels In this specification, we consider the use of bidirectional P-tunnels as advertised in the PTA of a BGP S-PMSI A-D route, or as advertised in the P-Group field or the FEC Element field of an S-PMSI Join message. 3.1. BIDIR-PIM P-Tunnels with GRE Encapsulation Each BIDIR-PIM P-Tunnel is identified by a unique P-group address [MVPN, section 3.1]. (The P-group address is called a "P-Multicast Group" in [MVPN-BGP]). The P-group address for a BIDIR-PIM P-tunnel must be configured at the PE that is to be the root of the P-tunnel. Associated with each such P-group address is a "Rendezvous Point Address" (RPA). Every PE that needs to join a particular BIDIR-PIM P-tunnel must be able to determine the RPA that corresponds to the P-tunnel's P-group address. This may be known through configuration, or by some automated means of RPA discovery. The RPA for a given P-group MUST uniquely identify the PE that is to be the root of the BIDIR-PIM tunnel. If a BIDIR-PIM P-tunnel is to be used, the path from each PE in the tunnel to the RPA MUST consist entirely of point-to-point links. In order to set up a BIDIR-PIM P-Tunnel, the P routers must also be able to determine the RPA associated with the PE at the root of the tunnel. If this is not known via some automated means of RP discovery, it can be determined from the PIM Join messages themselves, where the RPA is encoded in the source address field. The advertisement of a BIDIR-PIM P-Tunnel MUST be originated by the root of the tunnel. Any advertisement that is not originated by the root MUST be "ignored". If the "ignored" advertisement is a BGP A-D route, any MPLS label specified in its PTA MUST be ignored, and any PE Distinguisher Labels [MVPN-BGP] specified in the route MUST be ignored. Rosen, et al. [Page 5] Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010 3.2. MP2MP LSPs An MP2MP LSP is identified by an "MP2MP FEC element" [mLDP]. The FEC element contains the IP address of the "root", followed by an "opaque value" that identifies the MP2MP LSP uniquely in the context of the root's IP address. This opaque value may be configured or autogenerated, and within an MVPN, there is no need for different roots to use the same opaque value. Whether a particular VPN uses MP2MP LSPs with or without PE Distinguisher Labels is determined by provisioning. 3.2.1. MP2MP LSPs without PE Distinguisher Labels If an MP2MP LSP without PE Distinguisher Labels is being used, then the PE Distinguisher Labels attribute [MVPN-BGP] MUST NOT be included in any S-PMSI A-D route containing a PTA identifying that LSP. The advertisement of an "MP2MP LSP without PE Distinguisher Labels" P-tunnel MUST be originated by the PE that is the root (as specified in the advertised "FEC element") of the MP2MP LSP. Any such advertisement that is not originated by the root MUST be "ignored". If the "ignored" advertisement is a BGP A-D route, any MPLS label specified in its PTA MUST be ignored, and any PE Distinguisher Labels specified in the route MUST be ignored. 3.2.2. MP2MP LSPs with PE Distinguisher Labels If an MP2MP LSP with PE Distinguisher Labels is being used, it MUST be advertised in the PTA of a BGP A-D route originated by the root of the LSP. That route MUST include a "PE Distinguisher Labels" attribute. The PE at the root of the LSP MUST use the PE Distingusiher Labels attribute to bind an upstream-assigned MPLS label to the IP address of each other PE that attaches to the same MVPN (as determined by the RTs of the A-D route). That is, the PE at the root of the P-tunnel assigns a distinct label to each of the other PEs attaching to the same MVPN. This set of PEs is learned via the reception of Intra-AS I-PMSI A-D routes. An MP2MP LSP with PE Distinguisher Labels may also be advertised in an S-PMSI A-D route by a PE that is not at the root of the LSP. In this case, the PE Distinguisher Labels attribute MUST be omitted. Rosen, et al. [Page 6] Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010 3.2.3. Default Tunnel Identifier for MP2MP LSPs This section applies only to MP2MP LSPs without PE Distinguisher Labels. To identify a MP2MP LSP, the S-PMSI Join message or the PTA of a BGP A-D route contains an MP2MP FEC Element [mLDP] in its "Tunnel Identifier" field. This contains the IP address of the PE at the root of the LSP, as well as an "opaque value" which is unique at that PE. Each PMSI Tunnel is associated at its root PE with a particular VRF, and each VRF in a given PE has a unique default RD. Therefore one way to uniquely identify a MP2MP LSP is to use a MP2MP FEC Element whose Opaque Value length is 8 and whose Opaque Value value is the default RD of the associated VRF. This method of assigning a Tunnel Identifier MUST be the default method for any PMSI Tunnel which is bound to (C-*,C-*) traffic. Other methods MAY be available as well. Note that if aggregation of multiple VPNs onto a single default MP2MP LSP is not being supported, this method of assigning the Tunnel Identifier allows each PE to algorithmically determine the Tunnel Identifier that has been assigned by a particular upstream PE. A PE decides to join a particular MP2MP LSP because it has chosen that LSP's root as the upstream PE for a particular VPN-IP address. The RD of that VPN-IP address is the contents of the Opaque Value field of the corresponding MP2MP LSP FEC Element. 4. Associating Received Packets with VRFs When a packet is received from a bidirectional P-tunnel, the packet is first associated one or more VRFs, and then processed in the context of that VRF or VRFs. If the bidirectional P-tunnel was advertised in an S-PMSI Join message or in the PTA of an A-D route that did not specify an MPLS label, then all packets received from the P-tunnel are associated with the same set of VRFs. If the bidirectional P-tunnel was advertised in the PTA of an A-D route, and the PTA does specify an MPLS label, then received packets will carry a label that must be processed in order to determine the context. If the P-tunnel is a MP2MP LSP, this label appears below the label that identifies the LSP itself. If the procedure of section 3.2.3 is being used, the association of a received packet with a VRF can be determined algorithmically. Rosen, et al. [Page 7] Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010 5. Data Transmission and Reception 5.1. Without PE Distinguisher Labels The procedures in this section apply to P-tunnels on which PE Distinguisher Labels are not used. See section 5.2 for the specification of the use of P-tunnels on which PE Distinguisher Labels are used. 5.1.1. Binding (C-S,C-G) to Bidirectional P-tunnels When PE1 advertises an S-PMSI A-D route that binds a (C-S,C-G) flow to a bidirectional P-tunnel, or when PE1 sends an S-PMSI Join message that binds a (C-S,C-G) flow to a bidirectional P-tunnel, the semantics are as follows. PE1 is stating that any (C-S,C-G) traffic that it needs to transmit to other PEs will be transmitted on the specified P-tunnel. Any other PE that needs to receive such traffic from PE1 (i.e., any other PE that needs to receive (C-S,C-G) traffic and which has selected PE1 as the upstream PE for C-S) MUST join that P-tunnel. If a PE has joined the P-tunnel, but does not need to receive the (C-S,C-G) traffic, or if it needs to receive (C-S,C-G) traffic but has not selected PE1 as the upstream PE for C-S, then the PE MUST discard any such received traffic. Please note that if PIM is being used as the multicast control protocol, any traffic that is discarded will not be seen by PIM, and hence will not cause the generation of Assert messages. 5.1.2. Binding (C-*,C-G) Flows from Unidirectional C-trees When PE1 advertises an S-PMSI A-D route or sends an S-PMSI Join message that binds (C-*,C-G) [MVPN_WILD] to a bidirectional P-tunnel, where C-G is not a "Source-Specific Multicast" (SSM) group, and the (C-*,C-G) traffic is traveling on a unidirectional shared C-tree, the semantics are as follows. PE1 is stating that any traffic to C-G that is traveling the shared C-tree and which PE1 needs to transmit to other PEs will be transmitted on the specified P-tunnel. Any other PE that needs to receive such traffic from PE1 (i.e., any other PE that needs to receive (C-*,C-G) traffic and which has selected PE1 as the upstream PE for the C-RP corresponding to the C-G group) MUST join that P-tunnel. If a PE has joined the P-tunnel, but does not need to receive the (C-*,C-G) traffic, or if it needs to receive (C-*,C-G) traffic but Rosen, et al. [Page 8] Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010 has not selected PE1 as the upstream PE for the C-RP that corresponds to C-G, then the PE MUST discard any such received traffic. Please note that if PIM is being used as the multicast control protocol, traffic that is discarded will not be seen by PIM. 5.1.3. Binding (C-*,C-G) Flows from Bidirectional C-trees When PE1 advertises an S-PMSI A-D route or sends an S-PMSI Join message that binds (C-*,C-G) to a bidirectional P-tunnel, where C-G is not an SSM group, and the (C-*,C-G) traffic is traveling on a bidirectional shared C-tree, the semantics are as follows: - PE1 is stating that any traffic to C-G that it (PE1) needs to send downstream will be sent on the specified P-tunnel - Any other PE that is interested in receiving (C-*,C-G) traffic MUST join the specified P-tunnel - Any other PE, say PE2, that (a) has traffic to C-G to send upstream and (b) has selected PE1 as its upstream PE for the C-RPA corresponding to C-G, MUST join the specified P-tunnel, and MUST send such traffic on the specified P-tunnel. - If a PE, say PE3, has joined the specified P-tunnel, but does not need to receive the (C-*,C-G) traffic, or has not selected PE1 as the upstream PE for the C-RPA corresponding to C-G, then PE3 MUST NOT send any (C-*,C-G) traffic on that P-tunnel, and MUST discard any (C-*,C-G) traffic it received on that P-tunnel. These procedures implement, for S-PMSIs, the "partitioning" scheme described in section 11.2 of [MVPN]. The specification given so far requires an S-PMSI A-D route or an S-PMSI Join message to be sent for each (C-*,C-G) that is using a bidirectional C-tree. A more efficient method is given in the next section. 5.1.4. Binding (C-*,C-*) When PE1 advertises an S-PMSI A-D route or sends an S-PMSI Join message that binds (C-*,C-*) to a specified bidirectional P-tunnel of which PE1 is the root, the semantics are as that the bidirectional P-tunnel is to be used to carry C-multicast traffic in the following sets of cases: Rosen, et al. [Page 9] Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010 1. If PE1 has (C-S,C-G) traffic that is traveling on a source-specific C-tree, and PE1 needs to transmit that data to one or more other PEs, and PE1 has not bound (C-S,C-G) or (C-*,C-G) to a different P-tunnel, then the (C-S,C-G) traffic is sent by PE1 on the specified bidirectional P-tunnel. 2. If PE1 has (C-*,C-G) traffic that is traveling on a unidirectional shared C-tree, and PE1 needs to transmit that data to one or more other PEs, and PE1 has not bound (C-*,C-G) to a different P-tunnel, then the (C-*,C-G) traffic is sent by PE1 on the specified bidirectional P-tunnel. 3. If PE1 has (C-*,C-G) traffic that is traveling on a bidirectional shared C-tree, and PE1 needs to transmit that data to one or more other PEs, and PE1 has not bound (C-*,C-G) to a different P-tunnel, then the (C-*,C-G) traffic is sent by PE1 on the specified bidirectional P-tunnel. 4. Consider some other PE, PE2, that has received the S-PMSI A-D route or S-PMSI Join message from PE1. If PE2 has (C-*,C-G) traffic that is traveling on a bidirectional shared C-tree, and PE2 needs to transmit that traffic UPSTREAM, and PE2 has selected PE1 as the upstream PE for the C-RPA corresponding to C-G, and PE1 has not bound (C-*,C-G) to any other P-tunnel, then the (C-*,C-G) traffic is sent by by PE2 on the specified bidirectional P-tunnel. 5. If a PE receives traffic from a particular bidirectional P-tunnel, and the traffic is traveling a unidirectional (C-*,C-G) or (C-S,C-G) tree, and the root of the bidirectional P-tunnel is not the PE's selected upstream PE for the (C-*,C-G) or (C-S,C-G), the PE MUST discard the traffic. 6. If a PE receives traffic from a particular bidirectional P-tunnel, and the traffic is traveling a bidirectional (C-*,C-G) tree, and the PE's selected upstream PE for the C-RPA corresponding to C-G is not the root of the bidirectional P-tunnel, then the PE MUST discard the traffic. With respect to traffic traveling a bidirectional C-tree, these procedures implement, for S-PMSIs, the "partitioning" scheme described in section 11.2 of [MVPN], without the need to send an S-PMSI A-D route for each (C-*,C-G) that is using a bidirectional C-tree. Each PE becomes the root of a bidirectional P-tunnel, and binds the double wildcard selector to it. The bidirectional P-tunnels serve as the "partitions". The bidirectional P-tunnel rooted at PE1 becomes the default P-tunnel for all traffic that PE1 needs to send downstream to other PEs. It also becomes the default Rosen, et al. [Page 10] Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010 P-tunnel for all traffic that others PEs need to send upstream, as long as those other PEs have selected PE1 as the upstream PE for the C-RPA corresponding to that traffic. Note that other PEs SHOULD NOT join the specified bidirectional P-tunnel unless they have a need to send or receive data over it. A PE knows when it needs to receive data by virtue of having certain multicast state in its C-PIM instance. With regard to multicast data traveling on a bidirectional (C-*,C-G) tree, a PE may not know whether it has to send data until such data actually arrives over a VRF interface; the PE may be on a "sender-only" branch. However, the PE in this case would have to know, through provisioning or some automatic procedure such as "Bootstrap Routing Protocol for PIM" (BSR) [BSR], the set of C-RPAs that are being used to support (C-*,C-G) traffic. For each C-RPA, the PE could join the bidirectional P-tunnel advertised by its selected upstream PE for that C-RPA. Alternatively the PE could defer joining the P-tunnel until it actually has data to send. 5.2. With PE Distinguisher Labels The procedures for transmitting data on an MP2MP LSP with PE Distinguisher Labels differ from the procedures for transmitting data on other bidirectional P-tunnels only in the following way. Let PE1 be the root of the P-tunnel. When a packet that is traveling on a unidirectional C-tree is transmitted on the P-tunnel by a particular PE, say PE2, PE2 must push on the packet's label stack the label that PE1 assigned to PE2 via the procedure above. When a packet that is traveling on a bidirectional C-tree is transmitted on the P-tunnel by PE2, PE2 must push on the packet's label stack the label that PE1 assigned to PE3, where PE3 is the upstream PE that PE2 has selected for the C-RPA corresponding to C-G. For unidirectional flows, this allows the transmitter to be identified, and for bidirectional flows, this allows the partition to be identified. Packets received from the wrong upstream PE or from the wrong partition MUST be discarded. (In effect, this is a case of tunnel hierarchy, where the PE Distinguisher Labels represent a set of MP2MP LSPs, each of which instantiates an MS-PMSI, but those LSPs are all tunneled through a single bidirectional P-tunnel.) If the PTA identifying the bidirectional P-tunnel contains an MPLS label, then that label shall appear in the label stack immediately preceding the label specified in the PE Distinguisher Labels attribute. Rosen, et al. [Page 11] Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010 6. IANA Considerations This document has no actions for IANA. 7. Security Considerations There are no additional security considerations beyond those of [MVPN] and [MVPN-BGP]. 8. Authors' Addresses Arjen Boers E-mail: arjen@boers.com Yiqun Cai Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 E-mail: ycai@cisco.com Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 E-mail: erosen@cisco.com IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium E-mail: ice@cisco.com Rosen, et al. [Page 12] Internet Draft draft-rosen-l3vpn-mvpn-bidir-00.txt February 2010 9. Normative References [BIDIR-PIM] "Bidirectional Protocol Independent Multicast", Handley, Kouvelas, Speakman, Vicisano, RFC 5015, October 2007 [mLDP] "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Minei, Kompella, Wijnands, Thomas, draft-ietf-mpls-ldp-p2mp-08.txt, October 2009 [MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, et. al., draft-ietf-l3vpn-2547bis-mcast-10.txt, January 2010 [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", Aggarwal, Rosen, Morin, Rekhter, draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt, September 2009 [MVPN_WILD] "MVPN: S-PMSI Wild Card Selectors", Cai, Rosen, Wijnands, draft-rosen-l3vpn-mvpn-wildcards-00.txt, February 2010 [PIM] "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", Fenner, Handley, Holbrook, Kouvelas, RFC 4601, August 2006 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels.", Bradner, March 1997 10. Informative References [BSR] "Bootstrap Router (BSR) Mechanism for PIM", N. Bhaskar, et.al., RFC 5059, January 2008 Rosen, et al. [Page 13]