idnits 2.17.1 draft-ietf-mpls-ldp-dod-09.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 (July 13, 2013) is 3933 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I1' is mentioned on line 792, but not defined == Missing Reference: 'I' is mentioned on line 792, but not defined == Missing Reference: 'V' is mentioned on line 799, but not defined == Missing Reference: 'U2' is mentioned on line 799, but not defined == Missing Reference: 'Y' is mentioned on line 799, but not defined == Missing Reference: 'U' is mentioned on line 799, but not defined ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-07) exists of draft-ietf-karp-isis-analysis-00 == Outdated reference: A later version (-10) exists of draft-ietf-mpls-ldp-hello-crypto-auth-01 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-seamless-mpls-03 -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Beckhaus, Ed. 3 Internet-Draft Deutsche Telekom AG 4 Intended status: Standards Track B. Decraene 5 Expires: January 14, 2014 Orange 6 K. Tiruveedhula 7 Juniper Networks 8 M. Konstantynowicz, Ed. 9 L. Martini 10 Cisco Systems, Inc. 11 July 13, 2013 13 LDP Downstream-on-Demand in Seamless MPLS 14 draft-ietf-mpls-ldp-dod-09 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 January 14, 2014. 55 Copyright Notice 57 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Reference Topologies . . . . . . . . . . . . . . . . . . . . 4 74 2.1. Access Topologies with Static Routing . . . . . . . . . . 5 75 2.2. Access Topologies with Access IGP . . . . . . . . . . . . 7 76 3. LDP DoD Use Cases . . . . . . . . . . . . . . . . . . . . . . 9 77 3.1. Initial Network Setup . . . . . . . . . . . . . . . . . . 9 78 3.1.1. AN with Static Routing . . . . . . . . . . . . . . . 9 79 3.1.2. AN with Access IGP . . . . . . . . . . . . . . . . . 11 80 3.2. Service Provisioning and Activation . . . . . . . . . . . 11 81 3.3. Service Changes and Decommissioning . . . . . . . . . . . 14 82 3.4. Service Failure . . . . . . . . . . . . . . . . . . . . . 14 83 3.5. Network Transport Failure . . . . . . . . . . . . . . . . 15 84 3.5.1. General Notes . . . . . . . . . . . . . . . . . . . . 15 85 3.5.2. AN Node Failure . . . . . . . . . . . . . . . . . . . 15 86 3.5.3. AN/AGN Link Failure . . . . . . . . . . . . . . . . . 16 87 3.5.4. AGN Node Failure . . . . . . . . . . . . . . . . . . 17 88 3.5.5. AGN Network-side Reachability Failure . . . . . . . . 18 89 4. LDP DoD Procedures . . . . . . . . . . . . . . . . . . . . . 18 90 4.1. LDP Label Distribution Control and Retention Modes . . . 19 91 4.2. LDP DoD Session Negotiation . . . . . . . . . . . . . . . 20 92 4.3. Label Request Procedures . . . . . . . . . . . . . . . . 21 93 4.3.1. Access LSR/ABR Label Request . . . . . . . . . . . . 21 94 4.3.2. Label Request Retry . . . . . . . . . . . . . . . . . 22 95 4.4. Label Withdraw . . . . . . . . . . . . . . . . . . . . . 23 96 4.5. Label Release . . . . . . . . . . . . . . . . . . . . . . 24 97 4.6. Local Repair . . . . . . . . . . . . . . . . . . . . . . 24 98 5. LDP Extension for LDP DoD Fast-Up Convergence . . . . . . . . 24 99 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 100 6.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . 26 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 102 7.1. LDP DoD Native Security Properties . . . . . . . . . . . 27 103 7.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 28 104 7.3. Control Plane Security . . . . . . . . . . . . . . . . . 29 105 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 106 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 107 9.1. Normative References . . . . . . . . . . . . . . . . . . 30 108 9.2. Informative References . . . . . . . . . . . . . . . . . 30 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 111 1. Introduction 113 Seamless MPLS design [I-D.ietf-mpls-seamless-mpls] enables a single 114 IP/MPLS network to scale over core, metro and access parts of a large 115 packet network infrastructure using standardized IP/MPLS protocols. 116 One of the key goals of Seamless MPLS is to meet requirements 117 specific to access, including high number of devices, their position 118 in network topology and their compute and memory constraints that 119 limit the amount of state access devices can hold. 121 In general MPLS Label Switching Routers implement either LDP or RSVP 122 for MPLS label distribution. 124 The focus of this document is on LDP, as Seamless MPLS design does 125 not include a requirement for general purpose explicit traffic 126 engineering and bandwidth reservation. Document concentrates on the 127 unicast connectivity only. Multicast connectivity is subject for 128 further study. 130 In Seamless MPLS design [I-D.ietf-mpls-seamless-mpls], IP/MPLS 131 protocol optimization is possible due to a relatively simple access 132 network topologies. Examples of such topologies involving access 133 nodes (AN) and aggregation nodes (AGN) include: 135 a. A single AN homed to a single AGN. 137 b. A single AN dual-homed to two AGNs. 139 c. Multiple ANs daisy-chained via a hub-AN to a single AGN. 141 d. Multiple ANs daisy-chained via a hub-AN to two AGNs. 143 e. Two ANs dual-homed to two AGNs. 145 f. Multiple ANs chained in a ring and dual-homed to two AGNs. 147 The amount of IP RIB and FIB state on ANs can be easily controlled in 148 the listed access topologies by using simple IP routing configuration 149 with either static routes or dedicated access IGP. Note that in all 150 of the above topologies AGNs act as the access border routers (access 151 ABRs) connecting the access topology to the rest of the network. 152 Hence in many cases it is sufficient for ANs to have a default route 153 pointing towards AGNs in order to achieve complete network 154 connectivity from ANs to the network. 156 The amount of MPLS forwarding state however requires additional 157 consideration. In general MPLS routers implement LDP Downstream 158 Unsolicited (LDP DU) label advertisement [RFC5036] and advertise MPLS 159 labels for all valid routes in their RIB. This is seen as an 160 inadequate approach for ANs, which requires a small subset of the 161 total routes (and associated labels) based on the required 162 connectivity for the provisioned services. And although filters can 163 be applied to those LDP DU labels advertisements, it is not seen as a 164 suitable tool to facilitate any-to-any AN-driven connectivity between 165 access and the rest of the MPLS network. 167 This document describes an access node driven "subscription model" 168 for label distribution in the access. The approach relies on the 169 standard LDP Downstream-on-Demand (LDP DoD) label advertisements as 170 specified in [RFC5036]. LDP DoD enables on-demand label distribution 171 ensuring that only required labels are requested, provided and 172 installed. Procedures described in this document are equally 173 applicable to LDP IPv4 and IPv6 address families. For simplicity the 174 document provides examples based on LDP IPv4 address family. 176 The following sections describe a set of reference access topologies 177 considered for LDP DoD usage and their associated IP routing 178 configurations, followed by LDP DoD use cases and LDP DoD procedures 179 in the context of Seamless MPLS design. 181 2. Reference Topologies 183 LDP DoD use cases are described in the context of a generic reference 184 end-to-end network topology based on Seamless MPLS design 185 [I-D.ietf-mpls-seamless-mpls] shown in Figure 1 187 +-------+ +-------+ +------+ +------+ 188 ---+ AGN11 +--+ AGN21 +--+ ABR1 +--+ LSR1 +--> to LSR/AGN 189 +--------+/ +-------+ +-------+ +------+ +------+ 190 | Access | \/ \/ 191 | Network| /\ /\ 192 +--------+ +-------+ +-------+ +------+ +------+ 193 \---+ AGN12 +--+ AGN22 +--+ ABR2 +--+ LSR2 +--> to LSR/AGN 194 +-------+ +-------+ +------+ +------+ 196 static routes 197 or access IGP IGP area IGP area 198 <----Access----><--Aggregation Domain--><----Core-----> 199 <------------------------- MPLS ----------------------> 201 Figure 1: Seamless MPLS end-to-end reference network topology. 203 The access network is either single or dual homed to AGN1x, with 204 either a single or multiple parallel links to AGN1x. 206 Seamless MPLS access network topologies can range from a single- or 207 dual-homed access node to a chain or ring of access nodes, and use 208 either static routing or access IGP ( ISIS or OSPF ). The following 209 sections describe reference access topologies in more detail. 211 2.1. Access Topologies with Static Routing 213 In most cases access nodes connect to the rest of the network using 214 very simple topologies. Here static routing is sufficient to provide 215 the required IP connectivity. The following topologies are 216 considered for use with static routing and LDP DoD: 218 a. [I1] topology - a single AN homed to a single AGN. 220 b. [I] topology - multiple ANs daisy-chained to a single AGN. 222 c. [V] topology - a single AN dual-homed to two AGNs. 224 d. [U2] topology - two ANs dual-homed to two AGNs. 226 e. [Y] topology - multiple ANs daisy-chained to two AGNs. 228 The reference static routing and LDP configuration for [V] access 229 topology is shown in Figure 2. The same static routing and LDP 230 configuration also applies to [I1] topology. 232 +----+ +-------+ 233 |AN1 +------------------------+ AGN11 +------- 234 | +-------\ /-----------+ +-\ / 235 +----+ \ / +-------+ \ / 236 \/ \/ 237 /\ /\ 238 +----+ / \ +-------+ / \ 239 |AN2 +-------/ \-----------+ AGN12 +-/ \ 240 | +------------------------+ +------- 241 +----+ +-------+ 243 --(u)-> <-(d)-- 245 <----- static routing -------> <--- IGP ----> 246 <-- LDP DU --> 247 <--------- LDP DoD ----------> <-- BGP LU --> 249 (u) static routes: 0/0 default, (optional) /32 routes 250 (d) static routes: AN loopbacks 252 Figure 2: [V] access topology with static routes. 254 In line with the Seamless MPLS design, static routes configured on 255 AGN1x and pointing towards the access network are redistributed in 256 either IGP or BGP labeled unicast (BGP-LU) [RFC3107]. 258 The reference static routing and LDP configuration for [U2] access 259 topology is shown in Figure 3. 261 +----+ +-------+ 262 (d1) |AN1 +------------------------+ AGN11 +------- 263 | | + + +-\ / 264 v +-+--+ +-------+ \ / 265 | \/ 266 | /\ 267 ^ +-+--+ +-------+ / \ 268 | |AN2 + + AGN12 +-/ \ 269 (d2) | +------------------------+ +------- 270 +----+ +-------+ 272 --(u)-> <-(d)-- 274 <------- static routing --------> <--- IGP ----> 275 <-- LDP DU --> 276 <----------- LDP DoD -----------> <-- BGP LU --> 278 (u) static route 0/0 default, (optional) /32 routes 279 (d) static route for AN loopbacks 280 (d1) static route for AN2 loopback and 0/0 default with 281 lower preference 282 (d2) static route for AN1 loopback and 0/0 default with 283 lower preference 285 Figure 3: [U2] access topology with static routes. 287 The reference static routing and LDP configuration for [Y] access 288 topology is shown in Figure 4. The same static routing and LDP 289 configuration also applies to [I] topology. 291 +-------+ 292 | |---/ 293 /----+ AGN11 | 294 +----+ +----+ +----+ / | |---\ 295 | | | | | +----/ +-------+ 296 |ANn +...|AN2 +---+AN1 | 297 | | | | | +----\ +-------+ 298 +----+ +----+ +----+ \ | |---/ 299 \----+ AGN12 | 300 <-(d2)-- <-(d1)-- | |---\ 301 --(u)-> --(u)-> --(u)-> +-------+ 302 <-(d)-- 304 <------- static routing -------> <--- IGP ----> 305 <-- LDP DU --> 306 <---------- LDP DoD -----------> <-- BGP LU --> 308 (u) static routes: 0/0 default, (optional) /32 routes 309 (d) static routes: AN loopbacks [1..n] 310 (d1) static routes: AN loopbacks [2..n] 311 (d2) static routes: AN loopbacks [3..n] 313 Figure 4: [Y] access topology with static routes. 315 Note that in all of the above topologies parallel ECMP (or L2 LAG) 316 links can be used between the nodes. 318 ANs support Inter-area LDP [RFC5283] in order to use the IP default 319 route to match the LDP FEC advertised by AGN1x and other ANs. 321 2.2. Access Topologies with Access IGP 323 A dedicated access IGP instance is used in the access network to 324 perform the internal routing between AGN1x and connected AN devices. 325 Example of such IGP could be ISIS, OSPFv2&v3, RIPv2&RIPng. This 326 access IGP instance is distinct from the IGP of the aggegation 327 domain. 329 The following topologies are considered for use with access IGP 330 routing and LDP DoD: 332 a. [U] topology - multiple ANs chained in an open ring and dual- 333 homed to two AGNs. 335 b. [Y] topology - multiple ANs daisy-chained via a hub-AN to two 336 AGNs. 338 The reference access IGP and LDP configuration for [U] access 339 topology is shown in Figure 5. 341 +-------+ 342 +-----+ +-----+ +----+ | +---/ 343 | AN3 |---| AN2 |---|AN1 +-----+ AGN11 | 344 +-----+ +-----+ +----+ | +---\ 345 . +-------+ 346 . 347 . +-------+ 348 +-----+ +-----+ +----+ | +---/ 349 |ANn-2|---|ANn-1|---|ANn +-----+ AGN12 | 350 +-----+ +-----+ +----+ | +---\ 351 +-------+ 353 <---------- access IGP ------------> <--- IGP ----> 354 <-- LDP DU --> 355 <------------ LDP DoD -------------> <-- BGP LU --> 357 Figure 5: [U] access topology with access IGP. 359 The reference access IGP and LDP configuration for [Y] access 360 topology is shown in Figure 6. 362 +-------+ 363 | |---/ 364 /----+ AGN11 |2 365 +----+ +----+ +----+ / | |---\ 366 | | | | | +----/ +-------+ 367 |ANn +...|AN2 +---+AN1 | 368 | | | | | +----\ +-------+ 369 +----+ +----+ +----+ \ | |---/ 370 \----+ AGN12 | 371 | |---\ 372 +-------+ 374 <---------- access IGP ------------> <--- IGP ----> 375 <-- LDP DU --> 376 <------------ LDP DoD -------------> <-- BGP LU --> 378 Figure 6: [Y] access topology with access IGP. 380 Note that in all of the above topologies parallel ECMP (or L2 LAG) 381 links can be used between the nodes. 383 In both of the above topologies, ANs (ANn ... AN1) and AGN1x share 384 the access IGP and advertise their IPv4 and IPv6 loopbacks and link 385 addresses. AGN1x advertise a default route into the access IGP. 387 ANs support Inter-area LDP [RFC5283] in order to use the IP default 388 route for matching the LDP FECs advertised by AGN1x or other ANs. 390 3. LDP DoD Use Cases 392 LDP DoD use cases described in this document are based on the 393 Seamless MPLS scenarios listed in Seamless MPLS design 394 [I-D.ietf-mpls-seamless-mpls]. This section illustrates these use 395 cases focusing on services provisioned on the access nodes and 396 clarifies expected LDP DoD operation on the AN and AGN1x devices. 397 Two representative service types are used to illustrate the service 398 use cases: MPLS PWE3 [RFC4447] and BGP/MPLS IPVPN [RFC4364]. 400 Described LDP DoD operations apply equally to all reference access 401 topologies described in Section 2. Operations that are specific to 402 certain access topologies are called out explicitly. 404 References to upstream and downstream nodes are made in line with the 405 definition of upstream and downstream LSR [RFC3031]. 407 LDP DoD procedures follow the LDP specification [RFC5036], and are 408 equally applicable to LDP IPv4 and IPv6 address families. For 409 simplicity examples are provided for LDP IPv4 address family only. 411 3.1. Initial Network Setup 413 An access node is commissioned without any services provisioned on 414 it. The AN can request labels for loopback addresses of any AN, AGN 415 or other nodes within Seamless MPLS network for operational and 416 management purposes. It is assumed that AGN1x has required IP/MPLS 417 configuration for network-side connectivity in line with Seamless 418 MPLS design [I-D.ietf-mpls-seamless-mpls]. 420 LDP sessions are configured between adjacent ANs and AGN1x using 421 their respective loopback addresses. 423 3.1.1. AN with Static Routing 425 If access static routing is used, ANs are provisioned with the 426 following static IP routing entries (topology references from 427 Section 2 are listed in square brackets): 429 a. [I1, V, U2] - Static default route 0/0 pointing to links 430 connected to AGN1x. Requires support for Inter-area LDP 431 [RFC5283]. 433 b. [U2] - Static /32 routes pointing to the other AN. Lower 434 preference static default route 0/0 pointing to links connected 435 to the other AN. Requires support for Inter-area LDP [RFC5283]. 437 c. [I, Y] - Static default route 0/0 pointing to links leading 438 towards AGN1x. Requires support for Inter-area LDP [RFC5283]. 440 d. [I, Y] - Static /32 routes to all ANs in the daisy-chain pointing 441 to links towards those ANs. 443 e. [I1, V, U2] - Optional - Static /32 routes for specific nodes 444 within Seamless MPLS network, pointing to links connected to 445 AGN1x. 447 f. [I, Y] - Optional - Static /32 routes for specific nodes within 448 the Seamless MPLS network, pointing to links leading towards 449 AGN1x. 451 Upstream AN/AGN1x requests labels over LDP DoD session(s) from 452 downstream AN/AGN1x for configured static routes if those static 453 routes are configured with LDP DoD request policy and if they are 454 pointing to a next-hop selected by routing. It is expected that all 455 configured /32 static routes to be used for LDP DoD are configured 456 with such policy on AN/AGN1x. 458 Downstream AN/AGN1x responds to the Label Request from the upstream 459 AN/AGN1x with a Label Mapping if requested route is present in its 460 RIB, and there is a valid label binding from its downstream or it is 461 the egress node. In such case downstream AN/AGN1x installs the 462 advertised label as an incoming label in its label table (LIB) and 463 its forwarding table (LFIB). Upstream AN/AGN1x also installs the 464 received label as an outgoing label in their LIB and LFIB. If the 465 downstream AN/AGN1x does have the route present in its RIB, but does 466 not have a valid label binding from its downstream, it forwards the 467 request to its downstream. 469 In order to facilitate ECMP and IPFRR LFA local-repair, the upstream 470 AN/AGN1x also sends LDP DoD label requests to alternate next-hops per 471 its RIB, and install received labels as alternate entries in its LIB 472 and LFIB. 474 AGN1x node on the network side can use BGP labeled unicast [RFC3107] 475 in line with the Seamless MPLS design [I-D.ietf-mpls-seamless-mpls]. 476 In such a case AGN1x will be redistributing its static routes 477 pointing to local ANs into BGP labeled unicast to facilitate network- 478 to-access traffic flows. Likewise, to facilitate access-to-network 479 traffic flows, AGN1x will be responding to access-originated LDP DoD 480 label requests with label mappings based on its BGP labeled unicast 481 reachability for requested FECs. 483 3.1.2. AN with Access IGP 485 If access IGP is used, AN(s) advertise their loopbacks over the 486 access IGP with configured metrics. AGN1x advertise a default route 487 over the access IGP. 489 Routers request labels over LDP DoD session(s) according to their 490 needs for MPLS connectivity (LSPs). In particular if AGNs, as per 491 Seamless MPLS design [I-D.ietf-mpls-seamless-mpls], redistribute 492 routes from the IGP into BGP labeled unicast [RFC3107], they request 493 labels over LDP DoD session(s) for those routes. 495 Identically to the static route case, downstream AN/AGN1x responds to 496 the Label Request from the upstream AN/AGN1x with a Label Mapping (if 497 the requested route is present in its RIB, and there is a valid label 498 binding from its downstream), and installs the advertised label as an 499 incoming label in its LIB and LFIB. Upstream AN/AGN1x also installs 500 the received label as an outgoing label in their LIB and LFIB. 502 Identically to the static route case, in order to facilitate ECMP and 503 IPFRR LFA local-repair, upstream AN/AGN1x also sends LDP DoD label 504 requests to alternate next-hops per its RIB, and installs received 505 labels as alternate entries in its LIB and LFIB. 507 AGN1x node on the network side can use BGP labeled unicast [RFC3107] 508 in line with Seamless MPLS design [I-D.ietf-mpls-seamless-mpls]. In 509 such case AGN1x will be redistributing routes received over the 510 access IGP (and pointing to local ANs), into BGP labeled unicast to 511 facilitate network-to-access traffic flows. Likewise, to facilitate 512 access-to-network traffic flows AGN1x will be responding to access 513 originated LDP DoD label requests with label mappings based on its 514 BGP labeled unicast reachability for requested FECs. 516 3.2. Service Provisioning and Activation 518 Following the initial setup phase described in Section 3.1, a 519 specific access node, referred to as AN*, is provisioned with a 520 network service. AN* relies on LDP DoD to request the required MPLS 521 LSP(s) label(s) from downstream AN/AGN1x node(s). Note that LDP DoD 522 operations are service agnostic, that is, they are the same 523 independently of the services provisioned on the AN*. 525 For illustration purposes two service types are described: MPLS PWE3 526 [RFC4447] service and BGP/MPLS IPVPN [RFC4364]. 528 MPLS PWE3 service - for description simplicity it is assumed that a 529 single segment pseudowire is signaled using targeted LDP FEC128 530 (0x80), and it is provisioned with the pseudowire ID and the loopback 531 IPv4 address of the destination node. The following IP/MPLS 532 operations need to be completed on the AN* to successfully establish 533 such PWE3 service: 535 a. LSP labels for destination /32 FEC (outgoing label) and the local 536 /32 loopback (incoming label) need to be signaled using LDP DoD. 538 b. Targeted LDP session over an associated TCP/IP connection needs 539 to be established to the PWE3 destination PE. This is triggered 540 by either an explicit targeted LDP session configuration on the 541 AN* or automatically at the time of provisioning the PWE3 542 instance. 544 c. Local and remote PWE3 labels for specific FEC128 PW ID need to be 545 signaled using targeted LDP and PWE3 signaling procedures 546 [RFC4447]. 548 d. Upon successful completion of the above operations, AN* programs 549 its RIB/LIB and LFIB tables, and activates the MPLS PWE3 service. 551 Note - only minimum operations applicable to service connectivity 552 have been listed. Other non IP/MPLS connectivity operations that are 553 required for successful service provisioning and activation are out 554 of scope in this document. 556 BGP/MPLS IPVPN service - for description simplicity it is assumed 557 that AN* is provisioned with a unicast IPv4 IPVPN service (VPNv4 for 558 short) [RFC4364]. The following IP/MPLS operations need to be 559 completed on the AN* to successfully establish VPNv4 service: 561 a. BGP peering sessions with associated TCP/IP connections need to 562 be established with the remote destination VPNv4 PEs or Route 563 Reflectors. 565 b. Based on configured BGP policies, VPNv4 BGP NLRIs need to be 566 exchanged between AN* and its BGP peers. 568 c. Based on configured BGP policies, VPNv4 routes need to be 569 installed in the AN* VRF RIB and FIB, with corresponding BGP 570 next-hops. 572 d. LSP labels for destination BGP next-hop /32 FEC (outgoing label) 573 and the local /32 loopback (incoming label) need to be signaled 574 using LDP DoD. 576 e. Upon successful completion of above operations, AN* programs its 577 RIB/LIB and LFIB tables, and activates the BGP/MPLS IPVPN 578 service. 580 Note - only minimum operations applicable to service connectivity 581 have been listed. Other non IP/MPLS connectivity operations that are 582 required for successful service provisioning are out of scope in this 583 document. 585 To establish an LSP for destination /32 FEC for any of the above 586 services, AN* looks up its local routing table for a matching route, 587 selects the best next-hop(s) and associated outgoing link(s). 589 If a label for this /32 FEC is not already installed based on the 590 configured static route with LDP DoD request policy or access IGP RIB 591 entry, AN* sends an LDP DoD Label Mapping request. Downstream AN/ 592 AGN1x LSR(s) checks its RIB for presence of the requested /32 and 593 associated valid outgoing label binding, and if both are present, 594 replies with its label for this FEC and installs this label as 595 incoming in its LIB and LFIB. Upon receiving the Label Mapping the 596 AN* accepts this label based on the exact route match of advertised 597 FEC and route entry in its RIB or based on the longest match in line 598 with Inter-area LDP [RFC5283]. If the AN* accepts the label it 599 installs it as an outgoing label in its LIB and LFIB. 601 In access topologies [V] and [Y], if AN* is dual homed to two AGN1x 602 and routing entries for these AGN1x are configured as equal cost 603 paths, AN* sends LDP DoD label requests to both AGN1x devices and 604 install all received labels in its LIB and LFIB. 606 In order for AN* to implement IPFRR LFA local-repair, AN* also sends 607 LDP DoD label requests to alternate next-hops per its RIB, and 608 install received labels as alternate entries in its LIB and LFIB. 610 When forwarding PWE3 or VPNv4 packets AN* chooses the LSP label based 611 on the locally configured static /32 or default route, or default 612 route signaled via access IGP. If a route is reachable via multiple 613 interfaces to AGN1x nodes and the route has multiple equal cost 614 paths, AN* implements Equal Cost Multi-Path (ECMP) functionality. 615 This involves AN* using hash-based load-balancing mechanism and 616 sending the PWE3 or VPNv4 packets in a flow-aware manner with 617 appropriate LSP labels via all equal cost links. 619 ECMP mechanism is applicable in an equal manner to parallel links 620 between two network elements and multiple paths towards the 621 destination. The traffic demand is distributed over the available 622 paths. 624 AGN1x node on the network side can use BGP labeled unicast [RFC3107] 625 in line with Seamless MPLS design [I-D.ietf-mpls-seamless-mpls]. In 626 such case AGN1x will be redistributing its static routes (or routes 627 received from the access IGP) pointing to local ANs into BGP labeled 628 unicast to facilitate network-to-access traffic flows. Likewise, to 629 facilitate access-to-network traffic flows AGN1x will be responding 630 to access originated LDP DoD label requests with label mappings based 631 on its BGP labeled unicast reachability for requested FECs. 633 3.3. Service Changes and Decommissioning 635 Whenever AN* service gets decommissioned or changed and connectivity 636 to specific destination is not longer required, the associated MPLS 637 LSP label resources are to be released on AN*. 639 MPLS PWE3 service - if the PWE3 service gets decommissioned and it is 640 the last PWE3 to a specific destination node, the targeted LDP 641 session is not longer needed and is to be terminated (automatically 642 or by configuration). The MPLS LSP(s) to that destination is no 643 longer needed either. 645 BGP/MPLS IPVPN service - deletion of a specific VPNv4 (VRF) instance, 646 local or remote re-configuration can result in specific BGP next- 647 hop(s) being no longer needed. The MPLS LSP(s) to that destination 648 is no longer needed either. 650 In all of the above cases the following LDP DoD related operations 651 apply: 653 o If the /32 FEC label for the aforementioned destination node was 654 originally requested based on either tLDP session configuration 655 and default route or required BGP next-hop and default route, AN* 656 deletes the label from its LIB and LFIB, and release it from 657 downstream AN/AGN1x by using LDP DoD procedures. 659 o If the /32 FEC label was originally requested based on the static 660 /32 route configuration with LDP DoD request policy, the label is 661 retained by AN*. 663 3.4. Service Failure 665 A service instance can stop being operational due to a local or 666 remote service failure event. 668 In general, unless the service failure event modifies required MPLS 669 connectivity, there is no impact on the LDP DoD operation. 671 If the service failure event does modify the required MPLS 672 connectivity, LDP DoD operations apply as described in Section 3.2 673 and Section 3.3. 675 3.5. Network Transport Failure 677 A number of different network events can impact services on AN*. The 678 following sections describe network event types that impact LDP DoD 679 operation on AN and AGN1x nodes. 681 3.5.1. General Notes 683 If service on any of the ANs is affected by any network failure and 684 there is no network redundancy, the service goes into a failure 685 state. When the network failure is recovered from, the service is to 686 be re-established automatically. 688 The following additional LDP-related functions need to be supported 689 to comply with Seamless MPLS [I-D.ietf-mpls-seamless-mpls] fast 690 service restoration requirements as follows: 692 a. Local-repair - AN and AGN1x support local-repair for adjacent 693 link or node failure for access-to-network, network-to-access and 694 access-to-access traffic flows. Local-repair is to be 695 implemented by using either IPFRR LDP LFA, simple ECMP or primary 696 /backup switchover upon failure detection. 698 b. LDP session protection - LDP sessions are configured with LDP 699 session protection to avoid delay upon the recovery from link 700 failure. LDP session protection ensures that FEC label binding 701 is maintained in the control plane as long as LDP session stays 702 up. 704 c. IGP-LDP synchronization - If access IGP is used, LDP sessions 705 between ANs, and between ANs and AGN1x, are configured with IGP- 706 LDP synchronization to avoid unnecessary traffic loss in case the 707 access IGP converged before LDP and there is no LDP label binding 708 to the downstream best next-hop. 710 3.5.2. AN Node Failure 712 AN node fails and all links to adjacent nodes go down. 714 Adjacent AN/AGN1x nodes remove all routes pointing to the failed 715 link(s) from their RIB tables (including /32 loopback belonging to 716 the failed AN and any other routes reachable via the failed AN). 717 This in turn triggers the removal of associated outgoing /32 FEC 718 labels from their LIB and LFIB tables. 720 If access IGP is used, the AN node failure will be propagated via IGP 721 link updates across the access topology. 723 If a specific /32 FEC(s) is not reachable anymore from those AN/ 724 AGN1x, they also send LDP Label Withdraw to their upstream LSRs to 725 notify about the failure, and remove the associated incoming label(s) 726 from their LIB and LFIB tables. Upstream LSRs upon receiving Label 727 Withdraw remove the signaled labels from their LIB/LFIB tables, and 728 propagate LDP Label Withdraw across their upstream LDP DoD sessions. 730 In [U] topology there may be an alternative path to routes previously 731 reachable via the failed AN node. In this case adjacent AN/AGN1x 732 invoke local-repair (IPFRR LFA, ECMP) and switchover to alternate 733 next-hop to reach those routes. 735 AGN1x gets notified about the AN failure via either access IGP (if 736 used) and/or cascaded LDP DoD label withdraw(s). AGN1x implements 737 all relevant global-repair IP/MPLS procedures to propagate the AN 738 failure towards the core network. This involves removing associated 739 routes (in access IGP case) and labels from its LIB and LFIB tables, 740 and propagating the failure on the network side using BGP-LU and/or 741 core IGP/LDP-DU procedures. 743 Upon AN coming back up, adjacent AN/AGN1x nodes automatically add 744 routes pointing to recovered links based on the configured static 745 routes or access IGP adjacency and link state updates. This is then 746 followed by LDP DoD label signaling and subsequent binding and 747 installation of labels in LIB and LFIB tables. 749 3.5.3. AN/AGN Link Failure 751 Depending on the access topology and the failed link location 752 different cases apply to the network operation after AN link failure 753 (topology references from Section 2 in square brackets): 755 a. [all] - link failed, but at least one ECMP parallel link remains 756 - nodes on both sides of the failed link stop using the failed 757 link immediately (local-repair), and keep using the remaining 758 ECMP parallel links. 760 b. [I1, I, Y] - link failed, and there are no ECMP or alternative 761 links and paths - nodes on both sides of the failed link remove 762 routes pointing to the failed link immediately from the RIB, 763 remove associated labels from their LIB and LFIB tabels, and send 764 LDP label withdraw(s) to their upstream LSRs. 766 c. [U2, U, V, Y] - link failed, but at least one ECMP or alternate 767 path remains - AN/AGN1x node stops using the failed link and 768 immediately switchover (local-repair) to the remaining ECMP path 769 or alternate path. AN/AGN1x removes affected next-hops and 770 labels from its tables and invoke LDP Label Withdraw as per point 771 (a) above. If there is an AGN1x node terminating the failed 772 link, it removes routes pointing to the failed link immediately 773 from the RIB, remove associated labels from their LIB and LFIB 774 tabels, and propagate the failure on the network side using BGP- 775 LU and/or core IGP procedures. 777 If access IGP is used AN/AGN1x link failure will be propagated via 778 IGP link updates across the access topology. 780 LDP DoD will also propagate the link failure by sending label 781 withdraws to upstream AN/AGN1x nodes, and Label Release messages 782 downstream AN/AGN1x nodes. 784 3.5.4. AGN Node Failure 786 AGN1x fails and all links to adjacent access nodes go down. 788 Depending on the access topology, following cases apply to the 789 network operation after AGN1x node failure (topology references from 790 Section 2 in square brackets): 792 a. [I1, I] - ANs are isolated from the network - AN adjacent to the 793 failure removes routes pointing to the failed AGN1x node 794 immediately from the RIB, removes associated labels from their 795 LIB and LFIB tabels, and sends LDP label withdraw(s) to their 796 upstream LSRs. If access IGP is used, an IGP link update is 797 sent. 799 b. [U2, U, V, Y] - at least one ECMP or alternate path remains - AN 800 adjacent to failed AGN1x stops using the failed link and 801 immediately switchover (local-repair) to the remaining ECMP path 802 or alternate path. AN removes affected routes and labels from 803 its tables and invoke LDP Label Withdraw as per point (a) above. 805 Network side procedures for handling AGN1x node failure have been 806 described in Seamless MPLS [I-D.ietf-mpls-seamless-mpls]. 808 3.5.5. AGN Network-side Reachability Failure 810 AGN1x loses network reachability to a specific destination or set of 811 network-side destinations. 813 In such event AGN1x sends LDP Label Withdraw messages to its upstream 814 ANs, withdrawing labels for all affected /32 FECs. Upon receiving 815 those messages ANs remove those labels from their LIB and LFIB 816 tables, and use alternative LSPs instead if available as part of 817 global-repair. In turn ANs also send Label Withdraw messages for 818 affected /32 FECs to their upstream ANs. 820 If access IGP is used, and AGN1x gets completely isolated from the 821 core network, it stops advertising the default route 0/0 into the 822 access IGP. 824 4. LDP DoD Procedures 826 Label Distribution Protocol is specified in [RFC5036], and all LDP 827 Downstream-on-Demand implementations follow [RFC5036] specification. 828 This section does not update [RFC5036] procedures, but illustrates 829 LDP DoD operations in the context of use cases identified in 830 Section 3 in this document, for information only. 832 In the MPLS architecture [RFC3031], network traffic flows from 833 upstream to downstream LSR. The use cases in this document rely on 834 the downstream assignment of labels, where labels are assigned by the 835 downstream LSR and signaled to the upstream LSR as shown in Figure 7. 837 +----------+ +------------+ 838 | upstream | | downstream | 839 ------+ LSR +------+ LSR +---- 840 traffic | | | | address 841 source +----------+ +------------+ (/32 for IPv4) 842 traffic 843 label distribution for IPv4 FEC destination 844 <------------------------- 846 traffic flow 847 -------------------------> 849 Figure 7: LDP label assignment direction 851 4.1. LDP Label Distribution Control and Retention Modes 853 LDP protocol specification [RFC5036] defines two modes for label 854 distribution control, following the definitions in MPLS architecture 855 [RFC3031]: 857 o Independent mode - an LSR recognizes a particular FEC and makes a 858 decision to bind a label to the FEC independently from 859 distributing that label binding to its label distribution peers. 860 A new FEC is recognized whenever a new route becomes valid on the 861 LSR. 863 o Ordered mode - an LSR needs to bind a label to a particular FEC if 864 it knows how to forward packets for that FEC ( i.e. it has a route 865 corresponding to that FEC ) and if it has already received at 866 least one Label Request message from an upstream LSR. 868 Using independent label distribution control with LDP DoD and access 869 static routing would prevent the access LSRs from propagating label 870 binding failure along the access topology, making it impossible for 871 upstream LSR to be notified about the downstream failure and for an 872 application using the LSP to switchover to an alternate path, even if 873 such a path exists. 875 LDP protocol specification [RFC5036] defines two modes for label 876 retention, following the definitions in MPLS architecture [RFC3031]: 878 o Conservative mode - If operating in Downstream on Demand mode, an 879 LSR will request label mappings only from the next hop LSR 880 according to routing. The main advantage of the conservative mode 881 is that only the labels that are required for the forwarding of 882 data are allocated and maintained. This is particularly important 883 in LSRs where the label space is inherently limited, such as in an 884 ATM switch. A disadvantage of the conservative mode is that if 885 routing changes the next hop for a given destination, a new label 886 must be obtained from the new next hop before labeled packets can 887 be forwarded. 889 o Liberal mode - When operating in Downstream on Demand mode with 890 Liberal Label retention, an LSR might choose to request label 891 mappings for all known prefixes from all peer LSRs. The main 892 advantage of the Liberal Label retention mode is that reaction to 893 routing changes can be quick because labels already exist. The 894 main disadvantage of the liberal mode is that unneeded label 895 mappings are distributed and maintained. 897 Note that the conservative label retention mode would prevent LSRs 898 from requesting and maintaining label mappings for any backup routes 899 that are not used for forwarding. This in turn would prevent the 900 access LSRs (AN and AGN1x nodes) from implementing any local 901 protection schemes that rely on using alternate next-hops in case of 902 the primary next-hop failure. Such schemes include IPFRR LFA if 903 access IGP is used, or a primary and backup static route 904 configuration. Using LDP DoD in combination with liberal retention 905 mode allows the LSR to request labels for the specific FEC from 906 primary next-hop LSR(s) and the alternate next-hop LSR(s) for this 907 FEC. 909 Note that even though LDP DoD operates in a liberal retention mode, 910 if used with access IGP and if no LFA exists, the LDP DoD will 911 introduce additional delay in traffic restoration as the labels for 912 the new next-hop will get requested only after the access IGP 913 convergence. 915 Adhering to the overall design goals of Seamless MPLS 916 [I-D.ietf-mpls-seamless-mpls], specifically achieving a large network 917 scale without compromising fast service restoration, all access LSRs 918 (AN and AGN1x nodes) use LDP DoD advertisement mode with: 920 o Ordered label distribution control - enables propagation of label 921 binding failure within the access topology. 923 o Liberal label retention - enables pre-programming of alternate 924 next-hops with associated FEC labels. 926 In Seamless MPLS [I-D.ietf-mpls-seamless-mpls] AGN1x node acts as an 927 access ABR connecting access and metro domains. To enable failure 928 propagation between those domains, access ABR implements ordered 929 label distribution control when redistributing routes/FEC between the 930 access-side (using LDP DoD and static or access IGP) and the network- 931 side ( using BGP labeled unicast [RFC3107] or core IGP with LDP 932 Downstream Unsolicited label advertisement. 934 4.2. LDP DoD Session Negotiation 936 Access LSR/ABR propose the Downstream-on-Demand label advertisement 937 by setting "A" value to 1 in the Common Session Parameters TLV of the 938 Initialization message. The rules for negotiating the label 939 advertisement mode are specified in LDP protocol specification 940 [RFC5036]. 942 To establish a Downstream-on-Demand session between the two access 943 LSR/ABRs, both propose the Downstream-on-Demand label advertisement 944 mode in the Initialization message. If the access LSR only supports 945 LDP DoD and the access ABR proposes Downstream Unsolicited mode, the 946 access LSR sends a Notification message with status "Session Rejected 947 /Parameters Advertisement Mode" and then close the LDP session as 948 specified in LDP protocol specification [RFC5036]. 950 If an access LSR is acting in an active role, it re-attempts the LDP 951 session immediately. If the access LSR receives the same Downstream 952 Unsolicited mode again, it follows the exponential backoff algorithm 953 as defined in the LDP protocol specification [RFC5036] with delay of 954 15 seconds and subsequent delays growing to a maximum delay of 2 955 minutes. 957 In case a PWE3 service is required between the adjacent access LSR/ 958 ABR, and LDP DoD has been negotiated for IPv4 and IPv6 FECs, the same 959 LDP session is used for PWE3 FECs. Even if LDP DoD label 960 advertisement has been negotiated for IPv4 and IPv6 LDP FECs as 961 described earlier, LDP session uses Downstream Unsolicited label 962 advertisement for PWE3 FECs as specified in PWE3 LDP [RFC4447]. 964 4.3. Label Request Procedures 966 4.3.1. Access LSR/ABR Label Request 968 Upstream access LSR/ABR will request label bindings from adjacent 969 downstream access LSR/ABR based on the following trigger events: 971 a. Access LSR/ABR is configured with /32 static route with LDP DoD 972 Label Request policy in line with initial network setup use case 973 described in Section 3.1. 975 b. Access LSR/ABR is configured with a service in line with service 976 use cases described in Section 3.2 and Section 3.3. 978 c. Configuration with access static routes - Access LSR/ABR link to 979 adjacent node comes up and LDP DoD session is established. In 980 this case access LSR sends Label Request messages for all /32 981 static routes configured with LDP DoD policy and all /32 routes 982 related to provisioned services that are covered by default 983 route. 985 d. Configuration with access IGP - Access LSR/ABR link to adjacent 986 node comes up and LDP DoD session is established. In this case 987 access LSR sends Label Request messages for all /32 routes 988 learned over the access IGP and all /32 routes related to 989 provisioned services that are covered by access IGP routes. 991 e. In all above cases requests are sent to next-hop LSR(s) and 992 alternate LSR(s). 994 Downstream access LSR/ABR will respond with Label Mapping message 995 with a non-null label if any of the below conditions are met: 997 a. Downstream access LSR/ABR - requested FEC is an IGP or static 998 route and there is an LDP label already learnt from the next- 999 next-hop downstream LSR (by LDP DoD or LDP DU). If there is no 1000 label for the requested FEC and there is an LDP DoD session to 1001 the next-next-hop downstream LSR, downstream LSR sends a Label 1002 Request message for the same FEC to the next-next-hop downstream 1003 LSR. In such case downstream LSR will respond back to the 1004 requesting upstream access LSR only after getting a label from 1005 the next-next-hop downstream LSR peer. 1007 b. Downstream access ABR only - requested FEC is a BGP labelled 1008 unicast route [RFC3107] and this BGP route is the best selected 1009 for this FEC. 1011 Downstream access LSR/ABR can respond with a Label Mapping with 1012 explicit-null or implicit-null label if it is acting as an egress for 1013 the requested FEC, or it can respond with "No Route" notification if 1014 no route exists. 1016 4.3.2. Label Request Retry 1018 Following LDP specification LDP specification [RFC5036], if an access 1019 LSR/ABR receives a "No route" Notification in response to its Label 1020 Request message, it retries using an exponential backoff algorithm 1021 similar to the backoff algoritm mentioned in the LDP session 1022 negotiation described in Section 4.2. 1024 If there is no response to the sent Label Request message, the LDP 1025 specification [RFC5036] (section A.1.1, page# 100) states that the 1026 LSR does not send another request for the same label to the peer and 1027 mandates that a duplicate Label Request is considered a protocol 1028 error and is dropped by the receiving LSR by sending a Notification 1029 message. 1031 Thus, if there is no response from the downstream peer, the access 1032 LSR/ABR does not send a duplicate Label Request message again. 1034 If the static route corresponding to the FEC gets deleted or if the 1035 DoD request policy is modified to reject the FEC before receiving the 1036 Label Mapping message, then the access LSR/ABR sends a Label Abort 1037 message to the downstream LSR. 1039 To address the case of slower convergence resulting from described 1040 LDP behavior in line with LDP specification [RFC5036], a new LDP TLV 1041 extension is proposed and described in Section 5. 1043 4.4. Label Withdraw 1045 If an MPLS label on the downstream access LSR/ABR is no longer valid, 1046 the downstream access LSR/ABR withdraws this FEC/label binding from 1047 the upstream access LSR/ABR with the Label Withdraw Message [RFC5036] 1048 with a specified label TLV or with an empty label TLV. 1050 Downstream access LSR/ABR withdraws a label for specific FEC in the 1051 following cases: 1053 a. If LDP DoD ingress label is associated with an outgoing label 1054 assigned by BGP labelled unicast route, and this route is 1055 withdrawn. 1057 b. If LDP DoD ingress label is associated with an outgoing label 1058 assigned by LDP (DoD or DU) and the IGP route is withdrawn from 1059 the RIB or downstream LDP session is lost. 1061 c. If LDP DoD ingress label is associated with an outgoing label 1062 assigned by LDP (DoD or DU) and the outgoing label is withdrawn 1063 by the downstream LSR. 1065 d. If LDP DoD ingress label is associated with an outgoing label 1066 assigned by LDP (DoD or DU), route next-hop changed and 1068 * there is no LDP session to the new next-hop. To minimize 1069 probability of this, the access LSR/ABR implements LDP-IGP 1070 synchronization procedures as specified in [RFC5443]. 1072 * there is an LDP session but no label from downstream LSR. See 1073 note below. 1075 e. If access LSR/ABR is configured with a policy to reject exporting 1076 label mappings to upstream LSR. 1078 The upstream access LSR/ABR responds to the Label Withdraw Message 1079 with the Label Release Message [RFC5036]. 1081 After sending Label Release message to downstream access LSR/ABR, the 1082 upstream access LSR/ABR resends Label Request message, assuming 1083 upstream access LSR/ABR still requires the label. 1085 Downstream access LSR/ABR withdraws a label if the local route 1086 configuration (e.g. /32 loopback) is deleted. 1088 Note: For any events inducing next hop change, downstream access LSR/ 1089 ABR is to attempt to converge the LSP locally before withdrawing the 1090 label from an upstream access LSR/ABR. For example if the next-hop 1091 changes for a particular FEC and if the new next-hop allocates labels 1092 by LDP DoD session, then the downstream access LSR/ABR sends a Label 1093 Request on the new next-hop session. If downstream access LSR/ABR 1094 doesn't get Label Mapping for some duration, then and only then 1095 downstream access LSR/ABR withdraws the upstream label. 1097 4.5. Label Release 1099 If an access LSR/ABR does not need any longer a label for a FEC, it 1100 sends a Label Release Message [RFC5036] to the downstream access LSR/ 1101 ABR with or without the label TLV. 1103 If upstream access LSR/ABR receives an unsolicited Label Mapping on 1104 DoD session, they release the label by sending Label Release message. 1106 Access LSR/ABR sends a Label Release message to the downstream LSR in 1107 the following cases: 1109 a. If it receives a Label Withdraw from the downstream access LSR/ 1110 ABR. 1112 b. If the /32 static route with LDP DoD Label Request policy is 1113 deleted. 1115 c. If the service gets decommissioned and there is no corresponding 1116 /32 static route with LDP DoD Label Request policy configured. 1118 d. If the route next-hop changed, and the label does not point to 1119 the best or alternate next-hop. 1121 e. If it receives a Label Withdraw from a downstream DoD session. 1123 4.6. Local Repair 1125 To support local-repair with ECMP and IPFRR LFA, access LSR/ABR 1126 requests labels on both the best next-hop and the alternate next-hop 1127 LDP DoD sessions, as specified in the Label Request procedures in 1128 Section 4.3. If remote LFA is enabled, access LSR/ABR needs a label 1129 from its alternate next-hop toward the PQ node and needs a label from 1130 the remote PQ node toward its FEC/destination. If access LSR/ABR 1131 doesn't already know those labels, it requests them. 1133 This will enable access LSR/ABR to pre-program the alternate 1134 forwarding path with the alternate label(s), and invoke IPFRR LFA 1135 switch-over procedure if the primary next-hop link fails. 1137 5. LDP Extension for LDP DoD Fast-Up Convergence 1138 In some conditions, the exponential backoff algorithm usage described 1139 in Section 4.3.2 can result in a longer than desired wait time to get 1140 a successful LDP label to route mapping. An example is when a 1141 specific route is unavailable on the downstream LSR when the Label 1142 Mapping request from the upstream is received, but later comes back. 1143 In such case using the exponential backoff algorithm can result in a 1144 max delay wait time before the upstream LSR sends another LDP Label 1145 Request. 1147 This section describes an extension to the LDP DoD procedure to 1148 address fast-up convergence, and as such is to be treated as a 1149 normative reference. The downstream and upstream LSRs SHOULD 1150 implement this extension if the improvement in up convergence is 1151 desired. 1153 The extension consists of the upstream LSR indicating to the 1154 downstream LSR that the Label Request SHOULD be queued on the 1155 downstream LSR until the requested route is available. 1157 To implement this behavior, a new Optional Parameter is defined for 1158 use in the Label Request message: 1160 Optional Parameter Length Value 1161 Queue Request TLV 0 see below 1163 0 1 2 3 1164 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 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 |1|0| Queue Request (0x0971) | Length (0x00) | 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 U-bit = 1 1170 Unknown TLV bit. Upon receipt of an unknown TLV, due to U-bit 1171 being set (=1), the unknown TLV MUST be silently ignored and the 1172 rest of the message processed as if the unknown TLV did not 1173 exist. In case requested route is not available, the downstream 1174 LSR MUST ignore this unknown TLV and send a "no route" 1175 notification back. Ensures backward compatibility. 1177 F-bit = 0 1178 Forward unknown TLV bit. This bit applies only when the U-bit is 1179 set and the LDP message containing the unknown TLV is to be 1180 forwarded. Due to F-bit being clear (=0), the unknown TLV is not 1181 forwarded with the containing message. 1183 Type 1184 Queue Request Type value to be allocated by IANA. 1186 Length = 0x00 1187 Specifies the length of the Value field in octets. 1189 Specified operation is as follows. 1191 To benefit from the fast-up convergence improvement, the upstream LSR 1192 sends a Label Request message with a Queue Request TLV. 1194 If the downstream LSR supports the Queue Request TLV, it verifies if 1195 route is available and if so it replies with Label Mapping as per 1196 existing LDP procedures. If the route is not available, the 1197 downstream LSR queues the request and replies as soon as the route 1198 becomes available. In the meantime, it does not send a "no route" 1199 notification back. When sending a Label Request with the Queue 1200 Request TLV, the upstream LSR does not retry the Label Request 1201 message if it does not receive a reply from its downstream peer 1203 If the upstream LSR wants to abort an outstanding Label Request while 1204 the Label Request is queued in the downstream LSR, the upstream LSR 1205 sends a Label Abort Request message, making the downstream LSR to 1206 remove the original request from the queue and send back a 1207 notification Label Request Aborted [RFC5036]. 1209 If the downstream LSR does not support the Queue Request TLV, and 1210 requested route is not available, it ignores this unknown TLV and 1211 sends a "no route" notification back in line with [RFC5036]. In this 1212 case the upstream LSR invokes the exponential backoff algorithm 1213 described in Section 4.3.2 following standard LDP specification LDP 1214 specification [RFC5036]. 1216 This described procedure ensures backward compatitibility. 1218 6. IANA Considerations 1220 6.1. LDP TLV TYPE 1222 This document uses a new a new Optional Parameter Queue Request TLV 1223 in the Label Request message defined in Section 5. IANA already 1224 maintains a registry of name LDP "TLV TYPE NAME SPACE" defined by 1225 RFC5036. The following value is suggested for assignment: 1227 TLV type Description 1228 0x0971 Queue Request TLV 1230 7. Security Considerations 1231 MPLS LDP Downstream on Demand deployment in the access network is 1232 subject to similar security threats as any MPLS LDP deployment. It 1233 is recommended that baseline security measures are considered as 1234 described in Security Framework for MPLS and GMPLS networks [RFC5920] 1235 and the LDP specification [RFC5036] including ensuring authenticity 1236 and integrity of LDP messages, as well as protection against spoofing 1237 and Denial of Service attacks. 1239 Some deployments require increased measures of network security if a 1240 subset of Access Nodes are placed in locations with lower levels of 1241 physical security e.g. street cabinets (common practice for VDSL 1242 access). In such cases it is the responsibility of the system 1243 designer to take into account the physical security measures 1244 (environmental design, mechanical or electronic access control, 1245 intrusion detection), as well as monitoring and auditing measures 1246 (configuration and Operating System changes, reloads, routes 1247 advertisements). 1249 But even with all this in mind, the designer still needs to consider 1250 network security risks and adequate measures arising from the lower 1251 level of physical security of those locations. 1253 7.1. LDP DoD Native Security Properties 1255 MPLS LDP Downstream on Demand operation is request driven and 1256 unsolicited label mappings are not accepted by upstream LSR by 1257 design. This inherently limits the potential of an unauthorized 1258 third party injecting unsolicited label mappings on the wire. 1260 This native security property enables ABR LSR to act as a gateway to 1261 the MPLS network and to control the requests coming from any Access 1262 LSR and prevent cases when the Access LSR attempts to get access to 1263 an unauthorized FEC or remote LSR after being compromised. 1265 In the event when Access LSR gets compromised, and manages to 1266 advertise a FEC belonging to another LSR (e.g. in order to 'steal' 1267 third party data flows, or breach a privacy of a VPN), such Access 1268 LSR would also have to influence the routing decision for affected 1269 FEC on the ABR LSR to attract the flows. Following measures need to 1270 be considered on ABR LSR to prevent such event from occurring: 1272 a. Access with static routes - Access LSR can not influence ABR LSR 1273 routing decisions due to static nature of routing configuration, 1274 native property of the design. 1276 b. Access with IGP - access FEC "stealing" - if the compromised 1277 Access LSR is a leaf in the access topology (leaf node in 1278 topologies I1, I, V, Y described earlier), this will not have any 1279 adverse effect, due to the leaf IGP metrics being configured on 1280 the ABR LSR. If the compromised Access LSR is a transit LSR in 1281 the access topology (transit node in topologies I, Y, U), it is 1282 only possible for this Access LSR to attract traffic destined to 1283 the nodes upstream from it. Such a 'man in the middle attack' 1284 can be quickly detected by upstream Access LSRs not receiving 1285 traffic and LDP TCP session being lost. 1287 c. Access with IGP - network FEC "stealing" - the compromised Access 1288 LSR can use IGP to advertise "stolen" FEC prefix belonging to the 1289 network side. This case can be prevented by giving a better 1290 administrative preference to the labeled unicast BGP routes vs. 1291 access IGP routes. 1293 In summary the native properties of MPLS in access design with LDP 1294 DoD prevent a number of security attacks and make their detection 1295 quick and straightforward. 1297 Following two sections describe other security considerations 1298 applicable to general MPLS deployments in the access. 1300 7.2. Data Plane Security 1302 Data plane security risks applicable to the access MPLS network 1303 include : 1305 a. Labelled packets from specific Access LSR are sent to an 1306 unauthorized destination. 1308 b. Unlabelled packets are sent by Access LSR to remote network 1309 nodes. 1311 Following mechanisms apply to MPLS access design with LDP DoD that 1312 address listed data plane security risks: 1314 1. addressing (a) - Access and ABR LSRs are not accepting labeled 1315 packets over a particular data link, unless from the Access or 1316 ABR LSR perspective this data link is known to attach to a 1317 trusted system based on control plane security described in 1318 Section 7.3, and the top label has been distributed to the 1319 upstream neighbour by the receiving Access or ABR LSR. 1321 2. addressing (a) - ABR LSR restricts network reachability for 1322 access devices to a subset of remote network LSRs, based on 1323 control plane security described in Section 7.3, FEC filters and 1324 routing policy. 1326 3. addressing (a) - use control plane authentication described in 1327 Section 7.3. 1329 4. addressing (b) - ABR LSR restricts IP network reachability to and 1330 from the Access LSR. 1332 7.3. Control Plane Security 1334 Similarly to Inter-AS MPLS/VPN deployments [RFC4364], the control 1335 plane security is prerequisite to the data plane security. 1337 To ensure control plane security access LDP DoD sessions are 1338 established only with LDP peers that are considered trusted from the 1339 local LSR perspective, meaning they are reachable over a data link 1340 that is known to attach to a trusted system based on employed 1341 authentication mechanism(s) on the local LSR. 1343 The security of LDP sesions is analyzed in LDP specification 1344 [RFC5036] and in Analysis of BGP, LDP, PCEP and MSDP Issues According 1345 to KARP Design Guide [I-D.ietf-karp-routing-tcp-analysis]. Both 1346 documents state that LDP is subject to two different types of attacks 1347 - spoofing and denial of service attacks. 1349 Threat of spoofed LDP Hello messages can be reduced by following 1350 guidelines listed in LDP specification [RFC5036]: accepting Basic 1351 Hellos only on interfaces connected to trusted LSRs, ignoring Basic 1352 Hellos that are not addressed to All Routers on this Subnet multicast 1353 group, using access lists. LDP Hello messages can be also secured 1354 using an optional Cryptographic Authentication TLV specified in LDP 1355 Hello Cryptographic Authentication 1356 [I-D.ietf-mpls-ldp-hello-crypto-auth], what further reduces the 1357 threat of spoofing during LDP discovery phase. 1359 Spoofing during LDP session communication phase can be prevented by 1360 using TCP Authentication Option TCP-AO [RFC5925] that uses a stronger 1361 hashing algorithm e.g. SHA1 compared to traditionally used MD5 1362 authentication. TCP-AO is recommended as more secure compared to TCP 1363 /IP MD5 authentication option [RFC5925]. 1365 The threat of the Denial of Service targetting well-known UDP port 1366 for LDP discovery and TCP port for LDP session establishment can be 1367 reduced by following the guidelines listed in [RFC5036] and in 1368 [I-D.ietf-karp-routing-tcp-analysis]. 1370 Access IGP (if used) and any routing protocols used in access network 1371 for signaling service routes needs also to be secured following 1372 routing protocol security best practices. Refer to KARP IS-IS 1373 security analysis [I-D.ietf-karp-isis-analysis] and Analysis of OSPF 1374 Security According to KARP Design Guide [RFC6863] for further 1375 analysis of security properties of IS-IS and OSPF IGP routing 1376 protocols. 1378 8. Acknowledgements 1380 The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai 1381 Leymann, George Swallow, Geraldine Calvignac, Ina Minei, Eric Gray 1382 and Lizhong Jin for their suggestions and review. Additional thanks 1383 go to Adrian Farrel for thorough pre-publication review, Stephen Kent 1384 for review and guidance specifically for the security section. 1386 9. References 1388 9.1. Normative References 1390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1391 Requirement Levels", BCP 14, RFC 2119, March 1997. 1393 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1394 Label Switching Architecture", RFC 3031, January 2001. 1396 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1397 Networks (VPNs)", RFC 4364, February 2006. 1399 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 1400 Heron, "Pseudowire Setup and Maintenance Using the Label 1401 Distribution Protocol (LDP)", RFC 4447, April 2006. 1403 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1404 Specification", RFC 5036, October 2007. 1406 [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension 1407 for Inter-Area Label Switched Paths (LSPs)", RFC 5283, 1408 July 2008. 1410 9.2. Informative References 1412 [I-D.ietf-karp-isis-analysis] 1413 Chunduri, U., Tian, A., and W. Lu, "KARP IS-IS security 1414 analysis", draft-ietf-karp-isis-analysis-00 (work in 1415 progress), March 2013. 1417 [I-D.ietf-karp-routing-tcp-analysis] 1418 Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1419 BGP, LDP, PCEP and MSDP Issues According to KARP Design 1420 Guide", draft-ietf-karp-routing-tcp-analysis-07 (work in 1421 progress), April 2013. 1423 [I-D.ietf-mpls-ldp-hello-crypto-auth] 1424 Zheng, L., Chen, M., and M. Bhatia, "LDP Hello 1425 Cryptographic Authentication", draft-ietf-mpls-ldp-hello- 1426 crypto-auth-01 (work in progress), January 2013. 1428 [I-D.ietf-mpls-seamless-mpls] 1429 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 1430 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 1431 ietf-mpls-seamless-mpls-03 (work in progress), May 2013. 1433 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 1434 BGP-4", RFC 3107, May 2001. 1436 [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP 1437 Synchronization", RFC 5443, March 2009. 1439 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 1440 Networks", RFC 5920, July 2010. 1442 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1443 Authentication Option", RFC 5925, June 2010. 1445 [RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security 1446 According to the Keying and Authentication for Routing 1447 Protocols (KARP) Design Guide", RFC 6863, March 2013. 1449 Authors' Addresses 1451 Thomas Beckhaus (editor) 1452 Deutsche Telekom AG 1453 Heinrich-Hertz-Strasse 3-7 1454 Darmstadt 64307 1455 Germany 1457 Phone: +49 6151 58 12825 1458 Email: thomas.beckhaus@telekom.de 1460 Bruno Decraene 1461 Orange 1462 38-40 rue du General Leclerc 1463 Issy Moulineaux cedex 9 92794 1464 France 1466 Email: bruno.decraene@orange.com 1467 Kishore Tiruveedhula 1468 Juniper Networks 1469 10 Technology Park Drive 1470 Westford, Massachusetts 01886 1471 USA 1473 Phone: 1-(978)-589-8861 1474 Email: kishoret@juniper.net 1476 Maciek Konstantynowicz (editor) 1477 Cisco Systems, Inc. 1478 10 New Square Park, Bedfont Lakes 1479 London 1480 United Kingdom 1482 Email: maciek@cisco.com 1484 Luca Martini 1485 Cisco Systems, Inc. 1486 9155 East Nichols Avenue, Suite 400 1487 Englewood, CO 80112 1488 USA 1490 Email: lmartini@cisco.com