idnits 2.17.1 draft-ietf-mpls-targeted-mldp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 5, 2013) is 3917 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group Maria Napierala 3 Internet Draft AT&T 4 Intended Status: Standards Track 5 Expires: February 5, 2014 Eric C. Rosen 6 IJsbrands Wijnands 7 Cisco Systems, Inc. 9 August 5, 2013 11 Using LDP Multipoint Extensions on Targeted LDP Sessions 13 draft-ietf-mpls-targeted-mldp-03.txt 15 Abstract 17 As specified in RFC 6388, Label Distribution Protocol (LDP) can be 18 used to set up Point-to-Multipoint (P2MP) and Multipoint-to- 19 Multipoint (MP2MP) Label Switched Paths. However, RFC 6388 20 presupposes that the two endpoints of an LDP session are directly 21 connected. The LDP base specification (RFC 5036) allows for the case 22 where the two endpoints of an LDP session are not directly connected; 23 such a session is known as a "Targeted LDP" session. This document 24 provides the specification for using the LDP P2MP/MP2MP extensions 25 over a Targeted LDP session. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 Copyright and License Notice 50 Copyright (c) 2013 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1 Introduction .......................................... 3 66 1.1 Targeted mLDP ......................................... 3 67 1.2 Targeted mLDP and the Upstream LSR .................... 3 68 1.2.1 Selecting the Upstream LSR ............................ 3 69 1.2.2 Sending data from U to D .............................. 4 70 1.3 Applicability of Targeted mLDP ........................ 5 71 1.4 LDP Capabilities ...................................... 5 72 2 Targeted mLDP with Unicast Replication ................ 6 73 3 Targeted mLDP with Multicast Tunneling ................ 7 74 4 IANA Considerations ................................... 8 75 5 Security Considerations ............................... 8 76 6 Acknowledgments ....................................... 8 77 7 Authors' Addresses .................................... 9 78 8 Normative References .................................. 9 80 1. Introduction 82 1.1. Targeted mLDP 84 The Label Distribution Protocol (LDP) extensions for setting up 85 Point-to-MultiPoint (P2MP) Label Switched Paths (LSPs) and 86 Multipoint-to-Multipoint (MP2MP) LSPs are specified in [mLDP]. This 87 set of extensions is generally known as "Multipoint LDP" (mLDP). 89 A pair of Label Switched Routers (LSRs) that are the endpoints of an 90 LDP session are considered to be "LDP peers". When a pair of LDP 91 peers are "directly connected" (e.g., they are connected by a layer 2 92 medium, or are otherwise considered to be neighbors by the network's 93 interior routing protocol), the LDP session is said to be a "directly 94 connected" LDP session. When the pair of LDP peers are not directly 95 connected, the session between them is said to be a "Targeted" LDP 96 session. 98 The base specification for mLDP does not explicitly cover the case 99 where the LDP multipoint extensions are used over a targeted LDP 100 session. This document provides that specification. 102 We will use the term "Multipoint" to mean "either P2MP or MP2MP". 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 1.2. Targeted mLDP and the Upstream LSR 110 1.2.1. Selecting the Upstream LSR 112 In mLDP, a multipoint LSP (MP-LSP) has a unique identifier that is an 113 ordered pair of the form . The first element of 114 the ordered pair is the IP address of the MP-LSP's "root node". The 115 second element of the ordered pair is an identifier that is unique in 116 the context of the root node. 118 If LSR D is setting up the MP-LSP , D must determine the 119 "upstream LSR" for . In [mLDP], the upstream LSR for , 120 U, is defined to be the "next hop" on D's path to R, and "next hop" 121 is tacitly assumed to mean "IGP next hop". It is thus assumed that 122 there is a direct LDP session between D and U. In this 123 specification, we extend the notion of "upstream LSR" to cover the 124 following cases: 126 - U is the "BGP next hop" on D's path to R, where U and D are not 127 IGP neighbors, and where there is a Targeted LDP session between 128 U and D. In this case, we allow D to select U as the "upstream 129 LSR" for . 131 - If the "next hop interface" on D's path to R is an RSVP-TE P2P 132 tunnel whose remote endpoint is U, and if there is known to be an 133 RSVP-TE P2P tunnel from U to D, and if there is a Targeted LDP 134 session between U and D, then we allow D to select U as the 135 "upstream LSR" for . This is useful when D and U are part 136 of a network area that is fully meshed via RSVP-TE P2P tunnels. 138 The particular method used to select an "upstream LSR" is determined 139 by the Service Provider (SP). The method to use is determined by 140 provisioning; whichever method is used, must be known a priori to all 141 the LSRs involved. 143 Other methods than the two specified above MAY be used; however the 144 specification of other methods is outside the scope of this document. 146 1.2.2. Sending data from U to D 148 By using Targeted mLDP, we can construct an MP-LSP containing 149 an LSR U, where U has one or more downstream LSR neighbors (D1, ..., 150 Dn) to which it is not directly connected. In order for a data 151 packet to travel along this MP-LSP, U must have some way of 152 transmitting the packet to D1, ..., Dn. We will cover two methods of 153 transmission: 155 - Unicast Replication. 157 In this method, U creates n copies of the packet, and unicasts 158 each copy to exactly one of D1, ..., Dn. 160 - Multicast tunneling. 162 In this method, U becomes the root node of a multicast tunnel, 163 with D1, ..., Dn as leaf nodes. When a packet traveling along 164 the MP-LSP arrives at U, U transmits it through the 165 multicast tunnel, and as a result it arrives at D1, ..., Dn. 167 When this method is used, it may be desirable to carry traffic of 168 multiple MP-LSPs through a single multicast tunnel. We specify 169 procedures that allow for the proper demultiplexing of the MP- 170 LSPs at the leaf nodes of the multicast tunnel. We do not assume 171 that all the leaf nodes of the tunnel are on all the MP-LSPs 172 traveling through the tunnel; thus some of the tunnel leaf nodes 173 may need to discard some of the packets received through the 174 tunnel. For example, suppose MP-LSP contains node U with 175 downstream LSRs D1 and D2, while MP-LSP contains node U 176 with downstream LSRs D2 and D3. Suppose also that there is a 177 multicast tunnel with U as root and with D1, D2, and D3 as leaf 178 nodes. U can aggregate both MP-LSPs in this one tunnel. 179 However, D1 will have to discard packets that are traveling on 180 , while D3 will have to discard packets that are traveling 181 on . 183 1.3. Applicability of Targeted mLDP 185 When LSR D is setting up MP-LSP , it MUST NOT use targeted mLDP 186 unless D implements a procedure that can select, as the "upstream 187 LSR" for , an LSR U that is a Targeted mLDP peer of D. See 188 section 1.2.1. 190 Whether D uses Targeted mLDP when this condition holds is determined 191 by provisioning, or by other methods that are outside the scope of 192 this specification. 194 When Targeted mLDP is used, the choice between unicast replication 195 and multicast tunneling is determined by provisioning, or by other 196 methods that are outside the scope of this specification. It is 197 presupposed that all nodes will have a priori knowledge of whether to 198 use unicast replication or to use multicast tunneling. If the 199 latter, it is presupposed that all nodes will have a priori knowledge 200 of the type of multicast tunneling to use. 202 1.4. LDP Capabilities 204 Per [mLDP], any LSR that needs to set up an MP-LSP must support the 205 procedures of [LDP-CAP], and in particular must send and receive the 206 P2MP Capability and/or the MP2MP Capability. This specification does 207 not define any new capabilities; the advertisement of the P2MP and/or 208 MP2MP Capabilities on a Targeted LDP session means that the 209 advertising LSR is capable of following the procedures of this 210 document. 212 Some of the procedures of this document require the use of upstream- 213 assigned labels [LDP-UP]. In order to use upstream-assigned labels 214 as part of Targeted mLDP, an LSR must advertise the LDP Upstream- 215 Assigned Label Capability [LDP-UP] on the Targeted LDP session. 217 2. Targeted mLDP with Unicast Replication 219 When unicast replication is used, the mLDP procedures are exactly the 220 same as described in [mLDP], with the following exception. If LSR D 221 is setting up MP-LSP , its "upstream LSR" is selected according 222 to the procedures of section 1.2.1, and is not necessarily the "IGP 223 next hop" on D's path to R. 225 Suppose that LSRs D1 and D2 are both setting up the P2MP MP-LSP 226 , and that LSR U is the upstream LSR on each of their paths to 227 R. D1 and D2 each binds a label to , and each uses a label 228 mapping message to inform U of the label binding. Suppose D1 has 229 assigned label L1 to and D2 has assigned label L2 to . 230 (Note that L1 and L2 could have the same value or different values; 231 D1 and D2 do not coordinate their label assignments.) When U has a 232 packet to transmit on the MP-LSP , it makes a copy of the 233 packet, pushes on label L1, and unicasts the resulting packet to D1. 234 It also makes a second copy of the packet, pushes on label L2, and 235 then unicasts the resulting packet to D2. 237 This procedure also works when the MP-LSP is a MP2MP LSP. 238 Suppose that in addition to labels L1 and L2 described above, U has 239 assigned label L3 for traffic received from D1, and label L4 240 for traffic received from D2. When U processes a packet with 241 label L3 at the top of its label stack, it knows the packet is from 242 D1, so U sends a unicast copy of the packet to D2, after swapping L3 243 for L2. U does not send a copy back to D1. 245 Note that all labels used in this procedure are downstream-assigned 246 labels. 248 The method of unicast is a local matter, outside the scope of this 249 specification. The only requirement is that D1 will receive the copy 250 of the packet carrying label L1, and that D1 will process the packet 251 by looking up label L1. (And similarly, D2 must receive the copy of 252 the packet carrying label L2, and must process the packet by looking 253 up label L2.) 255 Note that if the method of unicast is MPLS, U will need to push 256 another label on each copy of the packet before transmitting it. 257 This label needs to ensure that delivery of the packet to the 258 appropriate LSR, D1 or D2. Use of penultimate-hop popping for that 259 label is perfectly legitimate. 261 3. Targeted mLDP with Multicast Tunneling 263 Suppose that LSRs D1 and D2 are both setting up MP-LSP , and 264 that LSR U is the upstream LSR on each of their paths to R. Since 265 multicast tunneling is being used, when U has a packet to send on 266 this MP-LSP, it does not necessarily send two copies, one to D1 and 267 one to D2. It may send only one copy of the packet, which will get 268 replicated somewhere downstream in the multicast tunnel. Therefore, 269 the label that gets bound to the MP-LSP must be an upstream-assigned 270 label, assigned by U. This requires a change from the procedures of 271 [mLDP]. D1 and D2 do not send label mapping messages to U; instead 272 they send label request messages to U, asking U to assign a label to 273 the MP-LSP . U responds with a label mapping message containing 274 an upstream-assigned label, L (using the procedures specified in 275 [LDP-UP]). As part of the same label mapping message, U also sends 276 an Interface TLV (as specified in [LDP-UP]) identifying the multicast 277 tunnel in which data on the MP-LSP will be carried. When U transmits 278 a packet on this tunnel, it first pushes on the upstream-assigned 279 label L, and then pushes on the label that corresponds to the 280 multicast tunnel. 282 If the numerical value L of the upstream-assigned label is the value 283 3, defined in [LDP] and [RFC3032] as "Implicit NULL", then the 284 specified multicast tunnel will carry only the specified MP-LSP. 285 That is, aggregation of multiple MP-LSPs into a single multicast 286 tunnel is not being done. In this case, no upstream-assigned label 287 is pushed onto a packet that is transmitted through the multicast 288 tunnel. 290 Various types of multicast tunnel may be used. The choice of tunnel 291 type is determined by provisioning, or by some other method that is 292 outside the scope of this document. [LDP-UP] specifies encodings 293 allowing U to identify an mLDP MP-LSP, and RSVP-TE P2MP LSP, as well 294 as other types of multicast tunnel. 296 This document does not specify procedures for tunneling one or more 297 MP2MP LSPs through P2MP tunnels. While it is possible to do this, it 298 is highly RECOMMENDED that MP2MP LSPs be tunneled through MP2MP LSPs 299 (unless, of course, unicast replication is being used). 301 If the multicast tunnel is an mLDP MP-LSP or an RSVP-TE P2MP LSP, 302 when U transmits a packet on the MP-LSP , the upstream-assigned 303 label L will be the second label in the label stack. Penultimate-hop 304 popping MUST NOT be done, because the top label provides the context 305 in which the second label is to be interpreted. See [RFC5331]. 307 When LSR U uses these procedures to inform LSR D that a particular 308 MP-LSP is being carried in a particular multicast tunnel, U and D 309 MUST take appropriate steps to ensure that packets U sends into this 310 tunnel will be received by D. The exact steps to take depend on the 311 tunnel type. As long as U is D's upstream LSR for any MP-LSP that 312 has been assigned to this tunnel, D must remain joined to the tunnel. 314 Note that U MAY assign the same multicast tunnel for multiple 315 different MP-LSPs. However, U MUST assign a distinct upstream- 316 assigned label to each MP-LSP. This allows the packets traveling 317 through the tunnel to be demultiplexed into the proper MP-LSPs. 319 If U has an MP-LSP with downstream LSRs D1 and D2, and an MP- 320 LSP with downstream LSRs D2 and D3, U may assign both MP-LSPs 321 to the same multicast tunnel. In this case, D3 will receive packets 322 traveling on . However, the upstream-assigned label carried 323 by those packets will not be recognized by D3, hence D3 will discard 324 those packets. Similarly, D1 will discard the packets. 326 This document does not specify any rules for deciding whether to 327 aggregate two or more MP-LSPs into a single multicast tunnel. Such 328 rules are outside the scope of this document. 330 Except for the procedures explicitly detailed in this document, the 331 procedures of [mLDP] and [LDP-UP] apply unchanged. 333 4. IANA Considerations 335 This document has no considerations for IANA. 337 5. Security Considerations 339 This document raises no new security considerations beyond those 340 discussed in [LDP], [LDP-UP], and [RFC5331]. 342 6. Acknowledgments 344 The authors wish to think Lizhong Jin and Lizhen Bin for their 345 comments. 347 7. Authors' Addresses 349 Maria Napierala 350 AT&T Labs 351 200 Laurel Avenue, Middletown, NJ 07748 352 E-mail: mnapierala@att.com 354 Eric C. Rosen 355 Cisco Systems, Inc. 356 1414 Massachusetts Avenue 357 Boxborough, MA, 01719 358 E-mail: erosen@cisco.com 360 IJsbrand Wijnands 361 Cisco Systems, Inc. 362 De kleetlaan 6a Diegem 1831 363 Belgium 364 E-mail: ice@cisco.com 366 8. Normative References 368 [LDP] Loa Andersson, Ina Minei, Bob Thomas, editors, "LDP 369 Specification", RFC 5036, October 2007 371 [LDP-CAP] Bob Thomas, Kamran Raza, Shivani Aggarwal, Rahul Aggarwal, 372 Jean-Louis Le Roux, "LDP Capabilities", RFC 5561, July 2009 374 [mLDP] IJsbrand Wijnands, Ina Minei, Kireeti Kompella, Bob Thomas, 375 "Label Distribution Protocol Extensions for Point-to-Multipoint and 376 Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 377 2011 379 [LDP-UP] Rahul Aggarwal, Jean-Louis Le Roux, "MPLS Upstream Label 380 Assignment for LDP", RFC 6389, November 2011 382 [RFC2119] "Key words for use in RFCs to Indicate Requirement 383 Levels.", Bradner, March 1997 385 [RFC3032] Eric Rosen, et. al., "MPLS Label Stack Encoding", RFC 3032, 386 January 2001 388 [RFC5331] Rahul Aggarwal, Yakov Rekhter, Eric Rosen, "MPLS Upstream 389 Label Assignment and Context-Specific Label Space", RFC 5331, August 390 2009