idnits 2.17.1 draft-hlj-l3vpn-mvpn-mrsvp-te-00.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 6, 2012) is 4305 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) == Outdated reference: A later version (-03) exists of draft-lzj-mpls-receiver-driven-multicast-rsvp-te-00 ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force L. Han, Ed. 3 Internet-Draft R. Li 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 7, 2013 C. Jacquenet 6 France Telecom Orange 7 July 6, 2012 9 Multicast VPN Support by Receiver-Driven Multicast Extensions to RSVP-TE 10 draft-hlj-l3vpn-mvpn-mrsvp-te-00 12 Abstract 14 This document describes a method to support multicast VPN (MVPN) by a 15 receiver-driven multicast extension to RSVP-TE (mRSVP-TE). This 16 method is desirable and applicable to MVPN applications when QoS 17 assurance and traffic-engineered tunnels are desired. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 7, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Multicast LSP . . . . . . . . . . . . . . . . . . . . . . 7 70 3.2. PIM States, PIM Interfaces and PMSI . . . . . . . . . . . 7 71 3.3. Reverse-Path Forwarding . . . . . . . . . . . . . . . . . 8 72 3.4. Default mLSP . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.4.1. Establishment of Default mLSP . . . . . . . . . . . . 9 74 3.4.2. Virtual PIM Interface for Default mLSP . . . . . . . . 10 75 3.4.3. PIM signaling over Default mLSP . . . . . . . . . . . 10 76 3.4.4. PIM state with Default mLSP . . . . . . . . . . . . . 12 77 3.4.5. Multicast data over default mLSP . . . . . . . . . . . 13 78 3.5. Data mLSP . . . . . . . . . . . . . . . . . . . . . . . . 13 79 3.5.1. Establishment of Data mLSP . . . . . . . . . . . . . . 13 80 3.5.2. Virtual PIM interface for Data mLSP . . . . . . . . . 14 81 3.5.3. mLSP ID and data mLSP mapping . . . . . . . . . . . . 14 82 3.5.4. Switching of Data mLSP . . . . . . . . . . . . . . . . 15 83 3.5.5. PIM Prune Impact to Data mLSP . . . . . . . . . . . . 15 84 3.5.6. Deletion of Data mLSP . . . . . . . . . . . . . . . . 16 85 3.5.7. PIM (S,G) signaling after Data mLSP is created . . . . 16 86 4. PIM-SSM Solutions . . . . . . . . . . . . . . . . . . . . . . 16 87 4.1. Option 1 . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 4.2. Option 2 . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 4.3. Option 3 . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 5. PIM-SM solutions . . . . . . . . . . . . . . . . . . . . . . . 18 91 5.1. RP-PE mLSP . . . . . . . . . . . . . . . . . . . . . . . . 18 92 5.2. Source-PE mLSP . . . . . . . . . . . . . . . . . . . . . . 18 93 5.3. PIM register process . . . . . . . . . . . . . . . . . . . 18 94 5.3.1. Scenario 1: The multicast source and RP are behind 95 the same PE . . . . . . . . . . . . . . . . . . . . . 18 97 5.3.2. Scenario 2: The multicast source and RP are behind 98 the different PE . . . . . . . . . . . . . . . . . . . 19 99 5.4. SPT switching . . . . . . . . . . . . . . . . . . . . . . 21 100 5.5. RPT prune . . . . . . . . . . . . . . . . . . . . . . . . 21 101 5.6. Data mLSP switching . . . . . . . . . . . . . . . . . . . 21 102 5.7. PIM state at Receiver-PE . . . . . . . . . . . . . . . . . 22 103 6. Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . 22 104 6.1. Aggregation by Default mLSP . . . . . . . . . . . . . . . 23 105 6.2. Aggregation by Data mLSP . . . . . . . . . . . . . . . . . 23 106 7. Non-VPN multicast support . . . . . . . . . . . . . . . . . . 23 107 8. Message Format and Constants . . . . . . . . . . . . . . . . . 24 108 8.1. Path session object for PIM-SSM option 1 (IPv4) . . . . . 24 109 8.2. Path session object for PIM-SSM option 1 (IPv6) . . . . . 25 110 8.3. Path session object for other PIM modes (IPv4) . . . . . . 26 111 8.4. Path session object for other PIM modes (IPv6) . . . . . . 26 112 8.5. mLSP TLV Message format for IPv4 . . . . . . . . . . . . . 27 113 8.6. mLSP TLV Message format for IPv6 . . . . . . . . . . . . . 27 114 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 115 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 116 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 117 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 118 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29 119 12.2. Informative References . . . . . . . . . . . . . . . . . . 30 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 122 1. Introduction 124 A L3VPN service that supports multicast is known as a Multicast VPN, 125 or MVPN for short. There have been different proposed messages, 126 procedures and mechanisms to support MVPN. These methods differ in 127 protocols used in the service provider's network, for example, the 128 mGRE-based MVPN, BGP extensions to transport customer's PIM signaling 129 and P2MP RSVP-TE extensions to transport multicast data streams, and 130 mLDP-based MVPN, as summarized as follows: 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Type | Data Plane| Protocols for core | Standard| 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | 1 | mGRE | PIM, BGP(with MDT_SAFI) | RFC6037 | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | 2 | MPLS | P2MP RSVP-TE, BGP(with extension) | RFC6513 | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | 3 | MPLS | mLDP | No | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Table 1. Existing mVPN Solutions 144 Type 1 solution requires to run PIM in the service provider's 145 network. 147 Both Type 2 and Type 3 require an MPLS data forwarding plane, but 148 they differ in protocols used in the service provider's network. 149 Type 2 uses RSVP-TE with a P2MP extension [RFC4875] for multicast 150 data streams and BGP extensions with multicast encodings and 151 procedures [RFC6514] for PIM signaling, or use mLDP [RFC6388] for 152 both control plane signaling and multicast data streams. Type 3 is 153 simpler than type 2 in terms of required protocols and provisioning. 155 With Type 2 solution, multicast traffic is carried over MPLS-TE 156 tunnels, QoS and traffic engineering are supported for mVPN 157 applications. It is an advantage of Type 2 over Type 3. 159 However, for Type 2 solution, BGP has to be extended with seven (7) 160 types of MCAST-VPN NLRIs together with four (4) new BGP attributes. 161 In some scenarios, multiple P2MP RSVP-TE tunnels are used. And 162 therefore, it requires to upgrade both BGP and RSVP-TE, which brings 163 more complexity and operational inconvenience. 165 In addition to the above-mentioned three methods, do we have any 166 alternative method which is expected to be simpler and more scalable, 167 but can still provide QoS assurance and traffic-engineered transport? 169 This document specifies a new method to implement multicast VPN by 170 receiver-driven multicast extensions to RSVP-TE (mRSVP-TE) specified 171 in [I-D.lzj-mpls-receiver-driven-multicast-rsvp-te]. mRSVP-TE is a 172 new extension to RSVP-TE for multicast applications in MPLS networks, 173 whose behavior is closer to IP PIM since both of them work by sending 174 control messages from the data receivers to the data senders. The 175 receiver-driven nature of the mRSVP-TE makes it more adaptive and 176 easier to be integrated with PIM for multicast applications including 177 multicast VPN. 179 As an extension to RSVP-TE, mRSVP-TE inherits all the desirable 180 features from RSVP-TE such as QoS assurance and traffic-engineered 181 paths, which makes it to distinguish from mLDP used in Type 3. 183 By using an MP2MP tunnel created by mRSVP-TE to carry the customer's 184 PIM signaling, we do not need to use BGP multicast extension to 185 signal customer's multicast information. 187 The MVPN method described in the document supports both PIM-SSM and 188 PIM-SM. For PIM-SM, this method supports multicast source, receiver, 189 Rendezvous Point (RP) located at any place including PE, CE or any 190 device connected to CE. It can also support Bootstrap Router (BSR) 191 Mechanism [RFC5059]. 193 2. Terminology 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 197 document are to be interpreted as described in RFC 2119 [RFC2119] and 198 indicate requirement levels for compliant MVPN implementations. 200 2.1. Definitions 202 In what follows we describe some terminologies which are widely used 203 in this document. 205 Source-PE 206 Source-PE is a PE which is connected to a MVPN CE and the 207 multicast source is on or behind the CE. 209 Receiver-PE 210 Receiver-PE is a PE which is connected to a MVPN CE and the 211 multicast receiver is on or behind the CE 213 RP-PE 214 RP PE is a PE which is connected to a MVPN CE and the multicast 215 Rendezvous Point for PIM-SM is on or behind the CE 217 PE type 218 A PE can be either Source-PE, Receiver-PE or RP-PE for 219 different MVPN and different (S,G). Its type can also be the 220 mixture of any combination of the three PE type. 222 MDT 223 Multicast Distribution Tree, introduced in [RFC6037] for the IP 224 backbone based MVPN. MDT is composed of mGRE tunnels. There 225 are default MDT and data MDT 227 mLSP 228 Multicast-Label-Switched-Path. It is the equivalent of MDT in 229 MPLS networks, and sometimes we will use mLSP and MDT 230 interchangeably. The same as MDT, we also have default mLSP 231 and data mLSP. 233 Source-PE mLSP 234 mLSP whose header-end is a Source-PE. 236 RP-PE mLSP 237 mLSP whose header-end is a RP-PE. 239 MI-PMSI(MVPN_ID) 240 It corresponds to the MI-PMSI [RFC6513] for a MVPN (ID is 241 MVPN_ID), it is the Multidirectional Inclusive P-Multicast 242 Service interface for the default mLSP or the MP2MP tunnel at 243 either tail-end or header-end. 245 S-PMSI(MVPN_ID, mLSP_ID) 246 It corresponds to a S-PMSI [RFC6513] for a MVPN (ID is MVPN_ID) 247 and the mLSP ID is mLSP_ID, it is the Selective P-Multicast 248 Service interface for the P2MP tunnel for (S,G) at either tail- 249 end or header-end. 251 OIF 252 Outgoing Interface for PIM state 254 IIF 255 Incoming Interface for PIM state 257 Olist 258 Outgoing Interface list for PIM state 260 3. Overview 261 3.1. Multicast LSP 263 Multicast-Label-Switched-Path (mLSP) is an MPLS tree in MPLS network 264 to distribute multicast data to different receivers who are 265 interested in particular multicasted data stream(s). An mLSP is 266 composed of multiple Sub-Label-Switched-Paths (sub-LSP) which connect 267 different Label Switch Routers (LSRs) to form an MPLS multicast 268 network. There are two basic types of mLSPs: P2MP LSP and MP2MP LSP. 269 In the case of P2MP LSP, the header-end of an mLSP is the Source-PE 270 which connects the source device of multicast traffic, and its tail- 271 ends are the Receiver-PEs which connect the destination device of 272 multicast traffic. The joint points on an mLSP are called "Branch 273 LSR" where the MPLS packets are replicated and then forwarded to 274 different downstream LSRs. In the case of MP2MP LSP, there is a 275 special LSR which serves as the root of the mLSP, and all the leaf 276 nodes are both the Source-PE and Receiver-PEs. 278 For mVPN multicast traffic, it travels on a multicast tree which 279 spans over two different networks: MPLS network operated by service 280 providers and IP network on the customer's sites. The mVPN multicast 281 traffic always starts from one customer's site as IP multicast, and 282 then is transported over the MPLS network to other customer's sites. 283 The traffic on customer's sites is distributed over a PIM multicast 284 distribution tree, while in service provider's MPLS network it is 285 distributed by mLSP tunnels. The mLSP and the PIM distribution tree 286 SHOULD be seamlessly integrated. The IP multicast data received from 287 a CE is encapsulated as MPLS packet at the Source-PE of an mLSP tree, 288 and then transported over the mLSP. The MPLS packet is replicated at 289 the branch LSRs and delivered to the different Receiver-PEs, where 290 the MPLS packet is de-capsulated to IP multicast packet and forwarded 291 to the connected IP multicast tree, then it is distributed to the 292 particular receivers. 294 3.2. PIM States, PIM Interfaces and PMSI 296 It is assumed that PIM is used on customer's sites and mRSVP-TE is 297 used in service provider's network without PIM being enabled in 298 service provider's network. In order to set up customer's multicast 299 distribution trees across a service provider's MPLS network, it is 300 desired that the customer's PIM SHOULD inter-work with service 301 provider's mRSVP-TE, which brings up some new requirements about PIM 302 states and interfaces. 304 The most important factors for PIM states are the IIF and OIF, both 305 of which are PIM-enabled interfaces. A PIM interface appearing in an 306 PIM state is characterized as follows: 308 o It has an IP address configured 310 o It has the PIM protocol enabled and running 312 o It has one or more PIM adjacencies 314 Since the customer's PIM adjacencies MUST be established between PEs, 315 virtual interfaces associated with the MPLS tunnels connecting PEs 316 are introduced. Such virtual interfaces are also called PMSI for 317 Provider Multicast Service Interface. In this document we will use 318 two types of PMSI: MI-PMSI and S-PMSI. 320 3.3. Reverse-Path Forwarding 322 For multicast forwarding by a PIM state (S,G), we need to check if 323 the packet is coming from the expected interface which is the egress 324 interface to reach the source S based on the unicast routing table. 325 The expected interface is called RPF interface, or the IIF (Incoming 326 interface). In this document, we will consider the following two 327 modes: 329 o PIM-SSM mode: the state to forward traffic is (S,G), so there is 330 only one IIF for a (S,G). 332 o PIM-SM mode: RP will have (*,G) before the traffic is received and 333 (S,G) after the register processing is finished. Other routers 334 have (*,G) before the SPT switching and (S,G) after the SPT 335 switching. For the (*,G), the RPF is the interface to reach RP by 336 unicast routing. 338 In the context of mVPN, PE is the boundary router between customer's 339 IP network and service provider's MPLS network, and thus needs to 340 handle the RPF issue as follows: 342 o For a Source-PE, the RPF checking for any (S,G) does not have any 343 change since the IIF is still a normal IP interface. 345 o For a Receiver-PE, the RPF interface for any (S,G) or (*,G) is not 346 derived from the unicast routing table for the multicast source S 347 or RP for a multicast stream. Instead, we MUST force the RPF 348 interface to be the PIM interface which is associated with either 349 an MI-PMSI or an S-PMSI. 351 o For a RP-PE, before traffic starts, the RPF interface is not set 352 for (*,G) since the multicast source is unknown. After the PIM 353 register process is completed, the (S,G) state will be created. 354 Then we MUST force the RPF interface to be the PIM interface which 355 is associated with the MI-PMSI for the MVPN. 357 RPF does not apply to the multicast forwarding in MPLS network by 358 mLSP. mLSP established by mRSVP-TE protocol can guarantee the loop- 359 free for packet forwarding which is the whole purpose of RPF 360 checking. 362 3.4. Default mLSP 364 To each mVPN, we associate an mLSP, called its default mLSP. Given 365 an mVPN, its default mLSP is a multi-directional shared tree with all 366 the PEs as its leaf nodes. Default mLSP is a MP2MP tunnel which can 367 provide a multi-directional transportation for any data. The default 368 mLSP is used for the following two purposes: 370 o Cusomer's PIM signaling: Cusomer's PIM signaling is transported 371 over such default mLSP 373 o Default customer's multicast data distribution: Customer's 374 multicast data are transported and distributed over such mLSP by 375 default. 377 3.4.1. Establishment of Default mLSP 379 The construction of default mLSP does not depend on the existence of 380 multicast traffic for a MVPN; it is built up before any such 381 multicast traffic is seen. 383 Default mLSP is established when a VPN attached to a PE enables MVPN 384 service. After the MVPN is enabled, the mRSVP-TE stack MUST send the 385 mRSVP-TE path message continuously. The time interval to send the 386 path message at each PE could be default value or configurable. If 387 it is configurable, different PE's interval value MUST be proper to 388 guarantee the mLSP state is steady without any flapping. 390 To enable MVPN service on a PE, root node(s) IP address MUST be 391 given. Root node is normally a P router inside the backbone network. 393 The location of root node may impact the efficiency of a MP2MP 394 tunnel. How to choose a root node to establish a MP2MP tunnel to 395 obtain the efficient multicast replication in MPLS network is out of 396 scope of the document. 398 In addition to the root node, explicit nodes from any PE to the root 399 node P MAY be applied as an option if user wants the path from the 400 root node P to a PE goes through some expected routers. 402 For the details of root node and explicit node in a MP2MP tunnel, 403 please refer to the [I-D.lzj-mpls-receiver-driven-multicast-rsvp-te]. 405 If the redundancy for the root node is desired to protect the failure 406 of root node, multiple root nodes may be given to construct multiple 407 default mLSP. The redundancy for root node is out of scope of this 408 document. 410 With the method herein, there is only one default mLSP for each MVPN, 411 or two for root redundancy case, 413 3.4.2. Virtual PIM Interface for Default mLSP 415 A MI-MPSI interface SHOULD be created at both Source-PE and 416 Receiver-PE when the default mLSP for a MVPN is established. This is 417 a PIM enabled interface for a MVPN. It is used for PIM adjacency, 418 PIM state keeping, and PIM IIF and OIF representation for the MPLS 419 packet forwarding over MPLS network. 421 MI-PMSI is a joint point of IP multicast tree and mLSP. If a MI-PMSI 422 is one OIF in the Olist for a multicast forwarding entry (S,G), it 423 means the IP multicast stream (S,G) will be replicated for the MI- 424 PMSI and sent to the interface. If a MI-PMSI is the IIF for a 425 multicast forwarding entry (S,G), it means the MPLS packet received 426 from MI-PMSI will be forwarded by the forwarding entry (S,G) if the 427 de-capsulated MPLS packet is IP packet, and source and group are S 428 and G respectively. 430 MI-PMSI is a PIM interface and its IP address will be the address for 431 the PIM peering. This address on one PE MUST be reachable from all 432 other PEs. When PIM adjacency are established between PEs, one PE 433 can see all its PIM adjacency's MI-PMSI are up. For the convenience, 434 it is RECOMMENDED to use the BGP source address for the BGP session 435 between PEs for MI-PMSI. The BGP session here refers to the BGP for 436 unicast VPN service. 438 All PIM hello variables for a virtual interface MI-PMSI, such as 439 timer, are default value when the interface is created. But they 440 could be configurable and this is up to the implementation. 442 3.4.3. PIM signaling over Default mLSP 444 For MVPN attached PE, PIM is enabled for the interfaces connecting 445 different CEs which may belong to the same or different VPNs. Each 446 interface has a MVPN instance associated with it. After a MI- 447 PMSI(MVPN_ID) is created for a default mLSP, it MUST join the same 448 PIM domain for the particular MVPN. 450 The default mLSP SHOULD support all PIM multicast messages: 452 o HELLO message 454 o JOIN/PRUNE message 456 o ASSERT 458 o BOOTSTRAP 460 For the following PIM unicast message, they SHOULD NOT be sent to the 461 default mLSP, instead, they SHOULD be sent over a unicast MPLS tunnel 462 to the destination PE. 464 o REGISTER message 466 o REGISTER-STOP message 468 o GRAFT 470 o GRAFT-ACK 472 o CANDIDATE-RP-ADV 474 For one MVPN at a PE, PIM signaling (multicast) messages SHOULD be 475 multicasted to all PIM interfaces for that particular MVPN including 476 MI-PMSI. PIM messages are sent to a MI-PMSI(MVPN_ID) immediately 477 after the interface is created. The messages are encapsulated to 478 MPLS packets and will be distributed to all other receiver-PEs in the 479 same MVPN through the default mLSP. 481 At Receiver-PE, the MPLS packets are de-capsulated and delivered to a 482 particular MVPN, the MVPN ID is determined by the MPLS label which 483 was allocated locally on Receiver-PE when the PE initializes the 484 default mLSP by sending mRSVP-TE path message to the root node. The 485 popped MPLS label from the received MPLS packet can associate the 486 packet with a MI-PMSI(MVPN_ID) interface as incoming interface, So, 487 the MI-PMSI(MVPN_ID) interface at Receiver-PE can be used for RPF 488 checking of multicast forwarding. 490 Receiver-PE SHOULD punt PIM signaling message to PIM protocol stack 491 for the particular MVPN. After all PIM HELLO messages are exchanged 492 between PEs, PIM adjacencies are established between multiple PEs 493 through each PE's MI-PMSI(MVPN_ID) which is associated with a 494 particular MVPN. 496 As the result of PIM adjacency over the default mLSP, the details of 497 MPLS backbone network topology is hidden for PIM. It will make the 498 MVPN PIM virtually run over a virtual muti-access interface which is 499 composed of multiple MI-PMSI(MVPN_ID) from different PEs. 501 3.4.4. PIM state with Default mLSP 503 Since the MI-PMSI interface is a PIM enabled interface, all PIM 504 multicast messages, Hello, Join, Prune, Bootstrap and Assert, can be 505 sent to or received from the MI-PMSI interface. PIM protocol can 506 create and update the appropriate state for a MVPN accordingly. MI- 507 PMSI can behavior as a normal PIM interface to join or exit the Olist 508 for PIM state. 510 Below is the detail of the PIM processing for different PIM modes and 511 join messages. All behaviors are based on the PIM protocol and some 512 PIM changes are required for MVPN solution described in this 513 document. 515 (S,G) join for PIM-SSM 516 When a Receiver-PE receives PIM (S,G) join message from 517 attached CE, it SHOULD send the join message through MI- 518 PMSI(MVPN_ID) interface to the default mLSP. Meanwhile, if PIM 519 (S,G) state was not created on the Receiver-PE, PIM MUST create 520 a (S,G) state for which the MI-PMSI(MVPN_ID) is IIF. As a 521 result of sending PIM join message to MI-PMSI(MVPN_ID) 522 interface, the message will be populated to all PEs connected 523 to the same default mLSP. However, only Source-PE SHOULD 524 process the PIM join message. The Source-PE is derived from 525 the BGP next hop of source address S. All other PEs SHOULD 526 ignore the join message. After the Source-PE receives the 527 (S,G) join from a default mLSP, if the PIM (S,G) state was not 528 created, PIM SHOULD create a PIM (S,G) state for multicast 529 routing table, the entry SHOULD add MI-PMSI(MVPN_ID) to its 530 Olist. After the 1st PIM join message is processed at both 531 Receiver-PE and Source-PE, the subsequent PIM join message will 532 only reset the PIM timer and will not change the PIM (S,G) 533 state. This behavior is same as PIM in IP network. 535 (*,G,RP) join for PIM-SM 536 PIM-SM (*,G) join message will be populated through default 537 mLSP to all PEs attached to the same mLSP. The behavior for 538 PIM (*,G) join is the same as PIM-SSM. The only difference is 539 that (*,G) join is sent to RP (Rendezvous Points). As a 540 result, only RP-PE SHOULD process the PIM join message. The 541 RP-PE is derived from the BGP next hop of RP address. All 542 other PEs SHOULD ignore the join message. After the PIM (*,G) 543 join message is sent from Receiver-PE and received by RP-PE. 544 PIM SHOULD create a (*,G) state on Receiver-PE, for which the 545 MI-PMSI(MVPN_ID) is IIF. PIM SHOULD create a (*,G) state at 546 RP-PE and add the MI-PMSI(MVPN_ID) to its Olist. 548 PIM prune message processing has no change on PE, it may lead to the 549 interface state change for a PIM state, or a PIM state deletion. 550 When a PIM state is deleted on a receiver-PE, it MUST send the PIM 551 prune message to the default mLSP to forward the prune message to 552 source-PE or RP-PE. When a Source-PE or RP-PE receives a prune 553 message from the default mLSP, it MUST prune the MI-PMSI from the PIM 554 state's Olist. 556 3.4.5. Multicast data over default mLSP 558 If a default mLSP is used to carry user's multicast data, it will 559 send the multicast data to all PEs connected to the default mLSP, no 560 matter if a PE is intended or not to receive the particular multicast 561 traffic. The PIM join or prune does not start or stop the traffic 562 over the default mLSP. This is normally used for the beginning of 563 the multicast traffic flowing when the traffic rate is low. 564 Obviously, there are two drawbacks for it 566 o Some PE may not want to receive some multicast traffic, this will 567 be wasteful for the bandwidth and resource for routers. 569 o Too much multicast data shares one tree can congest the MP2MP 570 tunnel. 572 To overcome above problems, data mLSP is used to offload the data 573 traffic from the default mLSP. 575 3.5. Data mLSP 577 Data mLSP is used to offload some data stream from the default mLSP. 578 It is a P2MP tunnel corresponding to a (S,G) entry in a MVPN. Data 579 mLSP is built up either statically or dynamically depending on the 580 solutions for different PIM modes. Section 4 and 5 will discuss 581 details. 583 3.5.1. Establishment of Data mLSP 585 Static data mLSP establishment is triggered by a Receiver-PE to send 586 the mRSVP-TE P2MP path message to a Source-PE. It will be described 587 in section 4.1. 589 Dynamical data mLSP establishment is driven by the multicast traffic. 590 The mechanism is similar to the data MDT described in [RFC6037]. 592 Source-PE MUST monitor the rate of all multicast streams passing 593 through it. As for how to monitor the traffic rate, it is out of the 594 scope of the document. 596 When a Source-PE detects the rate of a MVPN multicast stream (S,G) 597 exceeds the pre-configured threshold, it MUST send a data mLSP join 598 TLV to the default data mLSP. The format of data mLSP join TLV is 599 defined in section 8.5 and 8.6. 601 The data mLSP join TLV will be flooded to all PE connected to the 602 same default mLSP. When a PE receives the data mLSP join TLV and if 603 the PE has joined the group G, it MUST initialize the setup of P2MP 604 tunnel by sending the mRSVP-TE P2MP path message to the Source-PE for 605 (S,G). Source-PE address is derived from the BGP nexhop of the VPN 606 address S. 608 The periodically sending of mRSVP-TE path message from receiver-PE to 609 Source-PE is driven by the periodically received mLSP join TLV 610 message at receiver-PE 612 The operation of data mLSP is similar to the operation of data MDT 613 for mGRE based mVPN. It has four timer defined to govern the data 614 mLSP: MDT_DATA_DELAY, MDT_DATA_TIMEOUT, MDT_DATA_HOLDDOWN, 615 MDT_INTERVAL. For the detailed definition of those timers and 616 operations, please refer to [RFC6037]. 618 Since the interval to receive mLSP join TLV message will determine 619 the interval to send mRSVP-TE path message, we SHOULD make sure the 620 interval of mLSP join TLV is less than the timeout value of sub-LSP 621 created by the mRSVP-TE path message. 623 3.5.2. Virtual PIM interface for Data mLSP 625 After a data mLSP is created, the S-PMSI(MVPN_ID,mLSP_ID) MUST be 626 instantiated. S-PMSI(MVPN_ID,mLSP_ID) is only used for Incoming 627 Interface (IIF) at Receiver-PE and Outgoing Interface (OIF) at 628 Source-PE for the multicast forwarding, it is not used for PIM 629 signaling. 631 The mLSP_ID is "mLSP ID" shown in Fig.3 which is assigned at 632 Source-PE. 634 S-PMSI(MVPN_ID,mLSP_ID) points to the same PIM interface as MI- 635 PMSI(MVPN_ID). It only adds extra L2 rewriting information block to 636 the PIM interface for the packet forwarding purpose. 638 3.5.3. mLSP ID and data mLSP mapping 640 Data mLSP is identified by "mLSP ID" which is defined in section 8.3 641 and 8.4. mLSP ID is a 4 byte value starting from 1 for data mLSP. 642 mLSP ID 0 is reserved for the default mLSP. mLSP ID is to distinguish 643 different data mLSP (P2MP tunnel) at Source-PE side. During the data 644 mLSP building, the mLSP ID allocated at a Source-PE MUST be notified 645 to all Receiver-PE by the mLSP join TLV. 647 When a Source-PE detects the rate of a MVPN multicast stream (S,G) 648 exceeds the pre-configured threshold, it MUST assign a mLSP ID from 649 its mLSP pool for the (S,G). And the mLSP join TLV message binds 650 (S,G) with mLSP ID. The Receiver-PE receiving the mLSP join TLV will 651 know the binding relationship. As a result, both Source-PE and 652 Receiver-PE will have a mapping for the mLSP ID and data mLSP, this 653 is used for the switching of data MDT for a stream (S,G). 655 After a data MLSP is deleted, the associated mLSP ID MUST be returned 656 to the mLSP pool. 658 3.5.4. Switching of Data mLSP 660 The Source-PE SHOULD switch the traffic from default mLSP to data 661 mLSP after it created the data mLSP for a multicast stream (S,G). 662 The mLSP ID and data mLSP mapping information will tell which data 663 mLSP is used for which stream (S,G). From the PIM state point of 664 view, at Source-PE, the PIM state (S,G) SHOULD change the OIF from 665 MI-PMSI(MVPN_ID) to S-PMSI(MVPN_ID, mLSP_ID). Since MI-PMSI(MVPN_ID) 666 and S-PMSI(MVPN_ID, mLSP_ID) share the same PIM interface, the 667 switching essentially means the MPLS forwarding is switched from the 668 MP2MP tunnel to P2MP tunnel. There is no PIM interface changing for 669 PIM signaling during and after the data mLSP switching 671 After switching, Receiver-PE MUST use the correct data mLSP 672 associated S-PMSI(MVPN_ID, mLSP_ID) for the RPF checking for a stream 673 (S,G). 675 The data mLSP switching is associated with the change of forwarding 676 state for (S,G) as following 678 o Source-PE MUST modify the OIF from MI-PMSI(MVPN_ID) to 679 S-PMSI(MVPN_ID, mLSP_ID). 681 o Receiver-PE MUST modify the IIF from MI-PMSI(MVPN_ID) to 682 S-PMSI(MVPN_ID, mLSP_ID). 684 3.5.5. PIM Prune Impact to Data mLSP 686 When the multicast data is transported over a data mLSP, the PIM 687 prune may cause the prune of the data mLSP tree. After a Receiver-PE 688 receives PIM prune message and if the prune message leads to the IIF 689 prune for a PIM state, it MUST update the PIM state in such that the 690 IIF represented by the S-PMSI(MVPN_ID,mLSP_ID) is pruned. And the 691 Receiver-PE MUST send the mRSVP-TE PATHTEAR message to the upstream 692 LSR to prune the data mLSP tree. If a Source-PE receives the 693 mRSVP-TE PATHTEAR message, the whole data mLSP is deleted and 694 Source-PE MUST stop flooding the mLSP join TLV to the default mLSP. 696 3.5.6. Deletion of Data mLSP 698 Data mLSP join TLV will be flooded through default mLSP periodically 699 by the interval of MDT_INTERVAL [RFC6037], if during the timeout 700 period defined by MDT_DATA_TIMEOUT [RFC6037], there is no mLSP join 701 TLV received for a receiver-PE, the receiver-PE will start to delete 702 the P2MP leaf from the data mLSP. This is done by sending mRSVP-TE 703 PATHTEAR message to the upstream LSR. After the whole data mLSP is 704 deleted, the traffic will be switched back to the default mLSP. 706 3.5.7. PIM (S,G) signaling after Data mLSP is created 708 When a data mLSP is created for a particular multicast stream (S,G), 709 the PIM signaling is not changed. PIM join, prune for (S,G) is still 710 going through the default mLSP. 712 4. PIM-SSM Solutions 714 To support PIM-SSM by mRSVP, we have three options. 716 4.1. Option 1 718 PIM (S,G) join message received at Receiver-PE MUST trigger the data 719 mLSP setup by sending a mRSVP-TE P2MP path message to the Source-PE, 720 if the data mLSP was not created before. Source-PE address is the 721 BGP next hop of the address S. The mRSVP-TE path message MUST embed 722 the (S,G) information as shown in Fig. 1. 724 PIM join message is sent to default mLSP and received by the 725 Source-PE. This SHOULD trigger the PIM (S,G) state created at 726 Source-PE and Receiver-PE. The (S,G) state at Source-PE MUST add the 727 S-PMSI(MVPN_ID,mLSP_ID) for the data mLSP to its Olist; The (S,G) 728 state at reveier-PE SHOULD set the S-PMSI(MVPN_ID,mLSP_ID) as IIF. 730 After the PIM (S,G) state created at Source-PE, the traffic can be 731 sent to data mLSP immediately. 733 The P2MP mRSVP-TE path message for data mLSP MUST include the ERO 734 objects when the explicit path is given for the source S. 736 There is no default mLSP to data mLSP switching for this option. 738 4.2. Option 2 740 PIM (S,G) join message received at Receiver-PE MUST be sent to the 741 default mLSP and received by the Source-PE. This SHOULD trigger the 742 PIM (S,G) state created at Source-PE and Receiver-PE, if the PIM 743 state was not created before. The PIM (S,G) state at Source-PE 744 SHOULD add the MI-PMSI(MVPN_ID) as OIF; The (S,G) state at 745 receiver-PE SHOULD add the MI-PMSI(MVPN_ID) as IIF. 747 After the (S,G) state created at source-PE, the traffic can be sent 748 to the default mLSP. 750 Source-PE MUST detects the rate for the multicast stream (S,G) in a 751 MVPN. If the traffic rate for (S,G) exceeds the configured 752 threshold, the Source-PE MUST flood the mLSP join TLV to all PEs. 753 Each PE, if it is interested to receive the traffic for (S,G), MUST 754 initialize a mRSVP-TE P2MP path message to the Source-PE. 756 The P2MP path message MUST include the ERO objects when the explicit 757 path is given for the source S. 759 After the Source-PE creates a data mLSP for (S,G), it MUST switch the 760 traffic from default mLSP to data mLSP. 762 4.3. Option 3 764 PIM (S,G) join message received at Receiver-PE MUST be sent to the 765 default mLSP and received by the Source-PE. This SHOULD trigger the 766 PIM (S,G) state created at Source-PE and Receiver-PE, if the PIM 767 state was not created before. Unlike the option 2, PIM does not add 768 the default mLSP interface MI-PMSI(MVPN_ID) as the IIF and OIF for 769 (S,G) state. In stead, Source-PE MUST trigger a mLSP join TLV 770 flooded to all PEs. Each PE, if it is interested to receive the 771 traffic for (S,G), MUST initialize a mRSVP-TE P2MP path message to 772 the Source-PE to build up a data mLSP. 774 As the result of data mLSP setup, The PIM (S,G) state at receiver-PE 775 MUST add the S-PMSI(MVPN_ID, mLSP_ID) as IIF. At the Source-PE, 776 after the data mLSP is created. The PIM (S,G) state MUST add the 777 S-PMSI(MVPN_ID, mLSP_ID) as OIF; 779 The P2MP path message MUST include the ERO objects when the explicit 780 path is given for the source S. 782 There is no default mLSP to data mLSP switching for this option. 784 5. PIM-SM solutions 786 PIM-SM supporting is different to the PIM-SSM. It involves some 787 extra process like PIM register, register stop, RPT and SPT 788 switching, etc [RFC4601]. Following describes the details of 789 different scenarios for MVPN PIM-SM. 791 5.1. RP-PE mLSP 793 RP-PE mLSP is a mLSP whose header-end is at the RP-PE, and multiple 794 tail-ends at different Receiver-PEs. RP-PE mLSP is the equivalence 795 of RPT (RP tree or shared tree) of IP PIM in MPLS network. RP-PE 796 mLSP will use the default mLSP in the method specified in this 797 document. 799 PIM (*,G,RP) join message received at Receiver-PE MUST be sent to the 800 default mLSP and finally reach the RP-PE. Then, the Source-PE and 801 RP-PE can create the PIM state for (*,G). The (*, G) state at RP-PE 802 MUST have the MI-PMSI(MVPN_ID) as its OIF, and the (*, G) state at 803 Receiver-PE MUST have the MI-PMSI(MVPN_ID) as its IIF. 805 5.2. Source-PE mLSP 807 Source-PE mLSP is a mLSP whose header-end is at a Source-PE. 808 Depending on the location of tail-end, we have Source-PE to RP-PE 809 mLSP, and Source-PE to Receiver-PE mLSP. Source-PE to RP-PE mLSP is 810 the tree whose header-end is at the source-PE, and the tail-ends at 811 RP-PE. It is constructed after the PIM register process is finished 812 but before the PIM SPT switching or data mLSP switching. Source-PE 813 to receiver-PE mLSP is the tree whose header-end is at the source-PE, 814 and the tail-ends at receiver-PEs. It is built after SPT switching 815 or data mLSP switching. By the method specified in this document, 816 Source-PE to RP-PE mLSP also use the default mLSP like RP-PE mLSP. 817 source-PE to receiver-PE mLSP will use the data mLSP. 819 When the Source-PE and RP-PE are same (scenario 1 in section 6.3.1), 820 there is no Source-PE to RP-PE mLSP. 822 5.3. PIM register process 824 PIM register process is between multicast source and RP. Depending 825 on the PR location, we can have different scenarios. 827 5.3.1. Scenario 1: The multicast source and RP are behind the same PE 829 For this scenario, both RP and the multicast source are behind the 830 same PE for the same MVPN. In another words, the unicast path from 831 the multicast source to the multicast RP for a particular MVPN does 832 not need to go through one PE to another PE and cross the MPLS 833 network. So, the RP-PE is also the Source-PE. The PIM register 834 process does not cross different PEs in the core MPLS network. Both 835 RP-PE and source-PE are not aware of the PIM register process. There 836 is no particular design consideration for MPLS tunnels. 838 Before PIM register process, the PIM (*,G) join message from 839 different Receiver-PE MUST be forwarded to the RP-PE. As a result, 840 the PIM (*,G) state MUST be created on both RP-PE and Receiver-PE. 841 The state (*,G) at RP-PE has the MI-PMSI(MVPN_ID) as its OIF, and the 842 state (*,G) at Receiver-PE has the MI-PMSI(MVPN_ID) as its IIF. 844 After the PIM register process is finished, PIM state on RP-PE will 845 be changed to (S,G) which inherits all OIF from its parent (*,G). 846 There is no change for PIM state for (*,G) at Receiver-PE. The 847 multicast traffic will be flooded to all Receiver-PE through the RP- 848 mLSP, or default mLSP. the Receiver-PE SHOULD drop the traffic if it 849 does not have the (*,G) state created before. 851 5.3.2. Scenario 2: The multicast source and RP are behind the different 852 PE 854 For this scenario, RP and the multicast source are behind the 855 different PEs for the same MVPN. The unicast path from the multicast 856 source to the multicast RP MUST go through source-PE to RP-PE and 857 cross the MPLS network. 859 After the PIM(*,G) join is forwarded to the RP-PE through the default 860 mLSP from different Receiver-PE, Only the RP-PE and receiver-PE have 861 the state (*,G) created. The state at RP-PE has the default mLSP as 862 its OIF, and the interface connecting to a CE as the IIF, which CE is 863 the nexthop to reach RP from the RP-PE. The state at receiver-PE has 864 the default mLSP as IIF. 866 At Source-PE, there is no forwarding state. Multicast source S MUST 867 start the register process by sending data packet to RP. The PIM 868 register message is IP unicast message (encapsulated multicast data) 869 which destination is to RP from source S, it SHOULD go through a 870 unicast MPLS tunnel from Source-PE to RP-PE. The creation of unicast 871 MPLS tunnel is out of scope of this document. 873 When RP-PE receives register message which is encapsulated in MPLS 874 format, following things SHOULD happen: 876 o RP-PE MUST de-capsulate the MPLS packet and forward the PIM 877 register message to RP behind the RP-PE. RP then MUST forward the 878 multicast packet (de-capsulated from PIM register message) to all 879 Receiver-PE. This is done through the (*,G) state created before 880 PIM register process. The traffic from RP will be forwarded back 881 to RP-PE from the interface connecting to CE, and then RP-PE will 882 forward the traffic to RP-mLSP, or the default mLSP. 884 o All PEs attached to the default mLSP SHOULD receive the traffic. 885 Source-PE and receiver-PE which did not join the group G SHOULD 886 drop the traffic. 888 o RP initialize a PIM (S,G) join to source S. S address is retrieved 889 from the received data traffic from PIM register message. The 890 (S,G) join message MUST be forwarded from RP to RP-PE, and then 891 RP-PE MUST forward the join through the default mLSP to the 892 Source-PE. The address of Source-PE is determined by the BGP next 893 hop of the VPN address S. 895 o The Source-PE and RP-PE MUST create a PIM (S,G) state as a result 896 of PIM (S,G) join message processing, PIM (S,G) state at Source-PE 897 MUST have the MI-PMSI(MVPN_ID) as OIF, PIM (S,G) state at RP-PE 898 MUST inherit all OIF from the previous (*,G) state, and adds the 899 MI-PMSI(MVPN_ID) as IIF. Note, the OIF for old (*,G) state has 900 had the MI-PMSI(MVPN_ID) as OIF, this OIF MUST NOT be inherited 901 for (S,G). 903 o At Source-PE, the multicast traffic received from a multicast 904 source behind Source-PE, MUST be forwarded through the source-PE 905 to RP-PE mLSP represented by the OIF of MI-PMSI(MVPN_ID). The 906 "source-PE to RP-PE mLSP" is the default mLSP. Meanwhile, 907 multicast source S still embeds the traffic as the PIM register 908 message and send it to RP through the unicast MPLS tunnel. 910 o After the RP-PE receives the traffic from the source-PE to RP-PE 911 mLSP (default mLSP) during the PIM register process, following 912 events SHOULD happen 914 1. RP-PE SHOULD forward the traffic to RP. 916 2. After RP receives the native multicast traffic from the 917 interface which was used to forward the PIM (S,G) join message 918 to multicast source S, RP SHOULD stop de-capsulating the PIM 919 register message. All received PIM register message will be 920 discarded. 922 3. RP Sends a PIM register-stop (unicast) message to multicast 923 source S. 925 o After the multicast source receives register-stop message, it MUST 926 stop to send PIM register message to RP, and all multicast data is 927 natively forwarded by the (S,G) state to flood to the source-PE to 928 RP-PE mLSP, or the default mLSP. 930 5.4. SPT switching 932 After Receiver-PE receive multicast traffic from the default mLSP. 933 Each Receiver-PE SHOULD forward the traffic to some attached CEs by 934 the PIM state (*,G) created when the PIM (*,G) join was received from 935 the attached CEs. 937 After the traffic reaches the Last Hop Router (LHR), LHR can 938 initialize the Shortest Path Tree (SPT) switching by checking the 939 traffic rate. If the rate exceeds the pre-configured threshold, LHR 940 SHOULD send the PIM (S,G) join to the multicast source. 942 With the above solution for SPT switching, the Receiver-PE MUST still 943 forward the PIM (S,G) join to the default mLSP. And the PIM (S,G) 944 state SHOULD be created at the Receiver-PE and the state SHOULD 945 inherit all Olist from the previously created (*,G) state. 947 As a result of this SPT switching solution, only Receiver-PE has the 948 PIM state change. The traffic will be forwarded by (S,G) instead of 949 (*,G). Source-PE has no change to the PIM state (S,G). There is no 950 MPLS LSP changes for the traffic forwarding path in MPLS core 951 network. The traffic is still forwarded to the default mLSP at 952 source-PE. 954 5.5. RPT prune 956 Using the above method, the SPT switching does not lead to the 957 traffic receiving interface change on the receiver PE, so, there is 958 no RPT prune message triggered. 960 5.6. Data mLSP switching 962 As described in above section, the SPT switching does not change the 963 MPLS path for multicast forwarding. Some receiver-PEs still receive 964 the traffic even there is no intention to join the specific group G. 965 We will use data mLSP switching to serve the similar purpose for MPLS 966 network as SPT switching in IP network. By data mLSP switching, the 967 multicast forwarding path in MPLS network can be changed from a 968 shared tree (default mLSP) to a 970 o Shortest MPLS path from receiver to source, if the explicit path 971 is not configured for the source S, and the QoS is not required. 973 o User defined path, if the explicit path is configured for the 974 source S, or the QoS reservation is required. 976 If the traffic rate for the stream (S,G) exceeds the threshold, the 977 Source-PE MUST flood the mLSP join TLV to all PEs. Each PE, if it 978 has already created the PIM state for group G, MUST initialize a 979 mRSVP-TE P2MP path message to the Source-PE. The Source-PE is found 980 by the BGP next hop address for S. 982 The Receiver-PE MUST update its IIF for state (S,G) from MI- 983 PMSI(MVPN_ID) to S-PMSI(MVPN_ID, mLSP_ID). 985 After the data mLSP is constructed at Source-PE, the PIM state (S,G) 986 MUST add S-PMSI(MVPN_ID, mLSP_ID) to its Olist and prune the old OIF 987 MI-PMSI(MVPN_ID). Note, at this moment, the traffic is still sent to 988 the default mLSP from the Source-PE. 990 As a result of OIF updating for (S,G) at Source-PE, the traffic is 991 switched from the default mLSP to the data mLSP for (S,G). 993 5.7. PIM state at Receiver-PE 995 PIM state at Receiver-PE may be different due to the rate threshold 996 configuration of SPT switching and data mLSP switching. 998 o If the rate threshold for mLSP data switching is less than the 999 rate threshold for SPT switching, the data mLSP will be switched 1000 earlier than the SPT switching in IP. The multicast distribution 1001 tree in MPLS could be switched to a shortest path tree but the 1002 tree in IP network is still a shared tree. As a result, the 1003 traffic is carried by a P2MP tunnel in MPLS network. But at the 1004 receiver-PE, the de-capsulated MPLS traffic MUST be still 1005 forwarded by a PIM state (*,G) which is corresponding to a shared 1006 tree. 1008 o If the rate threshold for mLSP data switching is greater than the 1009 rate threshold for SPT switching, the data mLSP will be switched 1010 later than the SPT switching in IP. The tree in IP network is 1011 switched to a shortest path tree but the multicast distribution 1012 tree in MPLS is still a default mLSP. So, the traffic is carried 1013 by a MP2MP tunnel in MPLS network, and at the receiver-PE, the de- 1014 capsulated MPLS traffic will be forwarded by a PIM state (S,G) 1015 which is corresponding to a shortest path tree. 1017 6. Aggregation 1019 With the method described above, there is one data mLSP per multicast 1020 stream (S,G). This may not be feasible if the stream number is big, 1021 or, there is limit for MPLS label for multicast in a network. Under 1022 those scenarios, traffic aggregation in MPLS network is desired. 1024 Aggregation can save the MPLS tunnel, but always with trade off. 1025 When multiple MPLS multicast trees are not completely overlapped, to 1026 aggregate them will lead to some sub-LSP waste the bandwidth. For 1027 example, if two trees have different set of receiver-PEs, some 1028 traffic has to be dropped on a PE if it does not have the (S,G) state 1029 created before. 1031 6.1. Aggregation by Default mLSP 1033 The aggregation by the default mLSP is straightforward. If we do not 1034 set the data mLSP for any (S,G), the traffic of (S,G) will be kept in 1035 the default mLSP forever. The aggregation for selective (S,G) can be 1036 done at CLI level by ACL (Access List) or any other kind of tool to 1037 make the streams which satisfy some conditions to stay in the default 1038 mLSP. 1040 6.2. Aggregation by Data mLSP 1042 The aggregation by the data mLSP can be achieved by the following 1043 ways 1045 o Source-PE assigns the same mLSP ID for the streams expected to be 1046 aggregated, and keeps the mapping for the mLSP ID to different 1047 (S,G). 1049 o Source-PE floods the mLSP join TLV for each (S,G) with the same 1050 mLSP ID to default mLSP. 1052 o Receiver-PE receives the mLSP join TLV and checks if the data mLSP 1053 corresponding to the mLSP ID is created already. If yes, 1054 receiver-PE SHOULD only update its mapping for the mLSP ID to an 1055 new (S,G) but SHOULD NOT initialize the new path message to 1056 source-PE. 1058 o Source-PE SHOULD switch multiple streams which were assigned with 1059 the same mLSP ID to the same data mLSP after it is created. 1061 The aggregation by data mLSP essentially aggregates multicast streams 1062 which share the same source-PE even they have different multicast 1063 source. 1065 7. Non-VPN multicast support 1067 The method specified in this document can also apply to the non-VPN 1068 multicast support. 1070 For the non-VPN multicast case, we will take the same approach as VPN 1071 multicast case. Basically, we will treat the public table with a 1072 special VPN ID = 0 (see section 9 for VPN ID). By such treatment, 1073 the multicast in public domain becomes the multicast in a special 1074 table, and it can be supported as normal mVPN. 1076 8. Message Format and Constants 1078 Two types of new message format have to be introduced to support mVPN 1079 by mRSVP-TE. One is the SESSION-object message format for mRSVP-TE. 1080 Another is the mLSP join TLV message format. 1082 The SESSION-object defined in mRSVP-TE is a opaque value (Fig. 7 in 1083 [I-D.lzj-mpls-receiver-driven-multicast-rsvp-te]). So, we can define 1084 the details of the opaque value based on the mVPN requirement. For 1085 the PIM-SSM support option 1 (Fig. 1, Fig. 2), we can embed the 1086 "c-source" and "c-group" directly into the SESSION-object. But for 1087 PIM-SM support, and PIM-SSM support option 2/3, we can embed the 1088 "mLSP ID" into the SESSION-object (Fig. 3). "mLSP ID" can map to 1089 different "c-source" and "c-group" at PEs. 1091 The mLSP join TLV message format is similar to the MDT defined in 1092 section 7.2 and 7.3 [RFC6037]. The difference is that we have to use 1093 a value other than "P Group" for MPLS case since we do not have "P 1094 Group" for MPLS core network. 1096 8.1. Path session object for PIM-SSM option 1 (IPv4) 1098 The MVPN mRSVP path message for PIM-SSM option 1 for IPv4 has the 1099 following format. 1101 Class = SESSION, mRSVP_TE_MVPN_IPv4 C-Type = TBD 1103 0 1 2 3 1104 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 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | | 1107 + VPN ID + 1108 | | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 | C-source | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 | C-group | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 Fig. 1 mVPN mRSVP-TE path session object for PIM-SSM option 1 (IPv4) 1116 VPN ID: 1117 This is the ID for MVPN, it MUST be same for the same VPN cross 1118 a MPLS network. VRF RD (Route Distinguisher) or any other 1119 unique value in a MPLS network can be used for VPN ID. 0 is 1120 reserved for the global MPLS multicast or non MVPN case 1122 C-source (32 bits): 1123 the IPv4 address of the traffic source in the VPN. 1125 C-group (32 bits): 1126 the IPv4 address of the multicast traffic destination address 1127 in the VPN. 1129 8.2. Path session object for PIM-SSM option 1 (IPv6) 1131 The MVPN mRSVP path message for PIM-SSM option 1 for IPv6 has the 1132 following format. 1134 Class = SESSION, mRSVP_TE_MVPN_IPv6 C-Type = TBD 1136 0 1 2 3 1137 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 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 | | 1140 + VPN ID + 1141 | | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 | | 1144 | C-source | 1145 | | 1146 | | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 | | 1149 | C-group | 1150 | | 1151 | | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 Fig. 2 mVPN mRSVP-TE path session object for PIM-SSM option 1 (IPv6) 1156 VPN ID: 1157 Same definition as in Fig. 1 1159 C-source (128 bits): 1160 the IPv6 address of the traffic source in the VPN. 1162 C-group (128 bits): 1163 the IPv6 address of the multicast traffic destination address 1164 in the VPN. 1166 8.3. Path session object for other PIM modes (IPv4) 1168 The MVPN mRSVP-TE path message for PIM-SM, PIM-SSM (Option 2 and 3) 1169 for IPv4 has the following format. 1171 Class = SESSION, mRSVP_TE_MVPN_IPv4 C-Type = TBD 1173 0 1 2 3 1174 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 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 | | 1177 + VPN ID + 1178 | | 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | mLSP ID | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 Fig. 3 mVPN mRSVP-TE path session object for PIM-SM, PIM-SSM (Option 1184 2 and 3) 1186 VPN ID: 1187 Same definition as in Fig. 1 1189 mLSP ID: 1190 the mLSP ID corresponding to a tunnel, 0 is reserved for 1191 default mLSP. For all non-zero mLSP ID, it SHOULD come from 1192 the mLSP join TLV message, see Fig. 4 and Fig. 5 1194 8.4. Path session object for other PIM modes (IPv6) 1196 The MVPN mRSVP-TE path message for PIM-SM, PIM-SSM (Option 2 and 3) 1197 for IPv6 has the following format. 1199 Class = SESSION, mRSVP_TE_MVPN_IPv6 C-Type = TBD 1201 The session object format is the same as for IPv4 shown in Fig 3. 1203 8.5. mLSP TLV Message format for IPv4 1205 The mLSP Join TLV for IPv4 streams has the following format. 1207 0 1 2 3 1208 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 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 | Type | Length | Reserved | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | C-source | 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 | C-group | 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 | mLSP ID | 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 Fig. 4 mLSP join TLV message format for IPv4 1221 Type (8 bits): 1222 MUST be set to 1. 1224 Length (16 bits): 1225 MUST be set to 16. 1227 Reserved (8 bits): 1228 for future use. 1230 C-source (32 bits): 1231 the IPv4 address of the traffic source in the VPN. 1233 C-group (32 bits): 1234 the IPv4 address of the multicast traffic destination address 1235 in the VPN. 1237 mLSP ID (32 bits): 1238 the mLSP ID corresponding to the data mLSP carrying the flow 1239 (C-source, C-group). 1241 8.6. mLSP TLV Message format for IPv6 1243 The mLSP Join TLV for IPv6 streams has the following format. 1245 0 1 2 3 1246 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 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 | Type | Length | Reserved | 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 | | 1251 | C-source | 1252 | | 1253 | | 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 | | 1256 | C-group | 1257 | | 1258 | | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | mLSP ID | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 Fig. 5 mLSP join TLV message format for IPv6 1265 Type (8 bits): 1266 MUST be set to 4. 1268 Length (16 bits): 1269 MUST be set to 40. 1271 Reserved (8 bits): 1272 for future use. 1274 C-source (128 bits): 1275 the IPv6 address of the traffic source in the VPN. 1277 C-group (128 bits): 1278 the IPv6 address of the multicast traffic destination address 1279 in the VPN. 1281 mLSP ID (32 bits): 1282 the mLSP ID corresponding to the data mLSP carrying the flow 1283 (C-source, C-group). 1285 9. Acknowledgements 1287 We would like to thank Katherine Zhao and Quintin Zhao for comments 1288 on early drafts of this work. 1290 10. IANA Considerations 1292 There is no change with regards to IANA 1294 11. Security Considerations 1296 There is no change with regards to the security for PIM protocol and 1297 mRSVP-TE after the MVPN is provided 1299 12. References 1301 12.1. Normative References 1303 [I-D.lzj-mpls-receiver-driven-multicast-rsvp-te] 1304 Li, R., Zhao, Q., and C. Jacquenet, "Receiver-Driven 1305 Multicast Traffic Engineered Label Switched Paths", 1306 draft-lzj-mpls-receiver-driven-multicast-rsvp-te-00 (work 1307 in progress), March 2012. 1309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1310 Requirement Levels", BCP 14, RFC 2119, March 1997. 1312 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1313 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1314 Protocol Specification (Revised)", RFC 4601, August 2006. 1316 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 1317 "Extensions to Resource Reservation Protocol - Traffic 1318 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1319 Switched Paths (LSPs)", RFC 4875, May 2007. 1321 [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, 1322 "Bootstrap Router (BSR) Mechanism for Protocol Independent 1323 Multicast (PIM)", RFC 5059, January 2008. 1325 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 1326 "Label Distribution Protocol Extensions for Point-to- 1327 Multipoint and Multipoint-to-Multipoint Label Switched 1328 Paths", RFC 6388, November 2011. 1330 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 1331 VPNs", RFC 6513, February 2012. 1333 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1334 Encodings and Procedures for Multicast in MPLS/BGP IP 1335 VPNs", RFC 6514, February 2012. 1337 12.2. Informative References 1339 [RFC6037] Rosen, E., Cai, Y., and IJ. Wijnands, "Cisco Systems' 1340 Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037, 1341 October 2010. 1343 Authors' Addresses 1345 Lin Han (editor) 1346 Huawei Technologies 1347 2330 Central Expressway 1348 Santa Clara, CA 95050 1349 USA 1351 Phone: +10 408 330 4613 1352 Email: lin.han@huawei.com 1354 Renwei Li 1355 Huawei Technologies 1356 2330 Central Expressway 1357 Santa Clara, CA 95050 1358 USA 1360 Phone: 1361 Email: renwei.li@huawei.com 1363 Christian Jacquenet 1364 France Telecom Orange 1365 4 rue du Clos Courtel 1366 35512 Cesson Sevigne, 1367 France 1369 Phone: +33 2 99 12 43 82 1370 Email: christian.jacquenet@orange.com