idnits 2.17.1 draft-ietf-mpls-ldp-dod-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 16 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 date (August 2, 2012) is 4285 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I1' is mentioned on line 799, but not defined == Missing Reference: 'I' is mentioned on line 799, but not defined == Missing Reference: 'V' is mentioned on line 806, but not defined == Missing Reference: 'U2' is mentioned on line 806, but not defined == Missing Reference: 'Y' is mentioned on line 806, but not defined == Missing Reference: 'U' is mentioned on line 806, but not defined == Unused Reference: 'RFC4446' is defined on line 1434, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-mpls-ldp-ipv6-07 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-seamless-mpls-01 -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Beckhaus 3 Internet-Draft Deutsche Telekom AG 4 Intended status: Informational B. Decraene 5 Expires: February 3, 2013 France Telecom 6 K. Tiruveedhula 7 Juniper Networks 8 M. Konstantynowicz 9 L. Martini 10 Cisco Systems, Inc. 11 August 2, 2012 13 LDP Downstream-on-Demand in Seamless MPLS 14 draft-ietf-mpls-ldp-dod-03 16 Abstract 18 Seamless MPLS design enables a single IP/MPLS network to scale over 19 core, metro and access parts of a large packet network infrastructure 20 using standardized IP/MPLS protocols. One of the key goals of 21 Seamless MPLS is to meet requirements specific to access, including 22 high number of devices, their position in network topology and their 23 compute and memory constraints that limit the amount of state access 24 devices can hold.This can be achieved with LDP Downstream-on-Demand 25 (LDP DoD) label advertisement. This document describes LDP DoD use 26 cases and lists required LDP DoD procedures in the context of 27 Seamless MPLS design. 29 In addition, a new optional TLV type in the LDP label request message 30 is defined for fast-up convergence. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC2119 [RFC2119]. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on February 3, 2013. 55 Copyright Notice 57 Copyright (c) 2012 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Reference Topologies . . . . . . . . . . . . . . . . . . . . . 5 74 2.1. Access Topologies with Static Routing . . . . . . . . . . 6 75 2.2. Access Topologies with Access IGP . . . . . . . . . . . . 9 76 3. LDP DoD Use Cases . . . . . . . . . . . . . . . . . . . . . . 11 77 3.1. Initial Network Setup . . . . . . . . . . . . . . . . . . 11 78 3.1.1. AN with Static Routing . . . . . . . . . . . . . . . . 11 79 3.1.2. AN with Access IGP . . . . . . . . . . . . . . . . . . 13 80 3.2. Service Provisioning and Activation . . . . . . . . . . . 13 81 3.3. Service Changes and Decommissioning . . . . . . . . . . . 16 82 3.4. Service Failure . . . . . . . . . . . . . . . . . . . . . 16 83 3.5. Network Transport Failure . . . . . . . . . . . . . . . . 17 84 3.5.1. General Notes . . . . . . . . . . . . . . . . . . . . 17 85 3.5.2. AN Node Failure . . . . . . . . . . . . . . . . . . . 17 86 3.5.3. AN/AGN Link Failure . . . . . . . . . . . . . . . . . 18 87 3.5.4. AGN Node Failure . . . . . . . . . . . . . . . . . . . 19 88 3.5.5. AGN Network-side Reachability Failure . . . . . . . . 19 89 4. LDP DoD Procedures . . . . . . . . . . . . . . . . . . . . . . 20 90 4.1. LDP Label Distribution Control and Retention Modes . . . . 20 91 4.2. IPv6 Support . . . . . . . . . . . . . . . . . . . . . . . 22 92 4.3. LDP DoD Session Negotiation . . . . . . . . . . . . . . . 22 93 4.4. Label Request Procedures . . . . . . . . . . . . . . . . . 23 94 4.4.1. Access LSR/ABR Label Request . . . . . . . . . . . . . 23 95 4.4.2. Label Request Retry . . . . . . . . . . . . . . . . . 24 96 4.4.3. Label Request with Fast-Up Convergence . . . . . . . . 24 97 4.5. Label Withdraw . . . . . . . . . . . . . . . . . . . . . . 26 98 4.6. Label Release . . . . . . . . . . . . . . . . . . . . . . 27 99 4.7. Local Repair . . . . . . . . . . . . . . . . . . . . . . . 28 100 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 101 5.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . . 28 102 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 103 6.1. Security and LDP DoD . . . . . . . . . . . . . . . . . . . 29 104 6.1.1. Access to network packet flow direction . . . . . . . 29 105 6.1.2. Network to access packet flow direction . . . . . . . 29 106 6.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 30 107 6.3. Control Plane Security . . . . . . . . . . . . . . . . . . 31 108 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 109 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 110 8.1. Normative References . . . . . . . . . . . . . . . . . . . 32 111 8.2. Informative References . . . . . . . . . . . . . . . . . . 32 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 114 1. Introduction 116 Seamless MPLS design [I-D.ietf-mpls-seamless-mpls] enables a single 117 IP/MPLS network to scale over core, metro and access parts of a large 118 packet network infrastructure using standardized IP/MPLS protocols. 119 One of the key goals of Seamless MPLS is to meet requirements 120 specific to access, including high number of devices, their position 121 in network topology and their compute and memory constraints that 122 limit the amount of state access devices can hold. 124 In general MPLS routers implement either LDP or RSVP for MPLS label 125 distribution. The focus of this document is on LDP, as Seamless MPLS 126 design does not include a requirement for general purpose explicit 127 traffic engineering and bandwidth reservation. This document is 128 focusing on the unicast connectivity only. Multicast connectivity is 129 subject for further study. 131 In Seamless MPLS design [I-D.ietf-mpls-seamless-mpls], IP/MPLS 132 protocol optimization is possible due to a relatively simple access 133 network topologies. Examples of such topologies involving access 134 nodes (AN) and aggregation nodes (AGN) include: 136 a. A single AN homed to a single AGN. 138 b. A single AN dual-homed to two AGNs. 140 c. Multiple ANs daisy-chained via a hub-AN to a single AGN. 142 d. Multiple ANs daisy-chained via a hub-AN to two AGNs. 144 e. Two ANs dual-homed to two AGNs. 146 f. Multiple ANs chained in a ring and dual-homed to two AGNs. 148 The amount of IP RIB and FIB state on ANs can be easily controlled in 149 the listed access topologies by using simple IP routing configuration 150 with either static routes or dedicated access IGP. Note that in all 151 of the above topologies AGNs act as the access border routers (access 152 ABRs) connecting the access topology to the rest of the network. 153 Hence in many cases it is sufficient for ANs to have a default route 154 pointing towards AGNs in order to achieve complete network 155 connectivity from ANs to the network. 157 The amount of MPLS forwarding state however requires additional 158 consideration. In general MPLS routers implement LDP Downstream 159 Unsolicited (LDP DU) label advertisement [RFC5036] and advertise MPLS 160 labels for all valid routes in their RIB. This is seen as a very 161 insufficient approach for ANs, as they only require a small subset of 162 the total routes (and associated labels) based on the required 163 connectivity for the provisioned services. And although filters can 164 be applied to those LDP DU labels advertisements, it is not seen as a 165 suitable tool to facilitate any-to-any AN-driven connectivity between 166 access and the rest of the MPLS network. 168 This document describes an access node driven "subscription model" 169 for label distribution in the access. The approach relies on the 170 standard LDP Downstream-on-Demand (LDP DoD) label advertisements as 171 specified in [RFC5036]. LDP DoD enables on-demand label distribution 172 ensuring that only required labels are requested, provided and 173 installed. 175 Note that LDP DoD implementation is not widely available in today's 176 IP/MPLS devices despite the fact that it has been described in the 177 LDP specification [RFC5036]. This is due to the fact that the 178 originally LDP DoD advertisement mode was aimed mainly at ATM and 179 Frame Relay MPLS implementations, where conserving label space used 180 on the links was essential for compatibility with ATM and Frame Relay 181 LSRs. 183 The following sections describe a set of reference access topologies 184 considered for LDP DoD usage and their associated IP routing 185 configurations, followed by LDP DoD use cases and LDP DoD procedures 186 in the context of Seamless MPLS design. 188 2. Reference Topologies 190 LDP DoD use cases are described in the context of a generic reference 191 end-to-end network topology based on Seamless MPLS design 192 [I-D.ietf-mpls-seamless-mpls] shown in Figure 1 193 +-------+ +-------+ +------+ +------+ 194 ---+ AGN11 +--+ AGN21 +--+ ABR1 +--+ LSR1 +--> to LSR/AGN 195 +--------+/ +-------+ +-------+ +------+ +------+ 196 | Access | \/ \/ 197 | Network| /\ /\ 198 +--------+ +-------+ +-------+ +------+ +------+ 199 \---+ AGN12 +--+ AGN22 +--+ ABR2 +--+ LSR2 +--> to LSR/AGN 200 +-------+ +-------+ +------+ +------+ 202 static routes 203 or access IGP ISIS L1 ISIS L2 204 <----Access----><--Aggregation Domain--><----Core-----> 205 <------------------------- MPLS ----------------------> 207 Figure 1: Seamless MPLS end-to-end reference network topology. 209 The access network is either single or dual homed to AGN1x, with 210 either a single or multiple parallel links to AGN1x. 212 Seamless MPLS access network topologies can range from a single- or 213 dual-homed access node to a chain or ring of access nodes, and use 214 either static routing or access IGP. The following sections describe 215 reference access topologies in more detail. 217 2.1. Access Topologies with Static Routing 219 In most cases access nodes connect to the rest of the network using 220 very simple topologies. Here static routing is sufficient to provide 221 the required IP connectivity. The following topologies are 222 considered for use with static routing and LDP DoD: 224 a. [I1] topology - a single AN homed to a single AGN. 226 b. [I] topology - multiple ANs daisy-chained to a single AGN. 228 c. [V] topology - a single AN dual-homed to two AGNs. 230 d. [U2] topology - two ANs dual-homed to two AGNs. 232 e. [Y] topology - multiple ANs daisy-chained to two AGNs. 234 The reference static routing and LDP configuration for [V] access 235 topology is shown in Figure 2. The same static routing and LDP 236 configuration also applies to [I1] topology. 238 +----+ +-------+ 239 |AN1 +------------------------+ AGN11 +------- 240 | +-------\ /-----------+ +-\ / 241 +----+ \ / +-------+ \ / 242 \/ \/ 243 /\ /\ 244 +----+ / \ +-------+ / \ 245 |AN2 +-------/ \-----------+ AGN12 +-/ \ 246 | +------------------------+ +------- 247 +----+ +-------+ 249 --(u)-> <-(d)-- 251 <----- static routing -------> <--- ISIS ---> 252 <-- LDP DU --> 253 <--------- LDP DoD ----------> <-- BGP LU --> 255 (u) static routes: 0/0 default, (optional) /32 or /128 destinations 256 (d) static routes: /32 or /128 AN loopbacks 258 Figure 2: [V] access topology with static routes. 260 In line with the Seamless MPLS design, static routes configured on 261 AGN1x and pointing towards the access network are redistributed in 262 either ISIS or BGP labeled unicast (BGP-LU) [RFC3107]. 264 The reference static routing and LDP configuration for [U2] access 265 topology is shown in Figure 3. 267 +----+ +-------+ 268 (d1) |AN1 +------------------------+ AGN11 +------- 269 | | + + +-\ / 270 v +-+--+ +-------+ \ / 271 | \/ 272 | /\ 273 ^ +-+--+ +-------+ / \ 274 | |AN2 + + AGN12 +-/ \ 275 (d2) | +------------------------+ +------- 276 +----+ +-------+ 278 --(u)-> <-(d)-- 280 <------- static routing --------> <--- ISIS ---> 281 <-- LDP DU --> 282 <----------- LDP DoD -----------> <-- BGP LU --> 284 (u) static route 0/0 default (/32 or /128 destinations optional) 285 (d) static route for /32 or /128 AN loopbacks 286 (d1) static route for /32 or /128 AN2 loopback and 0/0 default with lower preference 287 (d2) static route for /32 or /128 AN1 loopback and 0/0 default with lower preference 289 Figure 3: [U2] access topology with static routes. 291 The reference static routing and LDP configuration for [Y] access 292 topology is shown in Figure 4. The same static routing and LDP 293 configuration also applies to [I] topology. 295 +-------+ 296 | |---/ 297 /----+ AGN11 | 298 +----+ +----+ +----+ / | |---\ 299 | | | | | +----/ +-------+ 300 |ANn +...|AN2 +---+AN1 | 301 | | | | | +----\ +-------+ 302 +----+ +----+ +----+ \ | |---/ 303 \----+ AGN12 | 304 <-(d2)-- <-(d1)-- | |---\ 305 --(u)-> --(u)-> --(u)-> +-------+ 306 <-(d)-- 308 <------- static routing -------> <--- ISIS ---> 309 <-- LDP DU --> 310 <---------- LDP DoD -----------> <-- BGP LU --> 312 (u) static routes: 0/0 default, (optional) /32 or /128 destinations 313 (d) static routes: /32 or /128 AN loopbacks [1..n] 314 (d1) static routes: /32 or /128 AN loopbacks [2..n] 315 (d2) static routes: /32 or /128 AN loopbacks [3..n] 317 Figure 4: [Y] access topology with static routes. 319 Note that in all of the above topologies parallel ECMP (or L2 LAG) 320 links can be used between the nodes. 322 ANs support Inter-area LDP [RFC5283] in order to use the IP default 323 route to match the LDP FEC advertised by AGN1x and other ANs. 325 2.2. Access Topologies with Access IGP 327 A dedicated access IGP instance is used in the access network to 328 perform the internal routing between AGN1x and connected AN devices. 329 Example of such IGP could be ISIS, OSPFv2&v3, RIPv2&RIPng. This 330 access IGP instance is distinct from the IGP of the aggegation 331 domain. 333 The following topologies are considered for use with access IGP 334 routing and LDP DoD: 336 a. [U] topology - multiple ANs chained in an open ring and dual- 337 homed to two AGNs. 339 b. [Y] topology - multiple ANs daisy-chained via a hub-AN to two 340 AGNs. 342 The reference access IGP and LDP configuration for [U] access 343 topology is shown in Figure 5. 345 +-------+ 346 +-----+ +-----+ +----+ | +---/ 347 | AN3 |---| AN2 |---|AN1 +-----+ AGN11 | 348 +-----+ +-----+ +----+ | +---\ 349 . +-------+ 350 . 351 . +-------+ 352 +-----+ +-----+ +----+ | +---/ 353 |ANn-2|---|ANn-1|---|ANn +-----+ AGN12 | 354 +-----+ +-----+ +----+ | +---\ 355 +-------+ 357 <---------- access IGP ------------> <--- ISIS ---> 358 <-- LDP DU --> 359 <------------ LDP DoD -------------> <-- BGP LU --> 361 Figure 5: [U] access topology with access IGP. 363 The reference access IGP and LDP configuration for [Y] access 364 topology is shown in Figure 6. 366 +-------+ 367 | |---/ 368 /----+ AGN11 |2 369 +----+ +----+ +----+ / | |---\ 370 | | | | | +----/ +-------+ 371 |ANn +...|AN2 +---+AN1 | 372 | | | | | +----\ +-------+ 373 +----+ +----+ +----+ \ | |---/ 374 \----+ AGN12 | 375 | |---\ 376 +-------+ 378 <---------- access IGP ------------> <--- ISIS ---> 379 <-- LDP DU --> 380 <------------ LDP DoD -------------> <-- BGP LU --> 382 Figure 6: [Y] access topology with access IGP. 384 Note that in all of the above topologies parallel ECMP (or L2 LAG) 385 links can be used between the nodes. 387 In both of the above topologies, ANs (ANn ... AN1) and AGN1x share 388 the access IGP and advertise their IPv4 and IPv6 loopbacks and link 389 addresses. AGN1x advertise a default route into the access IGP. 391 ANs support Inter-area LDP [RFC5283] in order to use the IP default 392 route for matching the LDP FECs advertised by AGN1x or other ANs. 394 3. LDP DoD Use Cases 396 LDP DoD operation is driven by Seamless MPLS use cases. This section 397 illustrates these use cases focusing on services provisioned on the 398 access nodes and clarifies expected LDP DoD operation on the AN and 399 AGN1x devices. Two representative service types are used to 400 illustrate the service use cases: MPLS PWE3 [RFC4447] and BGP/MPLS 401 IPVPN [RFC4364]. 403 Described LDP DoD operations apply equally to all reference access 404 topologies described in Section 2. Operations that are specific to 405 certain access topologies are called out explicitly. 407 References to upstream and downstream nodes are made in line with the 408 definition of upstream and downstream LSR [RFC3031]. 410 This document is focusing on IPv4 LDP DoD procedures. Similar 411 procedures are required for IPv6 LDP DoD, however some extension 412 specific to IPv6 are likely to apply including LSP mapping, peer 413 discovery, transport connection establishment. These will be added 414 in this document once LDP IPv6 standardization is advanced as per 415 [I-D.ietf-mpls-ldp-ipv6]. 417 3.1. Initial Network Setup 419 An access node is commissioned without any services provisioned on 420 it. The AN may request labels for loopback addresses of any AN, AGN 421 or other nodes within Seamless MPLS network for operational and 422 management purposes. It is assumed that AGN1x has required IP/MPLS 423 configuration for network-side connectivity in line with Seamless 424 MPLS design [I-D.ietf-mpls-seamless-mpls]. 426 LDP sessions are configured between adjacent ANs and AGN1x using 427 their respective loopback addresses. 429 3.1.1. AN with Static Routing 431 If access static routing is used, ANs are provisioned with the 432 following static IP routing entries (topology references from 433 Section 2 are listed in square brackets): 435 a. [I1, V, U2] - Static default route 0/0 pointing to links 436 connected to AGN1x. Requires support for Inter-area LDP 437 [RFC5283]. 439 b. [U2] - Static /32 or /128 routes pointing to the other AN. Lower 440 preference static default route 0/0 pointing to links connected 441 to the other AN. Requires support for Inter-area LDP [RFC5283]. 443 c. [I, Y] - Static default route 0/0 pointing to links leading 444 towards AGN1x. Requires support for Inter-area LDP [RFC5283]. 446 d. [I, Y] - Static /32 or /128 routes to all ANs in the daisy-chain 447 pointing to links towards those ANs. 449 e. [I1, V, U2] - Optional - Static /32 or /128 routes for specific 450 nodes within Seamless MPLS network, pointing to links connected 451 to AGN1x. 453 f. [I, Y] - Optional - Static /32 or /128 routes for specific nodes 454 within the Seamless MPLS network, pointing to links leading 455 towards AGN1x. 457 Upstream AN/AGN1x should request labels over LDP DoD session(s) from 458 downstream AN/AGN1x for configured static routes if those static 459 routes are configured with LDP DoD request policy and if they are 460 pointing to a next-hop selected by routing. It is expected that all 461 configured /32 and /128 static routes to be used for LDP DoD are 462 configured with such policy on AN/AGN1x. 464 Downstream AN/AGN1x should respond to the label request from the 465 upstream AN/AGN1x with a label mapping (if requested route is present 466 in its RIB, and there is a valid label binding from its downstream), 467 and must install the advertised label as an incoming label in its 468 label table (LIB) and its forwarding table (LFIB). Upstream AN/AGN1x 469 must also install the received label as an outgoing label in their 470 LIB and LFIB. If the downstream AN/AGN1x does have the route present 471 in its RIB, but does not have a valid label binding from its 472 downstream, it should forward the request to its downstream. 474 In order to facilitate ECMP and IPFRR LFA local-repair, the upstream 475 AN/AGN1x must also send LDP DoD label requests to alternate next-hops 476 per its RIB, and install received labels as alternate entries in its 477 LIB and LFIB. 479 AGN1x node on the network side may use BGP labeled unicast [RFC3107] 480 in line with the Seamless MPLS design [I-D.ietf-mpls-seamless-mpls]. 481 In such a case AGN1x will be redistributing its static routes 482 pointing to local ANs into BGP labeled unicast to facilitate network- 483 to-access traffic flows. Likewise, to facilitate access-to-network 484 traffic flows, AGN1x will be responding to access-originated LDP DoD 485 label requests with label mappings based on its BGP labeled unicast 486 reachability for requested FECs. 488 3.1.2. AN with Access IGP 490 If access IGP is used, AN(s) advertise their loopbacks over the 491 access IGP with configured metrics. AGN1x advertise a default route 492 over the access IGP. 494 Routers request labels over LDP DoD session(s) according to their 495 needs for MPLS connectivity (LSPs). In particular if AGNs, as per 496 Seamless MPLS design [I-D.ietf-mpls-seamless-mpls], redistribute 497 routes from the IGP into BGP labeled unicast [RFC3107], they should 498 request labels over LDP DoD session(s) for those routes. 500 Identically to the static route case, downstream AN/AGN1x should 501 respond to the label request from the upstream AN/AGN1x with a label 502 mapping (if the requested route is present in its RIB, and there is a 503 valid label binding from its downstream), and must install the 504 advertised label as an incoming label in its LIB and LFIB. Upstream 505 AN/AGN1x must also install the received label as an outgoing label in 506 their LIB and LFIB. 508 Identically to the static route case, in order to facilitate ECMP and 509 IPFRR LFA local-repair, upstream AN/AGN1x must also send LDP DoD 510 label requests to alternate next-hops per its RIB, and install 511 received labels as alternate entries in its LIB and LFIB. 513 AGN1x node on the network side may use BGP labeled unicast [RFC3107] 514 in line with Seamless MPLS design [I-D.ietf-mpls-seamless-mpls]. In 515 such case AGN1x will be redistributing routes received over the 516 access IGP (and pointing to local ANs), into BGP labeled unicast to 517 facilitate network-to-access traffic flows. Likewise, to facilitate 518 access-to-network traffic flows AGN1x will be responding to access 519 originated LDP DoD label requests with label mappings based on its 520 BGP labeled unicast reachability for requested FECs. 522 3.2. Service Provisioning and Activation 524 Following the initial setup phase described in Section 3.1, a 525 specific access node, referred to as AN*, is provisioned with a 526 network service. AN* relies on LDP DoD to request the required MPLS 527 LSP(s) label(s) from downstream AN/AGN1x node(s). Note that LDP DoD 528 operations are service agnostic, that is, they are the same 529 independently of the services provisioned on the AN*. 531 For illustration purposes two service types are described: MPLS PWE3 532 [RFC4447] service and BGP/MPLS IPVPN [RFC4364]. 534 MPLS PWE3 service - for description simplicity it is assumed that a 535 single segment pseudowire is signaled using targeted LDP FEC128 536 (0x80), and it is provisioned with the pseudowire ID and the loopback 537 IPv4 address of the destination node. The following IP/MPLS 538 operations need to be completed on the AN* to successfully establish 539 such PWE3 service: 541 a. LSP labels for destination /32 FEC (outgoing label) and the local 542 /32 loopback (incoming label) need to be signaled using LDP DoD. 544 b. Targeted LDP session over an associated TCP/IP connection needs 545 to be established to the PWE3 destination PE. This is triggered 546 by either an explicit targeted LDP session configuration on the 547 AN* or automatically at the time of provisioning the PWE3 548 instance. 550 c. Local and remote PWE3 labels for specific FEC128 PW ID need to be 551 signaled using targeted LDP and PWE3 signaling procedures 552 [RFC4447]. 554 d. Upon successful completion of the above operations, AN* programs 555 its RIB/LIB and LFIB tables, and activates the MPLS PWE3 service. 557 Note - only minimum operations applicable to service connectivity 558 have been listed. Other non IP/MPLS connectivity operations that may 559 be required for successful service provisioning and activation are 560 out of scope in this document. 562 BGP/MPLS IPVPN service - for description simplicity it is assumed 563 that AN* is provisioned with a unicast IPv4 IPVPN service (VPNv4 for 564 short) [RFC4364]. The following IP/MPLS operations need to be 565 completed on the AN* to successfully establish VPNv4 service: 567 a. BGP peering sessions with associated TCP/IP connections need to 568 be established with the remote destination VPNv4 PEs or Route 569 Reflectors. 571 b. Based on configured BGP policies, VPNv4 BGP NLRIs need to be 572 exchanged between AN* and its BGP peers. 574 c. Based on configured BGP policies, VPNv4 routes need to be 575 installed in the AN* VRF RIB and FIB, with corresponding BGP 576 next-hops. 578 d. LSP labels for destination BGP next-hop /32 FEC (outgoing label) 579 and the local /32 loopback (incoming label) need to be signaled 580 using LDP DoD. 582 e. Upon successful completion of above operations, AN* programs its 583 RIB/LIB and LFIB tables, and activates the BGP/MPLS IPVPN 584 service. 586 Note - only minimum operations applicable to service connectivity 587 have been listed. Other non IP/MPLS connectivity operations that may 588 be required for successful service provisioning are out of scope in 589 this document. 591 To establish an LSP for destination /32 FEC for any of the above 592 services, AN* looks up its local routing table for a matching route, 593 selects the best next-hop(s) and associated outgoing link(s). 595 If a label for this /32 FEC is not already installed based on the 596 configured static route with LDP DoD request policy or access IGP RIB 597 entry, AN* must send an LDP DoD label mapping request. Downstream 598 AN/AGN1x LSR(s) checks its RIB for presence of the requested /32 and 599 associated valid outgoing label binding, and if both are present, 600 replies with its label for this FEC and installs this label as 601 incoming in its LIB and LFIB. Upon receiving the label mapping the 602 AN* must accept this label based on the exact route match of 603 advertised FEC and route entry in its RIB or based on the longest 604 match in line with Inter-area LDP [RFC5283]. If the AN* accepts the 605 label it must install it as an outgoing label in its LIB and LFIB. 607 In access topologies [V] and [Y], if AN* is dual homed to two AGN1x 608 and routing entries for these AGN1x are configured as equal cost 609 paths, AN* must send LDP DoD label requests to both AGN1x devices and 610 install all received labels in its LIB and LFIB. 612 In order for AN* to implement IPFRR LFA local-repair, AN* must also 613 send LDP DoD label requests to alternate next-hops per its RIB, and 614 install received labels as alternate entries in its LIB and LFIB. 616 When forwarding PWE3 or VPNv4 packets AN* chooses the LSP label based 617 on the locally configured static /32 or default route, or default 618 route signaled via access IGP. If a route is reachable via multiple 619 interfaces to AGN1x nodes and the route has multiple equal cost 620 paths, AN* must implement Equal Cost Multi-Path (ECMP) functionality. 621 This involves AN* using hash-based load-balancing mechanism and 622 sending the PWE3 or VPNv4 packets in a flow-aware manner with 623 appropriate LSP labels via all equal cost links. 625 ECMP mechanism is applicable in an equal manner to parallel links 626 between two network elements and multiple paths towards the 627 destination. The traffic demand is distributed over the available 628 paths. 630 AGN1x node on the network side may use BGP labeled unicast [RFC3107] 631 in line with Seamless MPLS design [I-D.ietf-mpls-seamless-mpls]. In 632 such case AGN1x will be redistributing its static routes (or routes 633 received from the access IGP) pointing to local ANs into BGP labeled 634 unicast to facilitate network-to-access traffic flows. Likewise, to 635 facilitate access-to-network traffic flows AGN1x will be responding 636 to access originated LDP DoD label requests with label mappings based 637 on its BGP labeled unicast reachability for requested FECs. 639 3.3. Service Changes and Decommissioning 641 Whenever AN* service gets decommissioned or changed and connectivity 642 to specific destination is not longer required, the associated MPLS 643 LSP label resources should be released on AN*. 645 MPLS PWE3 service - if the PWE3 service gets decommissioned and it is 646 the last PWE3 to a specific destination node, the targeted LDP 647 session is not longer needed and should be terminated (automatically 648 or by configuration). The MPLS LSP(s) to that destination is no 649 longer needed either. 651 BGP/MPLS IPVPN service - deletion of a specific VPNv4 (VRF) instance, 652 local or remote re-configuration may result in specific BGP next- 653 hop(s) being no longer needed. The MPLS LSP(s) to that destination 654 is no longer needed either. 656 In all of the above cases the following LDP DoD related operations 657 apply: 659 o If the /32 FEC label for the aforementioned destination node was 660 originally requested based on either tLDP session configuration 661 and default route or required BGP next-hop and default route, AN* 662 should delete the label from its LIB and LFIB, and release it from 663 downstream AN/AGN1x by using LDP DoD procedures. 665 o If the /32 FEC label was originally requested based on the static 666 /32 route configuration with LDP DoD request policy, the label 667 must be retained by AN*. 669 3.4. Service Failure 671 A service instance may stop being operational due to a local or 672 remote service failure event. 674 In general, unless the service failure event modifies required MPLS 675 connectivity, there should be no impact on the LDP DoD operation. 677 If the service failure event does modify the required MPLS 678 connectivity, LDP DoD operations apply as described in Section 3.2 679 and Section 3.3. 681 3.5. Network Transport Failure 683 A number of different network events can impact services on AN*. The 684 following sections describe network event types that impact LDP DoD 685 operation on AN and AGN1x nodes. 687 3.5.1. General Notes 689 If service on any of the ANs is affected by any network failure and 690 there is no network redundancy, the service must go into a failure 691 state. When the network failure is recovered from, the service must 692 be re-established automatically. 694 The following additional LDP-related functions should be supported to 695 comply with Seamless MPLS [I-D.ietf-mpls-seamless-mpls] fast service 696 restoration requirements as follows: 698 a. Local-repair - AN and AGN1x should support local-repair for 699 adjacent link or node failure for access-to-network, network-to- 700 access and access-to-access traffic flows. Local-repair should 701 be implemented by using either IPFRR LDP LFA, simple ECMP or 702 primary/backup switchover upon failure detection. 704 b. LDP session protection - LDP sessions should be configured with 705 LDP session protection to avoid delay upon the recovery from link 706 failure. LDP session protection ensures that FEC label binding 707 is maintained in the control plane as long as LDP session stays 708 up. 710 c. IGP-LDP synchronization - If access IGP is used, LDP sessions 711 between ANs, and between ANs and AGN1x, should be configured with 712 IGP-LDP synchronization to avoid unnecessary traffic loss in case 713 the access IGP converged before LDP and there is no LDP label 714 binding to the downstream best next-hop. 716 3.5.2. AN Node Failure 718 AN node fails and all links to adjacent nodes go down. 720 Adjacent AN/AGN1x nodes remove all routes pointing to the failed 721 link(s) from their RIB tables (including /32 loopback belonging to 722 the failed AN and any other routes reachable via the failed AN). 723 This in turn triggers the removal of associated outgoing /32 FEC 724 labels from their LIB and LFIB tables. 726 If access IGP is used, the AN node failure will be propagated via IGP 727 link updates across the access topology. 729 If a specific /32 FEC(s) is not reachable anymore from those AN/ 730 AGN1x, they must also send LDP label withdraw to their upstream LSRs 731 to notify about the failure, and remove the associated incoming 732 label(s) from their LIB and LFIB tables. Upstream LSRs upon 733 receiving label withdraw should remove the signaled labels from their 734 LIB/LFIB tables, and propagate LDP label withdraw across their 735 upstream LDP DoD sessions. 737 In [U] topology there may be an alternative path to routes previously 738 reachable via the failed AN node. In this case adjacent AN/AGN1x 739 should invoke local-repair (IPFRR LFA, ECMP) and switchover to 740 alternate next-hop to reach those routes. 742 AGN1x gets notified about the AN failure via either access IGP (if 743 used) and/or cascaded LDP DoD label withdraw(s). AGN1x must 744 implement all relevant global-repair IP/MPLS procedures to propagate 745 the AN failure towards the core network. This should involve 746 removing associated routes (in access IGP case) and labels from its 747 LIB and LFIB tables, and propagating the failure on the network side 748 using BGP-LU and/or core IGP/LDP-DU procedures. 750 Upon AN coming back up, adjacent AN/AGN1x nodes automatically add 751 routes pointing to recovered links based on the configured static 752 routes or access IGP adjacency and link state updates. This should 753 be then followed by LDP DoD label signaling and subsequent binding 754 and installation of labels in LIB and LFIB tables. 756 3.5.3. AN/AGN Link Failure 758 Depending on the access topology and the failed link location 759 different cases apply to the network operation after AN link failure 760 (topology references from Section 2 in square brackets): 762 a. [all] - link failed, but at least one ECMP parallel link remains 763 - nodes on both sides of the failed link must stop using the 764 failed link immediately (local-repair), and keep using the 765 remaining ECMP parallel links. 767 b. [I1, I, Y] - link failed, and there are no ECMP or alternative 768 links and paths - nodes on both sides of the failed link must 769 remove routes pointing to the failed link immediately from the 770 RIB, remove associated labels from their LIB and LFIB tabels, and 771 must send LDP label withdraw(s) to their upstream LSRs. 773 c. [U2, U, V, Y] - link failed, but at least one ECMP or alternate 774 path remains - AN/AGN1x node must stop using the failed link and 775 immediately switchover (local-repair) to the remaining ECMP path 776 or alternate path. AN/AGN1x must remove affected next-hops and 777 labels from its tables and invoke LDP label withdraw as per point 778 (a) above. If there is an AGN1x node terminating the failed 779 link, it must remove routes pointing to the failed link 780 immediately from the RIB, remove associated labels from their LIB 781 and LFIB tabels, and must propagate the failure on the network 782 side using BGP-LU and/or core IGP procedures. 784 If access IGP is used AN/AGN1x link failure will be propagated via 785 IGP link updates across the access topology. 787 LDP DoD will also propagate the link failure by sending label 788 withdraws to upstream AN/AGN1x nodes, and label release messages 789 downstream AN/AGN1x nodes. 791 3.5.4. AGN Node Failure 793 AGN1x fails and all links to adjacent access nodes go down. 795 Depending on the access topology, following cases apply to the 796 network operation after AGN1x node failure (topology references from 797 Section 2 in square brackets): 799 a. [I1, I] - ANs are isolated from the network - AN adjacent to the 800 failure must remove routes pointing to the failed AGN1x node 801 immediately from the RIB, remove associated labels from their LIB 802 and LFIB tabels, and must send LDP label withdraw(s) to their 803 upstream LSRs. If access IGP is used, an IGP link update should 804 be sent. 806 b. [U2, U, V, Y] - at least one ECMP or alternate path remains - AN 807 adjacent to failed AGN1x must stop using the failed link and 808 immediately switchover (local-repair) to the remaining ECMP path 809 or alternate path. AN must remove affected routes and labels 810 from its tables and invoke LDP label withdraw as per point (a) 811 above. 813 Network side procedures for handling AGN1x node failure have been 814 described in Seamless MPLS [I-D.ietf-mpls-seamless-mpls]. 816 3.5.5. AGN Network-side Reachability Failure 818 AGN1x loses network reachability to a specific destination or set of 819 network-side destinations. 821 In such event AGN1x must send LDP Label Withdraw messages to its 822 upstream ANs, withdrawing labels for all affected /32 FECs. Upon 823 receiving those messages ANs must remove those labels from their LIB 824 and LFIB tables, and use alternative LSPs instead if available as 825 part of global-repair. In turn ANs should also sent Label Withdraw 826 messages for affected /32 FECs to their upstream ANs. 828 If access IGP is used, and AGN1x gets completely isolated from the 829 core network, it should stop advertising the default route 0/0 into 830 the access IGP. 832 4. LDP DoD Procedures 834 Label Distribution Protocol is specified in [RFC5036], and all LDP 835 Downstream-on-Demand implementations MUST follow this specification. 837 In the MPLS architecture [RFC3031], network traffic flows from 838 upstream to downstream LSR. The use cases in this document rely on 839 the downstream assignment of labels, where labels are assigned by the 840 downstream LSR and signaled to the upstream LSR as shown in Figure 7. 842 +----------+ +------------+ 843 | upstream | | downstream | 844 ------+ LSR +------+ LSR +---- 845 traffic | | | | address 846 source +----------+ +------------+ (/32 for IPv4) 847 traffic 848 label distribution for IPv4 FEC destination 849 <------------------------- 851 traffic flow 852 -------------------------> 854 Figure 7: LDP label assignment direction 856 4.1. LDP Label Distribution Control and Retention Modes 858 LDP protocol specification [RFC5036] defines two modes for label 859 distribution control, following the definitions in MPLS architecture 860 [RFC3031]: 862 o Independent mode - an LSR recognizes a particular FEC and makes a 863 decision to bind a label to the FEC independently from 864 distributing that label binding to its label distribution peers. 865 A new FEC is recognized whenever a new route becomes valid on the 866 LSR. 868 o Ordered mode - an LSR binds a label to a particular FEC if it is 869 the egress router for that FEC or if it has already received a 870 label binding for that FEC from its next-hop LSR for that FEC. 872 Using independent label distribution control with LDP DoD and access 873 static routing would prevent the access LSRs from propagating label 874 binding failure along the access topology, making it impossible for 875 upstream LSR to be notified about the downstream failure and for an 876 application using the LSP to switchover to an alternate path, even if 877 such a path exists. 879 LDP protocol specification [RFC5036] defines two modes for label 880 retention, following the definitions in MPLS architecture [RFC3031]: 882 o Conservative mode - If operating in Downstream on Demand mode, an 883 LSR will request label mappings only from the next hop LSR 884 according to routing. The main advantage of the conservative mode 885 is that only the labels that are required for the forwarding of 886 data are allocated and maintained. This is particularly important 887 in LSRs where the label space is inherently limited, such as in an 888 ATM switch. A disadvantage of the conservative mode is that if 889 routing changes the next hop for a given destination, a new label 890 must be obtained from the new next hop before labeled packets can 891 be forwarded. 893 o Liberal mode - When operating in Downstream on Demand mode with 894 Liberal Label retention, an LSR might choose to request label 895 mappings for all known prefixes from all peer LSRs. The main 896 advantage of the Liberal Label retention mode is that reaction to 897 routing changes can be quick because labels already exist. The 898 main disadvantage of the liberal mode is that unneeded label 899 mappings are distributed and maintained. 901 Note that the conservative label retention mode would prevent LSRs 902 from requesting and maintaining label mappings for any backup routes 903 that are not used for forwarding. This in turn would prevent the 904 access LSRs (AN and AGN1x nodes) from implementing any local 905 protection schemes that rely on using alternate next-hops in case of 906 the primary next-hop failure. Such schemes include IPFRR LFA if 907 access IGP is used, or a primary and backup static route 908 configuration. Using LDP DoD in combination with liberal retention 909 mode allows the LSR to request labels for the specific FEC from 910 primary next-hop LSR(s) and the alternate next-hop LSR(s) for this 911 FEC. 913 Note that even though LDP DoD operates in a liberal retention mode, 914 if used with access IGP and if no LFA exists, the LDP DoD will 915 introduce additional delay in traffic restoration as the labels for 916 the new next-hop will get requested only after the access IGP 917 convergence. 919 Adhering to the overall design goals of Seamless MPLS 921 [I-D.ietf-mpls-seamless-mpls], specifically achieving a large network 922 scale without compromising fast service restoration, all access LSRs 923 (AN and AGN1x nodes) MUST use LDP DoD advertisement mode with: 925 o Ordered label distribution control - enables propagation of label 926 binding failure within the access topology. 928 o Liberal label retention - enables pre-programming of alternate 929 next-hops with associated FEC labels. 931 In Seamless MPLS [I-D.ietf-mpls-seamless-mpls] AGN1x node acts as an 932 access ABR connecting access and metro domains. To enable failure 933 propagation between those domains, access ABR MUST implement ordered 934 label distribution control when redistributing routes/FEC between the 935 access-side (using LDP DoD and static or access IGP) and the network- 936 side ( using BGP labeled unicast [RFC3107] or core IGP with LDP 937 Downstream Unsolicited label advertisement. 939 4.2. IPv6 Support 941 Current LDP protocol specification [RFC5036] defines procedures and 942 messages for exchanging FEC-label bindings over IPv4 and/or IPv6 943 networks. However number of IPv6 usage areas are not clearly 944 specified including: packet to LSP mapping for IPv6 destination 945 router, no IPv6 specific LSP identifier, no LDP discovery using IPv6 946 multicast address, separate LSPs for IPv4 and IPv6, and others. 948 All of these issues and more are being addressed by 949 [I-D.ietf-mpls-ldp-ipv6] that will update LDP protocol specification 950 [RFC5036] in respect to the IPv6 usage. For the future deployment, 951 LDP DoD use case and procedures described in this document SHOULD 952 also support IPv6 for transport and services. 954 4.3. LDP DoD Session Negotiation 956 Access LSR/ABR should propose the Downstream-on-Demand label 957 advertisement by setting "A" value to 1 in the Common Session 958 Parameters TLV of the Initialization message. The rules for 959 negotiating the label advertisement mode are specified in LDP 960 protocol specification [RFC5036]. 962 To establish a Downstream-on-Demand session between the two access 963 LSR/ABRs, both should propose the Downstream-on-Demand label 964 advertisement mode in the Initialization message. If the access LSR 965 only supports LDP DoD and the access ABR proposes Downstream 966 Unsolicited mode, the access LSR SHOULD send a Notification message 967 with status "Session Rejected/Parameters Advertisement Mode" and then 968 close the LDP session as specified in LDP protocol specification 970 [RFC5036]. 972 If an access LSR is acting in an active role, it should re-attempt 973 the LDP session immediately. If the access LSR receives the same 974 Downstream Unsolicited mode again, it should follow the exponential 975 backoff algorithm as defined in the LDP protocol specification 976 [RFC5036] with delay of 15 seconds and subsequent delays growing to a 977 maximum delay of 2 minutes. 979 In case a PWE3 service is required between the adjacent access LSR/ 980 ABR, and LDP DoD has been negotiated for IPv4 and IPv6 FECs, the same 981 LDP session should be used for PWE3 FECs. Even if LDP DoD label 982 advertisement has been negotiated for IPv4 and IPv6 LDP FECs as 983 described earlier, LDP session should use Downstream Unsolicited 984 label advertisement for PWE3 FECs as specified in PWE3 LDP [RFC4447]. 986 4.4. Label Request Procedures 988 4.4.1. Access LSR/ABR Label Request 990 Upstream access LSR/ABR will request label bindings from adjacent 991 downstream access LSR/ABR based on the following trigger events: 993 a. Access LSR/ABR is configured with /32 static route with LDP DoD 994 label request policy in line with initial network setup use case 995 described in Section 3.1. 997 b. Access LSR/ABR is configured with a service in line with service 998 use cases described in Section 3.2 and Section 3.3. 1000 c. Configuration with access static routes - Access LSR/ABR link to 1001 adjacent node comes up and LDP DoD session is established. In 1002 this case access LSR should send label request messages for all 1003 /32 static routes configured with LDP DoD policy and all /32 1004 routes related to provisioned services that are covered by 1005 default route. 1007 d. Configuration with access IGP - Access LSR/ABR link to adjacent 1008 node comes up and LDP DoD session is established. In this case 1009 access LSR should send label request messages for all /32 routes 1010 learned over the access IGP and all /32 routes related to 1011 provisioned services that are covered by access IGP routes. 1013 e. In all above cases requests MUST be sent to next-hop LSR(s) and 1014 alternate LSR(s). 1016 Downstream access LSR/ABR will respond with label mapping message 1017 with a non-null label if any of the below conditions are met: 1019 a. Downstream access LSR/ABR - requested FEC is an IGP or static 1020 route and there is an LDP label already learnt from the next- 1021 next-hop downstream LSR (by LDP DoD or LDP DU). If there is no 1022 label for the requested FEC and there is an LDP DoD session to 1023 the next-next-hop downstream LSR, downstream LSR MUST send a 1024 label request message for the same FEC to the next-next-hop 1025 downstream LSR. In such case downstream LSR will respond back to 1026 the requesting upstream access LSR only after getting a label 1027 from the next-next-hop downstream LSR peer. 1029 b. Downstream access ABR only - requested FEC is a BGP labelled 1030 unicast route [RFC3107] and this BGP route is the best selected 1031 for this FEC. 1033 Downstream access LSR/ABR may respond with a label mapping with 1034 explicit-null or implicit-null label if it is acting as an egress for 1035 the requested FEC, or it may respond with "No Route" notification if 1036 no route exists. 1038 4.4.2. Label Request Retry 1040 If an access LSR/ABR receives a "No route" Notification in response 1041 to its label request message, it should retry using an exponential 1042 backoff algorithm similar to the backoff algoritm mentioned in the 1043 LDP session negotiation described in Section 4.3. 1045 If there is no response to the sent label request message, the LDP 1046 specification [RFC5036] (section A.1.1, page# 100) states that the 1047 LSR should not send another request for the same label to the peer 1048 and mandates that a duplicate label request is considered a protocol 1049 error and should be dropped by the receiving LSR by sending a 1050 Notification message. 1052 Thus, if there is no response from the downstream peer, the access 1053 LSR/ABR should not send a duplicate label request message again. 1055 If the static route corresponding to the FEC gets deleted or if the 1056 DoD request policy is modified to reject the FEC before receiving the 1057 label mapping message, then the access LSR/ABR should send a Label 1058 Abort message to the downstream LSR. 1060 4.4.3. Label Request with Fast-Up Convergence 1062 In some conditions, the exponential backoff algorithm usage described 1063 in Section 4.4.2 may result in a longer than desired wait time to get 1064 a successful LDP label to route mapping. An example is when a 1065 specific route is unavailable on the downstream LSR when the label 1066 mapping request from the upstream is received, but later comes back. 1068 In such case using the exponential backoff algorithm may result in a 1069 max delay wait time before the upstream LSR sends another LDP label 1070 request. 1072 Fast-up convergence can be addressed with a minor extension to the 1073 LDP DoD procedure, as described in this section. The downstream and 1074 upstream LSRs SHOULD implement this extension if up convergence 1075 improvement is desired. 1077 The extension consists of the upstream LSR indicating to the 1078 downstream LSR that the label request should be queued on the 1079 downstream LSR until the requested route is available. 1081 To implement this behavior, a new Optional Parameter is defined for 1082 use in the Label Request message: 1084 Optional Parameter Length Value 1085 Queue Request TLV 0 see below 1087 0 1 2 3 1088 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 |1|0| Queue Request (0x????) | Length (0x00) | 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 U-bit = 1 1094 Unknown TLV bit is set to 1. If this optional TLV is unknown, 1095 it should be ignored without sending "no route" notification. 1096 Ensures backward compatibility. 1098 F-bit = 0 1099 Forward unknown TLV bit is set to 0. The unknown TLV is not 1100 forwarded. 1102 Type 1103 Queue Request Type value to be allocated by IANA. 1105 Length = 0x00 1106 Specifies the length of the Value field in octets. 1108 The operation is as follows. 1110 To benefit from the fast-up convergence improvement, the upstream LSR 1111 sends a Label Request message with a Queue Request TLV. 1113 If the downstream LSR supports the Queue Request TLV, it verifies if 1114 route is available and if so it replies with label mapping as per 1115 existing LDP procedures. 1117 If the route is not available, the downstream LSR queues the request 1118 and replies as soon as the route becomes available. In the meantime, 1119 it does not send a "no route" notification back. When sending a 1120 label request with the Queue Request TLV, the upstream LSR does not 1121 retry the Label Request message if it does not receive a reply from 1122 its downstream peer 1124 If the upstream LSR wants to abort an outstanding label request while 1125 the Label Request is queued in the downstream LSR, the upstream LSR 1126 sends a Label Abort Request message, making the downstream LSR to 1127 remove the original request from the queue and send back a 1128 notification Label Request Aborted [RFC5036]. 1130 If the downstream LSR does not support the Queue Request TLV, it will 1131 silently ignores it, and sends a "no route" notification back. In 1132 this case the upstream LSR invokes the exponential backoff algorithm 1133 described in Section 4.4.2. 1135 This described procedure ensures backward compatitibility. 1137 4.5. Label Withdraw 1139 If an MPLS label on the downstream access LSR/ABR is no longer valid, 1140 the downstream access LSR/ABR withdraws this FEC/label binding from 1141 the upstream access LSR/ABR with the Label Withdraw Message [RFC5036] 1142 with a specified label TLV or with an empty label TLV. 1144 Downstream access LSR/ABR SHOULD withdraw a label for specific FEC in 1145 the following cases: 1147 a. If LDP DoD ingress label is associated with an outgoing label 1148 assigned by BGP labelled unicast route, and this route is 1149 withdrawn. 1151 b. If LDP DoD ingress label is associated with an outgoing label 1152 assigned by LDP (DoD or DU) and the IGP route is withdrawn from 1153 the RIB or downstream LDP session is lost. 1155 c. If LDP DoD ingress label is associated with an outgoing label 1156 assigned by LDP (DoD or DU) and the outgoing label is withdrawn 1157 by the downstream LSR. 1159 d. If LDP DoD ingress label is associated with an outgoing label 1160 assigned by LDP (DoD or DU), route next-hop changed and 1162 * there is no LDP session to the new next-hop. To minimize 1163 probability of this, the access LSR/ABR should implement LDP- 1164 IGP synchronization procedures as specified in [RFC5443]. 1166 * there is an LDP session but no label from downstream LSR. See 1167 note below. 1169 e. If access LSR/ABR is configured with a policy to reject exporting 1170 label mappings to upstream LSR. 1172 The upstream access LSR/ABR responds to the Label Withdraw Message 1173 with the Label Release Message [RFC5036]. 1175 After sending label release message to downstream access LSR/ABR, the 1176 upstream access LSR/ABR should resend label request message, assuming 1177 upstream access LSR/ABR still requires the label. 1179 Downstream access LSR/ABR should withdraw a label if the local route 1180 configuration (e.g. /32 loopback) is deleted. 1182 Note: For any events inducing next hop change, downstream access LSR/ 1183 ABR should attempt to converge the LSP locally before withdrawing the 1184 label from an upstream access LSR/ABR. For example if the next-hop 1185 changes for a particular FEC and if the new next-hop allocates labels 1186 by LDP DoD session, then the downstream access LSR/ABR must send a 1187 label request on the new next-hop session. If downstream access LSR/ 1188 ABR doesn't get label mapping for some duration, then and only then 1189 downstream access LSR/ABR must withdraw the upstream label. 1191 4.6. Label Release 1193 If an access LSR/ABR does not need any longer a label for a FEC, it 1194 sends a Label Release Message [RFC5036] to the downstream access LSR/ 1195 ABR with or without the label TLV. 1197 If upstream access LSR/ABR receives an unsolicited label mapping on 1198 DoD session, they should release the label by sending label release 1199 message. 1201 Access LSR/ABR should send a label release message to the downstream 1202 LSR in the following cases: 1204 a. If it receives a label withdraw from the downstream access LSR/ 1205 ABR. 1207 b. If the /32 static route with LDP DoD label request policy is 1208 deleted. 1210 c. If the service gets decommissioned and there is no corresponding 1211 /32 static route with LDP DoD label request policy configured. 1213 d. If the route next-hop changed, and the label does not point to 1214 the best or alternate next-hop. 1216 e. If it receives a label withdraw from a downstream DoD session. 1218 4.7. Local Repair 1220 To support local-repair with ECMP and IPFRR LFA, access LSR/ABR MUST 1221 request labels on both best next-hop and alternate next-hop LDP DoD 1222 sessions as specified in the label request procedures in Section 4.4. 1223 This will enable access LSR/ABR to pre-program the alternate 1224 forwarding path with the alternate label(s), and invoke IPFRR LFA 1225 switch-over procedure if the primary next-hop link fails. 1227 5. IANA Considerations 1229 5.1. LDP TLV TYPE 1231 This document uses a new a new Optional Parameter Queue Request TLV 1232 in the Label Request message defined in Section 4.4.3. IANA already 1233 maintains a registry of name LDP "TLV TYPE NAME SPACE" defined by 1234 RFC5036. The following value is suggested for assignment: 1236 TLV type Description 1237 0x0971 Queue Request TLV 1239 6. Security Considerations 1241 MPLS LDP Downstream on Demand deployment in the access network is 1242 subject to similar security threats as any MPLS LDP deployment. It 1243 is recommended that baseline security measures are considered as 1244 described in the LDP specification [RFC5036] including ensuring 1245 authenticity and integrity of LDP messages, as well as protection 1246 against spoofing and Denial of Service attacks. 1248 Some deployments may require increased measures of network security 1249 if a subset of Access Nodes are placed in locations with lower levels 1250 of physical security e.g. street cabinets (common practice for VDSL 1251 access). In such cases it is the responsibility of the system 1252 designer to take into account the physical security measures 1253 (environmental design, mechanical or electronic access control, 1254 intrusion detection), as well as monitoring and auditing measures 1255 (configuration and Operating System changes, reloads, routes 1256 advertisements). 1258 But even with all this in mind, the designer still should consider 1259 network security risks and adequate measures arising from the lower 1260 level of physical security of those locations. 1262 6.1. Security and LDP DoD 1264 6.1.1. Access to network packet flow direction 1266 An important property of MPLS LDP Downstream on Demand operation is 1267 that the upstream LSR (requesting LSR) accepts only mappings it sent 1268 a request for (in other words the ones it is interested in), and does 1269 not accept any unsolicited label mappings by design. 1271 This limits the potential of an unauthorized third party fiddling 1272 with label mappings operations on the wire. It also enables ABR LSR 1273 to monitor behaviour of any Access LSR in case the latter gets 1274 compromised and attempts to get access to an unauthorized FEC or 1275 remote LSR. Note that ABR LSR is effectively acting as a gateway to 1276 the MPLS network, and any label mapping requests made by any Access 1277 LSR are processed and can be monitored on this ABR LSR. 1279 6.1.2. Network to access packet flow direction 1281 Another important property of MPLS LDP DoD operation in the access is 1282 that the number of access nodes and associated MPLS FECs per ABR LSR 1283 is not large in number, and they are all known at the deployment 1284 time. Hence any changes of the access MPLS FECs can be easily 1285 controlled and monitored on the ABR LSR. 1287 And then, even in the event when Access LSR manages to advertise a 1288 FEC that belongs to another LSR (e.g. in order to 'steal' third party 1289 data flows, or breach a privacy of VPN), such Access LSR will have to 1290 influence the routing decision for affected FEC on the ABR LSR. 1291 Following measures SHOULD be considered to prevent such event from 1292 occurring: 1294 a. ABR LSR - access side with static routes - this is not possible 1295 for Access LSR. Access LSR has no way to influence ABR LSR 1296 routing decisions due to static nature of routing configuration 1297 here. 1299 b. ABR LSR - access side with IGP - this is still not possible if 1300 the compromised Access LSR is a leaf in the access topology (leaf 1301 node in topologies I1, I, V, Y described earlier in this 1302 document), due to the leaf metrics being configured on the ABR 1303 LSR. If the compromised Access LSR is a transit LSR in the 1304 access topology (transit node in topologies I, Y, U), it is 1305 possible for this Access LSR to attract to itself traffic 1306 destined to the nodes upstream from it. However elaborate such 1307 'man in the middle attack' is possible, but can be quickly 1308 detected by upstream Access LSRs not receiving traffic, and 1309 legitimate traffic from them getting dropped. 1311 c. ABR LSR - network side - designer SHOULD consider giving a higher 1312 administrative preference to the labeled unicast BGP routes vs. 1313 access IGP routes. 1315 In summary MPLS in access design with LDP DoD has number of native 1316 properties that prevent number of security attacks and make their 1317 detection quick and straightforward. 1319 Following two sections describe other security considerations 1320 applicable to general MPLS deployments in the access. 1322 6.2. Data Plane Security 1324 Data plane security risks applicable to the access MPLS network are 1325 listed below (a non-exhaustive list): 1327 a. packets from a specific access node flow to an altered transport 1328 layer or service layer destination. 1330 b. packets belonging to undefined services flow to and from the 1331 access network. 1333 c. unlabelled packets destined to remote network nodes. 1335 Following mechanisms should be considered to address listed data 1336 plane security risks: 1338 1. addressing (a) - Access and ABR LSRs SHOULD NOT accept labeled 1339 packets over a particular data link, unless from the Access or 1340 ABR LSR perspective this data link is known to attach to a 1341 trusted system based on employed authentication mechanism(s), and 1342 the top label has been distributed to the upstream neighbour by 1343 the receiving Access or ABR LSR. 1345 2. addressing (a) - ABR LSR MAY restrict network reachability for 1346 access devices to a subset of remote network LSR, based on 1347 authentication or other network security technologies employed 1348 towards Access LSRs. Restricted reachability can be enforced on 1349 the ABR LSR using local routing policies, and can be distributed 1350 towards the core MPLS network using routing policies associated 1351 with access MPLS FECs. 1353 3. addressing (b) - labeled service routes (e.g. MPLS/VPN, tLDP) 1354 are not accepted from unreliable routing peers. Detection of 1355 unreliable routing peers is achieved by engaging routing protocol 1356 detection and alarm mechanisms, and is out of scope of this 1357 document. 1359 4. addressing (a) and (b) - no successful attacks have been mounted 1360 on the control plane and has been detected. 1362 5. addressing (c) - ABR LSR MAY restrict IP network reachability to 1363 and from the access LSR. 1365 6.3. Control Plane Security 1367 Similarly to Inter-AS MPLS/VPN deployments [RFC4364], the data plane 1368 security depends on the security of the control plane. 1370 To ensure control plane security access LDP DoD connections MUST only 1371 be made with LDP peers that are considered trusted from the local LSR 1372 perspective, meaning they are reachable over a data link that is 1373 known to attach to a trusted system based on employed authentication 1374 mechanism(s) on the local LSR. 1376 The TCP/IP MD5 authentication option [RFC5925] should be used with 1377 LDP as described in LDP specification [RFC5036]. If TCP/IP MD5 1378 authentication is considered not secure enough, the designer may 1379 consider using a more elaborate and advanced TCP Authentication 1380 Option (TCP-AO RFC 5925) for LDP session authentication. 1382 Access IGP (if used) and any routing protocols used in access network 1383 for signalling service routes SHOULD also be secured in a similar 1384 manner. 1386 For increased level of authentication in the control plane security 1387 for a subset of access locations with lower physical security, 1388 designer could also consider using: 1390 o different crypto keys for use in authentication procedures for 1391 these locations. 1393 o stricter network protection mechanisms including DoS protection, 1394 interface and session flap dampening. 1396 7. Acknowledgements 1398 The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai 1399 Leymann, Geraldine Calvignac and Ina Minei for their suggestions and 1400 review. 1402 8. References 1404 8.1. Normative References 1406 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1407 Requirement Levels", BCP 14, RFC 2119, March 1997. 1409 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1410 Specification", RFC 5036, October 2007. 1412 8.2. Informative References 1414 [I-D.ietf-mpls-ldp-ipv6] 1415 Asati, R., Manral, V., Papneja, R., and C. Pignataro, 1416 "Updates to LDP for IPv6", draft-ietf-mpls-ldp-ipv6-07 1417 (work in progress), June 2012. 1419 [I-D.ietf-mpls-seamless-mpls] 1420 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 1421 M., and D. Steinberg, "Seamless MPLS Architecture", 1422 draft-ietf-mpls-seamless-mpls-01 (work in progress), 1423 March 2012. 1425 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1426 Label Switching Architecture", RFC 3031, January 2001. 1428 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 1429 BGP-4", RFC 3107, May 2001. 1431 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1432 Networks (VPNs)", RFC 4364, February 2006. 1434 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 1435 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 1437 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 1438 Heron, "Pseudowire Setup and Maintenance Using the Label 1439 Distribution Protocol (LDP)", RFC 4447, April 2006. 1441 [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension 1442 for Inter-Area Label Switched Paths (LSPs)", RFC 5283, 1443 July 2008. 1445 [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP 1446 Synchronization", RFC 5443, March 2009. 1448 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1449 Authentication Option", RFC 5925, June 2010. 1451 Authors' Addresses 1453 Thomas Beckhaus 1454 Deutsche Telekom AG 1455 Heinrich-Hertz-Strasse 3-7 1456 Darmstadt 64307 1457 Germany 1459 Phone: +49 6151 58 12825 1460 Email: thomas.beckhaus@telekom.de 1462 Bruno Decraene 1463 France Telecom 1464 38-40 rue du General Leclerc 1465 Issy Moulineaux cedex 9 92794 1466 France 1468 Email: bruno.decraene@orange.com 1470 Kishore Tiruveedhula 1471 Juniper Networks 1472 10 Technology Park Drive 1473 Westford, Massachusetts 01886 1474 USA 1476 Phone: 1-(978)-589-8861 1477 Email: kishoret@juniper.net 1479 Maciek Konstantynowicz 1480 Cisco Systems, Inc. 1481 10 New Square Park, Bedfont Lakes 1482 London 1483 United Kingdom 1485 Email: maciek@cisco.com 1487 Luca Martini 1488 Cisco Systems, Inc. 1489 9155 East Nichols Avenue, Suite 400 1490 Englewood, CO 80112 1491 USA 1493 Email: lmartini@cisco.com