idnits 2.17.1 draft-anand-spring-poi-sr-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 44 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 (December 22, 2016) is 2675 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 250, but not defined == Missing Reference: 'I-D.draft-sivabalan-pce-binding-label-sid-01' is mentioned on line 627, but not defined == Unused Reference: 'I-D.ietf-ospf-segment-routing-extensions' is defined on line 689, but no explicit reference was found in the text == Unused Reference: 'RFC4915' is defined on line 695, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ospf-ospfv3-segment-routing-extensions' is defined on line 699, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-ls-distribution' is defined on line 706, but no explicit reference was found in the text == Unused Reference: 'I-D.sivabalan-pce-binding-label-sid' is defined on line 717, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pce-segment-routing' is defined on line 723, 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 9 Expires: June 25, 2017 December 22, 2016 11 Packet-Optical Integration in Segment Routing 12 draft-anand-spring-poi-sr-02 14 Abstract 16 This document illustrates a way to integrate a new class of nodes and 17 links in segment routing to represent transport networks in an opaque 18 way into the segment routing domain. An instance of this class would 19 be optical networks that are typically transport centric. In the IP 20 centric network, this will help in defining a common control protocol 21 for packet optical integration that will include optical paths as 22 'transport segments' or sub-paths as an augmentation to the defined 23 extensions of segment routing. The transport segment option also 24 defines a general mechanism to allow for future extensibility of 25 segment routing into non-packet domains. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as 41 Internet-Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/1id-abstracts.html 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html 53 Copyright and License Notice 55 Copyright (c) 2016 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Reference Taxonomy . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Use case - Packet Optical Integration . . . . . . . . . . . . . 3 73 4. Mechanism overview . . . . . . . . . . . . . . . . . . . . . . 6 74 5. PCEP-LS extensions for supporting the transport segment . . . 6 75 6. OSPF extensions for supporting the transport segment . . . . . 8 76 7. OSPFv3 extensions for supporting the transport segment . . . . 9 77 8. IS-IS extensions for supporting the transport segment . . . . 10 78 9. BGP-LS extensions for supporting the transport segment . . . . 12 79 10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 81 12 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 82 12.1 PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 12.2 OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 12.3 OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 12.4 IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 12.5 BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 13.1 Normative References . . . . . . . . . . . . . . . . . . . 16 89 13.2 Informative References . . . . . . . . . . . . . . . . . . 18 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 92 1 Introduction 94 Packet and optical transport networks have evolved independently with 95 different control plane mechanisms that have to be provisioned and 96 maintained separately. Consequently, coordinating packet and optical 97 networks for delivering services such as end-to-end traffic 98 engineering or failure response has proved challenging. To address 99 this challenge, a unified control and management paradigm that 100 provides an incremental path to complete packet-optical integration 101 while leveraging existing signaling and routing protocols in either 102 domains is needed. This document introduces such a paradigm based on 103 Segment Routing (SR) [I-D.ietf-spring-segment-routing]. 105 This document introduces a new type of segment, Transport segment. 106 Transport segment can be used to model abstracted paths through the 107 optical transport domain and integrate it with the packet network for 108 delivering end-to-end services. In addition, this also introduces a 109 notion of a Packet optical gateway (POG). These are nodes in the 110 network that map packet services to the optical domain that originate 111 and terminate these transport segments. Given a transport segment, a 112 POG will expand it to a path in the optical transport network. 114 2. Reference Taxonomy 116 POG - Packet optical gateway Device 118 SR Edge Router - The Edge Router which is the ingress device 120 CE - Customer Edge Device that is outside of the SR domain 122 PCE - Path Computation Engine 124 Controller - A network controller 126 3. Use case - Packet Optical Integration 128 Many operators build and operate their networks that are both multi- 129 layer and multi-domain. Services are built around these layers and 130 domains to provide end-to-end services. Due to the nature of the 131 different domains, such as packet and optical, the management and 132 service creation has always been problematic and time consuming. With 133 segment routing, enabling a head-end node to select a path and embed 134 the information in the packet is a powerful construct that would be 135 used in the Packet Optical Gateways (POG). The path is usually 136 constructed for each domain that may be manually derived or through a 137 stateful PCE which is run specifically in that domain. 139 P5 140 P1 _ .-'-._ ,'P4 141 `._ .-' `-. ,' 142 `. _.-' `-._ ,' 143 `-. .-' `-. ,' 144 P2`.-'--------------------------`-.- P3 145 |\ /| 146 | \ / | Packet 147 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 148 | \ / | 149 | \ / | Transport 150 | \ / | 151 | ................../ | 152 | ,'O2 O3`. | 153 | ,' `. | 154 |,' `. | 155 O1\ | O4 156 \ ,' 157 \ ,' 158 .......................- 159 O6 O5 161 Figure 1: Representation of a packet-optical path 163 In Figure 1 above, the nodes represent a packet optical network. 164 P1,...,P5 are packet devices. Nodes P2 and P3 are connected via optical 165 network comprising of nodes O1,...,O6. Nodes P2 and P3 are POGs that 166 communicate with other packet devices and also with the devices in the 167 optical transport domain. In defining a link in the packet domain 168 between P2 and P3, we will need to specify both the nodes and the links 169 in the optical transport domain that establish this link. 171 To leverage segment routing to define a service between P1 and P4, the 172 ingress node P1 would append all outgoing packets in a SR header 173 consisting of the SIDs that constitute the path. In the packet domain 174 this would mean P1 would send its packets towards P4 using a segment 175 list {P2, P3, P4}. The operator would need to use a different mechanism 176 in the optical domain to set up the optical paths comprising the nodes 177 O1, O2 and O3. Each POG would announce the active optical path as a 178 transport segment - for example, in the case of P1, the optical path 179 {O1, O2, O3} would be represented as a label Om. This path is not known 180 to the packet SR domain and is only relevant to the optical domain D 181 between P2 and P3. A PCE that is run in Domain D would be responsible 182 for calculating path corresponding to label Om. The expanded segment 183 list would read as {P2, Om, P3, P4}. 185 +------------------------+ 186 | | 187 +--------------+----' PCE or Controller |----+---------------+ 188 | | | | | | 189 | | +------------------------+ | | 190 | | | | 191 | | .-----. | | 192 | | ( ) | | 193 +-------+ +-------+ .--( )--. +-------+ +-------+ 194 | SR | |Packet | ( ) |Packet | | SR | 195 | Edge | |Optical|-( Optical Transport )_ |Optical| | Edge | 196 |Router | ... |Gateway| ( Domain ) |Gateway| ... |Router | 197 +---+.--+ +-------+ ( ) +-------+ +---+.--+ 198 | '--( )--' | 199 ,--+. ( ) ,-+-. 200 ( CE ) '-----' ( CE ) 201 `---' `---' 203 Figure 3. Reference Topology for Transport Segment 204 4. Mechanism overview 206 The current proposal assumes that the SR domains run standard IGP 207 protocols to discover the topology and distribute labels without any 208 modification. There are also no modifications to the control plane 209 mechanisms in the Optical transport domains. The mechanism for 210 supporting the transport segment is as follows. 212 1. Firstly, the Packet Optical Gateway (POG) devices announce 213 themselves in the SR domain. This is indicated by advertising a new 214 SR node capability flag. The exact extensions to support this 215 capability are described in the subsequent sections of this 216 document. 218 2. Then, the POG devices announce paths to other POGs through the 219 optical transport domain as a transport segment (transport segment 220 binding SID) in the SR domain. The paths are announced with an 221 appropriate optical transport domain ID, and a label (Packet-Optical 222 Label) to be used to bind to the transport segment. The appropriate 223 IGP segment routing extensions to carry this information is described 224 in the subsequent sections of this document. 226 3. The transport segment can also optionally be announced with a 227 set of attributes that characterizes the path in the optical 228 transport domain between the two POG devices. For instance, those 229 attributes could define the OTN mapping used (e.g., ODU4, 230 ODU3,ODU3e1....ODU1), timeslots (1-8 or 4,6,7 or 1-2,5), or optical 231 path protection schemes. 233 4. The POG device is also responsible for programming its 234 forwarding table to map every transport segment label entry into an 235 appropriate forwarding action relevant in the optical domain, such as 236 mapping it to a label-switched path. 238 5. The transport segment is communicated to the PCE or Controller 239 using extensions to BGP-LS or PCEP-LS as described in subsequent 240 sections of this document. 242 6. Finally, the PCE or Controller then uses the transport segment 243 label to influence the path leaving the SR domain into the optical 244 domain, thereby defining the end-to-end path for a given service. 246 5. PCEP-LS extensions for supporting the transport segment 248 To communicate the Packet-Optical Gateway capability of the device, 249 we introduce a new PCEP capabilities TLV is defined as 250 follows(extensions to [I-D.draft-sivabalan-pce-segment-routing]): 252 Value Meaning Reference 253 -------- ------------------------------------ ----------------- 254 27 TRANSPORT-SR-PCE-CAPABILITY This document 256 A new type of TLV to accommodate a transport segment is defined 257 by extending Binding SIDs [I-D.draft-sivabalan-pce-binding-label-sid-01] 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Type | Length | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Binding Type (BT) | Domain ID | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Binding Value | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 ~ Transport Segment Sub TLVs (variable length) ~ 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 where: 273 Type: TBD, suggested value 32 275 Length: variable. 277 Binding Type: 0 or 1 as defined in 278 [I-D.draft-sivabalan-pce-binding-label-sid-01] 280 Domain ID: An identifier for the transport domain 282 Binding Value: is the transport segment label 284 Transport Segment Sub TLVs: TBD 286 IANA will be requested to allocate a new TLV type (recommended value 287 is 32) for TRANSPORT-SEGMENT-BINDING-TLV as specified in this document: 289 1 Transport Segment Label (This document) 291 6. OSPF extensions for supporting the transport segment 293 To communicate the Packet-Optical Gateway capability of the 294 device, we introduce an new optical informational capability bit in the 295 Router Information capabilities TLV (as defined in [RFC4970]). 297 Bit-24 - Optical - If set, then the router is capable of performing 298 Packet Optical Gateway function. 300 Further, a new OSPF sub-TLV (similar to the ERO SubTLV) of SID/Label 301 Binding Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the 302 transport segment label is defined as follows. 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Type | Length | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Domain ID | Flags | Reserved | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Packet-Optical Label | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 ~ Transport Segment Sub TLVs (variable length) ~ 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 where: 317 Type : TBD, Suggested Value 9 319 Length: variable. 321 Domain ID: An identifier for the transport domain 323 Flags: 1 octet field of following flags: 324 V - Value flag. If set, then the optical label carries a value. 325 By default the flag is SET. 326 L - Local. Local Flag. If set, then the value/index carried by 327 the Adj-SID has local significance. By default the flag is SET. 329 0 1 2 3 4 5 6 7 330 +-+-+-+-+-+-+-+-+ 331 |V|L| 332 +-+-+-+-+-+-+-+-+ 334 Packet-Optical Label : according to the V and L flags, it contains 335 either: 337 * A 3 octet local label where the 20 rightmost bits are 338 used for encoding the label value. In this case the V and 339 L flags MUST be set. 341 * A 4 octet index defining the offset in the label space 342 advertised by this router. In this case V and L flags MUST 343 be unset. 345 Transport Segment Sub TLVs: TBD 347 Multiple TRANSPORT-SEGMENT-BINDING-SUBTLV MAY be associated with a pair 348 of POG devices to represent multiple paths within the optical domain 350 7. OSPFv3 extensions for supporting the transport segment 352 To communicate the Packet-Optical Gateway capability of the 353 device, we introduce an new optical informational capability bit in the 354 Router Information capabilities TLV (as defined in [RFC4970]). 356 Bit-24 - Optical - If set, then the router is capable of performing 357 Packet Optical Gateway function. 359 Further, a new OSPFv3 sub-TLV similar to the ERO SubTLV) of SID/Label 360 Binding Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the 361 transport segment label is defined as follows. 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Type | Length | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Domain ID | Flags | Reserved | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Packet-Optical Label | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 ~ Transport Segment Sub TLVs (variable length) ~ 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 where: 376 Type : TBD,Suggested Value 12 378 Length: variable. 380 Domain ID: An identifier for the transport domain 382 Flags: 1 octet field of following flags: 383 V - Value flag. If set, then the optical label carries a value. 384 By default the flag is SET. 385 L - Local. Local Flag. If set, then the value/index carried by 386 the Adj-SID has local significance. By default the flag is SET. 388 0 1 2 3 4 5 6 7 389 +-+-+-+-+-+-+-+-+ 390 |V|L| 391 +-+-+-+-+-+-+-+-+ 393 Packet-Optical Label : according to the V and L flags, it contains 394 either: 396 * A 3 octet local label where the 20 rightmost bits are 397 used for encoding the label value. In this case the V and 398 L flags MUST be set. 400 * A 4 octet index defining the offset in the label space 401 advertised by this router. In this case V and L flags MUST 402 be unset. 404 Transport Segment Sub TLVs: TBD 406 Multiple TRANSPORT-SEGMENT-BINDING-SUBTLV MAY be associated with a pair 407 of POG devices to represent multiple paths within the optical domain 409 8. IS-IS extensions for supporting the transport segment 411 To communicate the Packet-Optical Gateway capability of the device, we 412 introduce a new flag O in the SR Node Capabilities sub-TLV: 414 0 1 2 3 4 5 6 7 415 +-+-+-+-+-+-+-+-+ 416 |I|V|H|O| | 417 +-+-+-+-+-+-+-+-+ 419 I, V, H flags are defined in [I-D.ietf-isis-segment-routing-extensions] 421 O-Flag: If set, then the router is capable of performing Packet 422 Optical Gateway function. 424 Further, a new IS-IS sub-TLV (similar to the ERO SubTLV) of SID/Label 425 Binding Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the 426 transport segment label is defined as follows. 428 First, we define the O flag in the SID/Label Binding TLV 430 0 1 2 3 4 5 6 7 431 +-+-+-+-+-+-+-+-+ 432 |F|M|S|D|A|O| | 433 +-+-+-+-+-+-+-+-+ 434 F, M, S, D, and A flags: are defined in [I-D.ietf-isis-segment-routing 435 -extensions] 436 O-Flag: If set, then the F flag, Range, Prefix Length FEC Prefix, must 437 be ignored in the SID/Label Binding TLV 439 Secondly, we define the SubTLV of the SID/Label Binding Sub-TLV: 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Type | Length | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Domain ID | Flags | Reserved | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Packet-Optical Label | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 ~ Transport Segment Sub TLVs (variable length) ~ 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 where: 455 Type : TBD, Suggested Value 151 457 Length: variable. 459 Domain ID: An identifier for the transport domain 461 Flags: 1 octet field of following flags: 462 V - Value flag. If set, then the optical label carries a value. 463 By default the flag is SET. 465 L - Local. Local Flag. If set, then the value/index carried by 466 the Adj-SID has local significance. By default the flag is SET. 468 0 1 2 3 4 5 6 7 469 +-+-+-+-+-+-+-+-+ 470 |V|L| 471 +-+-+-+-+-+-+-+-+ 473 Packet-Optical Label : according to the V and L flags, it contains 474 either: 476 * A 3 octet local label where the 20 rightmost bits are 477 used for encoding the label value. In this case the V and 478 L flags MUST be set. 480 * A 4 octet index defining the offset in the label space 481 advertised by this router. In this case V and L flags MUST 482 be unset. 484 Transport Segment Sub TLVs: TBD 486 Multiple TRANSPORT-SEGMENT-BINDING-SUBTLV MAY be associated with a pair 487 of POG devices to represent multiple paths within the optical domain 488 with perhaps different characteristics. 490 9. BGP-LS extensions for supporting the transport segment 492 9.1 Node Attribuites TLV 494 To communicate the Packet-Optical Gateway capability of the 495 device, we introduce an new optical informational capability 496 the following new Node Attribute TLV is defined: 498 +-----------+----------------------------+----------+---------------+ 499 | TLV Code | Description | Length | Section | 500 | Point | | | | 501 +-----------+----------------------------+----------+---------------+ 502 | 1172 | SR-Optical-Node-Capability | variable | | 503 | | TLV | | | 504 +-----------+----------------------------+----------+---------------+ 506 Table 1: Node Attribute TLVs 508 These TLVs can ONLY be added to the Node Attribute associated with 509 the node NLRI that originates the corresponding SR TLV. 511 9.2 SR-Optical-Node-Capability TLV 513 The SR Capabilities sub-TLV has following format: 515 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Type | Length | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Flags | RESERVED | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 where: 525 Type : TBD, Suggested Value 1157 527 Length: variable. 529 Flags: The Flags field currently has only one bit defined. If the bit 530 is set it has the capability of an Packet Optical Gateway. 532 9.3 Prefix Attribute TLVs 533 The following Prefix Attribute Binding SID Sub-TLVs have been added: 535 +------------+-------------------------+----------+-----------------+ 536 | TLV Code | Description | Length | Section | 537 | Point | | | | 538 +------------+-------------------------+----------+-----------------+ 539 | 1173 | TRANSPORT-SEGMENT-SID | 12 | | 540 | | | | | 541 +------------+-------------------------+----------+-----------------+ 543 Table 4: Prefix Attribute - Binding SID Sub-TLVs 545 The Transport segment TLV allows a node to advertise an transport 546 segment within a single IGP domain. The transport segment SID TLV 547 TRANSPORT-SEGMENT-TLV has the following format: 549 9.3.1 Transport Segment SID Sub-TLV 551 Further, a new sub-TLV (similar to the IPV4 ERO SubTLV) of 552 Binding SID Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the 553 transport segment label is defined as follows. 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Type | Length | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Domain ID | Flags | Reserved | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Packet-Optical Label | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 ~ Transport Segment Sub TLVs (variable length) ~ 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 where: 567 Type : TBD 569 Length: variable. 571 Domain ID: An identifier for the transport domain 573 Flags: 1 octet field of following flags: 574 V - Value flag. If set, then the optical label carries a value. 575 By default the flag is SET. 576 L - Local. Local Flag. If set, then the value/index carried by 577 the Adj-SID has local significance. By default the flag is SET. 579 0 1 2 3 4 5 6 7 580 +-+-+-+-+-+-+-+-+ 581 |V|L| 582 +-+-+-+-+-+-+-+-+ 584 Packet-Optical Label : according to the V and L flags, it contains 585 either: 587 * A 3 octet local label where the 20 rightmost bits are 588 used for encoding the label value. In this case the V and 589 L flags MUST be set. 591 * A 4 octet index defining the offset in the label space 592 advertised by this router. In this case V and L flags MUST 593 be unset. 595 Transport Segment Sub TLVs: TBD 597 Multiple TRANSPORT-SEGMENT-TLV MAY be associated with a pair 598 of POG devices to represent multiple paths within the optical domain 599 10. Summary 601 The motivation for introducing a new type of segment - transport 602 segment - is to integrate transport networks with the segment routing 603 domain and expose characteristics of the transport domain into the 604 packet domain. An end-to-end path across packet and transport domains 605 can then be specified by attaching appropriate SIDs to the packet. 606 An instance of transport segments has been defined here for optical 607 networks, where paths between packet-optical gateway devices has been 608 abstracted using binding SIDs. Extensions to various protocols to 609 announce the transport segment have been proposed in this document. 611 11. Security Considerations 613 This document does not introduce any new security considerations. 615 12 IANA Considerations 617 This documents request allocation for the following TLVs and subTLVs. 619 12.1 PCEP 620 Packet-Optical Gateway capability of the device 622 Value Meaning Reference 623 -------- ------------------------------------ ----------------- 624 27 TRANSPORT-SR-PCE-CAPABILITY This document 626 A new type of TLV to accommodate a transport segment is defined 627 by extending Binding SIDs [I-D.draft-sivabalan-pce-binding-label-sid-01] 629 Value Description Reference 631 32 TRANSPORT-SR-PCEP-TLV This document 633 This document requests that a registry is created to manage the value 634 of the Binding Type field in the TRANSPORT-SR-PCEP TLV. 636 Value Description Reference 638 1 Transport Segment Label This document 640 12.2 OSPF 641 Transport-Segment SubTLV of OSPF Extended Prefix LSA 642 Value Description Reference 644 9 TRANSPORT-SR-OSPF-SUBTLV This document 646 12.3 OSPFv3 647 Transport-Segment SubTLV of OSPFv3 Extend-LSA Sub-TLV registry 649 Value Description Reference 651 12 TRANSPORT-SR-OSPFv3-SUBTLV This document 653 12.4 IS-IS 654 Transport-Segment SubTLV of Segment Identifier / Label Binding TLV 656 Value Description Reference 658 151 TRANSPORT-SR-ISIS-SUBTLV This document 660 12.5 BGP-LS 661 Node Attributes TLV: 663 Value Description Reference 665 1172 TRANSPORT-SR-BGPLS-CAPABILITY This document 667 Prefix Attribute Binding SID SubTLV: 669 Value Description Reference 671 1173 TRANSPORT-SR-BGPLS-TLV This document 673 13 References 675 13.1 Normative References 677 [I-D.ietf-spring-segment-routing] 678 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 679 and r. rjs@rob.sh, "Segment Routing Architecture", draft- 680 ietf-spring-segment-routing-04 (work in progress), July 681 2015. 683 [I-D.ietf-isis-segment-routing-extensions] 684 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 685 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 686 Extensions for Segment Routing", draft-ietf-isis-segment- 687 routing-extensions-05 (work in progress), June 2015. 689 [I-D.ietf-ospf-segment-routing-extensions] 690 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 691 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 692 Extensions for Segment Routing", draft-ietf-ospf-segment- 693 routing-extensions-05 (work in progress), June 2015. 695 [RFC4915] L. Nguyen, P. Psenak, S. Mirtorabi, P. Pillay-Esnault, and 696 A. Roy, "Multi-Topology (MT) Routing in OSPF.", RFC4915, 697 . 699 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 700 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 701 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 702 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 703 segment-routing-extensions-03 (work in progress), June 704 2015. 706 [I-D.ietf-idr-ls-distribution] 707 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 708 Ray, "North-Bound Distribution of Link-State and TE 709 Information using BGP", draft-ietf-idr-ls-distribution-13 710 (work in progress), October 2015. 712 [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 713 S. Shaffer, "Extensions to OSPF for Advertising Optional 714 Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July 715 2007, . 717 [I-D.sivabalan-pce-binding-label-sid] 718 Sivabalan, S., Filsfils, C., Previdi, S., Tantsura, J., 719 Hardwick, J., and M. Nanduri, "Carrying Binding Label/ 720 Segment-ID in PCE-based Networks.", draft-sivabalan-pce- 721 binding-label-sid-01 (work in progress), March 2016. 723 [I-D.ietf-pce-segment-routing] 724 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 725 Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick, 726 "PCEP Extensions for Segment Routing", draft-ietf-pce- 727 segment-routing-07 (work in progress), March 2016. 729 13.2 Informative References 731 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 732 Requirement Levels", BCP 14, RFC 2119, 733 DOI 10.17487/RFC2119, March 1997, 734 . 736 Authors' Addresses 738 Madhukar Anand 739 Infinera Corporation 740 169 W Java Dr, Sunnyvale, CA 94089 742 Email: manand@infinera.com 744 Sanjoy Bardhan 745 Infinera Corporation 746 169 W Java Dr, Sunnyvale, CA 94089 748 Email: sbardhan@infinera.com 750 Ramesh Subrahmaniam 751 Infinera Corporation 752 169 W Java Dr, Sunnyvale, CA 94089 754 Email: RSubrahmaniam@infinera.com 756 Jeff Tantsura 758 Email: jefftant.ietf@gmail.com