idnits 2.17.1 draft-ietf-mpls-ldp-dod-06.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 is 1 instance of too long lines in the document, the longest one being 1 character 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 (May 10, 2013) is 4002 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 797, but not defined == Missing Reference: 'I' is mentioned on line 797, but not defined == Missing Reference: 'V' is mentioned on line 804, but not defined == Missing Reference: 'U2' is mentioned on line 804, but not defined == Missing Reference: 'Y' is mentioned on line 804, but not defined == Missing Reference: 'U' is mentioned on line 804, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-mpls-seamless-mpls-02 ** Downref: Normative reference to an Informational draft: draft-ietf-mpls-seamless-mpls (ref. 'I-D.ietf-mpls-seamless-mpls') ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) ** Downref: Normative reference to an Informational RFC: RFC 5920 -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 2 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: Standards Track B. Decraene 5 Expires: November 11, 2013 France Telecom 6 K. Tiruveedhula 7 Juniper Networks 8 M. Konstantynowicz 9 L. Martini 10 Cisco Systems, Inc. 11 May 10, 2013 13 LDP Downstream-on-Demand in Seamless MPLS 14 draft-ietf-mpls-ldp-dod-06 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 November 11, 2013. 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 . . . . . . . . . . . . 8 76 3. LDP DoD Use Cases . . . . . . . . . . . . . . . . . . . . . . 10 77 3.1. Initial Network Setup . . . . . . . . . . . . . . . . . . 10 78 3.1.1. AN with Static Routing . . . . . . . . . . . . . . . 10 79 3.1.2. AN with Access IGP . . . . . . . . . . . . . . . . . 11 80 3.2. Service Provisioning and Activation . . . . . . . . . . . 12 81 3.3. Service Changes and Decommissioning . . . . . . . . . . . 15 82 3.4. Service Failure . . . . . . . . . . . . . . . . . . . . . 15 83 3.5. Network Transport Failure . . . . . . . . . . . . . . . . 16 84 3.5.1. General Notes . . . . . . . . . . . . . . . . . . . . 16 85 3.5.2. AN Node Failure . . . . . . . . . . . . . . . . . . . 16 86 3.5.3. AN/AGN Link Failure . . . . . . . . . . . . . . . . . 17 87 3.5.4. AGN Node Failure . . . . . . . . . . . . . . . . . . 18 88 3.5.5. AGN Network-side Reachability Failure . . . . . . . . 18 89 4. LDP DoD Procedures . . . . . . . . . . . . . . . . . . . . . 19 90 4.1. LDP Label Distribution Control and Retention Modes . . . 19 91 4.2. LDP DoD Session Negotiation . . . . . . . . . . . . . . . 21 92 4.3. Label Request Procedures . . . . . . . . . . . . . . . . 22 93 4.3.1. Access LSR/ABR Label Request . . . . . . . . . . . . 22 94 4.3.2. Label Request Retry . . . . . . . . . . . . . . . . . 23 95 4.4. Label Withdraw . . . . . . . . . . . . . . . . . . . . . 23 96 4.5. Label Release . . . . . . . . . . . . . . . . . . . . . . 25 97 4.6. Local Repair . . . . . . . . . . . . . . . . . . . . . . 25 98 5. LDP Extension for LDP DoD Fast-Up Convergence . . . . . . . . 25 99 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 100 6.1. LDP TLV TYPE . . . . . . . . . . . . . . . . . . . . . . 27 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 102 7.1. Security and LDP DoD . . . . . . . . . . . . . . . . . . 28 103 7.1.1. Access to network packet flow direction . . . . . . . 28 104 7.1.2. Network to access packet flow direction . . . . . . . 28 105 7.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 29 106 7.3. Control Plane Security . . . . . . . . . . . . . . . . . 30 107 7.4. Network Node Security . . . . . . . . . . . . . . . . . . 31 108 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 109 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 110 9.1. Normative References . . . . . . . . . . . . . . . . . . 31 111 9.2. Informative References . . . . . . . . . . . . . . . . . 32 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 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 Label Switching Routers implement either LDP or RSVP 125 for MPLS label distribution. 127 The focus of this document is on LDP, as Seamless MPLS design does 128 not include a requirement for general purpose explicit traffic 129 engineering and bandwidth reservation. Document concentrates on the 130 unicast connectivity only. Multicast connectivity is subject for 131 further study. 133 In Seamless MPLS design [I-D.ietf-mpls-seamless-mpls], IP/MPLS 134 protocol optimization is possible due to a relatively simple access 135 network topologies. Examples of such topologies involving access 136 nodes (AN) and aggregation nodes (AGN) include: 138 a. A single AN homed to a single AGN. 140 b. A single AN dual-homed to two AGNs. 142 c. Multiple ANs daisy-chained via a hub-AN to a single AGN. 144 d. Multiple ANs daisy-chained via a hub-AN to two AGNs. 146 e. Two ANs dual-homed to two AGNs. 148 f. Multiple ANs chained in a ring and dual-homed to two AGNs. 150 The amount of IP RIB and FIB state on ANs can be easily controlled in 151 the listed access topologies by using simple IP routing configuration 152 with either static routes or dedicated access IGP. Note that in all 153 of the above topologies AGNs act as the access border routers (access 154 ABRs) connecting the access topology to the rest of the network. 155 Hence in many cases it is sufficient for ANs to have a default route 156 pointing towards AGNs in order to achieve complete network 157 connectivity from ANs to the network. 159 The amount of MPLS forwarding state however requires additional 160 consideration. In general MPLS routers implement LDP Downstream 161 Unsolicited (LDP DU) label advertisement [RFC5036] and advertise MPLS 162 labels for all valid routes in their RIB. This is seen as an 163 inadequate approach for ANs, which requires a small subset of the 164 total routes (and associated labels) based on the required 165 connectivity for the provisioned services. And although filters can 166 be applied to those LDP DU labels advertisements, it is not seen as a 167 suitable tool to facilitate any-to-any AN-driven connectivity between 168 access and the rest of the MPLS network. 170 This document describes an access node driven "subscription model" 171 for label distribution in the access. The approach relies on the 172 standard LDP Downstream-on-Demand (LDP DoD) label advertisements as 173 specified in [RFC5036]. LDP DoD enables on-demand label distribution 174 ensuring that only required labels are requested, provided and 175 installed. Procedures described in this document are equally 176 applicable to LDP IPv4 and IPv6 address families. For simplicity the 177 document provides examples based on LDP IPv4 address family. 179 The following sections describe a set of reference access topologies 180 considered for LDP DoD usage and their associated IP routing 181 configurations, followed by LDP DoD use cases and LDP DoD procedures 182 in the context of Seamless MPLS design. 184 2. Reference Topologies 186 LDP DoD use cases are described in the context of a generic reference 187 end-to-end network topology based on Seamless MPLS design 188 [I-D.ietf-mpls-seamless-mpls] shown in Figure 1 190 +-------+ +-------+ +------+ +------+ 191 ---+ AGN11 +--+ AGN21 +--+ ABR1 +--+ LSR1 +--> to LSR/AGN 193 +--------+/ +-------+ +-------+ +------+ +------+ 194 | Access | \/ \/ 195 | Network| /\ /\ 196 +--------+ +-------+ +-------+ +------+ +------+ 197 \---+ AGN12 +--+ AGN22 +--+ ABR2 +--+ LSR2 +--> to LSR/AGN 198 +-------+ +-------+ +------+ +------+ 200 static routes 201 or access IGP IGP area IGP area 202 <----Access----><--Aggregation Domain--><----Core-----> 203 <------------------------- MPLS ----------------------> 205 Figure 1: Seamless MPLS end-to-end reference network topology. 207 The access network is either single or dual homed to AGN1x, with 208 either a single or multiple parallel links to AGN1x. 210 Seamless MPLS access network topologies can range from a single- or 211 dual-homed access node to a chain or ring of access nodes, and use 212 either static routing or access IGP ( ISIS or OSPF ). The following 213 sections describe reference access topologies in more detail. 215 2.1. Access Topologies with Static Routing 217 In most cases access nodes connect to the rest of the network using 218 very simple topologies. Here static routing is sufficient to provide 219 the required IP connectivity. The following topologies are 220 considered for use with static routing and LDP DoD: 222 a. [I1] topology - a single AN homed to a single AGN. 224 b. [I] topology - multiple ANs daisy-chained to a single AGN. 226 c. [V] topology - a single AN dual-homed to two AGNs. 228 d. [U2] topology - two ANs dual-homed to two AGNs. 230 e. [Y] topology - multiple ANs daisy-chained to two AGNs. 232 The reference static routing and LDP configuration for [V] access 233 topology is shown in Figure 2. The same static routing and LDP 234 configuration also applies to [I1] topology. 236 +----+ +-------+ 237 |AN1 +------------------------+ AGN11 +------- 238 | +-------\ /-----------+ +-\ / 239 +----+ \ / +-------+ \ / 240 \/ \/ 241 /\ /\ 242 +----+ / \ +-------+ / \ 243 |AN2 +-------/ \-----------+ AGN12 +-/ \ 244 | +------------------------+ +------- 245 +----+ +-------+ 247 --(u)-> <-(d)-- 249 <----- static routing -------> <--- IGP ----> 250 <-- LDP DU --> 251 <--------- LDP DoD ----------> <-- BGP LU --> 253 (u) static routes: 0/0 default, (optional) /32 routes 254 (d) static routes: AN loopbacks 256 Figure 2: [V] access topology with static routes. 258 In line with the Seamless MPLS design, static routes configured on 259 AGN1x and pointing towards the access network are redistributed in 260 either IGP or BGP labeled unicast (BGP-LU) [RFC3107]. 262 The reference static routing and LDP configuration for [U2] access 263 topology is shown in Figure 3. 265 +----+ +-------+ 266 (d1) |AN1 +------------------------+ AGN11 +------- 267 | | + + +-\ / 268 v +-+--+ +-------+ \ / 269 | \/ 270 | /\ 271 ^ +-+--+ +-------+ / \ 272 | |AN2 + + AGN12 +-/ \ 273 (d2) | +------------------------+ +------- 274 +----+ +-------+ 276 --(u)-> <-(d)-- 278 <------- static routing --------> <--- IGP ----> 279 <-- LDP DU --> 280 <----------- LDP DoD -----------> <-- BGP LU --> 282 (u) static route 0/0 default, (optional) /32 routes 283 (d) static route for AN loopbacks 284 (d1) static route for AN2 loopback and 0/0 default with 285 lower preference 286 (d2) static route for AN1 loopback and 0/0 default with 287 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 -------> <--- IGP ----> 309 <-- LDP DU --> 310 <---------- LDP DoD -----------> <-- BGP LU --> 312 (u) static routes: 0/0 default, (optional) /32 routes 313 (d) static routes: AN loopbacks [1..n] 314 (d1) static routes: AN loopbacks [2..n] 315 (d2) static routes: 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 ------------> <--- IGP ----> 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 ------------> <--- IGP ----> 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 use cases described in this document are based on the 397 Seamless MPLS scenarios listed in Seamless MPLS design 398 [I-D.ietf-mpls-seamless-mpls]. This section illustrates these use 399 cases focusing on services provisioned on the access nodes and 400 clarifies expected LDP DoD operation on the AN and AGN1x devices. 401 Two representative service types are used to illustrate the service 402 use cases: MPLS PWE3 [RFC4447] and BGP/MPLS IPVPN [RFC4364]. 404 Described LDP DoD operations apply equally to all reference access 405 topologies described in Section 2. Operations that are specific to 406 certain access topologies are called out explicitly. 408 References to upstream and downstream nodes are made in line with the 409 definition of upstream and downstream LSR [RFC3031]. 411 LDP DoD procedures follow the LDP specification [RFC5036], and are 412 equally applicable to LDP IPv4 and IPv6 address families. For 413 simplicity examples are provided for LDP IPv4 address family only. 415 3.1. Initial Network Setup 417 An access node is commissioned without any services provisioned on 418 it. The AN may request labels for loopback addresses of any AN, AGN 419 or other nodes within Seamless MPLS network for operational and 420 management purposes. It is assumed that AGN1x has required IP/MPLS 421 configuration for network-side connectivity in line with Seamless 422 MPLS design [I-D.ietf-mpls-seamless-mpls]. 424 LDP sessions are configured between adjacent ANs and AGN1x using 425 their respective loopback addresses. 427 3.1.1. AN with Static Routing 429 If access static routing is used, ANs are provisioned with the 430 following static IP routing entries (topology references from 431 Section 2 are listed in square brackets): 433 a. [I1, V, U2] - Static default route 0/0 pointing to links 434 connected to AGN1x. Requires support for Inter-area LDP 435 [RFC5283]. 437 b. [U2] - Static /32 routes pointing to the other AN. Lower 438 preference static default route 0/0 pointing to links connected 439 to the other AN. Requires support for Inter-area LDP [RFC5283]. 441 c. [I, Y] - Static default route 0/0 pointing to links leading 442 towards AGN1x. Requires support for Inter-area LDP [RFC5283]. 444 d. [I, Y] - Static /32 routes to all ANs in the daisy-chain pointing 445 to links towards those ANs. 447 e. [I1, V, U2] - Optional - Static /32 routes for specific nodes 448 within Seamless MPLS network, pointing to links connected to 449 AGN1x. 451 f. [I, Y] - Optional - Static /32 routes for specific nodes within 452 the Seamless MPLS network, pointing to links leading towards 453 AGN1x. 455 Upstream AN/AGN1x should request labels over LDP DoD session(s) from 456 downstream AN/AGN1x for configured static routes if those static 457 routes are configured with LDP DoD request policy and if they are 458 pointing to a next-hop selected by routing. It is expected that all 459 configured /32 static routes to be used for LDP DoD are configured 460 with such policy on AN/AGN1x. 462 Downstream AN/AGN1x should respond to the Label Request from the 463 upstream AN/AGN1x with a Label Mapping if requested route is present 464 in its RIB, and there is a valid label binding from its downstream or 465 it is the egress node. In such case downstream AN/AGN1x must install 466 the advertised label as an incoming label in its label table (LIB) 467 and its forwarding table (LFIB). Upstream AN/AGN1x must also install 468 the received label as an outgoing label in their LIB and LFIB. If 469 the downstream AN/AGN1x does have the route present in its RIB, but 470 does not have a valid label binding from its downstream, it should 471 forward the request to its downstream. 473 In order to facilitate ECMP and IPFRR LFA local-repair, the upstream 474 AN/AGN1x must also send LDP DoD label requests to alternate next-hops 475 per its RIB, and install received labels as alternate entries in its 476 LIB and LFIB. 478 AGN1x node on the network side may use BGP labeled unicast [RFC3107] 479 in line with the Seamless MPLS design [I-D.ietf-mpls-seamless-mpls]. 480 In such a case AGN1x will be redistributing its static routes 481 pointing to local ANs into BGP labeled unicast to facilitate network- 482 to-access traffic flows. Likewise, to facilitate access-to-network 483 traffic flows, AGN1x will be responding to access-originated LDP DoD 484 label requests with label mappings based on its BGP labeled unicast 485 reachability for requested FECs. 487 3.1.2. AN with Access IGP 488 If access IGP is used, AN(s) advertise their loopbacks over the 489 access IGP with configured metrics. AGN1x advertise a default route 490 over the access IGP. 492 Routers request labels over LDP DoD session(s) according to their 493 needs for MPLS connectivity (LSPs). In particular if AGNs, as per 494 Seamless MPLS design [I-D.ietf-mpls-seamless-mpls], redistribute 495 routes from the IGP into BGP labeled unicast [RFC3107], they should 496 request labels over LDP DoD session(s) for those routes. 498 Identically to the static route case, downstream AN/AGN1x should 499 respond to the Label Request from the upstream AN/AGN1x with a Label 500 Mapping (if the requested route is present in its RIB, and there is a 501 valid label binding from its downstream), and must install the 502 advertised label as an incoming label in its LIB and LFIB. Upstream 503 AN/AGN1x must also install the received label as an outgoing label in 504 their LIB and LFIB. 506 Identically to the static route case, in order to facilitate ECMP and 507 IPFRR LFA local-repair, upstream AN/AGN1x must also send LDP DoD 508 label requests to alternate next-hops per its RIB, and install 509 received labels as alternate entries in its LIB and LFIB. 511 AGN1x node on the network side may use BGP labeled unicast [RFC3107] 512 in line with Seamless MPLS design [I-D.ietf-mpls-seamless-mpls]. In 513 such case AGN1x will be redistributing routes received over the 514 access IGP (and pointing to local ANs), into BGP labeled unicast to 515 facilitate network-to-access traffic flows. Likewise, to facilitate 516 access-to-network traffic flows AGN1x will be responding to access 517 originated LDP DoD label requests with label mappings based on its 518 BGP labeled unicast reachability for requested FECs. 520 3.2. Service Provisioning and Activation 522 Following the initial setup phase described in Section 3.1, a 523 specific access node, referred to as AN*, is provisioned with a 524 network service. AN* relies on LDP DoD to request the required MPLS 525 LSP(s) label(s) from downstream AN/AGN1x node(s). Note that LDP DoD 526 operations are service agnostic, that is, they are the same 527 independently of the services provisioned on the AN*. 529 For illustration purposes two service types are described: MPLS PWE3 530 [RFC4447] service and BGP/MPLS IPVPN [RFC4364]. 532 MPLS PWE3 service - for description simplicity it is assumed that a 533 single segment pseudowire is signaled using targeted LDP FEC128 534 (0x80), and it is provisioned with the pseudowire ID and the loopback 535 IPv4 address of the destination node. The following IP/MPLS 536 operations need to be completed on the AN* to successfully establish 537 such PWE3 service: 539 a. LSP labels for destination /32 FEC (outgoing label) and the local 540 /32 loopback (incoming label) need to be signaled using LDP DoD. 542 b. Targeted LDP session over an associated TCP/IP connection needs 543 to be established to the PWE3 destination PE. This is triggered 544 by either an explicit targeted LDP session configuration on the 545 AN* or automatically at the time of provisioning the PWE3 546 instance. 548 c. Local and remote PWE3 labels for specific FEC128 PW ID need to be 549 signaled using targeted LDP and PWE3 signaling procedures 550 [RFC4447]. 552 d. Upon successful completion of the above operations, AN* programs 553 its RIB/LIB and LFIB tables, and activates the MPLS PWE3 service. 555 Note - only minimum operations applicable to service connectivity 556 have been listed. Other non IP/MPLS connectivity operations that may 557 be required for successful service provisioning and activation are 558 out of scope in this document. 560 BGP/MPLS IPVPN service - for description simplicity it is assumed 561 that AN* is provisioned with a unicast IPv4 IPVPN service (VPNv4 for 562 short) [RFC4364]. The following IP/MPLS operations need to be 563 completed on the AN* to successfully establish VPNv4 service: 565 a. BGP peering sessions with associated TCP/IP connections need to 566 be established with the remote destination VPNv4 PEs or Route 567 Reflectors. 569 b. Based on configured BGP policies, VPNv4 BGP NLRIs need to be 570 exchanged between AN* and its BGP peers. 572 c. Based on configured BGP policies, VPNv4 routes need to be 573 installed in the AN* VRF RIB and FIB, with corresponding BGP 574 next-hops. 576 d. LSP labels for destination BGP next-hop /32 FEC (outgoing label) 577 and the local /32 loopback (incoming label) need to be signaled 578 using LDP DoD. 580 e. Upon successful completion of above operations, AN* programs its 581 RIB/LIB and LFIB tables, and activates the BGP/MPLS IPVPN 582 service. 584 Note - only minimum operations applicable to service connectivity 585 have been listed. Other non IP/MPLS connectivity operations that may 586 be required for successful service provisioning are out of scope in 587 this document. 589 To establish an LSP for destination /32 FEC for any of the above 590 services, AN* looks up its local routing table for a matching route, 591 selects the best next-hop(s) and associated outgoing link(s). 593 If a label for this /32 FEC is not already installed based on the 594 configured static route with LDP DoD request policy or access IGP RIB 595 entry, AN* must send an LDP DoD Label Mapping request. Downstream AN 596 /AGN1x LSR(s) checks its RIB for presence of the requested /32 and 597 associated valid outgoing label binding, and if both are present, 598 replies with its label for this FEC and installs this label as 599 incoming in its LIB and LFIB. Upon receiving the Label Mapping the 600 AN* must accept this label based on the exact route match of 601 advertised FEC and route entry in its RIB or based on the longest 602 match in line with Inter-area LDP [RFC5283]. If the AN* accepts the 603 label it must install it as an outgoing label in its LIB and LFIB. 605 In access topologies [V] and [Y], if AN* is dual homed to two AGN1x 606 and routing entries for these AGN1x are configured as equal cost 607 paths, AN* must send LDP DoD label requests to both AGN1x devices and 608 install all received labels in its LIB and LFIB. 610 In order for AN* to implement IPFRR LFA local-repair, AN* must also 611 send LDP DoD label requests to alternate next-hops per its RIB, and 612 install received labels as alternate entries in its LIB and LFIB. 614 When forwarding PWE3 or VPNv4 packets AN* chooses the LSP label based 615 on the locally configured static /32 or default route, or default 616 route signaled via access IGP. If a route is reachable via multiple 617 interfaces to AGN1x nodes and the route has multiple equal cost 618 paths, AN* must implement Equal Cost Multi-Path (ECMP) functionality. 619 This involves AN* using hash-based load-balancing mechanism and 620 sending the PWE3 or VPNv4 packets in a flow-aware manner with 621 appropriate LSP labels via all equal cost links. 623 ECMP mechanism is applicable in an equal manner to parallel links 624 between two network elements and multiple paths towards the 625 destination. The traffic demand is distributed over the available 626 paths. 628 AGN1x node on the network side may use BGP labeled unicast [RFC3107] 629 in line with Seamless MPLS design [I-D.ietf-mpls-seamless-mpls]. In 630 such case AGN1x will be redistributing its static routes (or routes 631 received from the access IGP) pointing to local ANs into BGP labeled 632 unicast to facilitate network-to-access traffic flows. Likewise, to 633 facilitate access-to-network traffic flows AGN1x will be responding 634 to access originated LDP DoD label requests with label mappings based 635 on its BGP labeled unicast reachability for requested FECs. 637 3.3. Service Changes and Decommissioning 639 Whenever AN* service gets decommissioned or changed and connectivity 640 to specific destination is not longer required, the associated MPLS 641 LSP label resources should be released on AN*. 643 MPLS PWE3 service - if the PWE3 service gets decommissioned and it is 644 the last PWE3 to a specific destination node, the targeted LDP 645 session is not longer needed and should be terminated (automatically 646 or by configuration). The MPLS LSP(s) to that destination is no 647 longer needed either. 649 BGP/MPLS IPVPN service - deletion of a specific VPNv4 (VRF) instance, 650 local or remote re-configuration may result in specific BGP next- 651 hop(s) being no longer needed. The MPLS LSP(s) to that destination 652 is no longer needed either. 654 In all of the above cases the following LDP DoD related operations 655 apply: 657 o If the /32 FEC label for the aforementioned destination node was 658 originally requested based on either tLDP session configuration 659 and default route or required BGP next-hop and default route, AN* 660 should delete the label from its LIB and LFIB, and release it from 661 downstream AN/AGN1x by using LDP DoD procedures. 663 o If the /32 FEC label was originally requested based on the static 664 /32 route configuration with LDP DoD request policy, the label 665 must be retained by AN*. 667 3.4. Service Failure 669 A service instance may stop being operational due to a local or 670 remote service failure event. 672 In general, unless the service failure event modifies required MPLS 673 connectivity, there should be no impact on the LDP DoD operation. 675 If the service failure event does modify the required MPLS 676 connectivity, LDP DoD operations apply as described in Section 3.2 677 and Section 3.3. 679 3.5. Network Transport Failure 681 A number of different network events can impact services on AN*. The 682 following sections describe network event types that impact LDP DoD 683 operation on AN and AGN1x nodes. 685 3.5.1. General Notes 687 If service on any of the ANs is affected by any network failure and 688 there is no network redundancy, the service must go into a failure 689 state. When the network failure is recovered from, the service must 690 be re-established automatically. 692 The following additional LDP-related functions should be supported to 693 comply with Seamless MPLS [I-D.ietf-mpls-seamless-mpls] fast service 694 restoration requirements as follows: 696 a. Local-repair - AN and AGN1x should support local-repair for 697 adjacent link or node failure for access-to-network, network-to- 698 access and access-to-access traffic flows. Local-repair should 699 be implemented by using either IPFRR LDP LFA, simple ECMP or 700 primary/backup switchover upon failure detection. 702 b. LDP session protection - LDP sessions should be configured with 703 LDP session protection to avoid delay upon the recovery from link 704 failure. LDP session protection ensures that FEC label binding 705 is maintained in the control plane as long as LDP session stays 706 up. 708 c. IGP-LDP synchronization - If access IGP is used, LDP sessions 709 between ANs, and between ANs and AGN1x, should be configured with 710 IGP-LDP synchronization to avoid unnecessary traffic loss in case 711 the access IGP converged before LDP and there is no LDP label 712 binding to the downstream best next-hop. 714 3.5.2. AN Node Failure 716 AN node fails and all links to adjacent nodes go down. 718 Adjacent AN/AGN1x nodes remove all routes pointing to the failed 719 link(s) from their RIB tables (including /32 loopback belonging to 720 the failed AN and any other routes reachable via the failed AN). 721 This in turn triggers the removal of associated outgoing /32 FEC 722 labels from their LIB and LFIB tables. 724 If access IGP is used, the AN node failure will be propagated via IGP 725 link updates across the access topology. 727 If a specific /32 FEC(s) is not reachable anymore from those AN/ 728 AGN1x, they must also send LDP Label Withdraw to their upstream LSRs 729 to notify about the failure, and remove the associated incoming 730 label(s) from their LIB and LFIB tables. Upstream LSRs upon 731 receiving Label Withdraw should remove the signaled labels from their 732 LIB/LFIB tables, and propagate LDP Label Withdraw across their 733 upstream LDP DoD sessions. 735 In [U] topology there may be an alternative path to routes previously 736 reachable via the failed AN node. In this case adjacent AN/AGN1x 737 should invoke local-repair (IPFRR LFA, ECMP) and switchover to 738 alternate next-hop to reach those routes. 740 AGN1x gets notified about the AN failure via either access IGP (if 741 used) and/or cascaded LDP DoD label withdraw(s). AGN1x must 742 implement all relevant global-repair IP/MPLS procedures to propagate 743 the AN failure towards the core network. This should involve 744 removing associated routes (in access IGP case) and labels from its 745 LIB and LFIB tables, and propagating the failure on the network side 746 using BGP-LU and/or core IGP/LDP-DU procedures. 748 Upon AN coming back up, adjacent AN/AGN1x nodes automatically add 749 routes pointing to recovered links based on the configured static 750 routes or access IGP adjacency and link state updates. This should 751 be then followed by LDP DoD label signaling and subsequent binding 752 and installation of labels in LIB and LFIB tables. 754 3.5.3. AN/AGN Link Failure 756 Depending on the access topology and the failed link location 757 different cases apply to the network operation after AN link failure 758 (topology references from Section 2 in square brackets): 760 a. [all] - link failed, but at least one ECMP parallel link remains 761 - nodes on both sides of the failed link must stop using the 762 failed link immediately (local-repair), and keep using the 763 remaining ECMP parallel links. 765 b. [I1, I, Y] - link failed, and there are no ECMP or alternative 766 links and paths - nodes on both sides of the failed link must 767 remove routes pointing to the failed link immediately from the 768 RIB, remove associated labels from their LIB and LFIB tabels, and 769 must send LDP label withdraw(s) to their upstream LSRs. 771 c. [U2, U, V, Y] - link failed, but at least one ECMP or alternate 772 path remains - AN/AGN1x node must stop using the failed link and 773 immediately switchover (local-repair) to the remaining ECMP path 774 or alternate path. AN/AGN1x must remove affected next-hops and 775 labels from its tables and invoke LDP Label Withdraw as per point 776 (a) above. If there is an AGN1x node terminating the failed 777 link, it must remove routes pointing to the failed link 778 immediately from the RIB, remove associated labels from their LIB 779 and LFIB tabels, and must propagate the failure on the network 780 side using BGP-LU and/or core IGP procedures. 782 If access IGP is used AN/AGN1x link failure will be propagated via 783 IGP link updates across the access topology. 785 LDP DoD will also propagate the link failure by sending label 786 withdraws to upstream AN/AGN1x nodes, and Label Release messages 787 downstream AN/AGN1x nodes. 789 3.5.4. AGN Node Failure 791 AGN1x fails and all links to adjacent access nodes go down. 793 Depending on the access topology, following cases apply to the 794 network operation after AGN1x node failure (topology references from 795 Section 2 in square brackets): 797 a. [I1, I] - ANs are isolated from the network - AN adjacent to the 798 failure must remove routes pointing to the failed AGN1x node 799 immediately from the RIB, remove associated labels from their LIB 800 and LFIB tabels, and must send LDP label withdraw(s) to their 801 upstream LSRs. If access IGP is used, an IGP link update should 802 be sent. 804 b. [U2, U, V, Y] - at least one ECMP or alternate path remains - AN 805 adjacent to failed AGN1x must stop using the failed link and 806 immediately switchover (local-repair) to the remaining ECMP path 807 or alternate path. AN must remove affected routes and labels 808 from its tables and invoke LDP Label Withdraw as per point (a) 809 above. 811 Network side procedures for handling AGN1x node failure have been 812 described in Seamless MPLS [I-D.ietf-mpls-seamless-mpls]. 814 3.5.5. AGN Network-side Reachability Failure 816 AGN1x loses network reachability to a specific destination or set of 817 network-side destinations. 819 In such event AGN1x must send LDP Label Withdraw messages to its 820 upstream ANs, withdrawing labels for all affected /32 FECs. Upon 821 receiving those messages ANs must remove those labels from their LIB 822 and LFIB tables, and use alternative LSPs instead if available as 823 part of global-repair. In turn ANs should also sent Label Withdraw 824 messages for affected /32 FECs to their upstream ANs. 826 If access IGP is used, and AGN1x gets completely isolated from the 827 core network, it should stop advertising the default route 0/0 into 828 the access IGP. 830 4. LDP DoD Procedures 832 Label Distribution Protocol is specified in [RFC5036], and all LDP 833 Downstream-on-Demand implementations follow [RFC5036] specification. 834 This section does not update [RFC5036] procedures, but illustrates 835 LDP DoD operations in the context of use cases identified in 836 Section 3 in this document, for information only. 838 In the MPLS architecture [RFC3031], network traffic flows from 839 upstream to downstream LSR. The use cases in this document rely on 840 the downstream assignment of labels, where labels are assigned by the 841 downstream LSR and signaled to the upstream LSR as shown in Figure 7. 843 +----------+ +------------+ 844 | upstream | | downstream | 845 ------+ LSR +------+ LSR +---- 846 traffic | | | | address 847 source +----------+ +------------+ (/32 for IPv4) 848 traffic 849 label distribution for IPv4 FEC destination 850 <------------------------- 852 traffic flow 853 -------------------------> 855 Figure 7: LDP label assignment direction 857 4.1. LDP Label Distribution Control and Retention Modes 859 LDP protocol specification [RFC5036] defines two modes for label 860 distribution control, following the definitions in MPLS architecture 861 [RFC3031]: 863 o Independent mode - an LSR recognizes a particular FEC and makes a 864 decision to bind a label to the FEC independently from 865 distributing that label binding to its label distribution peers. 866 A new FEC is recognized whenever a new route becomes valid on the 867 LSR. 869 o Ordered mode - an LSR needs to bind a label to a particular FEC if 870 it knows how to forward packets for that FEC ( i.e. it has a 871 route corresponding to that FEC ) and if it has already received 872 at least one Label Request message from an upstream LSR. 874 Using independent label distribution control with LDP DoD and access 875 static routing would prevent the access LSRs from propagating label 876 binding failure along the access topology, making it impossible for 877 upstream LSR to be notified about the downstream failure and for an 878 application using the LSP to switchover to an alternate path, even if 879 such a path exists. 881 LDP protocol specification [RFC5036] defines two modes for label 882 retention, following the definitions in MPLS architecture [RFC3031]: 884 o Conservative mode - If operating in Downstream on Demand mode, an 885 LSR will request label mappings only from the next hop LSR 886 according to routing. The main advantage of the conservative mode 887 is that only the labels that are required for the forwarding of 888 data are allocated and maintained. This is particularly important 889 in LSRs where the label space is inherently limited, such as in an 890 ATM switch. A disadvantage of the conservative mode is that if 891 routing changes the next hop for a given destination, a new label 892 must be obtained from the new next hop before labeled packets can 893 be forwarded. 895 o Liberal mode - When operating in Downstream on Demand mode with 896 Liberal Label retention, an LSR might choose to request label 897 mappings for all known prefixes from all peer LSRs. The main 898 advantage of the Liberal Label retention mode is that reaction to 899 routing changes can be quick because labels already exist. The 900 main disadvantage of the liberal mode is that unneeded label 901 mappings are distributed and maintained. 903 Note that the conservative label retention mode would prevent LSRs 904 from requesting and maintaining label mappings for any backup routes 905 that are not used for forwarding. This in turn would prevent the 906 access LSRs (AN and AGN1x nodes) from implementing any local 907 protection schemes that rely on using alternate next-hops in case of 908 the primary next-hop failure. Such schemes include IPFRR LFA if 909 access IGP is used, or a primary and backup static route 910 configuration. Using LDP DoD in combination with liberal retention 911 mode allows the LSR to request labels for the specific FEC from 912 primary next-hop LSR(s) and the alternate next-hop LSR(s) for this 913 FEC. 915 Note that even though LDP DoD operates in a liberal retention mode, 916 if used with access IGP and if no LFA exists, the LDP DoD will 917 introduce additional delay in traffic restoration as the labels for 918 the new next-hop will get requested only after the access IGP 919 convergence. 921 Adhering to the overall design goals of Seamless MPLS 922 [I-D.ietf-mpls-seamless-mpls], specifically achieving a large network 923 scale without compromising fast service restoration, all access LSRs 924 (AN and AGN1x nodes) use LDP DoD advertisement mode with: 926 o Ordered label distribution control - enables propagation of label 927 binding failure within the access topology. 929 o Liberal label retention - enables pre-programming of alternate 930 next-hops with associated FEC labels. 932 In Seamless MPLS [I-D.ietf-mpls-seamless-mpls] AGN1x node acts as an 933 access ABR connecting access and metro domains. To enable failure 934 propagation between those domains, access ABR implements ordered 935 label distribution control when redistributing routes/FEC between the 936 access-side (using LDP DoD and static or access IGP) and the network- 937 side ( using BGP labeled unicast [RFC3107] or core IGP with LDP 938 Downstream Unsolicited label advertisement. 940 4.2. LDP DoD Session Negotiation 942 Access LSR/ABR should propose the Downstream-on-Demand label 943 advertisement by setting "A" value to 1 in the Common Session 944 Parameters TLV of the Initialization message. The rules for 945 negotiating the label advertisement mode are specified in LDP 946 protocol specification [RFC5036]. 948 To establish a Downstream-on-Demand session between the two access 949 LSR/ABRs, both should propose the Downstream-on-Demand label 950 advertisement mode in the Initialization message. If the access LSR 951 only supports LDP DoD and the access ABR proposes Downstream 952 Unsolicited mode, the access LSR should send a Notification message 953 with status "Session Rejected/Parameters Advertisement Mode" and then 954 close the LDP session as specified in LDP protocol specification 955 [RFC5036]. 957 If an access LSR is acting in an active role, it should re-attempt 958 the LDP session immediately. If the access LSR receives the same 959 Downstream Unsolicited mode again, it should follow the exponential 960 backoff algorithm as defined in the LDP protocol specification 961 [RFC5036] with delay of 15 seconds and subsequent delays growing to a 962 maximum delay of 2 minutes. 964 In case a PWE3 service is required between the adjacent access LSR/ 965 ABR, and LDP DoD has been negotiated for IPv4 and IPv6 FECs, the same 966 LDP session should be used for PWE3 FECs. Even if LDP DoD label 967 advertisement has been negotiated for IPv4 and IPv6 LDP FECs as 968 described earlier, LDP session should use Downstream Unsolicited 969 label advertisement for PWE3 FECs as specified in PWE3 LDP [RFC4447]. 971 4.3. Label Request Procedures 973 4.3.1. Access LSR/ABR Label Request 975 Upstream access LSR/ABR will request label bindings from adjacent 976 downstream access LSR/ABR based on the following trigger events: 978 a. Access LSR/ABR is configured with /32 static route with LDP DoD 979 Label Request policy in line with initial network setup use case 980 described in Section 3.1. 982 b. Access LSR/ABR is configured with a service in line with service 983 use cases described in Section 3.2 and Section 3.3. 985 c. Configuration with access static routes - Access LSR/ABR link to 986 adjacent node comes up and LDP DoD session is established. In 987 this case access LSR should send Label Request messages for all / 988 32 static routes configured with LDP DoD policy and all /32 989 routes related to provisioned services that are covered by 990 default route. 992 d. Configuration with access IGP - Access LSR/ABR link to adjacent 993 node comes up and LDP DoD session is established. In this case 994 access LSR should send Label Request messages for all /32 routes 995 learned over the access IGP and all /32 routes related to 996 provisioned services that are covered by access IGP routes. 998 e. In all above cases requests must be sent to next-hop LSR(s) and 999 alternate LSR(s). 1001 Downstream access LSR/ABR will respond with Label Mapping message 1002 with a non-null label if any of the below conditions are met: 1004 a. Downstream access LSR/ABR - requested FEC is an IGP or static 1005 route and there is an LDP label already learnt from the next- 1006 next-hop downstream LSR (by LDP DoD or LDP DU). If there is no 1007 label for the requested FEC and there is an LDP DoD session to 1008 the next-next-hop downstream LSR, downstream LSR must send a 1009 Label Request message for the same FEC to the next-next-hop 1010 downstream LSR. In such case downstream LSR will respond back to 1011 the requesting upstream access LSR only after getting a label 1012 from the next-next-hop downstream LSR peer. 1014 b. Downstream access ABR only - requested FEC is a BGP labelled 1015 unicast route [RFC3107] and this BGP route is the best selected 1016 for this FEC. 1018 Downstream access LSR/ABR may respond with a Label Mapping with 1019 explicit-null or implicit-null label if it is acting as an egress for 1020 the requested FEC, or it may respond with "No Route" notification if 1021 no route exists. 1023 4.3.2. Label Request Retry 1025 Following LDP specification LDP specification [RFC5036], if an access 1026 LSR/ABR receives a "No route" Notification in response to its Label 1027 Request message, it should retry using an exponential backoff 1028 algorithm similar to the backoff algoritm mentioned in the LDP 1029 session negotiation described in Section 4.2. 1031 If there is no response to the sent Label Request message, the LDP 1032 specification [RFC5036] (section A.1.1, page# 100) states that the 1033 LSR should not send another request for the same label to the peer 1034 and mandates that a duplicate Label Request is considered a protocol 1035 error and should be dropped by the receiving LSR by sending a 1036 Notification message. 1038 Thus, if there is no response from the downstream peer, the access 1039 LSR/ABR should not send a duplicate Label Request message again. 1041 If the static route corresponding to the FEC gets deleted or if the 1042 DoD request policy is modified to reject the FEC before receiving the 1043 Label Mapping message, then the access LSR/ABR should send a Label 1044 Abort message to the downstream LSR. 1046 To address the case of slower convergence resulting from described 1047 LDP behavior in line with LDP specification [RFC5036], a new LDP TLV 1048 extension is proposed and described in Section 5. 1050 4.4. Label Withdraw 1051 If an MPLS label on the downstream access LSR/ABR is no longer valid, 1052 the downstream access LSR/ABR withdraws this FEC/label binding from 1053 the upstream access LSR/ABR with the Label Withdraw Message [RFC5036] 1054 with a specified label TLV or with an empty label TLV. 1056 Downstream access LSR/ABR should withdraw a label for specific FEC in 1057 the following cases: 1059 a. If LDP DoD ingress label is associated with an outgoing label 1060 assigned by BGP labelled unicast route, and this route is 1061 withdrawn. 1063 b. If LDP DoD ingress label is associated with an outgoing label 1064 assigned by LDP (DoD or DU) and the IGP route is withdrawn from 1065 the RIB or downstream LDP session is lost. 1067 c. If LDP DoD ingress label is associated with an outgoing label 1068 assigned by LDP (DoD or DU) and the outgoing label is withdrawn 1069 by the downstream LSR. 1071 d. If LDP DoD ingress label is associated with an outgoing label 1072 assigned by LDP (DoD or DU), route next-hop changed and 1074 * there is no LDP session to the new next-hop. To minimize 1075 probability of this, the access LSR/ABR should implement LDP- 1076 IGP synchronization procedures as specified in [RFC5443]. 1078 * there is an LDP session but no label from downstream LSR. See 1079 note below. 1081 e. If access LSR/ABR is configured with a policy to reject exporting 1082 label mappings to upstream LSR. 1084 The upstream access LSR/ABR responds to the Label Withdraw Message 1085 with the Label Release Message [RFC5036]. 1087 After sending Label Release message to downstream access LSR/ABR, the 1088 upstream access LSR/ABR should resend Label Request message, assuming 1089 upstream access LSR/ABR still requires the label. 1091 Downstream access LSR/ABR should withdraw a label if the local route 1092 configuration (e.g. /32 loopback) is deleted. 1094 Note: For any events inducing next hop change, downstream access LSR/ 1095 ABR should attempt to converge the LSP locally before withdrawing the 1096 label from an upstream access LSR/ABR. For example if the next-hop 1097 changes for a particular FEC and if the new next-hop allocates labels 1098 by LDP DoD session, then the downstream access LSR/ABR must send a 1099 Label Request on the new next-hop session. If downstream access LSR/ 1100 ABR doesn't get Label Mapping for some duration, then and only then 1101 downstream access LSR/ABR must withdraw the upstream label. 1103 4.5. Label Release 1105 If an access LSR/ABR does not need any longer a label for a FEC, it 1106 sends a Label Release Message [RFC5036] to the downstream access LSR/ 1107 ABR with or without the label TLV. 1109 If upstream access LSR/ABR receives an unsolicited Label Mapping on 1110 DoD session, they should release the label by sending Label Release 1111 message. 1113 Access LSR/ABR should send a Label Release message to the downstream 1114 LSR in the following cases: 1116 a. If it receives a Label Withdraw from the downstream access LSR/ 1117 ABR. 1119 b. If the /32 static route with LDP DoD Label Request policy is 1120 deleted. 1122 c. If the service gets decommissioned and there is no corresponding 1123 /32 static route with LDP DoD Label Request policy configured. 1125 d. If the route next-hop changed, and the label does not point to 1126 the best or alternate next-hop. 1128 e. If it receives a Label Withdraw from a downstream DoD session. 1130 4.6. Local Repair 1132 To support local-repair with ECMP and IPFRR LFA, access LSR/ABR must 1133 request labels on both the best next-hop and the alternate next-hop 1134 LDP DoD sessions, as specified in the Label Request procedures in 1135 Section 4.3. If remote LFA is enabled, access LSR/ABR needs a label 1136 from its alternate next-hop toward the PQ node and needs a label from 1137 the remote PQ node toward its FEC/destination. If access LSR/ABR 1138 doesn't already know those labels, it must request them. 1140 This will enable access LSR/ABR to pre-program the alternate 1141 forwarding path with the alternate label(s), and invoke IPFRR LFA 1142 switch-over procedure if the primary next-hop link fails. 1144 5. LDP Extension for LDP DoD Fast-Up Convergence 1145 In some conditions, the exponential backoff algorithm usage described 1146 in Section 4.3.2 may result in a longer than desired wait time to get 1147 a successful LDP label to route mapping. An example is when a 1148 specific route is unavailable on the downstream LSR when the Label 1149 Mapping request from the upstream is received, but later comes back. 1150 In such case using the exponential backoff algorithm may result in a 1151 max delay wait time before the upstream LSR sends another LDP Label 1152 Request. 1154 This section describes an extension to the LDP DoD procedure to 1155 address fast-up convergence, and as such should be treated as a 1156 normative reference. The downstream and upstream LSRs SHOULD 1157 implement this extension if the improvement in up convergence is 1158 desired. 1160 The extension consists of the upstream LSR indicating to the 1161 downstream LSR that the Label Request SHOULD be queued on the 1162 downstream LSR until the requested route is available. 1164 To implement this behavior, a new Optional Parameter is defined for 1165 use in the Label Request message: 1167 Optional Parameter Length Value 1168 Queue Request TLV 0 see below 1170 0 1 2 3 1171 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 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 |1|0| Queue Request (0x0971) | Length (0x00) | 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 U-bit = 1 1177 Unknown TLV bit. Upon receipt of an unknown TLV, due to U-bit 1178 being set (=1), the unknown TLV MUST be silently ignored and the 1179 rest of the message processed as if the unknown TLV did not exist. 1180 In case requested route is not available, the downstream LSR MUST 1181 ignore this unknown TLV and send a "no route" notification back. 1182 Ensures backward compatibility. 1184 F-bit = 0 1185 Forward unknown TLV bit. This bit applies only when the U-bit is 1186 set and the LDP message containing the unknown TLV is to be 1187 forwarded. Due to F-bit being clear (=0), the unknown TLV is not 1188 forwarded with the containing message. 1190 Type 1191 Queue Request Type value to be allocated by IANA. 1193 Length = 0x00 1194 Specifies the length of the Value field in octets. 1196 Specified operation is as follows. 1198 To benefit from the fast-up convergence improvement, the upstream LSR 1199 sends a Label Request message with a Queue Request TLV. 1201 If the downstream LSR supports the Queue Request TLV, it verifies if 1202 route is available and if so it replies with Label Mapping as per 1203 existing LDP procedures. If the route is not available, the 1204 downstream LSR queues the request and replies as soon as the route 1205 becomes available. In the meantime, it does not send a "no route" 1206 notification back. When sending a Label Request with the Queue 1207 Request TLV, the upstream LSR does not retry the Label Request 1208 message if it does not receive a reply from its downstream peer 1210 If the upstream LSR wants to abort an outstanding Label Request while 1211 the Label Request is queued in the downstream LSR, the upstream LSR 1212 sends a Label Abort Request message, making the downstream LSR to 1213 remove the original request from the queue and send back a 1214 notification Label Request Aborted [RFC5036]. 1216 If the downstream LSR does not support the Queue Request TLV, and 1217 requested route is not available, it ignores this unknown TLV and 1218 sends a "no route" notification back in line with [RFC5036]. In this 1219 case the upstream LSR invokes the exponential backoff algorithm 1220 described in Section 4.3.2 following standard LDP specification LDP 1221 specification [RFC5036]. 1223 This described procedure ensures backward compatitibility. 1225 6. IANA Considerations 1227 6.1. LDP TLV TYPE 1229 This document uses a new a new Optional Parameter Queue Request TLV 1230 in the Label Request message defined in Section 5. IANA already 1231 maintains a registry of name LDP "TLV TYPE NAME SPACE" defined by 1232 RFC5036. The following value is suggested for assignment: 1234 TLV type Description 1235 0x0971 Queue Request TLV 1237 7. Security Considerations 1238 MPLS LDP Downstream on Demand deployment in the access network is 1239 subject to similar security threats as any MPLS LDP deployment. It 1240 is recommended that baseline security measures are considered as 1241 described in Security Framework for MPLS and GMPLS networks [RFC5920] 1242 and the LDP specification [RFC5036] including ensuring authenticity 1243 and integrity of LDP messages, as well as protection against spoofing 1244 and Denial of Service attacks. 1246 Some deployments may require increased measures of network security 1247 if a subset of Access Nodes are placed in locations with lower levels 1248 of physical security e.g. street cabinets (common practice for VDSL 1249 access). In such cases it is the responsibility of the system 1250 designer to take into account the physical security measures 1251 (environmental design, mechanical or electronic access control, 1252 intrusion detection), as well as monitoring and auditing measures 1253 (configuration and Operating System changes, reloads, routes 1254 advertisements). 1256 But even with all this in mind, the designer still should consider 1257 network security risks and adequate measures arising from the lower 1258 level of physical security of those locations. 1260 7.1. Security and LDP DoD 1262 7.1.1. Access to network packet flow direction 1264 An important property of MPLS LDP Downstream on Demand operation is 1265 that the upstream LSR (requesting LSR) accepts only mappings it sent 1266 a request for (in other words the ones it is interested in), and does 1267 not accept any unsolicited label mappings by design. 1269 This limits the potential of an unauthorized third party fiddling 1270 with label mappings operations on the wire. It also enables ABR LSR 1271 to monitor behaviour of any Access LSR in case the latter gets 1272 compromised and attempts to get access to an unauthorized FEC or 1273 remote LSR. Note that ABR LSR is effectively acting as a gateway to 1274 the MPLS network, and any Label Mapping requests made by any Access 1275 LSR are processed and can be monitored on this ABR LSR. 1277 7.1.2. Network to access packet flow direction 1279 Another important property of MPLS LDP DoD operation in the access is 1280 that the number of access nodes and associated MPLS FECs per ABR LSR 1281 is not large in number, and they are all known at the deployment 1282 time. Hence any changes of the access MPLS FECs can be easily 1283 controlled and monitored on the ABR LSR. 1285 And then, even in the event when Access LSR manages to advertise a 1286 FEC that belongs to another LSR (e.g. in order to 'steal' third 1287 party data flows, or breach a privacy of VPN), such Access LSR will 1288 have to influence the routing decision for affected FEC on the ABR 1289 LSR. Following measures should be considered to prevent such event 1290 from occurring: 1292 a. ABR LSR - access side with static routes - this is not possible 1293 for Access LSR. Access LSR has no way to influence ABR LSR 1294 routing decisions due to static nature of routing configuration 1295 here. 1297 b. ABR LSR - access side with IGP - this is still not possible if 1298 the compromised Access LSR is a leaf in the access topology (leaf 1299 node in topologies I1, I, V, Y described earlier in this 1300 document), due to the leaf metrics being configured on the ABR 1301 LSR. If the compromised Access LSR is a transit LSR in the 1302 access topology (transit node in topologies I, Y, U), it is 1303 possible for this Access LSR to attract to itself traffic 1304 destined to the nodes upstream from it. However elaborate such 1305 'man in the middle attack' is possible, but can be quickly 1306 detected by upstream Access LSRs not receiving traffic, and 1307 legitimate traffic from them getting dropped. 1309 c. ABR LSR - network side - designer should consider giving a higher 1310 administrative preference to the labeled unicast BGP routes vs. 1311 access IGP routes. 1313 In summary MPLS in access design with LDP DoD has number of native 1314 properties that prevent number of security attacks and make their 1315 detection quick and straightforward. 1317 Following two sections describe other security considerations 1318 applicable to general MPLS deployments in the access. 1320 7.2. Data Plane Security 1322 Data plane security risks applicable to the access MPLS network are 1323 listed below (a non-exhaustive list): 1325 a. packets from a specific access node flow to an altered transport 1326 layer or service layer destination. 1328 b. packets belonging to undefined services flow to and from the 1329 access network. 1331 c. unlabelled packets destined to remote network nodes. 1333 Following mechanisms should be considered to address listed data 1334 plane security risks: 1336 1. addressing (a) - Access and ABR LSRs should NOT accept labeled 1337 packets over a particular data link, unless from the Access or 1338 ABR LSR perspective this data link is known to attach to a 1339 trusted system based on employed authentication mechanism(s), and 1340 the top label has been distributed to the upstream neighbour by 1341 the receiving Access or ABR LSR. 1343 2. addressing (a) - ABR LSR MAY restrict network reachability for 1344 access devices to a subset of remote network LSR, based on 1345 authentication or other network security technologies employed 1346 towards Access LSRs. Restricted reachability can be enforced on 1347 the ABR LSR using local routing policies, and can be distributed 1348 towards the core MPLS network using routing policies associated 1349 with access MPLS FECs. 1351 3. addressing (b) - labeled service routes (e.g. MPLS/VPN, tLDP) 1352 are not accepted from unreliable routing peers. Detection of 1353 unreliable routing peers is achieved by engaging routing protocol 1354 detection and alarm mechanisms, and is out of scope of this 1355 document. 1357 4. addressing (a) and (b) - no successful attacks have been mounted 1358 on the control plane and has been detected. 1360 5. addressing (c) - ABR LSR MAY restrict IP network reachability to 1361 and from the access LSR. 1363 7.3. Control Plane Security 1365 Similarly to Inter-AS MPLS/VPN deployments [RFC4364], the control 1366 plane security is prerequisite to the data plane security. 1368 To ensure control plane security access LDP DoD sessions should only 1369 be established with LDP peers that are considered trusted from the 1370 local LSR perspective, meaning they are reachable over a data link 1371 that is known to attach to a trusted system based on employed 1372 authentication mechanism(s) on the local LSR. 1374 The security of LDP sesions is analyzed in 1375 [I-D.ietf-karp-routing-tcp-analysis], and its reading is recommended. 1376 Specifically the TCP/IP MD5 authentication option [RFC5925] should be 1377 used with LDP as described in LDP specification [RFC5036]. If TCP/IP 1378 MD5 authentication is considered not secure enough, the designer may 1379 consider using a more elaborate and advanced TCP Authentication 1380 Option TCP-AO [RFC5925] for LDP session authentication. 1382 Access IGP (if used) and any routing protocols used in access network 1383 for signaling service routes should also be secured in a similar 1384 manner. Refer to [I-D.ietf-karp-routing-tcp-analysis] and [RFC6863] 1385 for further analysis of security properties of IS-IS and OSPF IGP 1386 routing protocols. 1388 For increased level of authentication in the control plane security 1389 for a subset of access locations with lower physical security, 1390 designer could also consider using: 1392 o different crypto keys for use in authentication procedures for 1393 these locations. 1395 o stricter network protection mechanisms including DoS protection, 1396 interface and session flap dampening. 1398 7.4. Network Node Security 1400 If a network node, especially an Access Node, is not located in a 1401 physically secured and controlled location, then this Access Node 1402 should implement some measures to provide a level of protection of 1403 the key(s) used to its authenticate to the network, so as to avoid an 1404 attacker to get those keys easily. Software tools should monitor and 1405 keep checking the integrity of the Access Node configuration and 1406 software version. Note that this is not specific to the node using 1407 LDP DoD. In the contrary, the use of LDP DoD will allow the upstream 1408 /network to check, log and possibly deny the FEC requests from the 1409 Access Node. 1411 8. Acknowledgements 1413 The authors would like to thank Nischal Sheth, Nitin Bahadur, Nicolai 1414 Leymann, Geraldine Calvignac, Ina Minei, Eric Gray and Lizhong Jin 1415 for their suggestions and review. 1417 9. References 1419 9.1. Normative References 1421 [I-D.ietf-mpls-seamless-mpls] 1422 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 1423 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 1424 ietf-mpls-seamless-mpls-02 (work in progress), October 1425 2012. 1427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1428 Requirement Levels", BCP 14, RFC 2119, March 1997. 1430 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1431 Label Switching Architecture", RFC 3031, January 2001. 1433 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1434 Networks (VPNs)", RFC 4364, February 2006. 1436 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 1437 Heron, "Pseudowire Setup and Maintenance Using the Label 1438 Distribution Protocol (LDP)", RFC 4447, April 2006. 1440 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1441 Specification", RFC 5036, October 2007. 1443 [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension 1444 for Inter-Area Label Switched Paths (LSPs)", RFC 5283, 1445 July 2008. 1447 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 1448 Networks", RFC 5920, July 2010. 1450 9.2. Informative References 1452 [I-D.ietf-karp-routing-tcp-analysis] 1453 Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1454 BGP, LDP, PCEP and MSDP Issues According to KARP Design 1455 Guide", draft-ietf-karp-routing-tcp-analysis-07 (work in 1456 progress), April 2013. 1458 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 1459 BGP-4", RFC 3107, May 2001. 1461 [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP 1462 Synchronization", RFC 5443, March 2009. 1464 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1465 Authentication Option", RFC 5925, June 2010. 1467 [RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security 1468 According to the Keying and Authentication for Routing 1469 Protocols (KARP) Design Guide", RFC 6863, March 2013. 1471 Authors' Addresses 1472 Thomas Beckhaus 1473 Deutsche Telekom AG 1474 Heinrich-Hertz-Strasse 3-7 1475 Darmstadt 64307 1476 Germany 1478 Phone: +49 6151 58 12825 1479 Email: thomas.beckhaus@telekom.de 1481 Bruno Decraene 1482 France Telecom 1483 38-40 rue du General Leclerc 1484 Issy Moulineaux cedex 9 92794 1485 France 1487 Email: bruno.decraene@orange.com 1489 Kishore Tiruveedhula 1490 Juniper Networks 1491 10 Technology Park Drive 1492 Westford, Massachusetts 01886 1493 USA 1495 Phone: 1-(978)-589-8861 1496 Email: kishoret@juniper.net 1498 Maciek Konstantynowicz 1499 Cisco Systems, Inc. 1500 10 New Square Park, Bedfont Lakes 1501 London 1502 United Kingdom 1504 Email: maciek@cisco.com 1506 Luca Martini 1507 Cisco Systems, Inc. 1508 9155 East Nichols Avenue, Suite 400 1509 Englewood, CO 80112 1510 USA 1512 Email: lmartini@cisco.com