idnits 2.17.1 draft-chan-torvi-jacquenet-mpls-rd-p2mp-te-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. 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 date (October 19, 2009) is 5302 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: 'TBD' is mentioned on line 459, but not defined == Unused Reference: 'RFC4420' is defined on line 493, but no explicit reference was found in the text == Unused Reference: 'RFC4206' is defined on line 499, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 511, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 515, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4420 (Obsoleted by RFC 5420) -- Obsolete informational reference (is this intentional?): RFC 5467 (Obsoleted by RFC 6387) == Outdated reference: A later version (-05) exists of draft-ietf-mpls-rsvp-upstream-04 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS R. Torvi 3 Internet-Draft K. Chan, Ed. 4 Expires: April 22, 2010 Huawei Technologies 5 C. Jacquenet 6 France Telecom 7 October 19, 2009 9 Receiver Driven Point-To-Multi-Point Traffic Engineered Label Switched 10 Paths 11 draft-chan-torvi-jacquenet-mpls-rd-p2mp-te-00 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 22, 2010. 36 Copyright Notice 38 Copyright (c) 2009 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 in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 For content delivery services that rely upon the IP multicast 50 transmission scheme, the distribution trees are receiver initiated. 51 The delivery of such services over MPLS networking infrastructures 52 may rely upon P2MP LSP tree structures that are sender initiated, 53 with the root of the P2MP tree being at the LSR router directly 54 connected to the sender. This document describes a mechanism that 55 aims at establishing MPLS P2MP tree structures that are receiver 56 initiated. This mechanism builds on the works of Point-to-MultiPoint 57 Traffic Engineered Lable Swithched Paths (P2MP-TE LSPs). This 58 mechanism can also be used to establish receiver driven BiDirectional 59 P2MP TE LSPs. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Signaling Protocol Extensions . . . . . . . . . . . . . . . . 6 68 2.1. Path Message Extensions . . . . . . . . . . . . . . . . . 6 69 2.2. Resv Message Extensions . . . . . . . . . . . . . . . . . 7 70 2.3. PathErr Message Extensions . . . . . . . . . . . . . . . . 8 71 2.4. ResvErr Message Extensions . . . . . . . . . . . . . . . . 8 72 2.5. PathTear Message Extensions . . . . . . . . . . . . . . . 9 73 3. Broadcast Interfaces . . . . . . . . . . . . . . . . . . . . . 9 74 4. Fast Re-Route Considerations . . . . . . . . . . . . . . . . . 9 75 5. Re-Merging and Crossover . . . . . . . . . . . . . . . . . . . 10 76 6. Receiver-Driven Bidirectional LSPs . . . . . . . . . . . . . . 10 77 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 11 78 8. Security Implications . . . . . . . . . . . . . . . . . . . . 11 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 83 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 Multiparty multimedia applications are getting greater attention in 89 the telecom world. Such applications are QoS-demanding and can 90 therefore benefit from the activation of MPLS traffic engineering 91 capabilities that lead to the dynamic computation and establishment 92 of MPLS LSPs whose characteristics comply with application-specific 93 QoS requirements. P2MP-TE [RFC4875] defines the procedure to setup 94 multipoint LSPs from sender to receiver. This document extends 95 P2MP-TE to be used for receiver-driven P2MP-TE LSPs. This document 96 complements P2MP-TE [RFC4875], allowing P2MP-TE LSPs to be 97 established either from a sender or from a receiver, unidirectional 98 or bidirectional. 100 1.1. Motivation 102 IP multicast distribution trees are receiver-initiated and dynamic by 103 nature. IP multicast-enabled applications are also bandwidth savvy, 104 especially in the area of residential IPTV services, where several 105 hundreds of thousands of IPTV receivers need to be served with the 106 appropriate level of quality. Current source-driven P2MP LSP 107 establishment assumes a prior knowledge of receiver(s) location for 108 the sake of the P2MP LSP tree structure's forwarding efficiency. But 109 the receiver's location information is not available a priori for the 110 root MPLS router to compute and establish the relevant P2MP tree 111 structure. 113 Receiver-driven MPLS P2MP tree structure do not require sender to 114 maintain/discover receiver information a priori, and their design 115 should better reflect the receiver-specific QoS conditions, such as 116 network access capabilities. 118 1.2. Terminology 120 With the receiver-driven concept, we have re-defined the following 121 terms: 123 o Sender: Sender refers to the Originator (and hence) Sender of the 124 content/payload. As in [RFC2205]. 126 o Receiver: Receiver refers to the Receiver of the content/payload. 127 As in [RFC2205]. 129 o Upstream: The direction of flow from content Receiver toward 130 content Sender. As defined in [RFC2205]. 132 o Downstream: The direction of flow from content Sender toward 133 content Receiver. As defined in [RFC2205]. 135 o Path-Sender: The sender of the RSVP PATH message, with NO 136 correlation to direction of content/payload flow. All other 137 control messages flow direction discussed in this document will 138 use this as the reference. 140 o Path-Receiver: The receiver of the RSVP PATH message, with NO 141 correlation to direction of content/payload flow. 143 o Path-Initiator: The Path-Sender that originated the RSVP PATH 144 message. This being different from Path-Sender because an 145 intermediate node can be a Path-Sender, but different from the 146 node that created and initiated the RSVP PATH message, the Path- 147 Initiator. 149 o Path-Terminator: The Path-Receiver that does NOT propagate the 150 Path message. This being different from Path-Receiver because an 151 intermediate node can be a Path-Receiver. 153 1.3. Overview 155 Although receiver-driven P2MP LSPs as defined in this document use 156 existing sender-driven syntax, there are important semantic 157 differences that need to be defined for correct interpretation and 158 interoperability. In the receiver-driven approach, we inverted the 159 semantics of P2MP-TE RSVP [RFC4875] messages, while keeping the 160 syntax unchanged. 162 Following are some key differences that are specific to the receiver- 163 driven paradigm: 165 1. Receiver initiates RSVP PATH message towards the one or more 166 senders. We keep same convention with respect to data flows, 167 which are opposite to control flows. 169 2. S2L Destinations (the leaves) are ingress routers where user data 170 payload traffic enter the LSP. 172 3. RSVP P2MP PATH messages traverse from receiver to senders. 174 4. RSVP P2MP RESV messages traverse from sender to receiver. 176 5. A node receiving a RSVP RESV message is interpreted as successful 177 resource reservation from the upstream node. 179 6. A node receiving a RSVP PATH message would first allocate 180 required resources on the interface through which the RSVP PATH 181 message is received, before sending the RSVP PATH message 182 upstream. So that the upstream node can send traffic soon after 183 successfully reserving resources on the downstream link, on which 184 the RSVP PATH message is received. 186 7. Label allocation on incoming interface is done prior to sending 187 RSVP PATH messages upstream. The syntax details are defined in 188 Section 2. 190 Path Terminator/Ingress Router 191 +---------+ 192 | R1 | 193 +-----+---+ _ 194 \ \ /\ Path Message w/ Label OBJECT 195 \ \ \ 196 Resv \ \ \ 197 Message \ \ \ 198 \ \ \ 199 _\/ \ \ Path Remerge 200 +------------+ Creates Branch Point 201 | R3 | 202 +------------+ _ 203 / \ /\ 204 / / \ \ Path Message 205 Resv Message / / \ \ w/ Label OBJECT 206 / / \ \ 207 / / \ \ 208 \/_ / \ \ 209 / +---+-----+ 210 +----------+ | R5 | 211 | R4 | +---------+ 212 +----------+ Path Initiator/Egress Router 213 Path Initiator LSP_ID = X 214 LSP_ID = X Originator ID = R5 215 Originator ID = R4 Destination = R1 216 Destination = R1 217 Session ID = A Session ID = A 219 Figure 1: Receiver-Driven P2MP RSVP-TE LSP Overview 221 2. Signaling Protocol Extensions 223 Receiver-driven P2MP MPLS-TE LSP uses the RSVP-TE protocol as 224 specified in [RFC4875], [RFC3473], and [RFC3209], but unlike what is 225 specified in [RFC4875], receivers initiate the RSVP PATH messages 226 toward the sender. 228 With receiver-driven P2MP MPLS-TE LSP, the content Receiver is the 229 Path-Originator. The RSVP RESV messages flow in the opposite 230 direction as compared to the RSVP PATH messages, i.e. RSVP RESV 231 messages are generated by the content Sender or the MPLS router it is 232 directly attached to. All other RSVP messages flow in reference to 233 this picture. 235 Within this receiver-driven context, the processing of receiver- 236 initiated P2MP RSVP-TE messages should be differentiated from the 237 other RSVP messages. Following the method used by RSVP-TE and P2MP 238 RSVP-TE, this document recommends the use of new SESSION C-Type as 239 follows: 241 Class Name = SESSION 242 C-Type 243 XX+0 RcvrD_P2MP_LSP_TUNNEL_IPv4 C-Type 244 XX+1 RcvrD_P2MP_LSP_TUNNEL_IPv6 C-Type 245 XX+2 BiDi_P2MP_LSP_TUNNEL_IPv4 C-Type 246 XX+4 BiDi_P2MP_LSP_TUNNEL_IPv6 C-Type 248 Where XX is a number allocated by IANA. 250 The new SESSION C-Type MUST be used in all receiver-driven P2MP 251 RSVP-TE messages. 253 The following sections describe the receiver-driven P2MP RSVP-TE 254 extensions to the P2MP RSVP-TE protocol. When there is no difference 255 in the protocol, usage of [RFC4875] is assumed. 257 2.1. Path Message Extensions 259 Receiver-driven P2MP MPLS-TE LSP uses the Path message to carry the 260 LABEL object upstream towards the Sender. With receiver-driven usage 261 of the RSVP PATH message, the LABEL_REQUEST object carried by the 262 PATH message is no longer mandatory, it becomes optional for 263 receiver-driven PATH messages, as indicated below: 265 ::= [ ] 266 [ [ | ] ...] 267 [ ] 268 269 270 [ ] 271 [ ] 272 [ ] 273 [ ... ] 274 [ ] 275 [ ] 276 [ ] 277 [ ... ] 278 279 [] 281 Using [RFC4875] as the base specification, with the LABEL object 282 being added to the SENDER DESCRIPTOR object: 284 ::= 285 [ ] 286 [ ] 287 [ ] 288 [ ] 289