idnits 2.17.1 draft-ietf-mpls-targeted-mldp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 3, 2012) is 4277 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 3, 2013 Eric C. Rosen 6 IJsbrands Wijnands 7 Cisco Systems, Inc. 9 August 3, 2012 11 Using LDP Multipoint Extensions on Targeted LDP Sessions 13 draft-ietf-mpls-targeted-mldp-00.txt 15 Abstract 17 Label Distribution Protocol (LDP) can be used to set up 18 Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label 19 Switched Paths. The existing specification for this functionality 20 assumes that a pair of LDP neighbors are directly connected. 21 However, the LDP base specification allows for the case where a pair 22 of LDP neighbors are not directly connected; the LDP session between 23 such a pair of neighbors is known as a "Targeted LDP" session. This 24 document provides the specification for using the LDP P2MP/MP2MP 25 extensions 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) 2012 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 ................ 5 73 3 Targeted mLDP with Multicast Tunneling ................ 6 74 4 IANA Considerations ................................... 8 75 5 Security Considerations ............................... 8 76 6 Acknowledgments ....................................... 8 77 7 Authors' Addresses .................................... 8 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 neighbors". When a pair of LDP 91 neighbors are "directly connected" (e.g., they are connected by a 92 layer 2 medium, or are otherwise considered to be neighbors by the a 93 network's interior routing protocol), the LDP session is said to be a 94 "directly connected" LDP session. When the pair of LDP neighbors are 95 not directly connected, the session between them is said to be a 96 "Targeted" LDP 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 SP. Other methods than the ones above MAY be used. 141 1.2.2. Sending data from U to D 143 By using Targeted mLDP, we can construct an MP-LSP containing 144 an LSR U, where U has one or more downstream LSR neighbors (D1, ..., 145 Dn) to which it is not directly connected. In order for a data 146 packet to travel along this MP-LSP, U must have some way of 147 transmitting the packet to D1, ..., Dn. We will cover two methods of 148 transmission: 150 - Unicast Replication. 152 In this method, U creates n copies of the packet, and unicasts 153 each copy to exactly one of D1, ..., Dn. 155 - Multicast tunneling. 157 In this method, U becomes the root node of a multicast tunnel, 158 with D1, ..., Dn as leaf nodes. When a packet traveling along 159 the MP-LSP arrives at U, U transmits it through the 160 multicast tunnel, and as a result it arrives at D1, ..., Dn. 162 When this method is used, it may be desirable to carry traffic of 163 multiple MP-LSPs through a single multicast tunnel. We specify 164 procedures that allow for the proper demultiplexing of the MP- 165 LSPs at the leaf nodes of the multicast tunnel. We do not assume 166 that all the leaf nodes of the tunnel are on all the MP-LSPs 167 traveling through the tunnel; thus some of the tunnel leaf nodes 168 may need to discard some of the packets received through the 169 tunnel. For example, suppose MP-LSP contains node U with 170 downstream LSRs D1 and D2, while MP-LSP contains node U 171 with downstream LSRs D2 and D3. Suppose also that there is a 172 multicast tunnel with U as root and with D1, D2, and D3 as leaf 173 nodes. U can aggregate both MP-LSPs in this one tunnel. 174 However, D1 will have to discard packets that are traveling on 175 , while D3 will have to discard packets that are traveling 176 on . 178 1.3. Applicability of Targeted mLDP 180 When LSR D is setting up MP-LSP , it MUST NOT use targeted mLDP 181 unless D can select the "upstream LSR" for using one of the 182 procedures discussed in section 1.3.1. 184 Whether D uses Targeted mLDP when this condition holds is determined 185 by provisioning, or by other methods that are outside the scope of 186 this specification. 188 When Targeted mLDP is used, the choice between unicast replication 189 and multicast tunneling is determined by provisioning, or by other 190 methods that are outside the scope of this specification. 192 1.4. LDP Capabilities 194 Per [mLDP], any LSR that needs to set up an MP-LSP must support the 195 procedures of [LDP-CAP], and in particular must send and receive the 196 P2MP Capability and/or the MP2MP Capability. This specification does 197 not define any new capabilities; the advertisement of the P2MP and/or 198 MP2MP Capabilities on a Targeted LDP session means that the 199 advertising LSR is capable of following the procedures of this 200 document. 202 Some of the procedures of this document require the use of upstream- 203 assigned labels [LDP-UP]. In order to use upstream-assigned labels 204 as part of Targeted mLDP, an LSR must advertise the LDP Upstream- 205 Assigned Label Capability [LDP-UP] on the Targeted LDP session. 207 2. Targeted mLDP with Unicast Replication 209 When unicast replication is used, the mLDP procedures are exactly the 210 same as described in [mLDP], with the following exception. If LSR D 211 is setting up MP-LSP , its "upstream LSR" is selected according 212 to the procedures of section 1.3.1, and is not necessarily the "IGP 213 next hop" on D's path to R. 215 Suppose that LSRs D1 and D2 are both setting up the P2MP MP-LSP 216 , and that LSR U is the upstream LSR on each of their paths to 217 R. D1 and D2 each binds a label to , and each uses a label 218 mapping message to inform U of the label binding. Suppose D1 has 219 assigned label L1 to and D2 has assigned label L2 to . 220 (Note that L1 and L2 could have the same value or different values; 221 D1 and D2 do not coordinate their label assignments.) When U has a 222 packet to transmit on the MP-LSP , it makes a copy of the 223 packet, pushes on label L1, and unicasts the resulting packet to D1. 224 It also makes a second copy of the packet, pushes on label L2, and 225 then unicasts the resulting packet to D2. 227 This procedure also works when the MP-LSP is a MP2MP LSP. 228 Suppose that in addition to labels L1 and L2 described above, U has 229 assigned label L3 for traffic received from D1, and label L4 230 for traffic received from D2. When U processes a packet with 231 label L3 at the top of its label stack, it knows the packet is from 232 D1, so U sends a unicast copy of the packet to D2, after swapping L3 233 for L2. U does not send a copy back to D1. 235 Note that all labels used in this procedure are downstream-assigned 236 labels. 238 The method of unicast is a local matter, outside the scope of this 239 specification. The only requirement is that D1 will receive the copy 240 of the packet carrying label L1, and that D1 will process the packet 241 by looking up label L1. (And similarly, D2 must receive the copy of 242 the packet carrying label L2, and must process the packet by looking 243 up label L2.) 245 Note that if the method of unicast is MPLS, U will need to push 246 another label on each copy of the packet before transmitting it. 247 This label needs to ensure that delivery of the packet to the 248 appropriate LSR, D1 or D2. Use of penultimate-hop popping for that 249 label is perfectly legitimate. 251 3. Targeted mLDP with Multicast Tunneling 253 Suppose that LSRs D1 and D2 are both setting up MP-LSP , and 254 that LSR U is the upstream LSR on each of their paths to R. Since 255 multicast tunneling is being used, when U has a packet to send on 256 this MP-LSP, it does not necessarily send two copies, one to D1 and 257 one to D2. It may send only one copy of the packet, which will get 258 replicated somewhere downstream in the multicast tunnel. Therefore, 259 the label that gets bound to the MP-LSP must be an upstream-assigned 260 label, assigned by U. This requires a change from the procedures of 261 [mLDP]. D1 and D2 do not send label mapping messages to U; instead 262 they send label request messages to U, asking U to assign a label to 263 the MP-LSP . U responds with a label mapping message containing 264 an upstream-assigned label, L (using the procedures specified in 266 [LDP-UP]). As part of the same label mapping message, U also sends 267 an Interface TLV (as specified in [LDP-UP]) identifying the multicast 268 tunnel in which data on the MP-LSP will be carried. When U transmits 269 a packet on this tunnel, it first pushes on the upstream-assigned 270 label L, and then pushes on the label that corresponds to the 271 multicast tunnel. 273 If the numerical value L of the upstream-assigned label is the value 274 3, defined in [LDP] and [RFC3032] as "Implicit NULL", then the 275 specified multicast tunnel will carry only the specified MP-LSP. 276 That is, aggregation of multiple MP-LSPs into a single multicast 277 tunnel is not being done. In this case, no upstream-assigned label 278 is pushed onto a packet that is transmitted through the multicast 279 tunnel. 281 Various types of multicast tunnel may be used. The choice of tunnel 282 type is determined by provisioning, or by some other method that is 283 outside the scope of this document. [LDP-UP] specifies encodings 284 allowing U to identify an mLDP MP-LSP, and RSVP-TE P2MP LSP, as well 285 as other types of multicast tunnel. 287 This document does not specify procedures for tunneling one or more 288 MP2MP LSPs through P2MP tunnels. While it is possible to do this, it 289 is highly RECOMMENDED that MP2MP LSPs be tunneled through MP2MP LSPs 290 (unless, of course, unicast replication is being used). 292 If the multicast tunnel is an mLDP MP-LSP or an RSVP-TE P2MP LSP, 293 when U transmits a packet on the MP-LSP , the upstream-assigned 294 label L will be the second label in the label stack. Penultimate-hop 295 popping MUST NOT be done, because the top label provides the context 296 in which the second label is to be interpreted. See [RFC5331]. 298 When LSR U uses these procedures to inform LSR D that a particular 299 MP-LSP is being carried in a particular multicast tunnel, U and D 300 MUST take appropriate steps to ensure that packets U sends into this 301 tunnel will be received by D. The exact steps to take depend on the 302 tunnel type. As long as U is D's upstream LSR for any MP-LSP that 303 has been assigned to this tunnel, D must remain joined to the tunnel. 305 Note that U MAY assign the same multicast tunnel for multiple 306 different MP-LSPs. However, U MUST assign a distinct upstream- 307 assigned label to each MP-LSP. This allows the packets traveling 308 through the tunnel to be demultiplexed into the proper MP-LSPs. 310 If U has an MP-LSP with downstream LSRs D1 and D2, and an MP- 311 LSP with downstream LSRs D2 and D3, U may assign both MP-LSPs 312 to the same multicast tunnel. In this case, D3 will receive packets 313 traveling on . However, the upstream-assigned label carried 314 by those packets will not be recognized by D3, hence D3 will discard 315 those packets. Similarly, D1 will discard the packets. 317 This document does not specify any rules for deciding whether to 318 aggregate two or more MP-LSPs into a single multicast tunnel. Such 319 rules are outside the scope of this document. 321 Except for the procedures explicitly detailed in this document, the 322 procedures of [mLDP] and [LDP-UP] apply unchanged. 324 4. IANA Considerations 326 This document has no considerations for IANA. 328 5. Security Considerations 330 This document raises no new security considerations beyond those 331 discussed in [LDP], [LDP-UP], and [RFC5331]. 333 6. Acknowledgments 335 The authors wish to think Lizhong Jin for his comments. 337 7. Authors' Addresses 339 Maria Napierala 340 AT&T Labs 341 200 Laurel Avenue, Middletown, NJ 07748 342 E-mail: mnapierala@att.com 344 Eric C. Rosen 345 Cisco Systems, Inc. 346 1414 Massachusetts Avenue 347 Boxborough, MA, 01719 348 E-mail: erosen@cisco.com 349 IJsbrand Wijnands 350 Cisco Systems, Inc. 351 De kleetlaan 6a Diegem 1831 352 Belgium 353 E-mail: ice@cisco.com 355 8. Normative References 357 [LDP] Loa Andersson, Ina Minei, Bob Thomas, editors, "LDP 358 Specification", RFC 5036, October 2007 360 [LDP-CAP] Bob Thomas, Kamran Raza, Shivani Aggarwal, Rahul Aggarwal, 361 Jean-Louis Le Roux, "LDP Capabilities", RFC 5561, July 2009 363 [mLDP] IJsbrand Wijnands, Ina Minei, Kireeti Kompella, Bob Thomas, 364 "Label Distribution Protocol Extensions for Point-to-Multipoint and 365 Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 366 2011 368 [LDP-UP] Rahul Aggarwal, Jean-Louis Le Roux, "MPLS Upstream Label 369 Assignment for LDP", RFC 6389, November 2011 371 [RFC2119] "Key words for use in RFCs to Indicate Requirement 372 Levels.", Bradner, March 1997 374 [RFC3032] Eric Rosen, et. al., "MPLS Label Stack Encoding", RFC 3032, 375 January 2001 377 [RFC5331] Rahul Aggarwal, Yakov Rekhter, Eric Rosen, "MPLS Upstream 378 Label Assignment and Context-Specific Label Space", RFC 5331, August 379 2009