idnits 2.17.1 draft-gredler-ospf-label-advertisement-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.gredler-rtgwg-igp-label-advertisement]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 42 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 21, 2013) is 3993 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-mrt-frr-architecture-02 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Shortest Path First IGP H. Gredler, Ed. 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Standards Track S. Amante 5 Expires: November 22, 2013 Level 3 Communications, Inc. 6 T. Scholl 7 Amazon 8 L. Jalil 9 Verizon 10 May 21, 2013 12 Advertising MPLS labels in OSPF 13 draft-gredler-ospf-label-advertisement-03 15 Abstract 17 Historically MPLS label distribution was driven by protocols like 18 LDP, RSVP and LBGP. All of those protocols are session oriented. In 19 order to obtain label binding for a given destination FEC from a 20 given router one needs first to establish an LDP/RSVP/LBGP session 21 with that router. 23 Advertising MPLS labels in IGPs 24 [I-D.gredler-rtgwg-igp-label-advertisement] describes several use 25 cases where utilizing the flooding machinery of link-state protocols 26 for MPLS label distribution allows to obtain the binding without 27 requiring to establish an LDP/RSVP/LBGP session with that router. 29 This document describes the protocol extension to distribute MPLS 30 label bindings by the OSPFv2 and OSPFv3 protocol. 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 RFC 2119 [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 22, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 2. Motivation, Rationale and Applicability . . . . . . . . . . . 5 74 2.1. Issue: Bi-directionality semantics . . . . . . . . . . . . 6 75 2.2. Issue: IP path semantics . . . . . . . . . . . . . . . . . 6 76 2.3. Issue: Lack of 'path' notion . . . . . . . . . . . . . . . 6 77 2.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7 78 3. OSPF MPLS LSA Format . . . . . . . . . . . . . . . . . . . . . 7 79 3.1. Common LSA Type . . . . . . . . . . . . . . . . . . . . . 7 80 3.2. OSPFv2 LSA ID . . . . . . . . . . . . . . . . . . . . . . 7 81 3.3. OSPFv2 LSA Format Overview . . . . . . . . . . . . . . . . 8 82 3.4. OSPFv3 LSA ID . . . . . . . . . . . . . . . . . . . . . . 8 83 3.5. OSPFv3 LSA Format Overview . . . . . . . . . . . . . . . . 9 84 3.6. TLV Header . . . . . . . . . . . . . . . . . . . . . . . . 9 85 4. LSA payload details . . . . . . . . . . . . . . . . . . . . . 10 86 4.1. ERO TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 4.1.1. IPv4 Prefix ERO TLV . . . . . . . . . . . . . . . . . 10 88 4.1.2. IPv6 Prefix ERO TLV . . . . . . . . . . . . . . . . . 11 89 4.1.3. Unnumbered Interface ID ERO TLV . . . . . . . . . . . 12 90 4.1.4. IPv4 Prefix Bypass ERO TLV . . . . . . . . . . . . . . 13 91 4.1.5. IPv6 Prefix Bypass ERO TLV . . . . . . . . . . . . . . 13 92 4.1.6. Unnumbered Interface ID Bypass ERO TLV . . . . . . . . 14 93 4.2. Flags TLV . . . . . . . . . . . . . . . . . . . . . . . . 15 94 4.3. All Router Block TLV . . . . . . . . . . . . . . . . . . . 15 95 4.4. All Router ID IPv4 Map TLV . . . . . . . . . . . . . . . . 17 96 4.5. All Router ID IPv6 Map TLV . . . . . . . . . . . . . . . . 18 97 5. Advertising Label Examples . . . . . . . . . . . . . . . . . . 18 98 5.1. Sample Topology . . . . . . . . . . . . . . . . . . . . . 18 99 5.1.1. Transport IP addresses and router-IDs . . . . . . . . 19 100 5.1.2. Link IP addresses . . . . . . . . . . . . . . . . . . 19 101 5.2. One-hop LSP to an adjacent Router . . . . . . . . . . . . 20 102 5.3. One-hop LSP to an adjacent Router using a specific link . 20 103 5.4. One-hop LSP to an adjacent external Router . . . . . . . . 20 104 5.5. Advertisement of an RSVP LSP . . . . . . . . . . . . . . . 21 105 5.6. Advertisement of an LDP LSP . . . . . . . . . . . . . . . 21 106 5.7. Interarea advertisement of diverse paths . . . . . . . . . 21 107 5.8. Advertisement of SPT labels using 'All Router Block' 108 TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 109 5.9. Expansion of an 'All Router Block' TLV . . . . . . . . . . 23 110 6. Inter Area Protocol Procedures . . . . . . . . . . . . . . . . 24 111 6.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 24 112 6.2. Data plane operations . . . . . . . . . . . . . . . . . . 24 113 6.3. Control plane operations . . . . . . . . . . . . . . . . . 24 114 6.3.1. MPLS Label operations . . . . . . . . . . . . . . . . 24 115 6.3.2. MPLS Label Block operations . . . . . . . . . . . . . 25 116 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 117 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 118 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 119 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 120 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 121 10.2. Informative References . . . . . . . . . . . . . . . . . . 27 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 124 1. Introduction 126 MPLS label allocations are predominantly distributed by using the LDP 127 [RFC5036], RSVP [RFC5151] or labeled BGP [RFC3107] protocol. All of 128 those protocols have in common that they are session oriented, which 129 means that in order to obtain label binding for a given destination 130 FEC from a given router one needs first to establish a direct control 131 plane (LDP/RSVP/LBGP) session with that router. 133 There are a couple of practical use cases 134 [I-D.gredler-rtgwg-igp-label-advertisement] where the consumer of a 135 MPLS label binding may not be adjacent to the router that performs 136 the binding. Bringing up an explicit session using the existing 137 label distribution protocols between the non-adjacent router that 138 binds the label and the router that acts as a consumer of this 139 binding is the existing remedy for this dilemma. 141 This document describes an OSPFv2 and OSPFv3 protocol extension which 142 allows routers to advertise MPLS label bindings within and beyond an 143 IGP domain, and controlling inter-area distribution. 145 2. Motivation, Rationale and Applicability 147 Distributing MPLS labels in an IGP (IS-IS) has been described in 148 Segment Routing [I-D.previdi-filsfils-isis-segment-routing]. The 149 authors propose to re-use existing traffic-engineering extensions for 150 carrying the label information. While retrofitting existing protocol 151 machinery for new purposes is generally a good thing, Segment Routing 152 [I-D.previdi-filsfils-isis-segment-routing] falls short of addressing 153 some use-cases defined in 154 [I-D.gredler-rtgwg-igp-label-advertisement]. 156 The dominant issue around re-using traffic-engineering extensions is 157 that both have existing protocol semantics, which might not be 158 applicable to advertising MPLS label switched paths in a generic 159 fashion. These are specifically: 161 o Bi-directionality semantics 163 o IP path semantics 165 o Lack of 'path' notion 167 2.1. Issue: Bi-directionality semantics 169 'Bi-directionality semantics', affects the complexity around 170 advertisement of unidirectional LSPs. Label advertisement of per- 171 link labels or 'Adj-SIDs' [I-D.previdi-filsfils-isis-segment-routing] 172 is done by attaching label information to adjacency advertisment 173 TLVs. Usually implementations need to have an adjacency in 'Up' 174 state prior to advertising this adjacency as TE-Link in its Link 175 State advertisment. In order to advertise a per-link LSP an 176 implementation first needs to have an adjacency, which only 177 transitions to 'Up' state after passing the 3-way check. This 178 implies bi-directionality. If an implementation wants to advertise 179 per-link MPLS LSPs to e.g. outside the IGP domain then it would need 180 to fake-up an adjacency. Changing existing IGP Adjacency code to 181 support such cases defeats the purpose of re-using existing 182 functionality as there is not much common functionality to be shared. 184 2.2. Issue: IP path semantics 186 LSPs pointing to a Node are advertised as 'Node-SIDs' 187 [I-D.previdi-filsfils-isis-segment-routing] using IP Prefix 188 containers. That means that in order to advertise a MPLS LSP, one is 189 inheriting the semantics of advertising an IP path. Consider router 190 A has got existing LSPs to its entire one-hop neighborhood and is re- 191 advertising those LSPs using IP reachability semantics. Now we have 192 two exact matching IP advertisements. One from the owning router 193 (router B) which advertises its stable transport loopback address and 194 another one from router A re-advertising a LSP path to router B. 195 Existing routing software may get confused now as the 'stable 196 transport' address shows up from multiple places in the network and 197 more worse the IP forwarding path for control-plane protocols may get 198 mingled with the MPLS data plane. 200 2.3. Issue: Lack of 'path' notion 202 Both exisiting traffic-engineering extension containers have limited 203 semantics describing MPLS label-switched paths in the sense of a 204 'path'. Both encoding formats allow to express a pointer to some 205 specific router, but not to describe a MPLS label switched path 206 containing all of its path segments. 207 [I-D.previdi-filsfils-isis-segment-routing] allows to define 208 'Forwarding Adjacencies' as per [RFC4206]. The way to describe a 209 path of a given forwarding adjacency is to enlist a list of "Segment 210 IDs". That implies that nodes which do not yet participate in 211 'Segment routing' or are outside of a 'Segment routing' domain can 212 not be expressed using those path semantics. 214 A protocol for advertising MPLS label switched paths, should be 215 generic enough to express paths sourced by existing MPLS LSPs, such 216 that ingress routers can flexibly combine them according to 217 application needs. 219 2.4. Motivation 221 IGP advertisement of MPLS label switched paths requires a new set of 222 protocol semantics (undirectional paradigm, path paradigm), which 223 hardly can be expressed using the existing OSPF and OSPF-TE protocol 224 semantics. This document describes protocol extensions which allows 225 generic advertisement of MPLS label bindings in the OSPFv2 and OSPFv3 226 protocol. 228 The Protocol extensions described in this document are equally 229 applicable to IPv4 and IPv6 carried over MPLS. Furthermore the 230 proposed use of distributing MPLS Labels using IGP prototocols 231 adheres to the architectural principles laid out in [RFC3031]. 233 3. OSPF MPLS LSA Format 235 3.1. Common LSA Type 237 One new LSA is defined, the MPLS Label LSA. This LSA advertises MPLS 238 labels along with their path information. The LSA contains more 239 specific information encoded in TLVs. Those TLV extensions are 240 shared between the OSPFv2 and OPSFv3 protocols. 242 3.2. OSPFv2 LSA ID 244 The LSA ID of an Opaque LSA is defined as having eight bits of type 245 data and 24 bits of type-specific data. The MPLS Label LSA uses type 246 149. The remaining 24 bits are 4 zero bits followed by the MPLS 247 Label or MPLS Label Base value as follows: 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | 149 |0|0|0|0| MPLS Label | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 1: OSPFv2 MPLS Label LSA-ID format 257 The 'MPLS Label' field holds the 20 Bit MPLS label for MPLS Label 258 base. Therefore a maximum of 2^20 MPLS Label LSAs may be sourced by 259 a single system. 261 3.3. OSPFv2 LSA Format Overview 263 This extension makes use of the Opaque LSAs [RFC5250]. 265 Three types of Opaque LSAs exist, each of which has a different 266 flooding scope. This proposal uses only Type 10 LSAs, which have an 267 area flooding scope. 269 The MPLS Label LSA for OSPFv2 starts with the standard OSPFv2 LSA 270 header: 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | LS age | Options | 10 | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | 149 |0|0|0|0| MPLS Label | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Advertising Router | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | LS sequence number | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | LS checksum | length | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | | 286 +- TLVs -+ 287 | ... | 289 Figure 2: OSPFv2 MPLS Label LSA format 291 3.4. OSPFv3 LSA ID 293 The OSPFv3 LSA ID of an MPLS Label LSA is defined as having twelve 294 bits of zero followed by the 20-Bit label MPLS Label value as 295 follows: 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 |0|0|0|0|0|0|0|0|0|0|0|0| MPLS Label | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Figure 3: OSPFv3 MPLS Label LSA-ID format 305 The 'MPLS Label' field holds the 20 Bit MPLS label or MPLS label base 306 value. Therefore a maximum of 2^20 MPLS Label LSAs may be sourced by 307 a single system. 309 3.5. OSPFv3 LSA Format Overview 311 The MPLS Label LSA for OSPFv3 starts with the standard OSPFv3 LSA 312 header: 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | LS age |1|0|1| 149 | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 |0|0|0|0|0|0|0|0|0|0|0|0| MPLS Label | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Advertising Router | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | LS sequence number | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | LS checksum | Length | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | | 328 +- TLVs -+ 329 | ... | 331 Figure 4: OSPFv3 MPLS Label LSA format 333 The OSPFv3 'U' Bit will always be set such that routers which do not 334 understand the new MPLS Label LSA will store and forward it further. 336 In analogy to the OSPFv2 opaque LSA 10 the flooding scope will be set 337 to 'Area scoping'. 339 3.6. TLV Header 341 The LSA payload consists of one or more nested Type/Length/Value 342 (TLV) triplets for extensibility. The format of each TLV is: 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Type | Length | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Value... | 350 . . 351 . . 352 . . 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Figure 5: TLV format 357 The Length field defines the length of the value portion in octets 358 (thus a TLV with no value portion would have a length of zero). The 359 TLV is padded to four-octet alignment; padding is not included in the 360 length field (so a three octet value would have a length of three, 361 but the total size of the TLV would be eight octets). Nested TLVs 362 are also 32-bit aligned. Unrecognized types are ignored. 364 This memo defines TLV Types 1 through 8. See the IANA Considerations 365 section for allocation of new Types. 367 4. LSA payload details 369 The MPLS Label LSA may be originated by any Traffic Engineering 370 [RFC3630] capable router in an OSPF domain. The router may advertise 371 a single label binding or a block of label bindings. For single 372 label binding advertisement a router needs to provide at least a 373 single 'nexthop style' anchor. The protocol supports more than one 374 'nexthop style' anchor to be attached to a Label binding, which 375 results into a simple path description language. In analogy to RSVP 376 the terminology for this is called an 'Explicit Route Object' (ERO). 377 Since ERO style path notation allows to anchor label bindings to to 378 both link and node IP addresses any label switched path, can be 379 described. Furthermore also Label Bindings from other protocols can 380 get easily re-advertised. 382 An LSA contains one or more TLVs, describing properties of the 383 advertised MPLS label. 385 The following TLV extensions may be shared in both OSPV2 and OSPFv3. 386 Passing an IP address of the other address family (IPv4 in OPSFv3 or 387 IPv6 in OSPFv2) is possible as the information carried are related 388 describing the hops along a path. The receiver of this information 389 is a protocol agnostic path computation module. 391 4.1. ERO TLVs 393 All 'ERO' information represents an ordered set which describes the 394 segments of a label-switched path. The last ERO TLV describes the 395 segment closest to the egress point of the LSP. Contrary the first 396 ERO TLV describes the first segment of a label switched path. If a 397 router extends or stitches a label switched path it MUST prepend the 398 new segments path information to the ERO list. 400 4.1.1. IPv4 Prefix ERO TLV 402 The IPv4 ERO TLV (Type 1) describes a path segment using IPv4 Prefix 403 style of encoding. Its appearance and semantics have been borrowed 404 from Section 4.3.3.2 [RFC3209]. 406 the 'IPv4 Address' is treated as a prefix based on the prefix length 407 value below. Bits beyond the prefix are ignored on receipt and 408 SHOULD be set to zero on transmission. 410 The 'Prefix Length' field contains the length of the prefix in bits. 412 The 'L' bit in the TLV is a one-bit attribute. If the L bit is set, 413 then the value of the attribute is 'loose.' Otherwise, the value of 414 the attribute is 'strict.' 416 The 'Reserved' bits are for future use. They should be zero on 417 transmission and ignored on receipt. 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Type | Length | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | IPv4 Address (4 octets) | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Prefix Length |L| Reserved | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 Figure 6: IPv4 Prefix ERO TLV format 431 4.1.2. IPv6 Prefix ERO TLV 433 The IPv6 ERO TLV (Type 2) describes a path segment using IPv6 Prefix 434 style of encoding. Its appearance and semantics have been borrowed 435 from Section 4.3.3.2 [RFC3209]. 437 the 'IPv6 Address' is treated as a prefix based on the prefix length 438 value below. Bits beyond the prefix are ignored on receipt and 439 SHOULD be set to zero on transmission. 441 The 'Prefix Length' field contains the length of the prefix in bits. 443 The 'L' bit in the TLV is a one-bit attribute. If the L bit is set, 444 then the value of the attribute is 'loose.' Otherwise, the value of 445 the attribute is 'strict.' 447 The 'Reserved' bits are for future use. They should be zero on 448 transmission and ignored on receipt. 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Type | Length | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | IPv6 Address (16 octets) | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | IPv6 Address (continued) | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | IPv6 Address (continued) | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | IPv6 Address (continued) | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Prefix Length |L| Reserved | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 Figure 7: IPv6 Prefix ERO TLV format 468 4.1.3. Unnumbered Interface ID ERO TLV 470 The appearance and semantics of the 'Unnumbered Interface ID' have 471 been borrowed from Section 4 [RFC3477]. 473 The Unnumbered Interface-ID ERO TLV (Type 9) describes a path segment 474 that spans over an unnumbered interface. Unnumbered interfaces are 475 referenced using the interface index. Interface indices are assigned 476 local to the router and therefore not unique within a domain. All 477 elements in an ERO path need to be unique within a domain and hence 478 need to be disambiguated using a domain unique Router-ID. 480 The 'Router-ID' field contains the router ID of the router which has 481 assigned the 'Interface ID' field. Its purpose is to disambiguate 482 the 'Interface ID' field from other routers in the domain. 484 The 'Interface ID' is the identifier assigned to the link by the 485 router specified by the router ID. 487 The 'L' bit in the TLV is a one-bit attribute. If the L bit is set, 488 then the value of the attribute is 'loose.' Otherwise, the value of 489 the attribute is 'strict.' 491 The 'Reserved' bits are for future use. They should be zero on 492 transmission and ignored on receipt. 494 0 1 2 3 495 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 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Type | Length | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Router ID | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Interface ID | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 |L| Reserved | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Figure 8: Unnumbered Interface ID ERO TLV format 508 4.1.4. IPv4 Prefix Bypass ERO TLV 510 The IPv4 Bypass ERO TLV (Type 3) describes a Bypass LSP path segment 511 using IPv4 Prefix style of encoding. Its appearance and semantics 512 have been borrowed from Section 4.3.3.2 [RFC3209]. 514 The 'Prefix Length' field contains the length of the prefix in bits. 516 The 'L' bit in the TLV is a one-bit attribute. If the L bit is set, 517 then the value of the attribute is 'loose.' Otherwise, the value of 518 the attribute is 'strict.' 520 The 'Reserved' bits are for future use. They should be zero on 521 transmission and ignored on receipt. 523 0 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Type | Length | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | IPv4 Address (4 octets) | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Prefix Length |L| Reserved | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 Figure 9: IPv4 Prefix Bypass ERO TLV format 535 4.1.5. IPv6 Prefix Bypass ERO TLV 537 The IPv6 ERO TLV (Type 4) describes a Bypass LSP path segment using 538 IPv6 Prefix style of encoding. Its appearance and semantics have 539 been borrowed from Section 4.3.3.3 [RFC3209]. 541 The 'Prefix Length' field contains the length of the prefix in bits. 543 The 'L' bit in the TLV is a one-bit attribute. If the L bit is set, 544 then the value of the attribute is 'loose.' Otherwise, the value of 545 the attribute is 'strict.' 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Type | Length | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | IPv6 Address (16 octets) | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | IPv6 Address (continued) | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | IPv6 Address (continued) | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | IPv6 Address (continued) | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Prefix Length |L| Reserved | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 Figure 10: IPv6 Prefix Bypass ERO TLV format 565 4.1.6. Unnumbered Interface ID Bypass ERO TLV 567 The appearance and semantics of the 'Unnumbered Interface ID' have 568 been borrowed from Section 4 [RFC3477]. 570 The Unnumbered Interface-ID Bypass ERO TLV (Type 10) describes a 571 Bypass path segment that spans over an unnumbered interface. 572 Unnumbered interfaces are referenced using the interface index. 573 Interface indices are assigned local to the router and therefore not 574 unique within a domain. All elements in an ERO path need to be 575 unique within a domain and hence need to be disambiguated using a 576 domain unique Router-ID. 578 The 'Router-ID' field contains the router ID of the router which has 579 assigned the 'Interface ID' field. Its purpose is to disambiguate 580 the 'Interface ID' field from other routers in the domain. 582 The 'Interface ID' is the identifier assigned to the link by the 583 router specified by the router ID. 585 The 'L' bit in the TLV is a one-bit attribute. If the L bit is set, 586 then the value of the attribute is 'loose.' Otherwise, the value of 587 the attribute is 'strict.' 589 The 'Reserved' bits are for future use. They should be zero on 590 transmission and ignored on receipt. 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Type | Length | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Router ID | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Interface ID | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 |L| Reserved | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 Figure 11: Unnumbered Interface ID Bypass ERO TLV format 606 4.2. Flags TLV 608 The Flags TLV (Type 5) describes Flags for further MPLS LSA 609 treatment. 611 Up/Down 'U' Bit: A router may flood MPLS label information across 612 area boundaries. In order to prevent flooding loops, a router will 613 Set the Up/Down (U-Bit) when propagating MPLS labels from Area 0 to a 614 non-zero Area. 616 The 'Reserved' bits are for future use. They should be zero on 617 transmission and ignored on receipt. 619 0 1 2 3 620 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 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Type | Length | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 |U| Reserved | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 Figure 12: Flags TLV format 629 4.3. All Router Block TLV 631 The 'All Router Block' TLV (Type 6) denominates the label block size 632 of an MPLS Label advertisement and its semantics to connect to all 633 routers in a given OSPF domain using a local assigned [RFC3031] label 634 range. Note that the actual mapping of a router within the label 635 range is done using the TLVs described in Section 4.4 and 636 Section 4.5. Since generation of an IPv4 or IPv6 Map TLV is a local 637 policy decision, it might be the case that connectivity is provided 638 not to 'All' but rather a subset of 'All' routers. Keeping policy 639 decisions aside, for simplicity reasons, assume that All Routers in a 640 domain do generate either the 'All Router ID IPv4 Map' or 'All Router 641 ID IPv6 Map' TLVs and therefore all routers desire construction of a 642 Label switched path from every source router in the network. The 643 basic concept of using label blocks to provide connectivity to a set 644 of routers has been borrowed from [RFC4761] which allows to advertise 645 labels from multiple end-points using a single control-plane message. 646 The difference to [RFC4761] is that rather than advertising where a 647 particular packet came from (=source semantics), destination 648 semantics (where a particular packet will be going to) is advertised. 650 Along with each label block a router advertises one for more 'IDs'. 651 The 'ID' must be unique within a given domain. The 'ID' serves as 652 ordinal to determine the actual label value inside the set of all 653 advertised label ranges of a given router. A receiving router uses 654 the ordinal to determine the actual label value in order to construct 655 forwarding state to a particular destination router. The 'ID' is 656 separately advertised using the TLVs described in Section 4.4 and 657 Section 4.5. 659 The ability to advertise more than one label block eases operational 660 procedures for increasing the number of supported routers within a 661 domain. For example consider a given domain has got support for 662 routers and runs out of ID space. It simply advertises one more 663 label block to cover additional ordinals outside the range of the 664 first label block. An example of label-block expansion is described 665 in more detail in Section 5.9 667 0 1 2 3 668 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 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | Type | Length | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Block Size | Algo | Reserved| Topology-ID | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 Figure 13: All Router Block TLV format 677 The 'Block Size' value contains the size of the label advertisement. 678 The 'value determines the amount of reachable router endpoints within 679 a given Label block. It MUST contain a value greater or equal than 680 two. Note that the label base is inferred from the LSA-ID in the LSA 681 header. For example if a router wants to advertise a label range of 682 5000-5099 then it would need to generate a LSA-ID of 5000 (= 683 0.0.19.136) and a Block Size of 100. 685 The 'Algo' value denominates the path computation algorithm in order 686 to calculate the forwarding topology. The basic SPF algorithm has an 687 assigned 'Algo' code point of zero. The purpose of the 'Algo' field 688 is to extend the notion of Label Block Signaling to arbitrary 689 algorithms like for example 'MRT' 690 ([I-D.ietf-rtgwg-mrt-frr-architecture]. Advertised Label Blocks with 691 an unknown, unsupported or non-configured algorithm MUST be silently 692 ignored. 694 The 'Reserved' bits are for future use. They should be zero on 695 transmission and ignored on receipt. 697 The 'Topology-ID' field contains the Multi Topology ID ([RFC4915]) 698 for which the advertised Label Block does apply. The basic IPv4 699 unicast Topology has an assigned 'Topology-ID' code point of zero. 700 Advertised Label Blocks with an unknown, unsupported or non- 701 configured Topology-ID MUST be silently ignored. 703 An LSA containing the 'All Router Block' TLV MUST only contain the 704 Flags TLV (Section 4.2, the 'All Router IPv4 Map' TLV (Section 4.4) 705 or the 'All Router IPv6 Map' TLV (Section 4.5). 707 4.4. All Router ID IPv4 Map TLV 709 The 'All Router ID IPv4 Map' TLV (Type 7) maps an 'ID' to a given 710 stable transport IPv4 address. Its purpose is to associate a given 711 transport IPv4 IP address to the ordinal inside a label range as 712 described in Section 4.3. 714 A router MAY advertise more than one 'ID' to 'IPv4 address' mapping 715 pair, in case it has more than one stable transport IPv4 address. 717 0 1 2 3 718 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 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Type | Length | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | IPv4 Address (4 octets) | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | ID | Reserved | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 Figure 14: All Router ID IPv4 Map TLV format 729 The 'IPv4 address' contains stable IPv4 transport address of a given 730 router. 732 The 'ID' contains the ordinal value of an advertising router inside 733 the set of all advertised label blocks of a given router. 735 The 'Reserved' bits are for future use. They should be zero on 736 transmission and ignored on receipt. 738 4.5. All Router ID IPv6 Map TLV 740 The 'All Router ID IPv6 Map' TLV (Type 8) maps an 'ID' to a given 741 stable transport IPv6 address. Its purpose is to associate a given 742 transport IPv6 IP address to the ordinal inside a label range as 743 described in Section 4.3. 745 A router MAY advertise more than one 'ID' to 'IPv6 address' mapping 746 pair, in case it has more than one stable transport IPv6 address. 748 0 1 2 3 749 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 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Type | Length | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | IPv6 Address (16 octets) | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | IPv6 Address (continued) | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | IPv6 Address (continued) | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | IPv6 Address (continued) | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | ID | Reserved | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 Figure 15: All Router ID IPv6 Map TLV format 766 The 'IPv6 address' contains the stable IPv6 transport address of a 767 given router. 769 The 'ID' contains the ordinal value of an advertising router inside 770 the set of all advertised label blocks of a given router. 772 The 'Reserved' bits are for future use. They should be zero on 773 transmission and ignored on receipt. 775 5. Advertising Label Examples 777 5.1. Sample Topology 779 The following topology (Figure 16) and IP addresses shall be used 780 throughout the Label advertisement examples. 782 AS1 : AS 2 783 : 784 : : 785 Area 1 : Area 0 : 786 : : 787 +-----+ +-----+-IP3--1-IP4--+-----+ : 788 | R1 +-IP1--1-IP2--+ R2 | | R3 | : 789 +--+--+ +--+--+-IP5--3-IP6--+--+--+-IP15-IP16- 790 | | | : \ 791 IP9 IP7 IP13 : \ 792 | | | : +--+--+ 793 1 1 1 : | R7 | 794 | | | : +--+--+ 795 IP10 IP8 IP14 : / 796 | | | : / 797 +--+--+ +--+--+ +--+--+-IP17-IP18- 798 | R4 +-IP19-2-IP20-+ R5 |-IP11-2-IP12-| R6 | : 799 +-----+ +-----+ +-----+ : 800 : : 801 : : 802 : : 804 Figure 16: Sample Topology 806 5.1.1. Transport IP addresses and router-IDs 808 o R1: 192.168.1.1 810 o R2: 192.168.1.2 812 o R3: 192.168.1.3 814 o R4: 192.168.1.4 816 o R5: 192.168.1.5 818 o R6: 192.168.1.6 820 o R7: 192.168.1.7 822 5.1.2. Link IP addresses 824 o R1 to R2 link: 10.0.0.1, 10.0.0.2 826 o R1 to R4 link: 10.0.0.9, 10.0.0.10 828 o R2 to R3 link #1: 10.0.0.3, 10.0.0.4 829 o R2 to R3 link #2: 10.0.0.5, 10.0.0.6 831 o R2 to R5 link: 10.0.0.7, 10.0.0.8 833 o R3 to R6 link: 10.0.0.13, 10.0.0.14 835 o R3 to R7 link: 10.0.0.15, 10.0.0.16 837 o R4 to R5 link: 10.0.0.19, 10.0.0.20 839 o R5 to R6 link: 10.0.0.11, 10.0.0.12 841 o R6 to R7 link: 10.0.0.17, 10.0.0.18 843 The IGP link metrics are displayed in the middle of the link. All of 844 them are assumed to be bi-directional. 846 5.2. One-hop LSP to an adjacent Router 848 If R1 would advertise a label bound to a one-hop LSP from R1 to 849 R2 it would encode as follows: 851 LSA 149, LSA-ID : 853 IPv4 Prefix ERO TLV: 192.168.1.2/32, Strict 855 5.3. One-hop LSP to an adjacent Router using a specific link 857 If R2 would advertise a label bound to a one-hop LSP from R2 to 858 R3, using the link #2 it would encode as follows 860 LSA 149, LSA-ID : 862 IPv4 Prefix ERO TLV: 10.0.0.6/32, Strict 864 5.4. One-hop LSP to an adjacent external Router 866 If R3 would advertise a label bound to a one-hop LSP from R3 to 867 R7 (which is outside of the IGP domain), it would encode as follows: 869 LSA 149, LSA-ID : 871 IPv4 Prefix ERO TLV: 192.168.1.7/32, Strict 873 As you can see the representation of an MPLS label crossing an 874 external link is identical as an internal link Section 5.2. 876 5.5. Advertisement of an RSVP LSP 878 Consider a RSVP LSP name "R2-to-R6" traversing (R2 to R3 using link 879 #1, R6): 881 If R2 would advertise a label bound to the RSVP LSP named 882 'R2-to-R6', it would encode as follows 884 LSA 149, LSA-ID : 886 IPv4 Prefix ERO TLV: 10.0.0.4/32, Strict 888 IPv4 Prefix ERO TLV: 192.168.1.6/32, Strict 890 5.6. Advertisement of an LDP LSP 892 Consider R2 that creates a LDP label binding for FEC 172.16.0.0./12 893 using label . 895 If R2 would re-advertise this label binding in OSPF it would encode 896 as follows 898 LSA 149, LSA-ID : 900 IPv4 Prefix ERO TLV: 172.16.0.0/12, Loose 902 5.7. Interarea advertisement of diverse paths 904 Consider two R2->R6 paths: {R2, R3, R6} and {R2, R5, R6} 906 Consider two R5->R3 paths: {R5, R2, R3} and {R5, R6, R3} 908 R2 encodes its two paths to R6 as follows: 910 LSA 149, LSA-ID : 912 IPv4 Prefix ERO TLV: 192.168.1.3, Loose 914 IPv4 Prefix ERO TLV: 192.168.1.6, Loose 916 Flags TLV: Down 918 LSA 149, LSA-ID : 920 IPv4 Prefix ERO TLV: 192.168.1.5, Loose 922 IPv4 Prefix ERO TLV: 192.168.1.6, Loose 923 Flags TLV: Down 925 R5 encodes its two paths to R3 as follows: 927 LSA 149, LSA-ID : 929 IPv4 Prefix ERO TLV: 192.168.1.2, Loose 931 IPv4 Prefix ERO TLV: 192.168.1.3, Loose 933 Flags TLV: Down 935 LSA 149, LSA-ID : 937 IPv4 Prefix ERO TLV: 192.168.1.6, Loose 939 IPv4 Prefix ERO TLV: 192.168.1.3, Loose 941 Flags TLV: Down 943 A receiving non-backbone router does see now all 4 paths and may 944 decide to load-balance across all or a subset of them. 946 5.8. Advertisement of SPT labels using 'All Router Block' TLV 948 All routers within a given area MUST advertise their Label Blocks 949 along with an 'ID'. 951 If R2 would advertise a label block with a size of 10, declaring 952 SPT label forwarding support to all routers within a given domain, it 953 would encode as follows: 955 LSA 149, LSA-ID : 957 All Router Block TLV: Block Size 10, Algo 0, Topology-ID 0 959 All Router ID IPv4 Map TLV: ID 2, 192.168.1.2 961 If R3 would advertise a label block with a size of 10, declaring 962 SPT label forwarding support to all routers within a given domain, it 963 would encode as follows: 965 LSA 149, LSA-ID : 967 All Router Block TLV: Block Size 10, Algo 0, Topology-ID 0 969 All Router ID IPv4 Map TLV: ID 3, 192.168.1.3 971 If R5 would advertise a label block with a size of 10, declaring 972 SPT label forwarding support to all routers within a given domain, it 973 would encode as follows: 975 LSA 149, LSA-ID : 977 All Router Block TLV: Block Size 10, Algo 0, Topology-ID 0 979 All Router ID IPv4 Map TLV: ID 5, 192.168.1.5 981 If R6 would advertise a label block with a size of 10, declaring 982 SPT label forwarding support to all routers within a given domain, it 983 would encode as follows: 985 LSA 149, LSA-ID : 987 All Router Block TLV: Block Size 10, Algo 0, Topology-ID 0 989 All Router ID IPv4 Map TLV: ID 6, 192.168.1.6 991 Consider now R2 constructing a SPT label for R6. R2s SPT to R6 is 992 {R2, IP4, R3, R6}. R2 first determines if its downstream router (R3) 993 has advertised a label-block. Since R3 has advertised a label block 994 'N2' and it has received R6 'ID' of 6 it will be picking the 6th 995 label value inside the advertised range of its downstream neighbor. 996 Specifically R2 MUST be program a MPLS SWAP for its own label range 997 Label(N1+6) to Label(N2+6), NH 10.0.0.4 into its MPLS transit RIB. 998 Furthermore R2 MAY program a MPLS PUSH operation for IP 192.168.1.6 999 to Label (N2+6), NH 10.0.0.4 into its IPv4 tunnel RIB. 1001 Next walk down to R3, which is the next router on the SPT tree 1002 towards R6. R3s SPT to R6 is {R3, R6}. R3 determines if its 1003 downstream router (R6) has advertised a label-block. Since R6 has 1004 advertised a label block 'N4' and it has received R6 'ID' of 6 it 1005 will be picking the 6th label value inside the advertised range of 1006 its downstream neighbor. Since R3 is the penultimate router to R6 it 1007 MUST program a MPLS POP for its own label range Label(N2+6) NH 1008 10.0.0.14 into its MPLS transit RIB. Furthermore R3 MAY program a 1009 MPLS NOP for IP 192.168.1.6, NH 10.0.0.14 into its IPv4 tunnel RIB. 1011 5.9. Expansion of an 'All Router Block' TLV 1013 All routers within a given area MUST advertise their Label Blocks 1014 along with an 'ID'. Now assume that the initial label block size 1015 assignment is too small to support all routers which generate an 1016 ordinal within an IGP domain. Consider the seven routers in 1017 Figure 16, and assume that R7 advertises a new ID '15' using an 'All 1018 Router ID Map' TLV. ID '15' is outside of the range of '10' as per 1019 the previous example in Section 5.8. Now all the routers in an IGP 1020 domain need to advertise one more label block in order to map the ID 1021 '15' to an actual label value. 1023 All routers would advertise in addition to their label block with 1024 a size of 10, a second label block with a size sufficient 1025 enough, that the new ordinal can get covered. In this example the 1026 same block size 10 is used also for the second label block. For 1027 example router R2 would advertise the following label bindings. 1029 LSA 149: LSA-ID : 1031 All Router Block TLV: Block Size 10, Algo 0, Topology 0 1033 All Router ID IPv4 Map TLV: ID 2, 192.168.1.2 1035 LSA 149: LSA-ID : 1037 All Router Block TLV: Block Size 10, Algo 0, Topology 0 1039 Now the upstream router can map the new ID of R7 to an actual label 1040 value, as ID '15' corresponds to the 5th label inside the second 1041 Label block. 1043 6. Inter Area Protocol Procedures 1045 6.1. Applicability 1047 Propagation of a MPLS LSPs and MPLS Block LSPs across an area 1048 boundary is a local policy decision. 1050 6.2. Data plane operations 1052 If local policy dictates that a given ABR router needs to re- 1053 advertise a MPLS LSPs from one area to another then it MUST allocate 1054 a new label and program its label forwarding table to connect the new 1055 label to the path in the respective other area. Depending on how to 1056 reach the re-advertised LSP, this is typically done using a MPLS 1057 'SWAP' or 'SWAP/PUSH' data plane operation. 1059 6.3. Control plane operations 1061 6.3.1. MPLS Label operations 1063 If local policy dictates that a given ABR router needs to re- 1064 advertise MPLS LSPs from one area to another then it must prepend its 1065 "Traffic-Engineering-ID" as a loose hop in the Prefix ERO TLV list. 1067 Furthermore it MUST append the Flags TLV and set the 'Down' Bit. 1069 6.3.2. MPLS Label Block operations 1071 If local policy dictates that a given ABR router advertises its 'All 1072 Router Block' into another area, then it also MUST re-advertise all 1073 known 'ID' ordinals (again gated by policy) to the respective other 1074 area. Without knowledge of all 'ID's in the network no router is 1075 able to construct SPT label switched paths. Furthermore an ABR MUST 1076 append the Flags TLV and set the 'Down' Bit for all re-advertised 1077 'CE' IDs. 1079 7. Acknowledgements 1081 Many thanks to Yakov Rekhter, John Drake and Shraddha Hedge for their 1082 useful comments. 1084 8. IANA Considerations 1086 This documents request allocation for one common OSPFv2 and OSPFv3 1087 LSA Type and TLVs contained within. 1089 +----------+--------------------------------+----------+------------+ 1090 | LSA Type | TLV | TLV Type | #Occurence | 1091 +----------+--------------------------------+----------+------------+ 1092 | 149 | | | >=0 | 1093 | | IPv4 Prefix ERO | 1 | >=0 | 1094 | | IPv6 Prefix ERO | 2 | >=0 | 1095 | | Unnumbered Interface ID ERO | 9 | >=0 | 1096 | | IPv4 Prefix Bypass ERO | 3 | >=0 | 1097 | | IPv6 Prefix Bypass ERO | 4 | >=0 | 1098 | | Unnumbered Bypass Interface ID | 10 | >=0 | 1099 | | ERO | | | 1100 | | Flags | 5 | 0,1 | 1101 | | All Router Block | 6 | >=0 | 1102 | | All Router ID IPv4 Map | 7 | >=0 | 1103 | | All Router ID IPv6 Map | 8 | >=0 | 1104 +----------+--------------------------------+----------+------------+ 1106 Table 1: IANA allocations 1108 The MPLS Label LSA requires a new sub-registry, with a starting TLV 1109 value of 1, and managed by IETF consensus. 1111 9. Security Considerations 1113 This document does not introduce any change in terms of OSPF 1114 security. It simply proposes to flood MPLS label information via the 1115 IGP. All existing procedures to ensure message integrity do apply 1116 here. 1118 10. References 1120 10.1. Normative References 1122 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1123 Requirement Levels", BCP 14, RFC 2119, March 1997. 1125 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1126 Label Switching Architecture", RFC 3031, January 2001. 1128 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 1129 BGP-4", RFC 3107, May 2001. 1131 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1132 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1133 Tunnels", RFC 3209, December 2001. 1135 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1136 in Resource ReSerVation Protocol - Traffic Engineering 1137 (RSVP-TE)", RFC 3477, January 2003. 1139 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1140 (TE) Extensions to OSPF Version 2", RFC 3630, 1141 September 2003. 1143 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1144 Hierarchy with Generalized Multi-Protocol Label Switching 1145 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 1147 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 1148 (VPLS) Using BGP for Auto-Discovery and Signaling", 1149 RFC 4761, January 2007. 1151 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1152 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1153 RFC 4915, June 2007. 1155 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1156 Specification", RFC 5036, October 2007. 1158 [RFC5151] Farrel, A., Ayyangar, A., and JP. Vasseur, "Inter-Domain 1159 MPLS and GMPLS Traffic Engineering -- Resource Reservation 1160 Protocol-Traffic Engineering (RSVP-TE) Extensions", 1161 RFC 5151, February 2008. 1163 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 1164 OSPF Opaque LSA Option", RFC 5250, July 2008. 1166 10.2. Informative References 1168 [I-D.gredler-rtgwg-igp-label-advertisement] 1169 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 1170 "Advertising MPLS labels in IGPs", 1171 draft-gredler-rtgwg-igp-label-advertisement-05 (work in 1172 progress), May 2013. 1174 [I-D.ietf-rtgwg-mrt-frr-architecture] 1175 Atlas, A., Kebler, R., Envedi, G., Csaszar, A., Tantsura, 1176 J., Konstantynowicz, M., White, R., and M. Shand, "An 1177 Architecture for IP/LDP Fast-Reroute Using Maximally 1178 Redundant Trees", draft-ietf-rtgwg-mrt-frr-architecture-02 1179 (work in progress), February 2013. 1181 [I-D.previdi-filsfils-isis-segment-routing] 1182 Previdi, S., Filsfils, C., Bashandy, A., Horneffer, M., 1183 Decraene, B., Litkowski, S., Milojevic, I., Shakir, R., 1184 Ytti, S., Henderickx, W., and J. Tantsura, "Segment 1185 Routing with IS-IS Routing Protocol", 1186 draft-previdi-filsfils-isis-segment-routing-02 (work in 1187 progress), March 2013. 1189 Authors' Addresses 1191 Hannes Gredler (editor) 1192 Juniper Networks, Inc. 1193 1194 N. Mathilda Ave. 1194 Sunnyvale, CA 94089 1195 US 1197 Email: hannes@juniper.net 1198 Shane Amante 1199 Level 3 Communications, Inc. 1200 1025 Eldorado Blvd 1201 Broomfield, CO 80021 1202 US 1204 Email: shane@level3.net 1206 Tom Scholl 1207 Amazon 1208 Seattle, WN 1209 US 1211 Email: tscholl@amazon.com 1213 Luay Jalil 1214 Verizon 1215 1201 E Arapaho Rd. 1216 Richardson, TX 75081 1217 US 1219 Email: luay.jalil@verizon.com