idnits 2.17.1 draft-rosen-l3vpn-mvpn-spmsi-joins-01.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 (May 21, 2010) is 5082 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Yiqun Cai 3 Internet Draft Eric C. Rosen (Editor) 4 Intended Status: Proposed Standard IJsbrand Wijnands 5 Expires: November 21, 2010 Cisco Systems, Inc. 7 May 21, 2010 9 MVPN: Customer IPv6 Using PIM Control Plane and S-PMSI Join Messages 11 draft-rosen-l3vpn-mvpn-spmsi-joins-01.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright and License Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Abstract 51 The specification for Multicast Virtual Private Networks (MVPN) 52 contains an option that allows the use of PIM as the control protocol 53 between provider edge routers. It also contains an option that 54 allows UDP-based "S-PMSI Join" messages to be used to bind particular 55 customer multicast flows to particular tunnels through a service 56 provider's network. This document extends the MVPN specification so 57 that these options can be used when the customer multicast flows are 58 IPv6 flows. 60 Table of Contents 62 1 Specification of requirements ......................... 2 63 2 Introduction .......................................... 3 64 3 S-PMSI Joins Binding IPv6 Flows to GRE/IPv4 P-Tunnels . 3 65 3.1 Encoding .............................................. 4 66 3.2 Encapsulation of S-PMSI Joins in UDP Datagrams ........ 5 67 4 PE-PE PIM/IPv6 over an IPv4 P-Tunnel .................. 5 68 5 IANA Considerations ................................... 5 69 6 Security Considerations ............................... 6 70 7 Acknowledgments ....................................... 6 71 8 Authors' Addresses .................................... 6 72 9 Normative References .................................. 6 74 1. Specification of requirements 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 2. Introduction 82 The Multicast Virtual Private Networks (MVPN) specification [MVPN] 83 allows PIM to be used as the control protocol between Provider Edge 84 (PE) routers. This requires PIM messages to be sent through a tunnel 85 (a "P-tunnel") from one PE in an MVPN to others in the same MVPN. 86 These PIM messages carry customer multicast routing information. 87 However, that specification does not cover the case where the 88 customer is using IPv6, but the service provider is using P-tunnels 89 created by PIM over an IPv4 infrastructure. The MVPN specification 90 also specifies "S-PMSI Join" messages, which are optionally used to 91 bind particular customer multicast flows to particular P-tunnels. 92 However, the specification does not cover the case where the customer 93 flows are IPv6 flows. 95 This document extends [MVPN] by adding the specifications for 96 handling customer IPv6 multicast flows when a service provider is 97 using PE-PE PIM and/or S-PMSI Join messages over an IPv4 98 infrastructure. This document also specifies how to send multiple 99 S-PMSI Join messages in a single UDP datagram. 101 This document uses terminology defined in [MVPN]: C-Source, C-Group, 102 C-flow, P-Group, (C-S,C-G) 104 3. S-PMSI Joins Binding IPv6 Flows to GRE/IPv4 P-Tunnels 106 The S-PMSI Join message is defined in section 7.4.2.2 of [MVPN]. 107 These messages contain a type field, and [MVPN] defines only "Type 1" 108 S-PMSI Joins. A Type 1 S-PMSI Join may be used to assign a customer 109 IPv4 (C-S,C-G) flow to a P-tunnel that is created by PIM/IPv4. 110 GRE/IPv4 encapsulation is used to send data or control packets on the 111 P-tunnel. 113 In this document we define the Type 4 S-PMSI Join. A Type 4 S-PMSI 114 Join may be used to assign a customer IPv6 (C-S,C-G) flow to a 115 P-tunnel that is created by PIM/IPv4. GRE/IPv4 encapsulation is used 116 to send data or control packets on the P-tunnel. 118 3.1. Encoding 120 0 1 2 3 121 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 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Type | Length | Reserved | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | | 126 | C-Source | 127 | | 128 | | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | | 131 | C-Group | 132 | | 133 | | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | P-Group | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 Type (8 bits): 4 140 Length (16 bits): 40, the length in octets of the entire S-PMSI Join 141 message, including the Type, Length, Reserved, C-Source, C-Group, and 142 P-Group fields. 144 Reserved (8 bits): this field SHOULD be zero when transmitted, and 145 MUST be ignored when received. 147 C-Source (128 bits): the IPv6 address of the traffic source in the 148 VPN. 150 C-Group (128 bits): the IPv6 group address of the multicast traffic 152 P-Group (32 bits): the IPv4 group address identifying the P-tunnel. 153 Data packets sent on this tunnel are encapsulated in IPv4 GRE packets 154 with this group address in the IP destination address field of the 155 outer header. 157 3.2. Encapsulation of S-PMSI Joins in UDP Datagrams 159 All S-PMSI Joins are encapsulated in UDP datagrams. A Type 4 S-PMSI 160 Join MUST be encapsulated in an IPv6 UDP datagram. The IPv6 source 161 address field of these datagrams SHOULD be the IPv4-mapped IPv6 162 address [RFC4291] corresponding to the IPv4 address that the 163 originating PE router uses as its source address in the instance of 164 PIM that is used to create the specified P-tunnel. 166 A single UDP datagram MAY carry multiple S-PMSI Join Messages, as 167 many as can fit entirely within it. If there are multiple S-PMSI 168 Joins in a UDP datagram, they MUST be of the same S-PMSI Join type. 169 The end of the last S-PMSI Join (as determined by the S-PMSI Join 170 length field) MUST coincide with the end of the UDP datagram, as 171 determined by the UDP length field. When processing a received UDP 172 datagram that contains one or more S-PMSI Joins, a router MUST 173 process all the S-PMSI Joins that fit into the datagram. 175 4. PE-PE PIM/IPv6 over an IPv4 P-Tunnel 177 If a VPN customer is using PIM over IPv6, but the SP is using an IPv4 178 infrastructure (i.e., is using an IPv4-based control protocol to 179 construct its P-tunnels), then the PE routers will need to originate 180 IPv6 PIM control messages. The IPv6 Source Address field of any such 181 IPv6 PIM control message SHOULD be the IPv4-mapped IPv6 address 182 [RFC4291] corresponding to the IPv4 address that the originating PE 183 router uses as its source address in the instance of PIM that is used 184 to create the specified P-tunnel. If the IPv6 Destination Address 185 field is the multicast address ALL-PIM-ROUTERS, the IPv6 form of the 186 address (ff02::d) is used. These IPv6 PIM control messages are of 187 course not transmitted natively over the service provider's network, 188 but rather are encapsulated in GRE/IPv4. 190 5. IANA Considerations 192 [MVPN] creates an IANA registry for the "S-PMSI Join Message Type 193 Field". This document requires that a new value be added to the 194 registry: 196 - The value 4 should be registered, and its description should read 197 "GRE S-PMSI for IPv6 traffic (unaggregated)". 199 6. Security Considerations 201 There are no additional security considerations beyond those of 202 [MVPN]. 204 7. Acknowledgments 206 The authors wish to thank DP Ayadevara, Arjen Boers, Rayen Mohanty, 207 Rajesh Sharma, and Karthik Subramanian. 209 8. Authors' Addresses 211 Yiqun Cai 212 Cisco Systems, Inc. 213 170 Tasman Drive 214 San Jose, CA, 95134 215 E-mail: ycai@cisco.com 217 Eric C. Rosen 218 Cisco Systems, Inc. 219 1414 Massachusetts Avenue 220 Boxborough, MA, 01719 221 E-mail: erosen@cisco.com 223 IJsbrand Wijnands 224 Cisco Systems, Inc. 225 De kleetlaan 6a Diegem 1831 226 Belgium 227 E-mail: ice@cisco.com 229 9. Normative References 231 [MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, et. al., 232 draft-ietf-l3vpn-2547bis-mcast-10.txt, January 2010 234 [RFC2119] "Key words for use in RFCs to Indicate Requirement 235 Levels.", Bradner, March 1997 237 [RFC4291] "IPv6 Addressing Architecture", Hinden, Deering, February 238 2006