idnits 2.17.1 draft-lzj-mpls-receiver-driven-multicast-rsvp-te-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 7, 2012) is 4311 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) == Missing Reference: 'RFC 4875' is mentioned on line 520, but not defined == Missing Reference: 'RFC 2205' is mentioned on line 520, but not defined == Missing Reference: 'RFC 4090' is mentioned on line 900, but not defined == Missing Reference: 'I-D.zlj-mpls-mpls-mrsvp-te-frr' is mentioned on line 906, but not defined == Missing Reference: 'TBD' is mentioned on line 914, but not defined == Unused Reference: 'RFC2119' is defined on line 975, but no explicit reference was found in the text == Unused Reference: 'RFC2702' is defined on line 978, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 982, but no explicit reference was found in the text == Unused Reference: 'RFC4461' is defined on line 989, but no explicit reference was found in the text == Unused Reference: 'RFC4420' is defined on line 998, but no explicit reference was found in the text == Unused Reference: 'RFC4206' is defined on line 1004, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 1012, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 1016, but no explicit reference was found in the text == Unused Reference: 'I-D.zlj-mpls-mrsvp-te-frr' is defined on line 1022, but no explicit reference was found in the text == Unused Reference: 'I-D.hlj-l3vpn-mvpn-mrsvp-te' is defined on line 1028, but no explicit reference was found in the text == Unused Reference: 'RFC3468' is defined on line 1034, but no explicit reference was found in the text == Unused Reference: 'RFC3564' is defined on line 1042, but no explicit reference was found in the text == Unused Reference: 'RFC5467' is defined on line 1046, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2702 ** Downref: Normative reference to an Informational RFC: RFC 4461 ** Obsolete normative reference: RFC 4420 (Obsoleted by RFC 5420) == Outdated reference: A later version (-02) exists of draft-zlj-mpls-mrsvp-te-frr-00 == Outdated reference: A later version (-01) exists of draft-hlj-l3vpn-mvpn-mrsvp-te-00 -- Obsolete informational reference (is this intentional?): RFC 5467 (Obsoleted by RFC 6387) Summary: 3 errors (**), 0 flaws (~~), 23 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group R. Li 3 Internet-Draft Q. Zhao 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 8, 2013 C. Jacquenet 6 France Telecom Orange 7 July 7, 2012 9 Receiver-Driven Multicast Traffic-Engineered Label-Switched Paths 10 draft-lzj-mpls-receiver-driven-multicast-rsvp-te-01.txt 12 Abstract 14 This document describes extensions to Resource Reservation Protocol - 15 Traffic Engineering (RSVP-TE) for the setup of Receiver-Driven 16 Traffic-Engineered point-to-multipoint (P2MP) and multipoint-to- 17 multipoint (MP2MP)Label Switched Paths (LSPs) in Multi-Protocol Label 18 Switching (MPLS) and Generalized MPLS (GMPLS)networks. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 8, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Receiver-Driven mRSVP-TE LSP Examples . . . . . . . . . . . . 7 71 2.1. P2MP Example . . . . . . . . . . . . . . . . . . . . . . . 8 72 2.2. MP2MP Example . . . . . . . . . . . . . . . . . . . . . . 9 73 3. Signaling Protocol Extensions . . . . . . . . . . . . . . . . 10 74 3.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 10 75 3.1.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . 10 76 3.1.2. L2S Sub-LSPs . . . . . . . . . . . . . . . . . . . . . 11 77 3.1.3. Path Originator and Data Receiver . . . . . . . . . . 12 78 3.1.4. Explicit Routing . . . . . . . . . . . . . . . . . . . 13 79 3.2. Path Messages . . . . . . . . . . . . . . . . . . . . . . 13 80 3.3. Resv Messages . . . . . . . . . . . . . . . . . . . . . . 15 81 3.4. PathErr Messages . . . . . . . . . . . . . . . . . . . . . 15 82 3.5. ResvErr Message . . . . . . . . . . . . . . . . . . . . . 15 83 3.6. PathTear Messages . . . . . . . . . . . . . . . . . . . . 16 84 4. New and Updated Objects . . . . . . . . . . . . . . . . . . . 16 85 4.1. SESSION Objects . . . . . . . . . . . . . . . . . . . . . 16 86 4.1.1. P2MP LSP for IPv4 SESSION Objects . . . . . . . . . . 16 87 4.1.2. MP2MP LSP for IPv4 SESSION Objects . . . . . . . . . . 17 88 4.1.3. P2MP LSP for IPv6 SESSION Objects . . . . . . . . . . 17 89 4.1.4. MP2MP LSP for IPv6 SESSION Objects . . . . . . . . . . 17 90 4.2. SENDER_TEMPLATE Objects . . . . . . . . . . . . . . . . . 18 91 4.2.1. Multicast LSP IPv4 SENDER_TEMPLATE Objects . . . . . . 18 92 4.2.2. Multicast LSP IPv6 SENDER_TEMPLATE Objects . . . . . . 18 93 4.3. L2S_SUB_LSP Objects . . . . . . . . . . . . . . . . . . . 19 94 4.3.1. L2S_SUB_LSP IPv4 Objects . . . . . . . . . . . . . . . 19 95 4.3.2. L2S_SUB_LSP IPv6 Objects . . . . . . . . . . . . . . . 19 96 4.4. FILTER_SPEC Objects . . . . . . . . . . . . . . . . . . . 20 97 4.4.1. mRSVP-TE LSP_IPv4 FILTER_SPEC Objects . . . . . . . . 20 98 4.4.2. mRSVP-TE LSP_IPv6 FILTER_SPEC Objects . . . . . . . . 20 99 5. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 5.1. Interwork with PIM . . . . . . . . . . . . . . . . . . . . 20 101 5.2. Multicast VPN . . . . . . . . . . . . . . . . . . . . . . 21 102 6. Fast Re-Route Considerations . . . . . . . . . . . . . . . . . 21 103 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 21 104 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 105 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 106 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 107 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 108 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 109 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 112 1. Introduction 114 Multiparty multimedia applications are getting greater attention in 115 the telecom and datacom world. Such applications are QoS-demanding 116 and can therefore benefit from the activation of MPLS traffic 117 engineering capabilities that lead to the dynamic computation and 118 establishment of MPLS LSPs whose characteristics comply with 119 application-specific QoS requirements. P2MP-TE [RFC4875] defines a 120 procedure to set up point-to-multipoint LSPs from sender to 121 receivers. Sometimes multicast data streams are required to get 122 transported over both IP networks and MPLS networks, which require 123 PIM must interwork with RSVP-TE. On other times, PIM bootstraping 124 messages need to transport over an intermediate MPLS domain. This 125 document extends RSVP-TE for the dynamic computation of receiver- 126 driven P2MP and MP2MP LSP tree structures. 128 1.1. Motivation 130 IP multicast distribution trees are receiver-initiated and dynamic by 131 nature. IP multicast-enabled applications are also bandwidth savvy, 132 especially in the area of residential IPTV services, where the 133 delivery of multicast contents to several hundreds of thousands of 134 IPTV receivers assumes the appropriate level of quality. 136 Current source-driven P2MP LSP establishment, as defined as in 137 [RFC4875], assumes a priori knowledge of receiver locations, and the 138 LSP signalling is initiated and driven by the data sender(headend). 139 The priori knowledge of receiver locations is obtained either through 140 static configuration or by using another protocol to discover such 141 receivers. On the other hand, there is no straightfoward way to 142 support MP2MP applications by using P2MP LSP unless full-meshed P2MP 143 LSPs are set up. 145 The receiver-driven extension to RSVP-TE defined in this document 146 will support both P2MP LSPs and MP2MP LSPs. Moreover, it does not 147 require the sender to know all the receivers' locations a priori. 148 The protocols for discovery of receivers are not needed. It provides 149 a natural mechanism to interwork with PIM dynamically. 151 1.2. Terminology 153 The following terms are used in this document: 155 o Sender: Sender refers to the Originator (and hence the Sender) of 156 the content/payload, as defined in [RFC2205]. 158 o Receiver: Receiver refers to the Receiver of the content/payload, 159 as defined in [RFC2205]. 161 o Upstream: The direction of flow from content Receiver toward 162 content Sender, as defined in [RFC2205]. 164 o Downstream: The direction of flow from content Sender toward 165 content Receiver, as defined in [RFC2205]. 167 o Path-Sender: The sender of RSVP PATH messages, with no correlation 168 to the direction of content/payload flows. Its flow direction is 169 irrelevant to that of Sender defined above. All other control 170 messages discussed in this document will use this as the 171 reference. 173 o Path-Receiver: The receiver of RSVP PATH messages, with no 174 correlation to the direction of content/payload flows. 176 o Path-Initiator: The Path-Sender that originated a RSVP PATH 177 message. This is different from Path-Sender in that an 178 intermediate node can be a Path-Sender, but such an intermediate 179 node cannot create and initiate the RSVP PATH message. A Path- 180 Initator is a Path-Sender, but a Path-Sender doesn't have to be a 181 Path-Initiator. 183 o Path-Terminator: The Path-Receiver that does NOT propagate the 184 Path message any further. This is different from Path-Receiver in 185 that an intermediate node can be a Path-Receiver, but such an 186 intermediate node will propagate the Path message to the next hop. 188 o Root: A router where a multcast LSP tree is rooted at. Data 189 enters the root and then is distributed to leaves along the P2MP/ 190 MP2MP LSP. 192 1.3. Overview 194 Although the receiver-driven extensions to RSVP-TE as defined in this 195 document use the existing sender-driven syntax, there are important 196 semantic differences that need to be defined for correct 197 interpretation and interoperability. In the receiver-driven context, 198 we inverted the semantics of RSVP-TE messages, while keeping the 199 syntax unchanged as much as possible. We will use mRSVP-TE to 200 represent the RSVP-TE with receiver-driven extensions described in 201 this document. 203 The following are some key differences that are specific to the 204 receiver-driven paradigm: 206 o The leaf router: the router that receives data/content/payload. 207 In this document, the leaf router will initiate PATH messages. In 208 some sense, the leaf router and the receiver mean the same thing. 210 The term "receiver-driven" also means "leaf-driven". 212 o L2S Destinations: routers where user data payload traffic enters 213 the LSP. L2S means Leaf-to-Source. The source is the sender or 214 root of a multicast stream. 216 o RSVP P2MP PATH messages traverse from receivers to the root. 218 o RSVP P2MP RESV messages traverse from the root to the leaf routers 219 of the P2MP tree strcuture. 221 o A RSVP RESV message received by a router is interpreted as a 222 successful resource reservation made by the upstream node for the 223 establishment of the P2MP tree structure. 225 o A RSVP RESV message received by a router is interpreted as 226 successful resource reservation made by the downstream node for 227 the establishment of an MP2MP tree structure. 229 o Label allocation on incoming interfaces is done prior to sending 230 RSVP PATH messages upstream for P2MP tree structures. 232 o Label allocation on incoming interfaces is done prior to sending 233 RSVP RESV messages upstream for MP2MP tree structures. 235 o For P2MP LSP tree structures, a node receiving a RSVP PATH message 236 first decides if this RSVP PATH message will make the said node a 237 branch LSR or not. If it is not a branch LSR, it is a transit 238 LSR. In the case that it will become a transit LSR because of 239 this PATH message, it will, before sending the RSVP PATH message 240 upstream, allocate required bandwidth on the interface on which 241 the RSVP PATH message is received. The upstream node can send 242 traffic soon after successfully reserving resources on the 243 downstream link, on which the RSVP PATH message SHOULD be 244 received. In the case that the node is already a branch or a 245 transit node before it receives the PATH message, then it will 246 allocate required bandwidth on the interface on which the RSVP 247 PATH message is received, and send the RESV message to the node 248 which sends the PATH message without propagating the PATH message 249 further to the upstream node. For P2MP LSPs, a label is carried 250 by the PATH message and should be used by the upstream node when 251 distributing the data from upstream to downstream. 253 o For MP2MP LSP tree structures, a node will allocate required 254 bandwidth on the interface through which the RSVP PATH message is 255 sent before sending the RSVP PATH message upstream. A node 256 receiving a RSVP PATH message MUST first decide if this RSVP PATH 257 message will make the said node a branch LSR or not. In the case 258 it will become a transit LSR because of this PATH message, then it 259 will allocate required bandwidth on the interface on which the 260 RSVP PATH message is received and will allocate required bandwidth 261 on the interface through which the RSVP PATH message is sent, 262 before sending the RSVP PATH message upstream. The downstream 263 node can send traffic soon after successfully reserving bandwidth 264 on the upstream link through which the RSVP PATH message SHOULD be 265 sent. The upstream node can send traffic soon after successfully 266 reserving bandwidth on the downstream link on which the RSVP PATH 267 message SHOULD be received. In the case that the node is already 268 a branch or a transit node before it receives the PATH message, 269 then it will allocate required resources on the interface on which 270 the RSVP PATH message is received, and send the RESV message to 271 the node which sends the PATH message without propagating the PATH 272 message further to the upstream node. The label carried by the 273 PATH message should be used by the Path-Receiver node to forward 274 data from the Path-Receiver node to the Path-Sender node, and the 275 label carried by RESV messages should be used by its corresponding 276 Path-Sender node to send data from the Path-Sender node to the 277 Path-Receiver node. 279 o For the sake of readability, from now on all mRSVP-TE LSPs will be 280 used to represent all P2MP and/or MP2MP LSPs in receiver-driven 281 (RD) multicast P2MP/MP2MP MPLS environments. We will sometimes 282 use RD P2MP TE LSP or RD MP2MP TE LSP to represent such receiver- 283 driven multicast LSPs. 285 2. Receiver-Driven mRSVP-TE LSP Examples 287 In what follows we describe two examples to show how P2MP and MP2MP 288 are set up, respectively. In both of such examples, Path messages 289 are initiated by data receivers. 291 For the P2MP example, a Path message carries a label for the use of 292 sending data downstream. And for the MP2MP example, both Path 293 message and Resv message carries a label for sending data downstream 294 and upstream. 296 2.1. P2MP Example 298 Sender/Source/Path Terminator/Ingress Router 299 +---------+ 300 | R1 | 301 +-----+---+ 302 _ 303 \ \ /\ 304 \ \ \ Path Message w/ Label OBJECT 305 Resv \ \ \ (msg2) 306 Message \ \ \ 307 (msg3) \ \ \ 308 _\/ \ \ 309 +----------------+ Path Remerge 310 | R3 | Creates Branch Point 311 +----------------+ 312 _ _ 313 / / /\ \ \ /\ 314 / / / \ \ \ Path Message (msg1) 315 Resv Message / / / msg4 \ \ \ w/ Label OBJECT 316 (msg6) / / / \ \ \ 317 / / /Path Msg \ \ \ 318 / / / (msg5) \ \ \ 319 \/_ / / w/Label OBJ _\/ \ \ 320 +----------+ +---+-----+ 321 | R4 | | R5 | 322 +----------+ +---------+ 323 Path Initiator Path Initiator 324 Originator ID = R4 Originator ID = R5 325 L2S Destination = R1 L2S Destination = R1 326 Session = S Session = S 328 Figure 1: P2MP Example 330 In Figure 1, when R5 is added as the first leaf of a mulitcast 331 distribution tree (multicast LSP), the message flow goes as follows: 332 R5->msg1->R3->msg2->R1->msg3->R3->msg4->R5. When the leaf R4 is 333 added, the message flow goes from R4->msg5->R3->msg6->R4. In this 334 case, when R3 receives msg5, R3 finds out that a multicast LSP has 335 already been set up for the same session and the same source. 336 Therefore, R3 finds itself a branch node for leaf R4 and R5, so it 337 will terminate the PATH message and build the corresponding RESV 338 message and send it back to R4. The association of the LSP initiated 339 by R4 to the existing multicast LSP is determined based on the 340 processing of the SESSION object and L2S_SUB_LSP object from the 341 mRSVP-TE message. The SESSION object and the L2S_SUB_LSP objects are 342 documented later in this draft. 344 2.2. MP2MP Example 346 Root/Path Terminator/Ingress Router 347 +---------+ 348 | R1 | 349 +-----+---+ 350 _ 351 \ \ /\ 352 \ \ \ Path-mp2mp Message w/ Label OBJECT 353 Resv \ \ \ (msg2) 354 Message \ \ \ 355 (msg3) \ \ \ 356 w/ Label OBJECT _\/ \ \ 357 +----------------+ Path-mp2mp 358 | R3 | (Branch Point) 359 +----------------+ 360 _ _ 361 / / /\ \ \ /\ 362 / / / \ \ \ Path-mp2mp Message (msg1) 363 Resv Message / / / msg4 \ \ \ (msg1) 364 (msg6) / / / \ \ \ w/ Label OBJECT 365 w/ Label OBJECT/ / /Path-mp2mp \ \ \ 366 / / / Message \ \ \ 367 / / / (msg5) \ \ \ 368 \/_ / / w/ Label OBJ _\/ \ \ 369 +----------+ +---+-----+ 370 | R4 | | R5 | 371 +----------+ +---------+ 372 Path-mp2mp Initiator Path-mp2mp Initiator 373 Originator ID = R4 Originator ID = R5 374 L2S Destination = R1 L2S Destination = R1 375 Session = S Session = S 377 Figure 2: MP2MP Example 379 In Figure 2, when R5 is added as the first leaf (as both a sender and 380 a receiver) of an MP2MP multicast LSP, the message flow goes from 381 R5->msg1->R3->msg2->R1->msg3->R3->msg4->R5. When the leaf R4 ( as 382 both a sender and a receiver)is added, the message flow goes from 383 R4->msg5->R3->msg6->R4. In this case, when R3 receives msg5, R3 384 finds out that an MP2MP mulitcast LSP has already been set up for the 385 same session and the same root and R3 will become the branch LSR for 386 the leaf R4 and R5, so it will terminate the PATH message, build a 387 RESV message and send the RESV message back to R4. The association 388 of the LSP initiated by R4 to the existing MP2MP LSP is determined 389 based on the processing of the SESSION object and the S2L_SUB_LSP 390 from the mRSVP-TE message. The SESSION objects and the L2S_SUB_LSP 391 objects are further documented later in this draft. 393 3. Signaling Protocol Extensions 395 The RSVP-TE with receiver-driven extensions (mRSVP-TE) is similar to 396 the RSVP-TE protocol as specified in [RFC4875], [RFC3473] and 397 [RFC3209], but differs in that the data receivers of an LSP tunnel 398 initiate the Path messages toward the data sender (or the root of a 399 mulitcast LSP). Compared with [RFC4875], mRSVP-TE can also be used 400 to set up MP2MP LSPs. 402 In the context of the receiver-driven RSVP-TE, the Receiver is the 403 Path-Originator. The Path messages go from the Receivers towards the 404 Sender. The Resv messages flow in the opposite direction as compared 405 to the Path messages, i.e. Resv messages are generated by the Sender 406 or a branch LSR. Path messages flow in opposite directions as 407 cmpared with those of the multicast stream distributions, while Resv 408 messages flow in the same directions as the multicast streams. 410 In the context of the receiver-driven RSVP-TE, a Path message will be 411 terminated at the "root" of the multicast distribution tree 412 (multicast LSP) or at an intermediate node if the intermediate node 413 has received another Path message from another receiver for the same 414 multicast distribution tree. When an intermediate node receives two 415 or more Path messages for the same multicast distribution tree, the 416 intermediate node will merge them together. Whether two Path 417 messages should be merged depends on the information encoded in the 418 SESSION and L2S-SUB-LSP objects. The SESSION object encodes 419 multicast group information and the L2S-SUB-LSP (leaf-to-source sub- 420 lsp) object encodes the multicast source or multicast root 421 information. 423 The following sections describe the receiver-driven extensions to the 424 RSVP-TE protocol. When there is no difference in the protocol, the 425 usage of [RFC4875] is assumed. 427 3.1. Mechanisms 429 3.1.1. Sessions 431 As specified in [RFC2205], a session is a data flow with a particular 432 destination and transport-layer protocol. In the context of 433 multicast, the data flow is essentially a multicast distribution tree 434 rooted at the P2MP source or MP2MP root. 436 For the sake of reliability, two or more sources/roots may be 437 deployed to distribute the same multicast streams. A mulitcast 438 stream is often represented by a mulitcast group address. In this 439 document, we will encode the mulitcast group address in the SESSION 440 object and the mulitcast source/root address in the leaf-to-source 441 sub-LSP object. Note that the same session can have different 442 sources/roots, and the same sources/roots can have different 443 sessions. 445 In the context of the receiver-driven mRSVP-TE, the processing of 446 SESSION objects is different from that of SESSION objects in sender- 447 driven RSVP-TE [RFC4875]. In order to distinguish them, we will 448 employ different C-Types of SESSIONs. In this document we will 449 document SESSION objects for native IPv4/IPv6 multicast applications. 450 For new and more applications, new types of SESSION objects will be 451 added. 453 Following the method used by RSVP-TE and P2MP RSVP-TE, this draft 454 documents the use of some new SESSION C-Type as follows: 456 Class Name = SESSION 457 C-Type 458 XX+0 mRSVP_TE_P2MP_LSP_TUNNEL_IPv4 C-Type 459 XX+1 mRSVP_TE_P2MP_LSP_TUNNEL_IPv6 C-Type 460 XX+2 mRSVP_TE_MP2MP_LSP_TUNNEL_IPv4 C-Type 461 XX+3 mRSVP_TE_MP2MP_LSP_TUNNEL_IPv6 C-Type 463 Where XX is a number to be allocated by IANA. 465 Figure 3: New C-Types of SESSIONs 467 The new SESSION C-Type MUST be used in all receiver-driven P2MP 468 RSVP-TE messages. 470 3.1.2. L2S Sub-LSPs 472 A multicast LSP is composed of one or more leaf-to-source sub-LSPs, 473 which are merged together at the branch nodes. There are two ways to 474 identify each such sub-LSP: 476 o From the Sender's perspective, each sub-LSP is identified by the 477 SESSION object, the SENDER_TEMPLATE object and S2L_SUB_LSP object, 478 as specified in [RFC 4875]. The SESSION object encodes P2MP ID, 479 Tunnel ID, and Extended Tunnel ID. The P2MP ID is unique within 480 the scope of the sender (ingress LSR) and remains constant 481 throughout the lifetime of the P2MP tree structure. The Extended 482 Tunnel ID, which remains constant throughout the lifetime of the 483 P2MP tree structure, and which should contain the sender's address 484 to make sure the identifier is globally unique. Finally, the 485 Tunnel ID, also remains constant throughout the lifetime of the 486 P2MP tree structure. The SENDER_TEMPLATE object contains the 487 ingress LSR source address. The S2L_SUB_LSP contains the 488 destination address of the sub-LSP. 490 o From the Receiver's perspective, each sub-LSP is identified by a 491 new SESSION object, a new SENDER_TEMPLATE object and a new 492 L2S_SUB_LSP object. The SESSION object, different from the one 493 used in typical sender-driven environments, contains information 494 to be used as the key to associate different PATH messages 495 originated from different leaves. The SENDER_TEMPLATE object 496 contains the Path-Originator's address, which is actually the Data 497 Receiver. The L2S_SUB_LSP contains the source or root address of 498 the sub-LSP, i.e. the data Sender's address. The SESSION, 499 SENDER_TEMPLATE and L2S_SUB_LSP all together will identify the 500 multicast stream, the multicast stream's source, and a mulitcast 501 stream's receiver 503 This document takes the approach from the Receiver's perspective. 504 The approach from the Sender's perspective is documented in [RFC 505 4875]. 507 Once an LSR receives a receiver-driven Path message with the SESSION 508 object and L2S_SUB_LSP object, the LSR should be able to use the 509 SESSION object and L2S_SUB_LSP object to determine whether the sub- 510 LSP signaled by this Path message should be merged with existing 511 multicast LSPs. 513 3.1.3. Path Originator and Data Receiver 515 In the context of the receiver-driven RSVP-TE, a Path Originator is 516 also a Data Receiver. This document will document a new type of 517 SENDER_TEMPLATE object, which contains the Path-Originator's IP 518 address and describes the identity of the Path Originator. 520 In [RFC 2205] and [RFC 4875], the "sender" is both a path originator 521 and a data sender. In the receiver-driven context, path originators 522 and data senders may be different. For P2MP, path originators are 523 actually the data receivers. For MP2MP, path originators are also 524 both the data senders and data receivers. 526 In this document, we will use the same Object Class SENDER_TEMPLATE 527 with a different C-Type to represent and identify Path Originator. 528 In the case of P2MP LSP, the SENDER_TEMPLATE describes the identify 529 of a data receiver. In the case of MP2MP, the SENDER_TEMPLATE 530 describes the identify of an LSR which work as both a data sender and 531 a data receiver. 533 All of the SESSION object, L2S_SUB_LSP object and SENDER_TEMPLATE 534 object together contained in a Path message will uniquely identify a 535 leaf-to-source sub-LSP. 537 3.1.4. Explicit Routing 539 An EXPLICIT_ROUTE Object (ERO) is used to optionally specify the 540 explicit route of an L2S sub-LSP. Each signaled ERO corresponds to a 541 particular L2S_SUB_LSP object. Details of explicit route encoding 542 are specified in section 4.5 of [RFC4875], but they are encoded in a 543 reverse order in the receiver-driven context. 545 When a Path message signals a L2S sub-LSP, the EXPLICIT_ROUTE object 546 encodes the path from the leaf to the root LSR. The Path message 547 also includes the L2S_SUB_LSP object for the L2S sub-LSP being 548 signaled. The < [], > tuple represents 549 the L2S sub-LSP and is referred to as the sub-LSP descriptor. 551 The absence of the ERO should be interpreted as requiring hop-by-hop 552 reverse-forwarding for the sub-LSP based on the root address field of 553 the L2S_SUB_LSP object. 555 3.2. Path Messages 557 The mechanism specified in this document allows a multicast P2MP/ 558 MP2MP LSP to be signaled using one or more Path messages. Each Path 559 message may signal one L2S sub-LSPs. 561 A receiver-driven P2MP MPLS-TE LSP uses the Path message to carry the 562 LABEL object upstream from the Receiver towards the Sender. With a 563 receiver-driven usage of the RSVP PATH messages, the LABEL_REQUEST 564 object carried by the PATH message is no longer mandatory, it becomes 565 optional for receiver-driven PATH messages, as specified in Figure 4: 567 ::= [ ] 568 [ [ | ] ...] 569 [ ] 570 571 572 [ ] 573 [ ] 574 [ ] 575 [ ... ] 576 [ ] 577 [ ] 578 [ ] 579 [ ... ] 580 581 [] 583 Figure 4: Path Message Extensions 585 The SESSION object encodes information about the being-signalled 586 multicast stream. The SESSION object together with L2S_SUB_LSP will 587 be used as the key to associate different sub-LSPs to the same 588 multicast LSP. 590 Using [RFC4875] as the base specification, the LABEL object is added 591 to the as specified in Figure 5: 593 ::= 594 [ ] 595 [ ] 596 [ ] 597 [ ] 598