idnits 2.17.1 draft-lzj-mpls-receiver-driven-multicast-rsvp-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 : ---------------------------------------------------------------------------- ** There are 78 instances of too long lines in the document, the longest one being 15 characters in excess of 72. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 425, but not defined == Missing Reference: 'RFC4873' is mentioned on line 441, but not defined == Missing Reference: 'TBD' is mentioned on line 824, but not defined == Unused Reference: 'RFC2119' is defined on line 884, but no explicit reference was found in the text == Unused Reference: 'RFC2702' is defined on line 887, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 891, but no explicit reference was found in the text == Unused Reference: 'RFC4420' is defined on line 907, but no explicit reference was found in the text == Unused Reference: 'RFC4206' is defined on line 913, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 921, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 925, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mpls-mp-ldp-reqs' is defined on line 934, but no explicit reference was found in the text == Unused Reference: 'RFC3468' is defined on line 942, but no explicit reference was found in the text == Unused Reference: 'RFC3564' is defined on line 950, but no explicit reference was found in the text == Unused Reference: 'RFC5467' is defined on line 954, 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) -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-mpls-rsvp-upstream' ** Downref: Normative reference to an Historic draft: draft-ietf-mpls-mp-ldp-reqs (ref. 'I-D.ietf-mpls-mp-ldp-reqs') -- Obsolete informational reference (is this intentional?): RFC 5467 (Obsoleted by RFC 6387) Summary: 5 errors (**), 0 flaws (~~), 17 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Li 3 Internet-Draft Q. Zhao 4 Intended status: Standards Track Huawei Technologies 5 Expires: August 30, 2012 C. Jacquenet 6 France Telecom 7 March 4, 2012 9 Receiver-Driven Multicast Traffic Engineered Label Switched Paths 10 draft-lzj-mpls-receiver-driven-multicast-rsvp-te-00.txt 12 Abstract 14 This document describes extensions to Resource Reservation Protocol - 15 Traffic Engineering (RSVP-TE) for the setup of Receiver-Driven Traffic 16 Engineered(TE) point-to-multipoint (P2MP) and multipoint-to-multipoint 17 (MP2MP)Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) 18 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 August 30, 2012. 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 1.4. Receiver-Driven mRSVP-TE LSP Exampls . . . . . . . . . . . 8 71 2. Signaling Protocol Extensions . . . . . . . . . . . . . . . . 10 72 2.1. L2S Sub-LSPs . . . . . . . . . . . . . . . . . . . . . . . 11 73 2.2. Explicit Routing . . . . . . . . . . . . . . . . . . . . . 12 74 2.3. L2S Sub-LSPs and Path Messages . . . . . . . . . . . . . . 12 75 2.4. Resv Message Extensions . . . . . . . . . . . . . . . . . 13 76 2.5. PathErr Message Extensions . . . . . . . . . . . . . . . . 14 77 2.6. ResvErr Message Extensions . . . . . . . . . . . . . . . . 14 78 2.7. PathTear Message Extensions . . . . . . . . . . . . . . . 14 79 2.8. SESSION Object . . . . . . . . . . . . . . . . . . . . . . 15 80 2.8.1. mRSVP-TE LSP Tunnel IPv4 SESSION Object . . . . . . . 16 81 2.8.2. mRSVP-TE LSP Tunnel IPv6 SESSION Object . . . . . . . 16 82 2.9. SENDER_TEMPLATE Object . . . . . . . . . . . . . . . . . . 17 83 2.9.1. mRSVP-TE LSP Tunnel IPv4 SENDER_TEMPLATE Object . . . 17 84 2.9.2. mRSVP-TE LSP Tunnel IPv6 SENDER_TEMPLATE Object . . . 17 85 2.10. L2S_SUB_LSP Object . . . . . . . . . . . . . . . . . . . . 18 86 2.10.1. L2S_SUB_LSP IPv4 Object . . . . . . . . . . . . . . . 18 87 2.10.2. L2S_SUB_LSP IPv6 Object . . . . . . . . . . . . . . . 19 88 2.11. FILTER_SPEC Object . . . . . . . . . . . . . . . . . . . . 19 89 2.11.1. P2MP LSP_IPv4 FILTER_SPEC Object . . . . . . . . . . . 19 90 2.11.2. mRSVP-TE LSP_IPv6 FILTER_SPEC Object . . . . . . . . . 19 91 2.11.3. mRSVP-TE SECONDARY_EXPLICIT_ROUTE Object (SERO) . . . 20 92 2.11.4. mRSVP-TE SECONDARY_RECORD_ROUTE Object (SRRO) . . . . 20 93 3. In-Band and Out-Band Signalling . . . . . . . . . . . . . . . 20 94 3.1. In-Band Signalling . . . . . . . . . . . . . . . . . . . . 20 95 3.2. Out-Band Signalling . . . . . . . . . . . . . . . . . . . 20 96 4. Broadcast Interfaces . . . . . . . . . . . . . . . . . . . . . 21 97 5. Fast Re-Route Considerations . . . . . . . . . . . . . . . . . 21 98 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 21 99 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 101 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 103 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 104 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 107 1. Introduction 109 Multiparty multimedia applications are getting greater attention in 110 the telecom world. Such applications are QoS-demanding and can 111 therefore benefit from the activation of MPLS traffic engineering 112 capabilities that lead to the dynamic computation and establishment 113 of MPLS LSPs whose characteristics comply with application-specific 114 QoS requirements. P2MP-TE [RFC4875] defines a procedure to set up 115 point-to-multipoint LSPs from sender to receivers. This document 116 extends RSVP-TE for the dynamic computation of receiver-driven P2MP 117 and MP2MP LSP tree structures. 119 1.1. Motivation 121 IP multicast distribution trees are receiver-initiated and dynamic 122 by nature. IP multicast-enabled applications are also bandwidth savvy, 123 especially in the area of residential IPTV services, where the delivery 124 of multicast contents to several hundreds of thousands of IPTV receivers 125 assumes the appropriate level of quality. Current source-driven P2MP 126 LSP establishment, as defined as in [RFC4875], assumes a priori knowledge 127 of receiver locations, and the LSP signalling is initiated and driven by 128 the data sender(headend). 130 Receiver-driven MPLS P2MP/MP2MP tree structures do not require sender 131 to maintain/discover receiver information a priori, and their design 132 should better accommodate the receiver-specific QoS conditions, such as 133 network access capabilities. 135 1.2. Terminology 137 The following terms are used in this document: 139 o Sender: Sender refers to the Originator (and hence) Sender of the 140 content/payload, as defined in [RFC2205]. 142 o Receiver: Receiver refers to the Receiver of the content/payload, 143 as defined in [RFC2205]. 145 o Upstream: The direction of flow from content Receiver toward 146 content Sender, as defined in [RFC2205]. 148 o Downstream: The direction of flow from content Sender toward 149 content Receiver, as defined in [RFC2205]. 151 o Path-Sender: The sender of RSVP PATH messages, with NO correlation 152 to the direction of content/payload flows. Its flow direction is 153 irrelevant to that of Sender defined above. All other control 154 messages discussed in this document will use this as the 155 reference. 157 o Path-Receiver: The receiver of RSVP PATH messages, with NO 158 correlation to the direction of content/payload flows. 160 o Path-Initiator: The Path-Sender that originated a RSVP PATH 161 message. This is different from Path-Sender in that an 162 intermediate node can be a Path-Sender, but such an intermediate 163 node cannot create and initiate the RSVP PATH message. 165 o Path-Terminator: The Path-Receiver that does NOT propagate the 166 Path message any further. This is different from Path-Receiver in 167 that an intermediate node can be a Path-Receiver, but such an 168 intermediate node will propagate the Path message to the next hop. 170 o Root: A router where a multcast LSP is rooted at. Data enters the 171 root and then is distributed to leaves along the P2MP/MP2MP LSP 173 1.3. Overview 175 Although receiver-driven P2MP LSPs as defined in this document use 176 existing sender-driven syntax, there are important semantic 177 differences that need to be defined for correct interpretation and 178 interoperability. In the receiver-driven approach, we inverted the 179 semantics of P2MP-TE RSVP [RFC4875] messages, while keeping the 180 syntax unchanged. 182 Following are some key differences that are specific to the receiver- 183 driven paradigm: 185 o The leaf router the receiver is connected to: that is, upon receipt 186 of an IGMP/MLD Report message, the router that embeds the IGMP/MLD Querier 187 would typically trigger a RSVP_PATH message towards the source. 188 We keep the same convention with respect to data flows, which are opposite 189 to control flows. 191 o L2S (Leaf-to-Source) Destinations (the sender or root) are routers where 192 user data payload traffic enters the LSP. 194 o RSVP P2MP PATH messages traverse from receivers to the root. 196 o RSVP P2MP RESV messages traverse from the root to the leaf routers of the 197 P2MP tree strcuture. 199 o A RSVP RESV message received by a router is interpreted as a successful 200 resource reservation made by the upstream node for the establishment of the 201 P2MP tree structure. 203 o A RSVP RESV message received by a router is interpreted as successful 204 resource reservation made by the downstream node for the establishment 205 of a MP2MP tree structure. 207 o Label allocation on incoming interfaces is done prior to sending 208 RSVP PATH messages upstream for P2MP tree structures. 210 o Label allocation on incoming interfaces is done prior to sending 211 RSVP RESV messages upstream for MP2MP tree structures. 213 o For P2MP LSP tree structures, a node receiving a RSVP PATH message first 214 decides if this RSVP PATH message will make the said node a branch LSR or 215 not. If it is not a branch LSR, it is a transit LSR. In the case 216 that it will become a transit LSR because of this PATH message, 217 then it will, before sending the RSVP PATH message upstream, 218 allocate required bandwidth on the interface on which the RSVP 219 PATH message is received. The upstream node can send traffic soon 220 after successfully reserving resources on the downstream link, on 221 which the RSVP PATH message SHOULD be received. In the case that 222 the node is already a branch or a transit node before it receives 223 the PATH message, then it will allocate required bandwidth on the 224 interface on which the RSVP PATH message is received, and send the 225 RESV message to the node which sends the PATH message without 226 propagating the PATH message further to the upstream node. For 227 P2MP LSPs, a label is carried by the PATH message and should be 228 used by the upstream node when distributing the data from 229 upstream to downstream. 231 o For MP2MP LSP tree structures, a node will allocate required bandwidth 232 on the interface through which the RSVP PATH message is sent before 233 sending the RSVP PATH message upstream. A node receiving a 234 RSVP PATH message MUST first decide if this RSVP PATH message will 235 make the said node a branch LSR or not. In the case it will become 236 a transit LSR because of this PATH message, then it will allocate 237 required bandwidth on the interface on which the RSVP PATH message 238 is received and will allocate required bandwidth on the interface 239 through which the RSVP PATH message is sent, before sending the 240 RSVP PATH message upstream. The downstream node can send traffic 241 soon after successfully reserving bandwidth on the upstream link 242 through which the RSVP PATH message SHOULD be sent. The upstream 243 node can send traffic soon after successfully reserving bandwidth 244 on the downstream link on which the RSVP PATH message SHOULD be 245 received. In the case that the node is a already a branch or 246 a transit node before it receives the PATH message, then it will 247 allocate required resources on the interface on which the RSVP 248 PATH message is received, and send the RESV message to the node 249 which sends the PATH message without propagating the PATH message 250 further to the upstream node. The label carried by 251 the PATH message should be used by the Path-Receiver node to 252 forward data from the Path-Receiver node to the Path-Sender 253 node, and the label carried by RESV messages should be used by its 254 corresponding Path-Sender node to deliver data from the Path- 255 Sender node to the Path-Receiver node. 257 o For the sake of readability, from now on, all mRSVP-TE messages will be 258 used to represent all the RSVP-TE messages which are used for the 259 computation of receiver-driven P2MP/MP2MP tree structures. 261 o For the sake of readability, from now on all mRSVP-TE LSPs will be used 262 to represent all P2MP and/or MP2MP LSPs in receiver-driven (RD) multicast 263 P2MP/MP2MP MPLS environments. We will sometimes use RD P2MP TE LSP 264 or RD MP2MP TE LSP to represent such receiver-driven multicast LSPs. 266 1.4. Receiver-Driven mRSVP-TE LSP Exampls 268 Path Terminator/Ingress Router 269 +---------+ 270 | R1 | 271 +-----+---+ 272 _ 273 \ \ /\ 274 \ \ \ Path Message w/ Label OBJECT 275 Resv \ \ \ (msg2) 276 Message \ \ \ 277 (msg3) \ \ \ 278 _\/ \ \ 279 +----------------+ Path Remerge 280 | R3 | Creates Branch Point 281 +----------------+ 282 _ _ 283 / / /\ \ \ /\ 284 / / / \ \ \ Path Message (msg1) 285 Resv Message / / / msg4 \ \ \ w/ Label OBJECT 286 (msg6) / / / \ \ \ 287 / / /Path Msg \ \ \ 288 / / / msg5 \ \ \ 289 \/_ / / w/Label OBJ _\/ \ \ 290 +----------+ +---+-----+ 291 | R4 | | R5 | 292 +----------+ +---------+ 293 Path Initiator Path Initiator 294 Originator ID = R4 Originator ID = R5 295 L2S Destination = R1 L2S Destination = R1 296 Session = S Session = S 298 Figure 1: P2MP EXAMPLE 300 Figure 1 shows that R5 is added as the first leaf of the RD P2MP TE 301 LSP, the message flow goes from R5->msg1->R3->msg2->R1->msg3->R3->msg4->R5. 302 When the leaf R4 is added, the message flow goes from R4->msg5->R3->msg6->R4. 303 In this case, when R3 receives msg5, R3 finds out that the RD P2MP LSP has 304 already been set up for R5: therefore, R3 finds itself a branch node for 305 leaf R4 and R5, so it will terminate the PATH message and build the corresponding 306 RESV message and send it back to R4. The association of the LSP initiated by R4 to 307 the existing RD P2MP LSP is determined based on the processing of the session object 308 from the mRSVP-TE message. This session object is further documented in Section 2 309 of this draft. 311 Path Terminator/Ingress Router 312 +---------+ 313 | R1 | 314 +-----+---+ 315 _ 316 \ \ /\ 317 \ \ \ Path-mp2mp Message w/ Label OBJECT 318 Resv \ \ \ (msg2) 319 Message \ \ \ 320 (msg3) \ \ \ 321 w/ Label OBJECT _\/ \ \ 322 +----------------+ Path-mp2mp 323 | R3 | (Branch Point) 324 +----------------+ 325 _ _ 326 / / /\ \ \ /\ 327 / / / \ \ \ Path-mp2mp Message (msg1) 328 Resv Message / / / msg4 \ \ \ w/ Label OBJECT 329 (msg6) / / / \ \ \ 330 w/ Label OBJECT/ / /Path-mp2mp \ \ \ 331 / / / Message msg5 \ \ \ 332 / / / w/ Label OBJ \ \ \ 333 \/_ / / _\/ \ \ 334 +----------+ +---+-----+ 335 | R4 | | R5 | 336 +----------+ +---------+ 337 Path-mp2mp Initiator Path-mp2mp Initiator 338 Originator ID = R4 Originator ID = R5 339 L2S Destination = R1 L2S Destination = R1 340 Session = S Session = S 342 Figure 2: MP2MP Example 344 Figure 2 shows that R5 is added as the first leaf 345 (as both a sender and a receiver) of the RD MP2MP TE LSP, the message 346 flow goes from R5->msg1->R3->msg2->R1->msg3->R3->msg4->R5. When the 347 leaf R4 (both receiver and sender)is added, the message flow goes 348 from R4->msg5->R3->msg6. In this case, when R3 receives msg5, R3 349 finds out that the RD MP2MP LSP has already been set up for R5, and R3 350 will become the branch LSR for the leaf R4 and R5, so it will 351 terminate the PATH message, build a RESV message and send the RESV 352 message back to R4. The association of the LSP initiated by R4 to 353 the existing MP2MP LSP is determined based on the processing of the 354 session object from the mRSVP-TE message. This session object is further 355 documented in Section 2 of this draft. 357 2. Signaling Protocol Extensions 359 mRSVP-TE is similar to the RSVP-TE protocol as specified in [RFC4875], 360 [RFC3473] and [RFC3209], but differs in that the receivers (or the leaf 361 routers they are connected to) 362 initiate the RSVP PATH messages toward the sender. Compared with 363 [RFC4875], mRSVP-TE to be specified in this document can also be used 364 to set up MP2MP LSPs. 366 Within RD P2MP/MP2MP LSP tree structure environments, the Receiver is the 367 Path-Originator. The RSVP RESV messages flow in the opposite direction as 368 compared to the RSVP PATH messages, i.e. RSVP RESV messages are generated 369 by the Sender or a branch LSR. 371 Within this receiver-driven context, the processing of receiver- 372 initiated mRSVP-TE P2MP messages is different from that of the 373 other RSVP messages. Following the method used by RSVP-TE and P2MP 374 RSVP-TE, this draft documents the use of new SESSION C-Type as 375 follows: 377 Class Name = SESSION 378 C-Type 379 XX+0 mRSVP_TE_P2MP_LSP_TUNNEL_IPv4 C-Type 380 XX+1 mRSVP_TE_P2MP_LSP_TUNNEL_IPv6 C-Type 381 XX+2 mRSVP_TE_MP2MP_LSP_TUNNEL_IPv4 C-Type 382 XX+3 mRSVP_TE_MP2MP_LSP_TUNNEL_IPv6 C-Type 384 Where XX is a number to be allocated by IANA. 386 The new SESSION C-Type MUST be used in all receiver-driven P2MP 387 RSVP-TE messages. 389 The following sections describe the receiver-driven P2MP RSVP-TE 390 extensions to the P2MP RSVP-TE protocol. When there is no difference 391 in the protocol, usage of [RFC4875] is assumed. 393 2.1. L2S Sub-LSPs 395 A RD P2MP or MP2MP LSP is composed of one or more L2S sub-LSPs, which 396 are merged together at the branch nodes. 398 An L2S sub-LSP exists within the context of a RD P2MP or MP2MP LSP. 399 There are two ways to identify each sub-LSP: 401 o From the Sender's perspective, each sub-LSP is identified by 402 the SESSION object, the SENDER_TEMPLATE object and S2L_SUB_LSP 403 object, as specified in [RFC 4875]. The SESSION object encodes 404 P2MP ID, which is unique within the scope of the sender (ingress 405 LSR) and remains constant throughout the lifetime of the P2MP 406 tree structure. The Extended Tunnel ID, which remains constant 407 throughout the lifetime of the P2MP tree structure, and which should 408 contain the sender's address to make sure the identifier is globally 409 unique identifier. Finally, the Tunnel ID, also remains constant 410 throughout the lifetime of the P2MP tree structure. The 411 SENDER_TEMPLATE object contains the ingress LSR source address. 412 The S2L_SUB_LSP contains the destination address of the sub-LSP. 414 o From the Receiver's perspective, each sub-LSP is identified 415 by a new SESSION object specified in this document, the 416 SENDER_TEMPLATE object and L2S_SUB_LSP. The SESSION object, 417 different from the one used in typical sender-driven environments, 418 contains some opaque values to be used as the key to associate 419 different PATH messages originated from different leaves. The 420 SENDER_TEMPLATE object contains the Path-Sender's address, which 421 is actually the Data Receiver. The L2S_SUB_LSP contains the 422 source address of the sub-LSP, i.e. the data Sender's address. 424 This document takes the approach from the Receiver's perspective. 425 The approach from the Sender's perspective is documented in [RFC 4875]. 426 In this draft, the SESSION object will encode multicast 427 information such as multicast source and group addresses as the opaque 428 value. 430 Once either the Sender LSR, a transit LSR, or a branch LSR receives 431 a PATH message containing SESSION object, the LSR should be able to use 432 the opaque values encoded in the SESSION object to determine whether the 433 sub-LSP signaled by this PATH message should be merged with existing 434 LSPs. 436 An EXPLICIT_ROUTE Object (ERO) or mRSVP-TE_SECONDARY_EXPLICIT_ROUTE 437 Object (SERO) is used to optionally specify the explicit route of a 438 L2S sub-LSP. Each ERO or SERO that is signaled corresponds to a 439 particular L2S_SUB_LSP object. Details of explicit route encoding 440 are specified in section 4.5 of [RFC4875]. The 441 SECONDARY_EXPLICIT_ROUTE Object is defined in [RFC4873], the mRSVP-TE 442 SECONDARY_EXPLICIT_ROUTE Object C-type and the matching mRSVP- 443 TE_SECONDARY_RECORD_ROUTE Object C-type is defined in this docuemnt. 445 2.2. Explicit Routing 447 When a Path message signals a L2S sub-LSP, the EXPLICIT_ROUTE object 448 encodes the path from the leaf to the root LSR. The Path message 449 also includes the L2S_SUB_LSP object for the L2S sub-LSP being 450 signaled. The <(EXPLICIT_ROUTE), (L2S_SUB_LSP)> tuple represents the 451 L2S sub-LSP and is referred to as the sub-LSP descriptor. The 452 absence of the ERO should be interpreted as requiring hop-by-hop 453 routing for the sub-LSP based on the L2S sub-LSP root address field 454 of the L2S_SUB_LSP object. 456 2.3. L2S Sub-LSPs and Path Messages 458 The mechanism specified in this document allows a RD P2MP/MP2MP LSP to 459 be signaled using one or more Path messages. Each Path message may 460 signal one L2S sub-LSPs. 462 Receiver-driven P2MP MPLS-TE LSP uses the Path message to carry the 463 LABEL object upstream towards the Sender. With a receiver-driven usage 464 of the RSVP PATH message, the LABEL_REQUEST object carried by the 465 PATH message is no longer mandatory, it becomes optional for 466 receiver-driven PATH messages, as mentioned in Figure 4: 468 ::= [ ] 469 [ [ | ] ...] 470 [ ] 471 472 473 [ ] 474 [ ] 475 [ ] 476 [ ... ] 477 [ ] 478 [ ] 479 [ ] 480 [ ... ] 481 482 [] 484 Figure 4: PATH Message Extensions. 486 The SESSION object encodes an opaque value which is used as a key to 487 associate different PATHs to the same RD P2MP/MP2MP tree structure. 489 Using [RFC4875] as the base specification, with the LABEL object 490 being added to the SENDER DESCRIPTOR object (Figure 5): 492 ::= 493 [ ] 494 [ ] 495 [ ] 496 [ ] 497