idnits 2.17.1 draft-ietf-l3vpn-mvpn-spmsi-joins-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 8, 2010) is 4880 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN Working Group Yiqun Cai 3 Internet Draft Eric C. Rosen (Editor) 4 Intended Status: Proposed Standard IJsbrand Wijnands 5 Expires: May 8, 2011 Cisco Systems, Inc. 7 November 8, 2010 9 IPv6 MVPN Support Using PIM Control Plane and S-PMSI Join Messages 11 draft-ietf-l3vpn-mvpn-spmsi-joins-02.txt 13 Abstract 15 The specification for Multicast Virtual Private Networks (MVPN) 16 contains an option that allows the use of PIM as the control protocol 17 between provider edge routers. It also contains an option that 18 allows UDP-based messages, known as S-PMSI ("Selective Provider 19 Multicast Service Interface") Join messages, to be used to bind 20 particular customer multicast flows to particular tunnels through a 21 service provider's network. This document extends the MVPN 22 specification so that these options can be used when the customer 23 multicast flows are IPv6 flows. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as 33 Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 Copyright and License Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 . 63 Table of Contents 65 1 Specification of requirements ......................... 3 66 2 Introduction .......................................... 3 67 3 S-PMSI Joins Binding IPv6 Flows to GRE/IPv4 P-Tunnels . 3 68 3.1 Encoding .............................................. 5 69 3.2 Encapsulation of S-PMSI Joins in UDP Datagrams ........ 6 70 4 PE-PE PIM/IPv6 over an IPv4 P-Tunnel .................. 6 71 5 IANA Considerations ................................... 6 72 6 Security Considerations ............................... 7 73 7 Acknowledgments ....................................... 7 74 8 Authors' Addresses .................................... 7 75 9 Normative References .................................. 7 77 1. Specification of requirements 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 2. Introduction 85 The Multicast Virtual Private Networks (MVPN) specification [MVPN] 86 defines the notion of a "PMSI" (Provider Multicast Service 87 Interface), and specifies how a PMSI can be instantiated by various 88 kinds of tunnels through a service provider's network ("P-tunnels"). 89 It also specifies the procedures for using PIM ("Protocol Independent 90 Multicast", [RFC4601]) as the control protocol between Provider Edge 91 (PE) routers. When PIM is used as the control protocol, PIM messages 92 are sent through a P-tunnel from one PE in an MVPN to others in the 93 same MVPN. These PIM messages carry customer multicast routing 94 information. However, [MVPN] does not cover the case where the 95 customer is using IPv6, but the service provider is using P-tunnels 96 created by PIM over an IPv4 infrastructure. 98 The MVPN specification also specifies "S-PMSI (Selective PMSI) Join" 99 messages, which are optionally used to bind particular customer 100 multicast flows to particular P-tunnels. However, the specification 101 does not cover the case where the customer flows are IPv6 flows. 103 This document extends [MVPN] by adding the specification for handling 104 customer IPv6 multicast flows when a service provider is using PE-PE 105 PIM and/or S-PMSI Join messages over an IPv4 infrastructure. This 106 document also specifies how to send multiple S-PMSI Join messages in 107 a single UDP datagram. 109 This document uses terminology defined in [MVPN]: C-Source, C-Group, 110 C-flow, P-Group, (C-S,C-G) 112 3. S-PMSI Joins Binding IPv6 Flows to GRE/IPv4 P-Tunnels 114 The S-PMSI Join message is defined in section 7.4.2.2 of [MVPN]. 115 These messages contain a type field, and [MVPN] defines only "Type 1" 116 S-PMSI Joins. A Type 1 S-PMSI Join may be used to assign a customer 117 IPv4 (C-S,C-G) flow to a P-tunnel that is created by PIM/IPv4. To 118 transmit data or control packets over such a P-tunnel, the packets 119 are encapsulated in GRE ("Generic Routing Encapsulation") within 120 IPv4, as specified in section 12 of [MVPN]. 122 In this document we define the Type 4 S-PMSI Join. A Type 4 S-PMSI 123 Join may be used to assign a customer IPv6 (C-S,C-G) flow to a 124 P-tunnel that is created by PIM/IPv4. GRE/IPv4 encapsulation is used 125 to send data or control packets on the P-tunnel. 127 3.1. Encoding 129 0 1 2 3 130 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 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Type | Length | Reserved | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | | 135 | C-Source | 136 | | 137 | | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | | 140 | C-Group | 141 | | 142 | | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | P-Group | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 Type (8 bits): 4 149 Length (16 bits): 40, the length in octets of the entire S-PMSI Join 150 message, including the Type, Length, Reserved, C-Source, C-Group, and 151 P-Group fields. 153 Reserved (8 bits): this field SHOULD be zero when transmitted, and 154 MUST be ignored when received. 156 C-Source (128 bits): the IPv6 address of the traffic source in the 157 VPN. 159 C-Group (128 bits): the IPv6 group address of the multicast traffic 161 P-Group (32 bits): the IPv4 group address identifying the P-tunnel. 162 Data packets sent on this tunnel are encapsulated in IPv4 GRE packets 163 with this group address in the IP destination address field of the 164 outer header. 166 3.2. Encapsulation of S-PMSI Joins in UDP Datagrams 168 All S-PMSI Joins are encapsulated in UDP datagrams [RFC768]. A Type 169 4 S-PMSI Join MUST be encapsulated in an IPv6 UDP datagram. The IPv6 170 source address field of these datagrams SHOULD be the IPv4-mapped 171 IPv6 address [RFC4291] corresponding to the IPv4 address that the 172 originating PE router uses as its source address in the instance of 173 PIM that is used to create the specified P-tunnel. 175 A single UDP datagram MAY carry multiple S-PMSI Join Messages, as 176 many as can fit entirely within it. If there are multiple S-PMSI 177 Joins in a UDP datagram, they MUST be of the same S-PMSI Join type. 178 The end of the last S-PMSI Join (as determined by the S-PMSI Join 179 length field) MUST coincide with the end of the UDP datagram, as 180 determined by the UDP length field. When processing a received UDP 181 datagram that contains one or more S-PMSI Joins, a router MUST 182 process all the S-PMSI Joins that fit into the datagram. 184 4. PE-PE PIM/IPv6 over an IPv4 P-Tunnel 186 If a VPN customer is using PIM over IPv6, but the SP (Service 187 Provider) is using an IPv4 infrastructure (i.e., is using an 188 IPv4-based control protocol to construct its P-tunnels), then the PE 189 routers will need to originate IPv6 PIM control messages. The IPv6 190 Source Address field of any such IPv6 PIM control message SHOULD be 191 the IPv4-mapped IPv6 address [RFC4291] corresponding to the IPv4 192 address that the originating PE router uses as its source address in 193 the instance of PIM that is used to create the specified P-tunnel. 194 If the IPv6 Destination Address field is the multicast address ALL- 195 PIM-ROUTERS, the IPv6 form of the address (ff02::d) is used. These 196 IPv6 PIM control messages are of course not transmitted natively over 197 the service provider's network, but rather are encapsulated in 198 GRE/IPv4. 200 5. IANA Considerations 202 [MVPN] creates an IANA registry for the "S-PMSI Join Message Type 203 Field". This document requires that a new value be added to the 204 registry: 206 - The value 4 should be registered, and its description should read 207 "GRE S-PMSI for IPv6 traffic (unaggregated)". 209 6. Security Considerations 211 There are no additional security considerations beyond those of 212 [MVPN]. 214 7. Acknowledgments 216 The authors wish to thank DP Ayadevara, Arjen Boers, Rayen Mohanty, 217 Rajesh Sharma, and Karthik Subramanian. 219 8. Authors' Addresses 221 Yiqun Cai 222 Cisco Systems, Inc. 223 170 Tasman Drive 224 San Jose, CA, 95134 225 E-mail: ycai@cisco.com 227 Eric C. Rosen 228 Cisco Systems, Inc. 229 1414 Massachusetts Avenue 230 Boxborough, MA, 01719 231 E-mail: erosen@cisco.com 233 IJsbrand Wijnands 234 Cisco Systems, Inc. 235 De kleetlaan 6a Diegem 1831 236 Belgium 237 E-mail: ice@cisco.com 239 9. Normative References 241 [MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, et. al., 242 draft-ietf-l3vpn-2547bis-mcast-10.txt, January 2010 244 [RFC2119] "Key words for use in RFCs to Indicate Requirement 245 Levels.", Bradner, March 1997 247 [RFC4291] "IPv6 Addressing Architecture", Hinden, Deering, February 248 2006 250 [RFC4601] "Protocol Independent Multicast - Sparse Mode (PIM-SM)", 251 Fenner, Handley, Holbrook, Kouvelas, August 2006, RFC 4601 253 [RFC768] "User Datagram Protocol", Postel, August 1980, RFC 768