idnits 2.17.1 draft-gredler-ospf-label-advertisement-02.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 6, 2013) is 4007 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 (-05) exists of draft-gredler-rtgwg-igp-label-advertisement-04 == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-mrt-frr-architecture-02 Summary: 2 errors (**), 0 flaws (~~), 5 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 7, 2013 Level 3 Communications, Inc. 6 T. Scholl 7 Amazon 8 L. Jalil 9 Verizon 10 May 6, 2013 12 Advertising MPLS labels in OSPF 13 draft-gredler-ospf-label-advertisement-02 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 7, 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. Prefix ERO TLVs . . . . . . . . . . . . . . . . . . . . . 10 87 4.1.1. IPv4 Prefix ERO TLV . . . . . . . . . . . . . . . . . 11 88 4.1.2. IPv6 Prefix ERO TLV . . . . . . . . . . . . . . . . . 11 89 4.2. IPv4 Prefix Bypass ERO TLV . . . . . . . . . . . . . . . . 12 90 4.3. IPv6 Prefix Bypass ERO TLV . . . . . . . . . . . . . . . . 13 91 4.4. Flags TLV . . . . . . . . . . . . . . . . . . . . . . . . 13 92 4.5. All Router Block TLV . . . . . . . . . . . . . . . . . . . 14 93 4.6. All Router ID IPv4 Map TLV . . . . . . . . . . . . . . . . 15 94 4.7. All Router ID IPv6 Map TLV . . . . . . . . . . . . . . . . 16 95 5. Advertising Label Examples . . . . . . . . . . . . . . . . . . 17 96 5.1. Sample Topology . . . . . . . . . . . . . . . . . . . . . 17 97 5.1.1. Transport IP addresses and router-IDs . . . . . . . . 18 98 5.1.2. Link IP addresses . . . . . . . . . . . . . . . . . . 18 99 5.2. One-hop LSP to an adjacent Router . . . . . . . . . . . . 19 100 5.3. One-hop LSP to an adjacent Router using a specific link . 19 101 5.4. One-hop LSP to an adjacent external Router . . . . . . . . 19 102 5.5. Advertisement of an RSVP LSP . . . . . . . . . . . . . . . 20 103 5.6. Advertisement of an LDP LSP . . . . . . . . . . . . . . . 20 104 5.7. Interarea advertisement of diverse paths . . . . . . . . . 20 105 5.8. Advertisement of SPT labels using 'All Router Block' 106 TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 107 5.9. Expansion of an 'All Router Block' TLV . . . . . . . . . . 22 108 6. Inter Area Protocol Procedures . . . . . . . . . . . . . . . . 23 109 6.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 23 110 6.2. Data plane operations . . . . . . . . . . . . . . . . . . 23 111 6.3. Control plane operations . . . . . . . . . . . . . . . . . 23 112 6.3.1. MPLS Label operations . . . . . . . . . . . . . . . . 23 113 6.3.2. MPLS Label Block operations . . . . . . . . . . . . . 24 114 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 115 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 116 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 117 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 118 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 119 10.2. Informative References . . . . . . . . . . . . . . . . . . 26 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 122 1. Introduction 124 MPLS label allocations are predominantly distributed by using the LDP 125 [RFC5036], RSVP [RFC5151] or labeled BGP [RFC3107] protocol. All of 126 those protocols have in common that they are session oriented, which 127 means that in order to obtain label binding for a given destination 128 FEC from a given router one needs first to establish a direct control 129 plane (LDP/RSVP/LBGP) session with that router. 131 There are a couple of practical use cases 132 [I-D.gredler-rtgwg-igp-label-advertisement] where the consumer of a 133 MPLS label binding may not be adjacent to the router that performs 134 the binding. Bringing up an explicit session using the existing 135 label distribution protocols between the non-adjacent router that 136 binds the label and the router that acts as a consumer of this 137 binding is the existing remedy for this dilemma. 139 This document describes an OSPFv2 and OSPFv3 protocol extension which 140 allows routers to advertise MPLS label bindings within and beyond an 141 IGP domain, and controlling inter-area distribution. 143 2. Motivation, Rationale and Applicability 145 Distributing MPLS labels in an IGP (IS-IS) has been described in 146 Segment Routing [I-D.previdi-filsfils-isis-segment-routing]. The 147 authors propose to re-use existing traffic-engineering extensions for 148 carrying the label information. While retrofitting existing protocol 149 machinery for new purposes is generally a good thing, Segment Routing 150 [I-D.previdi-filsfils-isis-segment-routing] falls short of addressing 151 some use-cases defined in 152 [I-D.gredler-rtgwg-igp-label-advertisement]. 154 The dominant issue around re-using traffic-engineering extensions is 155 that both have existing protocol semantics, which might not be 156 applicable to advertising MPLS label switched paths in a generic 157 fashion. These are specifically: 159 o Bi-directionality semantics 161 o IP path semantics 163 o Lack of 'path' notion 165 2.1. Issue: Bi-directionality semantics 167 'Bi-directionality semantics', affects the complexity around 168 advertisement of unidirectional LSPs. Label advertisement of per- 169 link labels or 'Adj-SIDs' [I-D.previdi-filsfils-isis-segment-routing] 170 is done by attaching label information to adjacency advertisment 171 TLVs. Usually implementations need to have an adjacency in 'Up' 172 state prior to advertising this adjacency as TE-Link in its Link 173 State advertisment. In order to advertise a per-link LSP an 174 implementation first needs to have an adjacency, which only 175 transitions to 'Up' state after passing the 3-way check. This 176 implies bi-directionality. If an implementation wants to advertise 177 per-link MPLS LSPs to e.g. outside the IGP domain then it would need 178 to fake-up an adjacency. Changing existing IGP Adjacency code to 179 support such cases defeats the purpose of re-using existing 180 functionality as there is not much common functionality to be shared. 182 2.2. Issue: IP path semantics 184 LSPs pointing to a Node are advertised as 'Node-SIDs' 185 [I-D.previdi-filsfils-isis-segment-routing] using IP Prefix 186 containers. That means that in order to advertise a MPLS LSP, one is 187 inheriting the semantics of advertising an IP path. Consider router 188 A has got existing LSPs to its entire one-hop neighborhood and is re- 189 advertising those LSPs using IP reachability semantics. Now we have 190 two exact matching IP advertisements. One from the owning router 191 (router B) which advertises its stable transport loopback address and 192 another one from router A re-advertising a LSP path to router B. 193 Existing routing software may get confused now as the 'stable 194 transport' address shows up from multiple places in the network and 195 more worse the IP forwarding path for control-plane protocols may get 196 mingled with the MPLS data plane. 198 2.3. Issue: Lack of 'path' notion 200 Both exisiting traffic-engineering extension containers have limited 201 semantics describing MPLS label-switched paths in the sense of a 202 'path'. Both encoding formats allow to express a pointer to some 203 specific router, but not to describe a MPLS label switched path 204 containing all of its path segments. 205 [I-D.previdi-filsfils-isis-segment-routing] allows to define 206 'Forwarding Adjacencies' as per [RFC4206]. The way to describe a 207 path of a given forwarding adjacency is to enlist a list of "Segment 208 IDs". That implies that nodes which do not yet participate in 209 'Segment routing' or are outside of a 'Segment routing' domain can 210 not be expressed using those path semantics. 212 A protocol for advertising MPLS label switched paths, should be 213 generic enough to express paths sourced by existing MPLS LSPs, such 214 that ingress routers can flexibly combine them according to 215 application needs. 217 2.4. Motivation 219 IGP advertisement of MPLS label switched paths requires a new set of 220 protocol semantics (undirectional paradigm, path paradigm), which 221 hardly can be expressed using the existing OSPF and OSPF-TE protocol 222 semantics. This document describes protocol extensions which allows 223 generic advertisement of MPLS label bindings in the OSPFv2 and OSPFv3 224 protocol. 226 The Protocol extensions described in this document are equally 227 applicable to IPv4 and IPv6 carried over MPLS. Furthermore the 228 proposed use of distributing MPLS Labels using IGP prototocols 229 adheres to the architectural principles laid out in [RFC3031]. 231 3. OSPF MPLS LSA Format 233 3.1. Common LSA Type 235 One new LSA is defined, the MPLS Label LSA. This LSA advertises MPLS 236 labels along with their path information. The LSA contains more 237 specific information encoded in TLVs. Those TLV extensions are 238 shared between the OSPFv2 and OPSFv3 protocols. 240 3.2. OSPFv2 LSA ID 242 The LSA ID of an Opaque LSA is defined as having eight bits of type 243 data and 24 bits of type-specific data. The MPLS Label LSA uses type 244 149. The remaining 24 bits are 4 zero bits followed by the MPLS 245 Label or MPLS Label Base value as follows: 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | 149 |0|0|0|0| MPLS Label | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Figure 1: OSPFv2 MPLS Label LSA-ID format 255 The 'MPLS Label' field holds the 20 Bit MPLS label for MPLS Label 256 base. Therefore a maximum of 2^20 MPLS Label LSAs may be sourced by 257 a single system. 259 3.3. OSPFv2 LSA Format Overview 261 This extension makes use of the Opaque LSAs [RFC5250]. 263 Three types of Opaque LSAs exist, each of which has a different 264 flooding scope. This proposal uses only Type 10 LSAs, which have an 265 area flooding scope. 267 The MPLS Label LSA for OSPFv2 starts with the standard OSPFv2 LSA 268 header: 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | LS age | Options | 10 | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | 149 |0|0|0|0| MPLS Label | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Advertising Router | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | LS sequence number | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | LS checksum | length | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | | 284 +- TLVs -+ 285 | ... | 287 Figure 2: OSPFv2 MPLS Label LSA format 289 3.4. OSPFv3 LSA ID 291 The OSPFv3 LSA ID of an MPLS Label LSA is defined as having twelve 292 bits of zero followed by the 20-Bit label MPLS Label value as 293 follows: 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 |0|0|0|0|0|0|0|0|0|0|0|0| MPLS Label | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Figure 3: OSPFv3 MPLS Label LSA-ID format 303 The 'MPLS Label' field holds the 20 Bit MPLS label or MPLS label base 304 value. Therefore a maximum of 2^20 MPLS Label LSAs may be sourced by 305 a single system. 307 3.5. OSPFv3 LSA Format Overview 309 The MPLS Label LSA for OSPFv3 starts with the standard OSPFv3 LSA 310 header: 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | LS age |1|0|1| 149 | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 |0|0|0|0|0|0|0|0|0|0|0|0| MPLS Label | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Advertising Router | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | LS sequence number | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | LS checksum | Length | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | | 326 +- TLVs -+ 327 | ... | 329 Figure 4: OSPFv3 MPLS Label LSA format 331 The OSPFv3 'U' Bit will always be set such that routers which do not 332 understand the new MPLS Label LSA will store and forward it further. 334 In analogy to the OSPFv2 opaque LSA 10 the flooding scope will be set 335 to 'Area scoping'. 337 3.6. TLV Header 339 The LSA payload consists of one or more nested Type/Length/Value 340 (TLV) triplets for extensibility. The format of each TLV is: 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Type | Length | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Value... | 348 . . 349 . . 350 . . 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Figure 5: TLV format 355 The Length field defines the length of the value portion in octets 356 (thus a TLV with no value portion would have a length of zero). The 357 TLV is padded to four-octet alignment; padding is not included in the 358 length field (so a three octet value would have a length of three, 359 but the total size of the TLV would be eight octets). Nested TLVs 360 are also 32-bit aligned. Unrecognized types are ignored. 362 This memo defines TLV Types 1 through 8. See the IANA Considerations 363 section for allocation of new Types. 365 4. LSA payload details 367 The MPLS Label LSA may be originated by any Traffic Engineering 368 [RFC3630] capable router in an OSPF domain. The router may advertise 369 a single label binding or a block of label bindings. For single 370 label binding advertisement a router needs to provide at least a 371 single 'nexthop style' anchor. The protocol supports more than one 372 'nexthop style' anchor to be attached to a Label binding, which 373 results into a simple path description language. In analogy to RSVP 374 the terminology for this is called an 'Explicit Route Object' (ERO). 375 Since ERO style path notation allows to anchor label bindings to to 376 both link and node IP addresses any label switched path, can be 377 described. Furthermore also Label Bindings from other protocols can 378 get easily re-advertised. 380 An LSA contains one or more TLVs, describing properties of the 381 advertised MPLS label. 383 The following TLV extensions may be shared in both OSPV2 and OSPFv3. 384 Passing an IP address of the other address family (IPv4 in OPSFv3 or 385 IPv6 in OSPFv2) is possible as the information carried are related 386 describing the hops along a path. The receiver of this information 387 is a protocol agnostic path computation module. 389 4.1. Prefix ERO TLVs 391 All 'Prefix ERO' information represents an ordered set which 392 describes the segments of a label-switched path. The last Prefix ERO 393 TLV describes the segment closest to the egress point of the LSP. 394 Contrary the first Prefix ERO TLV describes the first segment of a 395 label switched path. If a router extends or stitches a label 396 switched path it MUST prepend the new segments path information to 397 the Prefix ERO list. 399 4.1.1. IPv4 Prefix ERO TLV 401 The IPv4 ERO TLV (Type 1) describes a path segment using IPv4 Prefix 402 style of encoding. Its appearance and semantics have been borrowed 403 from Section 4.3.3.2 [RFC3209]. 405 the 'IPv4 Address' is treated as a prefix based on the prefix length 406 value below. Bits beyond the prefix are ignored on receipt and 407 SHOULD be set to zero on transmission. 409 The 'Prefix Length' field contains the length of the prefix in bits. 411 The 'L' bit in the TLV is a one-bit attribute. If the L bit is set, 412 then the value of the attribute is 'loose.' Otherwise, the value of 413 the attribute is 'strict.' 415 The 'Reserved' bits are for future use. They should be zero on 416 transmission and ignored on receipt. 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Type | Length | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | IPv4 Address (4 octets) | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Prefix Length |L| Reserved | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Figure 6: IPv4 Prefix ERO TLV format 430 4.1.2. IPv6 Prefix ERO TLV 432 The IPv6 ERO TLV (Type 2) describes a path segment using IPv6 Prefix 433 style of encoding. Its appearance and semantics have been borrowed 434 from Section 4.3.3.2 [RFC3209]. 436 the 'IPv6 Address' is treated as a prefix based on the prefix length 437 value below. Bits beyond the prefix are ignored on receipt and 438 SHOULD be set to zero on transmission. 440 The 'Prefix Length' field contains the length of the prefix in bits. 442 The 'L' bit in the TLV is a one-bit attribute. If the L bit is set, 443 then the value of the attribute is 'loose.' Otherwise, the value of 444 the attribute is 'strict.' 446 The 'Reserved' bits are for future use. They should be zero on 447 transmission and ignored on receipt. 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Type | Length | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | IPv6 Address (16 octets) | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | IPv6 Address (continued) | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | IPv6 Address (continued) | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | IPv6 Address (continued) | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Prefix Length |L| Reserved | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 Figure 7: IPv6 Prefix ERO TLV format 467 4.2. IPv4 Prefix Bypass ERO TLV 469 The IPv4 Bypass ERO TLV (Type 3) describes a Bypass LSP path segment 470 using IPv4 Prefix style of encoding. Its appearance and semantics 471 have been borrowed from Section 4.3.3.2 [RFC3209]. 473 The 'Prefix Length' field contains the length of the prefix in bits. 475 The 'L' bit in the TLV is a one-bit attribute. If the L bit is set, 476 then the value of the attribute is 'loose.' Otherwise, the value of 477 the attribute is 'strict.' 479 The 'Reserved' bits are for future use. They should be zero on 480 transmission and ignored on receipt. 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Type | Length | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | IPv4 Address (4 octets) | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Prefix Length |L| Reserved | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 Figure 8: IPv4 Prefix Bypass ERO TLV format 494 4.3. IPv6 Prefix Bypass ERO TLV 496 The IPv6 ERO TLV (Type 4) describes a Bypass LSP path segment using 497 IPv6 Prefix style of encoding. Its appearance and semantics have 498 been borrowed from Section 4.3.3.3 [RFC3209]. 500 The 'Prefix Length' field contains the length of the prefix in bits. 502 The 'L' bit in the subTLV is a one-bit attribute. If the L bit is 503 set, then the value of the attribute is 'loose.' Otherwise, the 504 value of the attribute is 'strict.' 506 0 1 2 3 507 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 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Type | Length | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | IPv6 Address (16 octets) | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | IPv6 Address (continued) | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | IPv6 Address (continued) | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | IPv6 Address (continued) | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Prefix Length |L| Reserved | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 Figure 9: IPv6 Prefix Bypass ERO TLV format 524 4.4. Flags TLV 526 The Flags TLV (Type 5) describes Flags for further MPLS LSA 527 treatment. 529 Up/Down 'U' Bit: A router may flood MPLS label information across 530 area boundaries. In order to prevent flooding loops, a router will 531 Set the Up/Down (U-Bit) when propagating MPLS labels from Area 0 to a 532 non-zero Area. 534 The 'Reserved' bits are for future use. They should be zero on 535 transmission and ignored on receipt. 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Type | Length | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 |U| Reserved | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 Figure 10: Flags TLV format 547 4.5. All Router Block TLV 549 The 'All Router Block' TLV (Type 6) denominates the label block size 550 of an MPLS Label advertisement and its semantics to connect to all 551 routers in a given OSPF domain using a local assigned [RFC3031] label 552 range. Note that the actual mapping of a router within the label 553 range is done using the TLVs described in Section 4.6 and 554 Section 4.7. Since generation of an IPv4 or IPv6 Map TLV is a local 555 policy decision, it might be the case that connectivity is provided 556 not to 'All' but rather a subset of 'All' routers. Keeping policy 557 decisions aside, for simplicity reasons, assume that All Routers in a 558 domain do generate either the 'All Router ID IPv4 Map' or 'All Router 559 ID IPv6 Map' TLVs and therefore all routers desire construction of a 560 Label switched path from every source router in the network. The 561 basic concept of using label blocks to provide connectivity to a set 562 of routers has been borrowed from [RFC4761] which allows to advertise 563 labels from multiple end-points using a single control-plane message. 564 The difference to [RFC4761] is that rather than advertising where a 565 particular packet came from (=source semantics), destination 566 semantics (where a particular packet will be going to) is advertised. 568 Along with each label block a router advertises one for more 'IDs'. 569 The 'ID' must be unique within a given domain. The 'ID' serves as 570 ordinal to determine the actual label value inside the set of all 571 advertised label ranges of a given router. A receiving router uses 572 the ordinal to determine the actual label value in order to construct 573 forwarding state to a particular destination router. The 'ID' is 574 separately advertised using the TLVs described in Section 4.6 and 575 Section 4.7. 577 The ability to advertise more than one label block eases operational 578 procedures for increasing the number of supported routers within a 579 domain. For example consider a given domain has got support for 580 routers and runs out of ID space. It simply advertises one more 581 label block to cover additional ordinals outside the range of the 582 first label block. An example of label-block expansion is described 583 in more detail in Section 5.9 584 0 1 2 3 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Type | Length | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Block Size | Algo | Reserved| Topology-ID | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 Figure 11: All Router Block TLV format 594 The 'Block Size' value contains the size of the label advertisement. 595 The 'value determines the amount of reachable router endpoints within 596 a given Label block. It MUST contain a value greater or equal than 597 two. Note that the label base is inferred from the LSA-ID in the LSA 598 header. For example if a router wants to advertise a label range of 599 5000-5099 then it would need to generate a LSA-ID of 5000 (= 600 0.0.19.136) and a Block Size of 100. 602 The 'Algo' value denominates the path computation algorithm in order 603 to calculate the forwarding topology. The basic SPF algorithm has an 604 assigned 'Algo' code point of zero. The purpose of the 'Algo' field 605 is to extend the notion of Label Block Signaling to arbitrary 606 algorithms like for example 'MRT' 607 ([I-D.ietf-rtgwg-mrt-frr-architecture]. Advertised Label Blocks with 608 an unknown, unsupported or non-configured algorithm MUST be silently 609 ignored. 611 The 'Reserved' bits are for future use. They should be zero on 612 transmission and ignored on receipt. 614 The 'Topology-ID' field contains the Multi Topology ID ([RFC4915]) 615 for which the advertised Label Block does apply. The basic IPv4 616 unicast Topology has an assigned 'Topology-ID' code point of zero. 617 Advertised Label Blocks with an unknown, unsupported or non- 618 configured Topology-ID MUST be silently ignored. 620 An LSA containing the 'All Router Block' TLV MUST only contain the 621 Flags TLV (Section 4.4, the 'All Router IPv4 Map' TLV (Section 4.6) 622 or the 'All Router IPv6 Map' TLV (Section 4.7). 624 4.6. All Router ID IPv4 Map TLV 626 The 'All Router ID IPv4 Map' TLV (Type 7) maps an 'ID' to a given 627 stable transport IPv4 address. Its purpose is to associate a given 628 transport IPv4 IP address to the ordinal inside a label range as 629 described in Section 4.5. 631 A router MAY advertise more than one 'ID' to 'IPv4 address' mapping 632 pair, in case it has more than one stable transport IPv4 address. 634 0 1 2 3 635 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 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Type | Length | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | IPv4 Address (4 octets) | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | ID | Reserved | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 Figure 12: All Router ID IPv4 Map TLV format 646 The 'IPv4 address' contains stable IPv4 transport address of a given 647 router. 649 The 'ID' contains the ordinal value of an advertising router inside 650 the set of all advertised label blocks of a given router. 652 The 'Reserved' bits are for future use. They should be zero on 653 transmission and ignored on receipt. 655 4.7. All Router ID IPv6 Map TLV 657 The 'All Router ID IPv6 Map' TLV (Type 8) maps an 'ID' to a given 658 stable transport IPv6 address. Its purpose is to associate a given 659 transport IPv6 IP address to the ordinal inside a label range as 660 described in Section 4.5. 662 A router MAY advertise more than one 'ID' to 'IPv6 address' mapping 663 pair, in case it has more than one stable transport IPv6 address. 665 0 1 2 3 666 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 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | Type | Length | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | IPv6 Address (16 octets) | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | IPv6 Address (continued) | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | IPv6 Address (continued) | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | IPv6 Address (continued) | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | ID | Reserved | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 Figure 13: All Router ID IPv6 Map TLV format 683 The 'IPv6 address' contains the stable IPv6 transport address of a 684 given router. 686 The 'ID' contains the ordinal value of an advertising router inside 687 the set of all advertised label blocks of a given router. 689 The 'Reserved' bits are for future use. They should be zero on 690 transmission and ignored on receipt. 692 5. Advertising Label Examples 694 5.1. Sample Topology 696 The following topology (Figure 14) and IP addresses shall be used 697 throughout the Label advertisement examples. 699 AS1 : AS 2 700 : 701 : : 702 Area 1 : Area 0 : 703 : : 704 +-----+ +-----+-IP3--1-IP4--+-----+ : 705 | R1 +-IP1--1-IP2--+ R2 | | R3 | : 706 +--+--+ +--+--+-IP5--3-IP6--+--+--+-IP15-IP16- 707 | | | : \ 708 IP9 IP7 IP13 : \ 709 | | | : +--+--+ 710 1 1 1 : | R7 | 711 | | | : +--+--+ 712 IP10 IP8 IP14 : / 713 | | | : / 714 +--+--+ +--+--+ +--+--+-IP17-IP18- 715 | R4 +-IP19-2-IP20-+ R5 |-IP11-2-IP12-| R6 | : 716 +-----+ +-----+ +-----+ : 717 : : 718 : : 719 : : 721 Figure 14: Sample Topology 723 5.1.1. Transport IP addresses and router-IDs 725 o R1: 192.168.1.1 727 o R2: 192.168.1.2 729 o R3: 192.168.1.3 731 o R4: 192.168.1.4 733 o R5: 192.168.1.5 735 o R6: 192.168.1.6 737 o R7: 192.168.1.7 739 5.1.2. Link IP addresses 741 o R1 to R2 link: 10.0.0.1, 10.0.0.2 743 o R1 to R4 link: 10.0.0.9, 10.0.0.10 745 o R2 to R3 link #1: 10.0.0.3, 10.0.0.4 746 o R2 to R3 link #2: 10.0.0.5, 10.0.0.6 748 o R2 to R5 link: 10.0.0.7, 10.0.0.8 750 o R3 to R6 link: 10.0.0.13, 10.0.0.14 752 o R3 to R7 link: 10.0.0.15, 10.0.0.16 754 o R4 to R5 link: 10.0.0.19, 10.0.0.20 756 o R5 to R6 link: 10.0.0.11, 10.0.0.12 758 o R6 to R7 link: 10.0.0.17, 10.0.0.18 760 The IGP link metrics are displayed in the middle of the link. All of 761 them are assumed to be bi-directional. 763 5.2. One-hop LSP to an adjacent Router 765 If R1 would advertise a label bound to a one-hop LSP from R1 to 766 R2 it would encode as follows: 768 LSA 149, LSA-ID : 770 IPv4 Prefix ERO TLV: 192.168.1.2/32, Strict 772 5.3. One-hop LSP to an adjacent Router using a specific link 774 If R2 would advertise a label bound to a one-hop LSP from R2 to 775 R3, using the link #2 it would encode as follows 777 LSA 149, LSA-ID : 779 IPv4 Prefix ERO TLV: 10.0.0.6/32, Strict 781 5.4. One-hop LSP to an adjacent external Router 783 If R3 would advertise a label bound to a one-hop LSP from R3 to 784 R7 (which is outside of the IGP domain), it would encode as follows: 786 LSA 149, LSA-ID : 788 IPv4 Prefix ERO TLV: 192.168.1.7/32, Strict 790 As you can see the representation of an MPLS label crossing an 791 external link is identical as an internal link Section 5.2. 793 5.5. Advertisement of an RSVP LSP 795 Consider a RSVP LSP name "R2-to-R6" traversing (R2 to R3 using link 796 #1, R6): 798 If R2 would advertise a label bound to the RSVP LSP named 799 'R2-to-R6', it would encode as follows 801 LSA 149, LSA-ID : 803 IPv4 Prefix ERO TLV: 10.0.0.4/32, Strict 805 IPv4 Prefix ERO TLV: 192.168.1.6/32, Strict 807 5.6. Advertisement of an LDP LSP 809 Consider R2 that creates a LDP label binding for FEC 172.16.0.0./12 810 using label . 812 If R2 would re-advertise this label binding in OSPF it would encode 813 as follows 815 LSA 149, LSA-ID : 817 IPv4 Prefix ERO TLV: 172.16.0.0/12, Loose 819 5.7. Interarea advertisement of diverse paths 821 Consider two R2->R6 paths: {R2, R3, R6} and {R2, R5, R6} 823 Consider two R5->R3 paths: {R5, R2, R3} and {R5, R6, R3} 825 R2 encodes its two paths to R6 as follows: 827 LSA 149, LSA-ID : 829 IPv4 Prefix ERO TLV: 192.168.1.3, Loose 831 IPv4 Prefix ERO TLV: 192.168.1.6, Loose 833 Flags TLV: Down 835 LSA 149, LSA-ID : 837 IPv4 Prefix ERO subTLV: 192.168.1.5, Loose 839 IPv4 Prefix ERO subTLV: 192.168.1.6, Loose 840 Flags TLV: Down 842 R5 encodes its two paths to R3 as follows: 844 LSA 149, LSA-ID : 846 IPv4 Prefix ERO subTLV: 192.168.1.2, Loose 848 IPv4 Prefix ERO subTLV: 192.168.1.3, Loose 850 Flags TLV: Down 852 LSA 149, LSA-ID : 854 IPv4 Prefix ERO subTLV: 192.168.1.6, Loose 856 IPv4 Prefix ERO subTLV: 192.168.1.3, Loose 858 Flags TLV: Down 860 A receiving non-backbone router does see now all 4 paths and may 861 decide to load-balance across all or a subset of them. 863 5.8. Advertisement of SPT labels using 'All Router Block' TLV 865 All routers within a given area MUST advertise their Label Blocks 866 along with an 'ID'. 868 If R2 would advertise a label block with a size of 10, declaring 869 SPT label forwarding support to all routers within a given domain, it 870 would encode as follows: 872 LSA 149, LSA-ID : 874 All Router Block TLV: Block Size 10, Algo 0, Topology-ID 0 876 All Router ID IPv4 Map TLV: ID 2, 192.168.1.2 878 If R3 would advertise a label block with a size of 10, declaring 879 SPT label forwarding support to all routers within a given domain, it 880 would encode as follows: 882 LSA 149, LSA-ID : 884 All Router Block TLV: Block Size 10, Algo 0, Topology-ID 0 886 All Router ID IPv4 Map TLV: ID 3, 192.168.1.3 888 If R5 would advertise a label block with a size of 10, declaring 889 SPT label forwarding support to all routers within a given domain, it 890 would encode as follows: 892 LSA 149, LSA-ID : 894 All Router Block TLV: Block Size 10, Algo 0, Topology-ID 0 896 All Router ID IPv4 Map TLV: ID 5, 192.168.1.5 898 If R6 would advertise a label block with a size of 10, declaring 899 SPT label forwarding support to all routers within a given domain, it 900 would encode as follows: 902 LSA 149, LSA-ID : 904 All Router Block TLV: Block Size 10, Algo 0, Topology-ID 0 906 All Router ID IPv4 Map TLV: ID 6, 192.168.1.6 908 Consider now R2 constructing a SPT label for R6. R2s SPT to R6 is 909 {R2, IP4, R3, R6}. R2 first determines if its downstream router (R3) 910 has advertised a label-block. Since R3 has advertised a label block 911 'N2' and it has received R6 'ID' of 6 it will be picking the 6th 912 label value inside the advertised range of its downstream neighbor. 913 Specifically R2 MUST be program a MPLS SWAP for its own label range 914 Label(N1+6) to Label(N2+6), NH 10.0.0.4 into its MPLS transit RIB. 915 Furthermore R2 MAY program a MPLS PUSH operation for IP 192.168.1.6 916 to Label (N2+6), NH 10.0.0.4 into its IPv4 tunnel RIB. 918 Next walk down to R3, which is the next router on the SPT tree 919 towards R6. R3s SPT to R6 is {R3, R6}. R3 determines if its 920 downstream router (R6) has advertised a label-block. Since R6 has 921 advertised a label block 'N4' and it has received R6 'ID' of 6 it 922 will be picking the 6th label value inside the advertised range of 923 its downstream neighbor. Since R3 is the penultimate router to R6 it 924 MUST program a MPLS POP for its own label range Label(N2+6) NH 925 10.0.0.14 into its MPLS transit RIB. Furthermore R3 MAY program a 926 MPLS NOP for IP 192.168.1.6, NH 10.0.0.14 into its IPv4 tunnel RIB. 928 5.9. Expansion of an 'All Router Block' TLV 930 All routers within a given area MUST advertise their Label Blocks 931 along with an 'ID'. Now assume that the initial label block size 932 assignment is too small to support all routers which generate an 933 ordinal within an IGP domain. Consider the seven routers in 934 Figure 14, and assume that R7 advertises a new ID '15' using an 'All 935 Router ID Map' TLV. ID '15' is outside of the range of '10' as per 936 the previous example in Section 5.8. Now all the routers in an IGP 937 domain need to advertise one more label block in order to map the ID 938 '15' to an actual label value. 940 All routers would advertise in addition to their label block with 941 a size of 10, a second label block with a size sufficient 942 enough, that the new ordinal can get covered. In this example the 943 same block size 10 is used also for the second label block. For 944 example router R2 would advertise the following label bindings. 946 LSA 149: LSA-ID : 948 All Router Block TLV: Block Size 10, Algo 0, Topology 0 950 All Router ID IPv4 Map TLV: ID 2, 192.168.1.2 952 LSA 149: LSA-ID : 954 All Router Block TLV: Block Size 10, Algo 0, Topology 0 956 Now the upstream router can map the new ID of R7 to an actual label 957 value, as ID '15' corresponds to the 5th label inside the second 958 Label block. 960 6. Inter Area Protocol Procedures 962 6.1. Applicability 964 Propagation of a MPLS LSPs and MPLS Block LSPs across an area 965 boundary is a local policy decision. 967 6.2. Data plane operations 969 If local policy dictates that a given ABR router needs to re- 970 advertise a MPLS LSPs from one area to another then it MUST allocate 971 a new label and program its label forwarding table to connect the new 972 label to the path in the respective other area. Depending on how to 973 reach the re-advertised LSP, this is typically done using a MPLS 974 'SWAP' or 'SWAP/PUSH' data plane operation. 976 6.3. Control plane operations 978 6.3.1. MPLS Label operations 980 If local policy dictates that a given ABR router needs to re- 981 advertise MPLS LSPs from one area to another then it must prepend its 982 "Traffic-Engineering-ID" as a loose hop in the Prefix ERO TLV list. 984 Furthermore it MUST append the Flags TLV and set the 'Down' Bit. 986 6.3.2. MPLS Label Block operations 988 If local policy dictates that a given ABR router advertises its 'All 989 Router Block' into another area, then it also MUST re-advertise all 990 known 'ID' ordinals (again gated by policy) to the respective other 991 area. Without knowledge of all 'ID's in the network no router is 992 able to construct SPT label switched paths. Furthermore an ABR MUST 993 append the Flags TLV and set the 'Down' Bit for all re-advertised 994 'CE' IDs. 996 7. Acknowledgements 998 Many thanks to Yakov Rekhter and Shraddha Hedge for their useful 999 comments. 1001 8. IANA Considerations 1003 This documents request allocation for one common OSPFv2 and OSPFv3 1004 LSA Type and TLVs contained within. 1006 +----------+------------------------+----------+------------+ 1007 | LSA Type | TLV | TLV Type | #Occurence | 1008 +----------+------------------------+----------+------------+ 1009 | 149 | | | >=0 | 1010 | | IPv4 Prefix ERO | 1 | >=0 | 1011 | | IPv6 Prefix ERO | 2 | >=0 | 1012 | | IPv4 Prefix Bypass ERO | 3 | >=0 | 1013 | | IPv6 Prefix Bypass ERO | 4 | >=0 | 1014 | | Flags | 5 | 0,1 | 1015 | | All Router Block | 6 | >=0 | 1016 | | All Router ID IPv4 Map | 7 | >=0 | 1017 | | All Router ID IPv6 Map | 8 | >=0 | 1018 +----------+------------------------+----------+------------+ 1020 Table 1: IANA allocations 1022 The MPLS Label LSA requires a new sub-registry, with a starting TLV 1023 value of 1, and managed by IETF consensus. 1025 9. Security Considerations 1027 This document does not introduce any change in terms of OSPF 1028 security. It simply proposes to flood MPLS label information via the 1029 IGP. All existing procedures to ensure message integrity do apply 1030 here. 1032 10. References 1034 10.1. Normative References 1036 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1037 Requirement Levels", BCP 14, RFC 2119, March 1997. 1039 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1040 Label Switching Architecture", RFC 3031, January 2001. 1042 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 1043 BGP-4", RFC 3107, May 2001. 1045 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1046 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1047 Tunnels", RFC 3209, December 2001. 1049 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1050 (TE) Extensions to OSPF Version 2", RFC 3630, 1051 September 2003. 1053 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1054 Hierarchy with Generalized Multi-Protocol Label Switching 1055 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 1057 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 1058 (VPLS) Using BGP for Auto-Discovery and Signaling", 1059 RFC 4761, January 2007. 1061 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1062 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1063 RFC 4915, June 2007. 1065 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1066 Specification", RFC 5036, October 2007. 1068 [RFC5151] Farrel, A., Ayyangar, A., and JP. Vasseur, "Inter-Domain 1069 MPLS and GMPLS Traffic Engineering -- Resource Reservation 1070 Protocol-Traffic Engineering (RSVP-TE) Extensions", 1071 RFC 5151, February 2008. 1073 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 1074 OSPF Opaque LSA Option", RFC 5250, July 2008. 1076 10.2. Informative References 1078 [I-D.gredler-rtgwg-igp-label-advertisement] 1079 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 1080 "Advertising MPLS labels in IGPs", 1081 draft-gredler-rtgwg-igp-label-advertisement-04 (work in 1082 progress), May 2013. 1084 [I-D.ietf-rtgwg-mrt-frr-architecture] 1085 Atlas, A., Kebler, R., Envedi, G., Csaszar, A., Tantsura, 1086 J., Konstantynowicz, M., White, R., and M. Shand, "An 1087 Architecture for IP/LDP Fast-Reroute Using Maximally 1088 Redundant Trees", draft-ietf-rtgwg-mrt-frr-architecture-02 1089 (work in progress), February 2013. 1091 [I-D.previdi-filsfils-isis-segment-routing] 1092 Previdi, S., Filsfils, C., Bashandy, A., Horneffer, M., 1093 Decraene, B., Litkowski, S., Milojevic, I., Shakir, R., 1094 Ytti, S., Henderickx, W., and J. Tantsura, "Segment 1095 Routing with IS-IS Routing Protocol", 1096 draft-previdi-filsfils-isis-segment-routing-02 (work in 1097 progress), March 2013. 1099 Authors' Addresses 1101 Hannes Gredler (editor) 1102 Juniper Networks, Inc. 1103 1194 N. Mathilda Ave. 1104 Sunnyvale, CA 94089 1105 US 1107 Email: hannes@juniper.net 1109 Shane Amante 1110 Level 3 Communications, Inc. 1111 1025 Eldorado Blvd 1112 Broomfield, CO 80021 1113 US 1115 Email: shane@level3.net 1116 Tom Scholl 1117 Amazon 1118 Seattle, WN 1119 US 1121 Email: tscholl@amazon.com 1123 Luay Jalil 1124 Verizon 1125 1201 E Arapaho Rd. 1126 Richardson, TX 75081 1127 US 1129 Email: luay.jalil@verizon.com