idnits 2.17.1 draft-anand-spring-poi-sr-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 43 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 26, 2017) is 2496 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.draft-sivabalan-pce-segment-routing' is mentioned on line 306, but not defined == Missing Reference: 'I-D.draft-sivabalan-pce-binding-label-sid-01' is mentioned on line 708, but not defined == Unused Reference: 'I-D.ietf-ospf-segment-routing-extensions' is defined on line 771, but no explicit reference was found in the text == Unused Reference: 'RFC4915' is defined on line 777, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ospf-ospfv3-segment-routing-extensions' is defined on line 781, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-ls-distribution' is defined on line 788, but no explicit reference was found in the text == Unused Reference: 'I-D.sivabalan-pce-binding-label-sid' is defined on line 799, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pce-segment-routing' is defined on line 805, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-04 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-05 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-05 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-03 ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) == Outdated reference: A later version (-07) exists of draft-sivabalan-pce-binding-label-sid-01 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-07 Summary: 2 errors (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group Madhukar Anand 3 Internet-Draft Sanjoy Bardhan 4 Intended Status: Informational Ramesh Subrahmaniam 5 Infinera Corporation 7 Jeff Tantsura 8 Individual 10 Utpal Mukhopadhyaya 11 Equinix Inc 13 Expires: December 28, 2017 June 26, 2017 15 Packet-Optical Integration in Segment Routing 16 draft-anand-spring-poi-sr-03 18 Abstract 20 This document illustrates a way to integrate a new class of nodes and 21 links in segment routing to represent transport networks in an opaque 22 way into the segment routing domain. An instance of this class would 23 be optical networks that are typically transport centric. In the IP 24 centric network, this will help in defining a common control protocol 25 for packet optical integration that will include optical paths as 26 'transport segments' or sub-paths as an augmentation to the defined 27 extensions of segment routing. The transport segment option also 28 defines a general mechanism to allow for future extensibility of 29 segment routing into non-packet domains. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of this Memo 39 This Internet-Draft is submitted to IETF in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as 45 Internet-Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 The list of current Internet-Drafts can be accessed at 53 http://www.ietf.org/1id-abstracts.html 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html 58 Copyright and License Notice 60 Copyright (c) 2017 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Reference Taxonomy . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Use case - Packet Optical Integration . . . . . . . . . . . . . 5 78 4. Mechanism overview . . . . . . . . . . . . . . . . . . . . . . 8 79 5. PCEP-LS extensions for supporting the transport segment . . . 8 80 6. OSPF extensions for supporting the transport segment . . . . . 10 81 7. OSPFv3 extensions for supporting the transport segment . . . . 11 82 8. IS-IS extensions for supporting the transport segment . . . . 12 83 9. BGP-LS extensions for supporting the transport segment . . . . 14 84 10. Note about Transport Segments and Scalability . . . . . . . . 17 85 11. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 87 13 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 88 13.1 PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 13.2 OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 13.3 OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 13.4 IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 13.5 BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 14 References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 14.1 Normative References . . . . . . . . . . . . . . . . . . . 19 95 14.2 Informative References . . . . . . . . . . . . . . . . . . 20 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 98 1 Introduction 100 Packet and optical transport networks have evolved independently with 101 different control plane mechanisms that have to be provisioned and 102 maintained separately. Consequently, coordinating packet and optical 103 networks for delivering services such as end-to-end traffic 104 engineering or failure response has proved challenging. To address 105 this challenge, a unified control and management paradigm that 106 provides an incremental path to complete packet-optical integration 107 while leveraging existing signaling and routing protocols in either 108 domains is needed. This document introduces such a paradigm based on 109 Segment Routing (SR) [I-D.ietf-spring-segment-routing]. 111 This document introduces a new type of segment, Transport segment. 112 Transport segment can be used to model abstracted paths through the 113 optical transport domain and integrate it with the packet network for 114 delivering end-to-end services. In addition, this also introduces a 115 notion of a Packet optical gateway (POG). These are nodes in the 116 network that map packet services to the optical domain that originate 117 and terminate these transport segments. Given a transport segment, a 118 POG will expand it to a path in the optical transport network. 120 The concept of POG introduced here allows for multiple instantiations 121 of the concept. In one case, the packet device is distinct from the 122 optical transport device, and the POG is a logical entity that spans 123 these two devices. In this case, the POG functionality is achieved 124 with the help of external coordination between the packet and optical 125 devices. In another case, the packet and optical components are 126 integrated into one physical device, and the co-ordination required 127 for functioning of the POG is performed by this integrated device. 128 It must be noted that in either case, it is the packet/optical data 129 plane that is either disaggregated or integrated. Control of the 130 devices can be logically centralized or distributed in either 131 scenario. The focus of this document is to define the logical 132 functions of a POG without going into the exact instantiations of the 133 concept. 135 2. Reference Taxonomy 137 POG - Packet optical gateway Device 139 SR Edge Router - The Edge Router which is the ingress device 141 CE - Customer Edge Device that is outside of the SR domain 143 PCE - Path Computation Engine 145 Controller - A network controller 147 3. Use case - Packet Optical Integration 149 Many operators build and operate their networks that are both multi- 150 layer and multi-domain. Services are built around these layers and 151 domains to provide end-to-end services. Due to the nature of the 152 different domains, such as packet and optical, the management and 153 service creation has always been problematic and time consuming. With 154 segment routing, enabling a head-end node to select a path and embed 155 the information in the packet is a powerful construct that would be 156 used in the Packet Optical Gateways (POG). The path is usually 157 constructed for each domain that may be manually derived or through a 158 stateful PCE which is run specifically in that domain. 160 P5 161 P1 _ .-'-._ ,'P4 162 `._ .-' `-. ,' 163 `. _.-' `-._ ,' 164 `-. .-' `-. ,' 165 P2`.-'--------------------------`-.- P3 166 |\ /| 167 | \ / | Packet 168 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 169 | \ / | 170 | \ / | Transport 171 | \ / | 172 | ................../ | 173 | ,'O2 O3`. | 174 | ,' `. | 175 |,' `. | 176 O1\ | O4 177 \ ,' 178 \ ,' 179 .......................- 180 O6 O5 182 Figure 1: Representation of a packet-optical path 184 In Figure 1 above, the nodes represent a packet optical network. 185 P1,...,P5 are packet devices. Nodes P2 and P3 are connected via optical 186 network comprising of nodes O1,...,O6. Nodes P2 and P3 are POGs that 187 communicate with other packet devices and also with the devices in the 188 optical transport domain. In defining a link in the packet domain 189 between P2 and P3, we will need to specify both the nodes and the links 190 in the optical transport domain that establish this link. 192 To leverage segment routing to define a service between P1 and P4, the 193 ingress node P1 would append all outgoing packets in a SR header 194 consisting of the SIDs that constitute the path. In the packet domain 195 this would mean P1 would send its packets towards P4 using a segment 196 list {P2, P3, P4} or {P2, P5, P3, P4} as the case may be. The operator 197 would need to use a different mechanism in the optical domain to set up 198 the optical paths comprising the nodes O1, O2 and O3. Each POG would 199 announce the active optical path as a transport segment - for example, 200 the optical path {O1, O2, O3} could be represented as a label Om and the 201 optical path {O2, O3} could be represented as a transport label On. Both 202 Om and On will be advertised by Packet node P1. These paths are not 203 known to the packet SR domain and is only relevant to the optical domain 204 D between P2 and P3. A PCE that is run in Domain D would be 205 responsible for calculating paths corresponding to label Om and On. The 206 expanded segment list would read as {P2, Om, P3, P4} or {P2, On, P3, 207 P4}. It is to be noted that there are other possible paths between P2 208 and P3 in the optical domain involving optical nodes O5, O6, and O4. 209 There is no requirement that every path between P2 and P3 be represented 210 as transport segments. A discussion on transport segments and 211 scalability can be found in Section 10. 213 Use-case examples of transport segments. 215 1. Consider the scenario where there are multiple fibers between two 216 packet end points. The network operator may choose to route packet 217 traffic on the first fiber, and reserve the second fiber only to 218 maintenance or low priority traffic. 220 2. As a second use-case, consider the case where the packet end points 221 are connected by optical transport provided by two different service 222 providers. The packet operator wants to preferentially route traffic 223 over one of the providers and use the second provider as a backup. 225 3. Finally, let the packet end points be connected by optical paths that 226 lie in different geographies. For instance, one optical transport path 227 may lie completely in one country while the other optical transport path 228 transits another country. Weather, tariffs, security considerations and 229 other factors may determine how the packet operator wants to route 230 different types of traffic on this network. 232 All of the above use-cases can be supported by first mapping distinct 233 optical transport paths to different transport segments and then, 234 depending on the need, affixing appropriate transport segment identifier 235 to the specific packet to route it appropriately through the transport 236 domain. 238 +------------------------+ 239 | | 240 +--------------+----' PCE or Controller |----+---------------+ 241 | | | | | | 242 | | +------------------------+ | | 243 | | | | 244 | | .-----. | | 245 | | ( ) | | 246 +-------+ +-------+ .--( )--. +-------+ +-------+ 247 | SR | |Packet | ( ) |Packet | | SR | 248 | Edge | |Optical|-( Optical Transport )_ |Optical| | Edge | 249 |Router | ... |Gateway| ( Domain ) |Gateway| ... |Router | 250 +---+.--+ +-------+ ( ) +-------+ +---+.--+ 251 | '--( )--' | 252 ,--+. ( ) ,-+-. 253 ( CE ) '-----' ( CE ) 254 `---' `---' 256 Figure 3. Reference Topology for Transport Segment Mechanism 258 4. Mechanism overview 260 The current proposal assumes that the SR domains run standard IGP 261 protocols to discover the topology and distribute labels without any 262 modification. There are also no modifications to the control plane 263 mechanisms in the Optical transport domains. For example, the optical 264 paths may be setup using a domain-specific controller or PCE based on 265 requirements from the packet domain (such as bandwidth, QoS, latency 266 and cost). The mechanism for supporting the transport segment in the 267 packet domain is as follows. 269 1. Firstly, the Packet Optical Gateway (POG) devices announce 270 themselves in the SR domain. This is indicated by advertising a new 271 SR node capability flag. The exact extensions to support this 272 capability are described in the subsequent sections of this 273 document. 275 2. Then, the POG devices announce paths to other POGs through the 276 optical transport domain as a transport segment (transport segment 277 binding SID) in the SR domain. The paths are announced with an 278 appropriate optical transport domain ID, and a label (Packet-Optical 279 Label) to be used to bind to the transport segment. The appropriate 280 IGP segment routing extensions to carry this information is described 281 in the subsequent sections of this document. 283 3. The transport segment can also optionally be announced with a 284 set of attributes that characterizes the path in the optical 285 transport domain between the two POG devices. For instance, those 286 attributes could define the OTN mapping used (e.g., ODU4, 287 ODU3,ODU3e1....ODU1), timeslots (1-8 or 4,6,7 or 1-2,5), or optical 288 path protection schemes. 290 4. The POG device is also responsible for programming its 291 forwarding table to map every transport segment label entry into an 292 appropriate forwarding action relevant in the optical domain, such as 293 mapping it to a label-switched path. 295 5. The transport segment is communicated to the PCE or Controller 296 using extensions to BGP-LS or PCEP-LS as described in subsequent 297 sections of this document. 299 6. Finally, the PCE or Controller then uses the transport segment 300 label to influence the path leaving the SR domain into the optical 301 domain, thereby defining the end-to-end path for a given service. 303 5. PCEP-LS extensions for supporting the transport segment 304 To communicate the Packet-Optical Gateway capability of the device, 305 we introduce a new PCEP capabilities TLV is defined as 306 follows(extensions to [I-D.draft-sivabalan-pce-segment-routing]): 308 Value Meaning Reference 309 -------- ------------------------------------ ----------------- 310 27 TRANSPORT-SR-PCE-CAPABILITY This document 312 A new type of TLV to accommodate a transport segment is defined 313 by extending Binding SIDs [I-D.draft-sivabalan-pce-binding-label-sid-01] 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Type | Length | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Binding Type (BT) | Domain ID | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Binding Value | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 ~ Transport Segment Sub TLVs (variable length) ~ 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 where: 329 Type: TBD, suggested value 32 331 Length: variable. 333 Binding Type: 0 or 1 as defined in 334 [I-D.draft-sivabalan-pce-binding-label-sid-01] 336 Domain ID: An identifier for the transport domain 338 Binding Value: is the transport segment label 340 Transport Segment Sub TLVs: TBD 342 IANA will be requested to allocate a new TLV type (recommended value 343 is 32) for TRANSPORT-SEGMENT-BINDING-TLV as specified in this document: 345 1 Transport Segment Label (This document) 347 6. OSPF extensions for supporting the transport segment 349 To communicate the Packet-Optical Gateway capability of the 350 device, we introduce an new optical informational capability bit in the 351 Router Information capabilities TLV (as defined in [RFC4970]). 353 Bit-24 - Optical - If set, then the router is capable of performing 354 Packet Optical Gateway function. 356 Further, a new OSPF sub-TLV (similar to the ERO SubTLV) of SID/Label 357 Binding Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the 358 transport segment label is defined as follows. 359 0 1 2 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Type | Length | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Domain ID | Flags | Reserved | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Packet-Optical Label | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 ~ Transport Segment Sub TLVs (variable length) ~ 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 where: 373 Type : TBD, Suggested Value 9 375 Length: variable. 377 Domain ID: An identifier for the transport domain 379 Flags: 1 octet field of following flags: 380 V - Value flag. If set, then the optical label carries a value. 381 By default the flag is SET. 382 L - Local. Local Flag. If set, then the value/index carried by 383 the Adj-SID has local significance. By default the flag is SET. 385 0 1 2 3 4 5 6 7 386 +-+-+-+-+-+-+-+-+ 387 |V|L| 388 +-+-+-+-+-+-+-+-+ 390 Packet-Optical Label : according to the V and L flags, it contains 391 either: 393 * A 3 octet local label where the 20 rightmost bits are 394 used for encoding the label value. In this case the V and 395 L flags MUST be set. 397 * A 4 octet index defining the offset in the label space 398 advertised by this router. In this case V and L flags MUST 399 be unset. 401 Transport Segment Sub TLVs: TBD 403 Multiple TRANSPORT-SEGMENT-BINDING-SUBTLV MAY be associated with a pair 404 of POG devices to represent multiple paths within the optical domain 406 7. OSPFv3 extensions for supporting the transport segment 408 To communicate the Packet-Optical Gateway capability of the 409 device, we introduce an new optical informational capability bit in the 410 Router Information capabilities TLV (as defined in [RFC4970]). 412 Bit-24 - Optical - If set, then the router is capable of performing 413 Packet Optical Gateway function. 415 Further, a new OSPFv3 sub-TLV similar to the ERO SubTLV) of SID/Label 416 Binding Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the 417 transport segment label is defined as follows. 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 | Domain ID | Flags | Reserved | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Packet-Optical Label | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 ~ Transport Segment Sub TLVs (variable length) ~ 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 where: 433 Type : TBD,Suggested Value 12 435 Length: variable. 437 Domain ID: An identifier for the transport domain 439 Flags: 1 octet field of following flags: 440 V - Value flag. If set, then the optical label carries a value. 441 By default the flag is SET. 442 L - Local. Local Flag. If set, then the value/index carried by 443 the Adj-SID has local significance. By default the flag is SET. 445 0 1 2 3 4 5 6 7 446 +-+-+-+-+-+-+-+-+ 447 |V|L| 448 +-+-+-+-+-+-+-+-+ 450 Packet-Optical Label : according to the V and L flags, it contains 451 either: 453 * A 3 octet local label where the 20 rightmost bits are 454 used for encoding the label value. In this case the V and 455 L flags MUST be set. 457 * A 4 octet index defining the offset in the label space 458 advertised by this router. In this case V and L flags MUST 459 be unset. 461 Transport Segment Sub TLVs: TBD 463 Multiple TRANSPORT-SEGMENT-BINDING-SUBTLV MAY be associated with a pair 464 of POG devices to represent multiple paths within the optical domain 466 8. IS-IS extensions for supporting the transport segment 468 To communicate the Packet-Optical Gateway capability of the device, we 469 introduce a new flag O in the SR Node Capabilities sub-TLV: 471 0 1 2 3 4 5 6 7 472 +-+-+-+-+-+-+-+-+ 473 |I|V|H|O| | 474 +-+-+-+-+-+-+-+-+ 476 I, V, H flags are defined in [I-D.ietf-isis-segment-routing-extensions] 478 O-Flag: If set, then the router is capable of performing Packet 479 Optical Gateway function. 481 Further, a new IS-IS sub-TLV (similar to the ERO SubTLV) of SID/Label 482 Binding Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the 483 transport segment label is defined as follows. 485 First, we define the O flag in the SID/Label Binding TLV 487 0 1 2 3 4 5 6 7 488 +-+-+-+-+-+-+-+-+ 489 |F|M|S|D|A|O| | 490 +-+-+-+-+-+-+-+-+ 491 F, M, S, D, and A flags: are defined in [I-D.ietf-isis-segment-routing 492 -extensions] 493 O-Flag: If set, then the F flag, Range, Prefix Length FEC Prefix, must 494 be ignored in the SID/Label Binding TLV 496 Secondly, we define the SubTLV of the SID/Label Binding Sub-TLV: 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Type | Length | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Domain ID | Flags | Reserved | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Packet-Optical Label | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 ~ Transport Segment Sub TLVs (variable length) ~ 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 where: 512 Type : TBD, Suggested Value 151 514 Length: variable. 516 Domain ID: An identifier for the transport domain 518 Flags: 1 octet field of following flags: 520 V - Value flag. If set, then the optical label carries a value. 521 By default the flag is SET. 522 L - Local. Local Flag. If set, then the value/index carried by 523 the Adj-SID has local significance. By default the flag is SET. 525 0 1 2 3 4 5 6 7 526 +-+-+-+-+-+-+-+-+ 527 |V|L| 528 +-+-+-+-+-+-+-+-+ 530 Packet-Optical Label : according to the V and L flags, it contains 531 either: 533 * A 3 octet local label where the 20 rightmost bits are 534 used for encoding the label value. In this case the V and 535 L flags MUST be set. 537 * A 4 octet index defining the offset in the label space 538 advertised by this router. In this case V and L flags MUST 539 be unset. 541 Transport Segment Sub TLVs: TBD 543 Multiple TRANSPORT-SEGMENT-BINDING-SUBTLV MAY be associated with a pair 544 of POG devices to represent multiple paths within the optical domain 545 with perhaps different characteristics. 547 9. BGP-LS extensions for supporting the transport segment 549 9.1 Node Attribuites TLV 551 To communicate the Packet-Optical Gateway capability of the 552 device, we introduce an new optical informational capability 553 the following new Node Attribute TLV is defined: 555 +-----------+----------------------------+----------+---------------+ 556 | TLV Code | Description | Length | Section | 557 | Point | | | | 558 +-----------+----------------------------+----------+---------------+ 559 | 1172 | SR-Optical-Node-Capability | variable | | 560 | | TLV | | | 561 +-----------+----------------------------+----------+---------------+ 563 Table 1: Node Attribute TLVs 565 These TLVs can ONLY be added to the Node Attribute associated with 566 the node NLRI that originates the corresponding SR TLV. 568 9.2 SR-Optical-Node-Capability TLV 570 The SR Capabilities sub-TLV has following format: 572 0 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Type | Length | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Flags | RESERVED | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 where: 582 Type : TBD, Suggested Value 1157 584 Length: variable. 586 Flags: The Flags field currently has only one bit defined. If the bit 587 is set it has the capability of an Packet Optical Gateway. 589 9.3 Prefix Attribute TLVs 590 The following Prefix Attribute Binding SID Sub-TLVs have been added: 592 +------------+-------------------------+----------+-----------------+ 593 | TLV Code | Description | Length | Section | 594 | Point | | | | 595 +------------+-------------------------+----------+-----------------+ 596 | 1173 | TRANSPORT-SEGMENT-SID | 12 | | 597 | | | | | 598 +------------+-------------------------+----------+-----------------+ 600 Table 4: Prefix Attribute - Binding SID Sub-TLVs 602 The Transport segment TLV allows a node to advertise an transport 603 segment within a single IGP domain. The transport segment SID TLV 604 TRANSPORT-SEGMENT-TLV has the following format: 606 9.3.1 Transport Segment SID Sub-TLV 608 Further, a new sub-TLV (similar to the IPV4 ERO SubTLV) of 609 Binding SID Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the 610 transport segment label is defined as follows. 612 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 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Type | Length | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Domain ID | Flags | Reserved | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Packet-Optical Label | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 ~ Transport Segment Sub TLVs (variable length) ~ 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 where: 624 Type : TBD 626 Length: variable. 628 Domain ID: An identifier for the transport domain 630 Flags: 1 octet field of following flags: 631 V - Value flag. If set, then the optical label carries a value. 632 By default the flag is SET. 633 L - Local. Local Flag. If set, then the value/index carried by 634 the Adj-SID has local significance. By default the flag is SET. 636 0 1 2 3 4 5 6 7 637 +-+-+-+-+-+-+-+-+ 638 |V|L| 639 +-+-+-+-+-+-+-+-+ 641 Packet-Optical Label : according to the V and L flags, it contains 642 either: 644 * A 3 octet local label where the 20 rightmost bits are 645 used for encoding the label value. In this case the V and 646 L flags MUST be set. 648 * A 4 octet index defining the offset in the label space 649 advertised by this router. In this case V and L flags MUST 650 be unset. 652 Transport Segment Sub TLVs: TBD 654 Multiple TRANSPORT-SEGMENT-TLV MAY be associated with a pair 655 of POG devices to represent multiple paths within the optical domain 657 10. Note about Transport Segments and Scalability 659 In most operational scenarios, there would be multiple, distinct paths 660 between the POGs. There is no requirement that every distinct path in 661 the optical domain be advertised as a separate transport segment. 662 Transport segments are designed to be consumed in the packet domain, 663 and the correspondence between transport segments and exact paths in 664 the optical domain are determined by their utility to the packet world. 665 Therefore, the number of transport segments is to be determined by the 666 individual packet-optical use-case. The number of actual paths in the 667 optical domain between the POG is expected to be large (counting the 668 number of active and passive devices in the optical network), it is 669 likely that multiple actual paths are to be advertised as one transport 670 segment. Of course, in the degenerate case, it is possible that there 671 is a one-to-one correspondence between an optical path and a transport 672 segment. Given this view of network operation, the POG is not expected 673 to handle a large number of transport segments (and identifiers). This 674 framework does leave open the possibility of handling a large number 675 of transport segments in future. For instance, a hierarchical 676 partitioning of the optical domain along with stacking of multiple 677 transport segment identifiers could be explored towards reducing 678 the overall number of transport segment identifiers. 680 11. Summary 682 The motivation for introducing a new type of segment - transport 683 segment - is to integrate transport networks with the segment routing 684 domain and expose characteristics of the transport domain into the 685 packet domain. An end-to-end path across packet and transport domains 686 can then be specified by attaching appropriate SIDs to the packet. 687 An instance of transport segments has been defined here for optical 688 networks, where paths between packet-optical gateway devices has been 689 abstracted using binding SIDs. Extensions to various protocols to 690 announce the transport segment have been proposed in this document. 692 12. Security Considerations 694 This document does not introduce any new security considerations. 696 13 IANA Considerations 698 This documents request allocation for the following TLVs and subTLVs. 700 13.1 PCEP 701 Packet-Optical Gateway capability of the device 703 Value Meaning Reference 704 -------- ------------------------------------ ----------------- 705 27 TRANSPORT-SR-PCE-CAPABILITY This document 707 A new type of TLV to accommodate a transport segment is defined 708 by extending Binding SIDs [I-D.draft-sivabalan-pce-binding-label-sid-01] 710 Value Description Reference 712 32 TRANSPORT-SR-PCEP-TLV This document 714 This document requests that a registry is created to manage the value 715 of the Binding Type field in the TRANSPORT-SR-PCEP TLV. 717 Value Description Reference 719 1 Transport Segment Label This document 721 13.2 OSPF 722 Transport-Segment SubTLV of OSPF Extended Prefix LSA 724 Value Description Reference 726 9 TRANSPORT-SR-OSPF-SUBTLV This document 728 13.3 OSPFv3 729 Transport-Segment SubTLV of OSPFv3 Extend-LSA Sub-TLV registry 731 Value Description Reference 733 12 TRANSPORT-SR-OSPFv3-SUBTLV This document 735 13.4 IS-IS 736 Transport-Segment SubTLV of Segment Identifier / Label Binding TLV 738 Value Description Reference 740 151 TRANSPORT-SR-ISIS-SUBTLV This document 742 13.5 BGP-LS 743 Node Attributes TLV: 745 Value Description Reference 747 1172 TRANSPORT-SR-BGPLS-CAPABILITY This document 749 Prefix Attribute Binding SID SubTLV: 751 Value Description Reference 753 1173 TRANSPORT-SR-BGPLS-TLV This document 755 14 References 757 14.1 Normative References 759 [I-D.ietf-spring-segment-routing] 760 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 761 and r. rjs@rob.sh, "Segment Routing Architecture", draft- 762 ietf-spring-segment-routing-04 (work in progress), July 763 2015. 765 [I-D.ietf-isis-segment-routing-extensions] 766 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 767 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 768 Extensions for Segment Routing", draft-ietf-isis-segment- 769 routing-extensions-05 (work in progress), June 2015. 771 [I-D.ietf-ospf-segment-routing-extensions] 772 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 773 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 774 Extensions for Segment Routing", draft-ietf-ospf-segment- 775 routing-extensions-05 (work in progress), June 2015. 777 [RFC4915] L. Nguyen, P. Psenak, S. Mirtorabi, P. Pillay-Esnault, and 778 A. Roy, "Multi-Topology (MT) Routing in OSPF.", RFC4915, 779 . 781 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 782 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 783 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 784 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 785 segment-routing-extensions-03 (work in progress), June 786 2015. 788 [I-D.ietf-idr-ls-distribution] 789 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 790 Ray, "North-Bound Distribution of Link-State and TE 791 Information using BGP", draft-ietf-idr-ls-distribution-13 792 (work in progress), October 2015. 794 [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 795 S. Shaffer, "Extensions to OSPF for Advertising Optional 796 Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July 797 2007, . 799 [I-D.sivabalan-pce-binding-label-sid] 800 Sivabalan, S., Filsfils, C., Previdi, S., Tantsura, J., 801 Hardwick, J., and M. Nanduri, "Carrying Binding Label/ 802 Segment-ID in PCE-based Networks.", draft-sivabalan-pce- 803 binding-label-sid-01 (work in progress), March 2016. 805 [I-D.ietf-pce-segment-routing] 806 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 807 Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick, 808 "PCEP Extensions for Segment Routing", draft-ietf-pce- 809 segment-routing-07 (work in progress), March 2016. 811 14.2 Informative References 813 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 814 Requirement Levels", BCP 14, RFC 2119, 815 DOI 10.17487/RFC2119, March 1997, 816 . 818 Authors' Addresses 820 Madhukar Anand 821 Infinera Corporation 822 169 W Java Dr, Sunnyvale, CA 94089 824 Email: manand@infinera.com 826 Sanjoy Bardhan 827 Infinera Corporation 828 169 W Java Dr, Sunnyvale, CA 94089 830 Email: sbardhan@infinera.com 832 Ramesh Subrahmaniam 833 Infinera Corporation 834 169 W Java Dr, Sunnyvale, CA 94089 836 Email: RSubrahmaniam@infinera.com 838 Jeff Tantsura 839 Email: jefftant.ietf@gmail.com 841 Utpal Mukhopadhyaya 842 Equinix Inc 843 1188 E. Arques, Sunnyvale, CA 94085 844 Email: umukhopadhyaya@equinix.com