idnits 2.17.1 draft-previdi-6man-segment-routing-header-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 5, 2015) is 3278 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 963 -- Looks like a reference, but probably isn't: '1' on line 951 -- Looks like a reference, but probably isn't: '2' on line 945 -- Looks like a reference, but probably isn't: '3' on line 586 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-03 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-12) exists of draft-ietf-spring-ipv6-use-cases-04 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-01 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-00 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Previdi, Ed. 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: November 6, 2015 B. Field 6 Comcast 7 I. Leung 8 Rogers Communications 9 May 5, 2015 11 IPv6 Segment Routing Header (SRH) 12 draft-previdi-6man-segment-routing-header-06 14 Abstract 16 Segment Routing (SR) allows a node to steer a packet through a 17 controlled set of instructions, called segments, by prepending a SR 18 header to the packet. A segment can represent any instruction, 19 topological or service-based. SR allows to enforce a flow through 20 any path (topological, or application/service based) while 21 maintaining per-flow state only at the ingress node to the SR domain. 23 Segment Routing can be applied to the IPv6 data plane with the 24 addition of a new type of Routing Extension Header. This draft 25 describes the Segment Routing Extension Header Type and how it is 26 used by SR capable nodes. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on November 6, 2015. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Structure of this document . . . . . . . . . . . . . . . . . 3 68 2. Segment Routing Documents . . . . . . . . . . . . . . . . . . 3 69 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3.1. Data Planes supporting Segment Routing . . . . . . . . . 4 71 3.2. Illustration . . . . . . . . . . . . . . . . . . . . . . 4 72 4. Abstract Routing Model . . . . . . . . . . . . . . . . . . . 7 73 4.1. Segment Routing Global Block (SRGB) . . . . . . . . . . . 8 74 4.2. Traffic Engineering with SR . . . . . . . . . . . . . . . 9 75 4.3. Segment Routing Database . . . . . . . . . . . . . . . . 10 76 5. IPv6 Instantiation of Segment Routing . . . . . . . . . . . . 10 77 5.1. Segment Identifiers (SIDs) and SRGB . . . . . . . . . . . 10 78 5.1.1. Node-SID . . . . . . . . . . . . . . . . . . . . . . 10 79 5.1.2. Adjacency-SID . . . . . . . . . . . . . . . . . . . . 11 80 5.2. Segment Routing Extension Header (SRH) . . . . . . . . . 12 81 5.2.1. SRH and RFC2460 behavior . . . . . . . . . . . . . . 15 82 6. SRH Procedures . . . . . . . . . . . . . . . . . . . . . . . 16 83 6.1. Segment Routing Operations . . . . . . . . . . . . . . . 16 84 6.2. Segment Routing Node Functions . . . . . . . . . . . . . 16 85 6.2.1. Ingress SR Node . . . . . . . . . . . . . . . . . . . 17 86 6.2.2. Transit Non-SR Capable Node . . . . . . . . . . . . . 18 87 6.2.3. SR Intra Segment Transit Node . . . . . . . . . . . . 18 88 6.2.4. SR Segment Endpoint Node . . . . . . . . . . . . . . 18 89 6.3. FRR Flag Settings . . . . . . . . . . . . . . . . . . . . 19 90 7. SR and Tunneling . . . . . . . . . . . . . . . . . . . . . . 19 91 8. Example Use Case . . . . . . . . . . . . . . . . . . . . . . 19 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 93 10. Manageability Considerations . . . . . . . . . . . . . . . . 22 94 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 95 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 96 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 97 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 98 14.1. Normative References . . . . . . . . . . . . . . . . . . 22 99 14.2. Informative References . . . . . . . . . . . . . . . . . 23 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 102 1. Structure of this document 104 Section 3 gives an introduction on SR for IPv6 networks. 106 Section 4 describes the Segment Routing abstract model. 108 Section 5 defines the Segment Routing Header (SRH) allowing 109 instantiation of SR over IPv6 dataplane. 111 Section 6 details the procedures of the Segment Routing Header. 113 2. Segment Routing Documents 115 Segment Routing terminology is defined in 116 [I-D.ietf-spring-segment-routing]. 118 Segment Routing use cases are described in 119 [I-D.filsfils-spring-segment-routing-use-cases]. 121 Segment Routing IPv6 use cases are described in 122 [I-D.ietf-spring-ipv6-use-cases]. 124 Segment Routing protocol extensions are defined in 125 [I-D.ietf-isis-segment-routing-extensions], and 126 [I-D.psenak-ospf-segment-routing-ospfv3-extension]. 128 The security mechanisms of the Segment Routing Header (SRH) are 129 described in [I-D.vyncke-6man-segment-routing-security]. 131 3. Introduction 133 Segment Routing (SR), defined in [I-D.ietf-spring-segment-routing], 134 allows a node to steer a packet through a controlled set of 135 instructions, called segments, by prepending a SR header to the 136 packet. A segment can represent any instruction, topological or 137 service-based. SR allows to enforce a flow through any path 138 (topological or service/application based) while maintaining per-flow 139 state only at the ingress node to the SR domain. Segments can be 140 derived from different components: IGP, BGP, Services, Contexts, 141 Locators, etc. The list of segment forming the path is called the 142 Segment List and is encoded in the packet header. 144 SR allows the use of strict and loose source based routing paradigms 145 without requiring any additional signaling protocols in the 146 infrastructure hence delivering an excellent scalability property. 148 The source based routing model described in 149 [I-D.ietf-spring-segment-routing] is inherited from the ones proposed 150 by [RFC1940] and [RFC2460]. The source based routing model offers 151 the support for explicit routing capability. 153 3.1. Data Planes supporting Segment Routing 155 Segment Routing (SR), can be instantiated over MPLS 156 ([I-D.ietf-spring-segment-routing-mpls]) and IPv6. This document 157 defines its instantiation over the IPv6 data-plane based on the use- 158 cases defined in [I-D.ietf-spring-ipv6-use-cases]. 160 Segment Routing for IPv6 (SR-IPv6) is required in networks where MPLS 161 data-plane is not used or, when combined with SR-MPLS, in networks 162 where MPLS is used in the core and IPv6 is used at the edge (home 163 networks, datacenters). 165 This document defines a new type of Routing Header (originally 166 defined in [RFC2460]) called the Segment Routing Header (SRH) in 167 order to convey the Segment List in the packet header as defined in 168 [I-D.ietf-spring-segment-routing]. Mechanisms through which segment 169 are known and advertised are outside the scope of this document. 171 3.2. Illustration 173 In the context of Figure 1 where all the links have the same IGP 174 cost, let us assume that a packet P enters the SR domain at an 175 ingress edge router I and that the operator requests the following 176 requirements for packet P: 178 The local service S offered by node B must be applied to packet P. 180 The links AB and CE cannot be used to transport the packet P. 182 Any node N along the journey of the packet should be able to 183 determine where the packet P entered the SR domain and where it 184 will exit. The intermediate node should be able to determine the 185 paths from the ingress edge router to itself, and from itself to 186 the egress edge router. 188 Per-flow State for packet P should only be created at the ingress 189 edge router. 191 The operator can forbid, for security reasons, anyone outside the 192 operator domain to exploit its intra-domain SR capabilities. 194 I---A---B---C---E 195 \ | / \ / 196 \ | / F 197 \|/ 198 D 200 Figure 1: An illustration of SR properties 202 All these properties may be realized by instructing the ingress SR 203 edge router I to push the following abstract SR header on the packet 204 P. 206 +---------------------------------------------------------------+ 207 | | | 208 | Abstract SR Header | | 209 | | | 210 | {SD, SB, SS, SF, SE}, Ptr, SI, SE | Transported | 211 | ^ | | Packet | 212 | | | | P | 213 | +---------------------+ | | 214 | | | 215 +---------------------------------------------------------------+ 217 Figure 2: Packet P at node I 219 The abstract SR header contains a source route encoded as a list of 220 segments {SD, SB, SS, SF, SE}, a pointer (Ptr) and the identification 221 of the ingress and egress SR edge routers (segments SI and SE). 223 A segment identifies a topological instruction or a service 224 instruction. A segment can either be global or local. The 225 instruction associated with a global segment is recognized and 226 executed by any SR-capable node in the domain. The instruction 227 associated with a local segment is only supported by the specific 228 node that originates it. 230 Let us assume some IGP (i.e.: ISIS and OSPF) extensions to define a 231 "Node Segment" as a global instruction within the IGP domain to 232 forward a packet along the shortest path to the specified node. Let 233 us further assume that within the SR domain illustrated in Figure 1, 234 segments SI, SD, SB, SE and SF respectively identify IGP node 235 segments to I, D, B, E and F. 237 Let us assume that node B identifies its local service S with local 238 segment SS. 240 With all of this in mind, let us describe the journey of the packet 241 P. 243 The packet P reaches the ingress SR edge router. I pushes the SR 244 header illustrated in Figure 2 and sets the pointer to the first 245 segment of the list (SD). 247 SD is an instruction recognized by all the nodes in the SR domain 248 which causes the packet to be forwarded along the shortest path to D. 250 Once at D, the pointer is incremented and the next segment is 251 executed (SB). 253 SB is an instruction recognized by all the nodes in the SR domain 254 which causes the packet to be forwarded along the shortest path to B. 256 Once at B, the pointer is incremented and the next segment is 257 executed (SS). 259 SS is an instruction only recognized by node B which causes the 260 packet to receive service S. 262 Once the service applied, the next segment is executed (SF) which 263 causes the packet to be forwarded along the shortest path to F. 265 Once at F, the pointer is incremented and the next segment is 266 executed (SE). 268 SE is an instruction recognized by all the nodes in the SR domain 269 which causes the packet to be forwarded along the shortest path to E. 271 E then removes the SR header and the packet continues its journey 272 outside the SR domain. 274 All of the requirements are met. 276 First, the packet P has not used links AB and CE: the shortest-path 277 from I to D is I-A-D, the shortest-path from D to B is D-B, the 278 shortest-path from B to F is B-C-F and the shortest-path from F to E 279 is F-E, hence the packet path through the SR domain is I-A-D-B-C-F-E 280 and the links AB and CE have been avoided. 282 Second, the service S supported by B has been applied on packet P. 284 Third, any node along the packet path is able to identify the service 285 and topological journey of the packet within the SR domain. For 286 example, node C receives the packet illustrated in Figure 3 and hence 287 is able to infer where the packet entered the SR domain (SI), how it 288 got up to itself {SD, SB, SS, SE}, where it will exit the SR domain 289 (SE) and how it will do so {SF, SE}. 291 +---------------------------------------------------------------+ 292 | | | 293 | SR Header | | 294 | | | 295 | {SD, SB, SS, SF, SE}, Ptr, SI, SE | Transported | 296 | ^ | | Packet | 297 | | | | P | 298 | +--------+ | | 299 | | | 300 +---------------------------------------------------------------+ 302 Figure 3: Packet P at node C 304 Fourth, only node I maintains per-flow state for packet P. The 305 entire program of topological and service instructions to be executed 306 by the SR domain on packet P is encoded by the ingress edge router I 307 in the SR header in the form of a list of segments where each segment 308 identifies a specific instruction. No further per-flow state is 309 required along the packet path. The per-flow state is in the SR 310 header and travels with the packet. Intermediate nodes only hold 311 states related to the IGP global node segments and the local IGP 312 adjacency segments. These segments are not per-flow specific and 313 hence scale very well. Typically, an intermediate node would 314 maintain in the order of 100's to 1000's global node segments and in 315 the order of 10's to 100 of local adjacency segments. Typically the 316 SR IGP forwarding table is expected to be much less than 10000 317 entries. 319 Fifth, the SR header is inserted at the entrance to the domain and 320 removed at the exit of the operator domain. For security reasons, 321 the operator can forbid anyone outside its domain to use its intra- 322 domain SR capability. 324 4. Abstract Routing Model 326 At the entrance of the SR domain, the ingress SR edge router pushes 327 the SR header on top of the packet. At the exit of the SR domain, 328 the egress SR edge router removes the SR header. 330 The abstract SR header contains an ordered list of segments, a 331 pointer identifying the next segment to process and the 332 identifications of the ingress and egress SR edge routers on the path 333 of this packet. The pointer identifies the segment that MUST be used 334 by the receiving router to process the packet. This segment is 335 called the active segment. 337 A property of SR is that the entire source route of the packet, 338 including the identity of the ingress and egress edge routers is 339 always available with the packet. This allows for interesting 340 accounting and service applications. 342 We define three SR-header operations: 344 "PUSH": an SR header is pushed on an IP packet, or additional 345 segments are added at the head of the segment list. The pointer 346 is moved to the first entry of the added segments. 348 "NEXT": the active segment is completed, the pointer is moved to 349 the next segment in the list. 351 "CONTINUE": the active segment is not completed, the pointer is 352 left unchanged. 354 In the future, other SR-header management operations may be defined. 356 As the packet travels through the SR domain, the pointer is 357 incremented through the ordered list of segments and the source route 358 encoded by the SR ingress edge node is executed. 360 A node processes an incoming packet according to the instruction 361 associated with the active segment. 363 Any instruction might be associated with a segment: for example, an 364 intra-domain topological strict or loose forwarding instruction, a 365 service instruction, etc. 367 At minimum, a segment instruction must define two elements: the 368 identity of the next-hop to forward the packet to (this could be the 369 same node or a context within the node) and which SR-header 370 management operation to execute. 372 Each segment is known in the network through a Segment Identifier 373 (SID). The terms "segment" and "SID" are interchangeable. 375 4.1. Segment Routing Global Block (SRGB) 377 In the SR abstract model, a segment is identified by a Segment 378 Routing Identifier (SID). The SR abstract model doesn't mandate a 379 specific format for the SID (IPv6 address or other formats). 381 In Segment Routing IPv6 the SID is an IPv6 address. Therefore, the 382 SRGB is materialized by the global IPv6 address space which 383 represents the set of IPv6 routable addresses in the SR domain. The 384 following rules apply: 386 o Each node of the SR domain MUST be configured with the Segment 387 Routing Global Block (SRGB). 389 o All global segments must be allocated from the SRGB. Any SR 390 capable node MUST be able to process any global segment advertised 391 by any other node within the SR domain. 393 o Any segment outside the SRGB has a local significance and is 394 called a "local segment". An SR-capable node MUST be able to 395 process the local segments it originates. An SR-capable node MUST 396 NOT support the instruction associated with a local segment 397 originated by a remote node. 399 4.2. Traffic Engineering with SR 401 An SR Traffic Engineering policy is composed of two elements: a flow 402 classification and a segment-list to prepend on the packets of the 403 flow. 405 In SR, this per-flow state only exists at the ingress edge node where 406 the policy is defined and the SR header is pushed. 408 It is outside the scope of the document to define the process that 409 leads to the instantiation at a node N of an SR Traffic Engineering 410 policy. 412 [I-D.filsfils-spring-segment-routing-use-cases] illustrates various 413 alternatives: 415 N is deriving this policy automatically (e.g. FRR). 417 N is provisioned explicitly by the operator. 419 N is provisioned by a controller or server (e.g.: SDN Controller). 421 N is provisioned by the operator with a high-level policy which is 422 mapped into a path thanks to a local CSPF-based computation (e.g. 423 affinity/SRLG exclusion). 425 N could also be provisioned by other means. 427 [I-D.filsfils-spring-segment-routing-use-cases] explains why the 428 majority of use-cases require very short segment-lists, hence 429 minimizing the performance impact, if any, of inserting and 430 transporting the segment list. 432 A SDN controller, which desires to instantiate at node N an SR 433 Traffic Engineering policy, collects the SR capability of node N such 434 as to ensure that the policy meets its capability. 436 4.3. Segment Routing Database 438 The Segment routing Database (SRDB) is a set of entries where each 439 entry is identified by a SID. The instruction associated with each 440 entry at least defines the identity of the next-hop to which the 441 packet should be forwarded and what operation should be performed on 442 the SR header (PUSH, CONTINUE, NEXT). 444 +---------+-----------+---------------------------------+ 445 | Segment | Next-Hop | SR Header operation | 446 +---------+-----------+---------------------------------+ 447 | Sk | M | CONTINUE | 448 | Sj | N | NEXT | 449 | Sl | NAT Srvc | NEXT | 450 | Sm | FW srvc | NEXT | 451 | Sn | Q | NEXT | 452 | etc. | etc. | etc. | 453 +---------+-----------+---------------------------------+ 455 Figure 4: SR Database 457 Each SR-capable node maintains its local SRDB. SRDB entries can 458 either derive from local policy or from protocol segment 459 advertisement. 461 5. IPv6 Instantiation of Segment Routing 463 5.1. Segment Identifiers (SIDs) and SRGB 465 Segment Routing, as described in [I-D.ietf-spring-segment-routing], 466 defines Node-SID and Adjacency-SID. When SR is used over IPv6 data- 467 plane the following applies. 469 The SRGB is the global IPv6 address space which represents the set of 470 IPv6 routable addresses in the SR domain. 472 5.1.1. Node-SID 474 The Node-SID identifies a node. With SR-IPv6 the Node-SID is an IPv6 475 prefix that the operator configured on the node and that is used as 476 the node identifier. Typically, in case of a router, this is the 477 IPv6 address of the node loopback interface. Therefore, SR-IPv6 does 478 not require any additional SID advertisement for the Node Segment. 479 The Node-SID is in fact the IPv6 address of the node. 481 Node SIDs are IPv6 addresses part of the SRGB (i.e.: addresses of 482 global scope). 484 5.1.2. Adjacency-SID 486 Adjacency-SIDs can be either globally scoped IPv6 addresses or any 487 128-bit identifier representing the adjacency. Obviously, in the 488 latter case, the scope of the Adjacency-SID is local to the router 489 and any packet with the a such Adjacency-SID would need first to 490 reach the node through the node's Node-SID prior for the node to 491 process the Adjacency-SID. In other wrods, two segments (SIDs) would 492 then be required: the first is the node's Node-SID that brings the 493 packet to the node and the second is the Adjacency-SID that will make 494 the node to forward the packet through the interface the Adjacency- 495 SID is allocated to. 497 In the SR architecture defined in [I-D.ietf-spring-segment-routing] 498 the Adjacency-SID (or Adj-SID) is the segment identifier associated 499 with the instruction of forwarding the packet through the interface 500 the Adj-SID is assigned to. Adj-SIDs can be either globally scoped 501 IPv6 addresses or any 128-bit identifier representing the adjacency. 502 Obviously, in the latter case, the scope of the Adj-SID is local to 503 the router and any packet with the a such Adj-SID would need first to 504 reach the node through the node's Node-SID prior for the node to 505 process the Adj-SID. In other wrods, two segments (SIDs) would then 506 be required: the first is the node's Node-SID that brings the packet 507 to the node and the second is the Adj-SID that will make the node to 508 forward the packet through the interface the Adj-SID is allocated to. 509 A node may advertise one (or more) Adj-SIDs allocated to the same 510 interface as well as a node can advertise the same Adj-SID for 511 multiple interfaces. Use cases of Adj-SID advertisements are 512 described in [I-D.ietf-spring-segment-routing]The semantic of the 513 Adj-SID is: 515 Send out the packet to the interface this Adj-SID is allocated to. 517 When SR is applied to IPv6, Node-SIDs are a global IPv6 addresses and 518 therefore, an Adj-SID has a global significance (i.e.: the IPv6 519 address representing the SID is a global address). In other words, a 520 node that advertises the Adj-SID in the form of a global IPv6 address 521 representing the link/adjacency the packet has to be forwarded to, 522 will apply to the Adj-SID a global significance. 524 Advertisement of Adj-SID may be done using multiple mechanisms among 525 which the ones described in ISIS and OSPF protocol extensions: 526 [I-D.ietf-isis-segment-routing-extensions] and 527 [I-D.psenak-ospf-segment-routing-ospfv3-extension]. The distinction 528 between local and global significance of the Adj-SID is given in the 529 encoding of the Adj-SID advertisement. 531 5.2. Segment Routing Extension Header (SRH) 533 A new type of the Routing Header (originally defined in [RFC2460]) is 534 defined: the Segment Routing Header (SRH) which has a new Routing 535 Type, (suggested value 4) to be assigned by IANA. 537 As an example, if an explicit path is to be constructed across a core 538 network running ISIS or OSPF, the segment list will contain SIDs 539 representing the nodes across the path (loose or strict) which, 540 usually, are the IPv6 loopback interface address of each node. If 541 the path is across service or application entities, the segment list 542 contains the IPv6 addresses of these services or application 543 instances. 545 The Segment Routing Header (SRH) is defined as follows: 547 0 1 2 3 548 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | First Segment | Flags | HMAC Key ID | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | | 555 | Segment List[0] (128 bits ipv6 address) | 556 | | 557 | | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | | 560 | | 561 ... 562 | | 563 | | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | | 566 | Segment List[n] (128 bits ipv6 address) | 567 | | 568 | | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | | 571 | Policy List[0] (optional) | 572 | | 573 | | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | | 576 | Policy List[1] (optional) | 577 | | 578 | | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | | 581 | Policy List[2] (optional) | 582 | | 583 | | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | | 586 | Policy List[3] (optional) | 587 | | 588 | | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | | 591 | | 592 | | 593 | HMAC (256 bits) | 594 | (optional) | 595 | | 596 | | 597 | | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 where: 602 o Next Header: 8-bit selector. Identifies the type of header 603 immediately following the SRH. 605 o Hdr Ext Len: 8-bit unsigned integer, is the length of the SRH 606 header in 8-octet units, not including the first 8 octets. 608 o Routing Type: TBD, to be assigned by IANA (suggested value: 4). 610 o Segments Left. Defined in [RFC2460], it contains the index, in 611 the Segment List, of the next segment to inspect. Segments Left 612 is decremented at each segment and it is used as an index in the 613 segment list. 615 o First Segment: offset in the SRH, not including the first 8 octets 616 and expressed in 16-octet units, pointing to the last element of 617 the segment list, which is in fact the first segment of the 618 segment routing path. 620 o Flags: 16 bits of flags. Following flags are defined: 622 1 623 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 |C|P|R|R| Policy Flags | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 C-flag: Clean-up flag. Set when the SRH has to be removed from 629 the packet when packet reaches the last segment. 631 P-flag: Protected flag. Set when the packet has been rerouted 632 through FRR mechanism by a SR endpoint node. See Section 6.3 633 for more details. 635 R-flags. Reserved and for future use. 637 Policy Flags. Define the type of the IPv6 addresses encoded 638 into the Policy List (see below). The following have been 639 defined: 641 Bits 4-6: determine the type of the first element after the 642 segment list. 644 Bits 7-9: determine the type of the second element. 646 Bits 10-12: determine the type of the third element. 648 Bits 13-15: determine the type of the fourth element. 650 The following values are used for the type: 652 0x0: Not present. If value is set to 0x0, it means the 653 element represented by these bits is not present. 655 0x1: SR Ingress. 657 0x2: SR Egress. 659 0x3: Original Source Address. 661 o HMAC Key ID and HMAC field, and their use are defined in 662 [I-D.vyncke-6man-segment-routing-security]. 664 o Segment List[n]: 128 bit IPv6 addresses representing the nth 665 segment in the Segment List. The Segment List is encoded starting 666 from the last segment of the path. I.e., the first element of the 667 segment list (Segment List [0]) contains the last segment of the 668 path while the last segment of the Segment List (Segment List[n]) 669 contains the first segment of the path. The index contained in 670 "Segments Left" identifies the current active segment. 672 o Policy List. Optional addresses representing specific nodes in 673 the SR path such as: 675 SR Ingress: a 128 bit generic identifier representing the 676 ingress in the SR domain (i.e.: it needs not to be a valid IPv6 677 address). 679 SR Egress: a 128 bit generic identifier representing the egress 680 in the SR domain (i.e.: it needs not to be a valid IPv6 681 address). 683 Original Source Address: IPv6 address originally present in the 684 SA field of the packet. 686 The segments in the Policy List are encoded after the segment list 687 and they are optional. If none are in the SRH, all bits of the 688 Policy List Flags MUST be set to 0x0. 690 5.2.1. SRH and RFC2460 behavior 692 The SRH being a new type of the Routing Header, it also has the same 693 properties: 695 SHOULD only appear once in the packet. 697 Only the router whose address is in the DA field of the packet 698 header MUST inspect the SRH. 700 Therefore, Segment Routing in IPv6 networks implies that the segment 701 identifier (i.e.: the IPv6 address of the segment) is moved into the 702 DA of the packet. 704 The DA of the packet changes at each segment termination/completion 705 and therefore the original DA of the packet MUST be encoded as the 706 last segment of the path. 708 As illustrated in Section 3.2, nodes that are within the path of a 709 segment will forward packets based on the DA of the packet without 710 inspecting the SRH. This ensures full interoperability between SR- 711 capable and non-SR-capable nodes. 713 6. SRH Procedures 715 In this section we describe the different procedures on the SRH. 717 6.1. Segment Routing Operations 719 When Segment Routing is instantiated over the IPv6 data plane the 720 following applies: 722 o The segment list is encoded in the SRH. 724 o The active segment is in the destination address of the packet. 726 o The Segment Routing CONTINUE operation (as described in 727 [I-D.ietf-spring-segment-routing]) is implemented as a regular/ 728 plain IPv6 operation consisting of DA based forwarding. 730 o The NEXT operation is implemented through the update of the DA 731 with the value represented by the Next Segment field in the SRH. 733 o The PUSH operation is implemented through the insertion of the SRH 734 or the insertion of additional segments in the SRH segment list. 736 6.2. Segment Routing Node Functions 738 SR packets are forwarded to segments endpoints (i.e.: nodes whose 739 address is in the DA field of the packet). The segment endpoint, 740 when receiving a SR packet destined to itself, does: 742 o Inspect the SRH. 744 o Determine the next active segment. 746 o Update the Segments Left field (or, if requested, remove the SRH 747 from the packet). 749 o Update the DA. 751 o Send the packet to the next segment. 753 The procedures applied to the SRH are related to the node function. 754 Following nodes functions are defined: 756 Ingress SR Node. 758 Transit Non-SR Node. 760 Transit SR Intra Segment Node. 762 SR Endpoint Node. 764 6.2.1. Ingress SR Node 766 Ingress Node can be a router at the edge of the SR domain or a SR- 767 capable host. The ingress SR node may obtain the segment list by 768 either: 770 Local path computation. 772 Local configuration. 774 Interaction with an SDN controller delivering the path as a 775 complete SRH. 777 Any other mechanism (mechanisms through which the path is acquired 778 are outside the scope of this document). 780 The following are the steps of the creation of the SRH: 782 Next Header and Hdr Ext Len fields are set according to [RFC2460]. 784 Routing Type field is set as TBD (SRH). 786 The Segment List is built with the FIRST segment of the path 787 encoded in the LAST element of the Segment List. Subsequent 788 segments are encoded on top of the first segment. Finally, the 789 LAST segment of the path is encoded in the FIRST element of the 790 Segment List. In other words, the Segment List is encoded in the 791 reverse order of the path. 793 The original DA of the packet is encoded as the last segment of 794 the path (encoded in the first element of the Segment List). 796 The DA of the packet is set with the value of the first segment 797 (found in the last element of the segment list). 799 The Segments Left field is set to n-1 where n is the number of 800 elements in the Segment List. 802 The First Segment field is set to n-1 where n is the number of 803 elements in the Segment List. 805 The packet is sent out towards the first segment (i.e.: 806 represented in the packet DA). 808 6.2.1.1. Security at Ingress 810 The procedures related to the Segment Routing security are detailed 811 in [I-D.vyncke-6man-segment-routing-security]. 813 In the case where the SR domain boundaries are not under control of 814 the network operator (e.g.: when the SR domain edge is in a home 815 network), it is important to authenticate and validate the content of 816 any SRH being received by the network operator. In such case, the 817 security procedure described in 818 [I-D.vyncke-6man-segment-routing-security] is to be used. 820 The ingress node (e.g.: the host in the home network) requests the 821 SRH from a control system (e.g.: an SDN controller) which delivers 822 the SRH with its HMAC signature on it. 824 Then, the home network host can send out SR packets (with an SRH on 825 it) that will be validated at the ingress of the network operator 826 infrastructure. 828 The ingress node of the network operator infrastructure, is 829 configured in order to validate the incoming SRH HMACs in order to 830 allow only packets having correct SRH according to their SA/DA 831 addresses. 833 6.2.2. Transit Non-SR Capable Node 835 SR is interoperable with plain IPv6 forwarding. Any non SR-capable 836 node will forward SR packets solely based on the DA. There's no SRH 837 inspection. This ensures full interoperability between SR and non-SR 838 nodes. 840 6.2.3. SR Intra Segment Transit Node 842 Only the node whose address is in DA inspects and processes the SRH 843 (according to [RFC2460]). An intra segment transit node is not in 844 the DA and its forwarding is based on DA and its SR-IPv6 FIB. 846 6.2.4. SR Segment Endpoint Node 848 The SR segment endpoint node is the node whose address is in the DA. 849 The segment endpoint node inspects the SRH and does: 851 1. IF DA = myself (segment endpoint) 852 2. IF Segments Left > 0 THEN 853 decrement Segments Left 854 update DA with Segment List[Segments Left] 855 3. IF Segments Left == 0 THEN 856 IF Clean-up bit is set THEN remove the SRH 857 4. ELSE give the packet to next PID (application) 858 End of processing. 859 5. Forward the packet out 861 6.3. FRR Flag Settings 863 A node supporting SR and doing Fast Reroute (as described in 864 [I-D.filsfils-spring-segment-routing-use-cases], when rerouting 865 packets through FRR mechanisms, SHOULD inspect the rerouted packet 866 header and look for the SRH. If the SRH is present, the rerouting 867 node SHOULD set the Protected bit on all rerouted packets. 869 7. SR and Tunneling 871 Encapsulation can be realized in two different ways with SR-IPv6: 873 Outer encapsulation. 875 SRH with SA/DA original addresses. 877 Outer encapsulation tunneling is the traditional method where an 878 additional IPv6 header is prepended to the packet. The original IPv6 879 header being encapsulated, everything is preserved and the packet is 880 switched/routed according to the outer header (that could contain a 881 SRH). 883 SRH allows encoding both original SA and DA, hence an operator may 884 decide to change the SA/DA at ingress and restore them at egress. 885 This can be achieved without outer encapsulation, by changing SA/DA 886 and encoding the original SA in the Policy List and in the original 887 DA in the Segment List. 889 8. Example Use Case 891 A more detailed description of use cases are available in 892 [I-D.ietf-spring-ipv6-use-cases]. In this section, a simple SR-IPv6 893 example is illustrated. 895 In the topology described in Figure 6 it is assumed an end-to-end SR 896 deployment. Therefore SR is supported by all nodes from A to J. 898 Home Network | Backbone | Datacenter 899 | | 900 | +---+ +---+ +---+ | +---+ | 901 +---|---| C |---| D |---| E |---|---| I |---| 902 | | +---+ +---+ +---+ | +---+ | 903 | | | | | | | | +---+ 904 +---+ +---+ | | | | | | |--| X | 905 | A |---| B | | +---+ +---+ +---+ | +---+ | +---+ 906 +---+ +---+ | | F |---| G |---| H |---|---| J |---| 907 | +---+ +---+ +---+ | +---+ | 908 | | 909 | +-----------+ 910 | SDN | 911 | Orch/Ctlr | 912 +-----------+ 914 Figure 6: Sample SR topology 916 The following workflow applies to packets sent by host A and destined 917 to server X. 919 . Host A sends a request for a path to server X to the SDN 920 controller or orchestration system. 922 . The SDN controller/orchestrator builds a SRH with: 923 . Segment List: C, F, J, X 924 . HMAC 925 that satisfies the requirements expressed in the request 926 by host A and based on policies applicable to host A. 928 . Host A receives the SRH and insert it into the packet. 929 The packet has now: 930 . SA: A 931 . DA: C 932 . SRH with 933 . SL: X, J, F, C 934 . Segments Left: 3 (i.e.: Segment List size - 1) 935 . PL: C (ingress), J (egress) 936 Note that X is the last segment and C is the 937 first segment (i.e.: the SL is encoded in the reverse 938 path order). 939 . HMAC 941 . When packet arrives in C (first segment), C does: 942 . Validate the HMAC of the SRH. 943 . Decrement Segments Left by one: 2 944 . Update the DA with the next segment found in 945 Segment List[2]. DA is set to F. 946 . Forward the packet to F. 948 . When packet arrives in F (second segment), F does: 949 . Decrement Segments Left by one: 1 950 . Update the DA with the next segment found in 951 Segment List[1]. DA is set to J. 952 . Forward the packet to J. 954 . Packet travels across G and H nodes which do plain 955 IPv6 forwarding based on DA. No inspection of SRH needs 956 to be done in these nodes. However, any SR capable node 957 is allowed to set the Protected bit in case of FRR 958 protection. 960 . When packet arrives in J (third segment), J does: 961 . Decrement Segments Left by one: 0 962 . Update the DA with the next segment found in 963 Segment List[0]. DA is set to X. 964 . If the cleanup bit is set, then node J will strip out 965 the SRH from the packet. 966 . Forward the packet to X. 968 The packet arrives in the server that may or may not support SR. The 969 return traffic, from server to host, may be sent using the same 970 procedures. 972 9. IANA Considerations 974 TBD 976 10. Manageability Considerations 978 TBD 980 11. Security Considerations 982 Security mechanisms applied to Segment Routing over IPv6 networks are 983 detailed in [I-D.vyncke-6man-segment-routing-security]. 985 12. Contributors 987 The authors would like to thank Dave Barach, John Leddy, John 988 Brzozowski, Pierre Francois, Nagendra Kumar, Mark Townsley, Christian 989 Martin, Roberta Maglione, Eric Vyncke, James Connolly, David Lebrun 990 and Fred Baker for their contribution to this document. 992 13. Acknowledgements 994 TBD 996 14. References 998 14.1. Normative References 1000 [I-D.ietf-isis-segment-routing-extensions] 1001 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 1002 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 1003 Extensions for Segment Routing", draft-ietf-isis-segment- 1004 routing-extensions-03 (work in progress), October 2014. 1006 [I-D.psenak-ospf-segment-routing-ospfv3-extension] 1007 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1008 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 1009 Extensions for Segment Routing", draft-psenak-ospf- 1010 segment-routing-ospfv3-extension-02 (work in progress), 1011 July 2014. 1013 [I-D.vyncke-6man-segment-routing-security] 1014 Vyncke, E., Previdi, S., and D. Lebrun, "IPv6 Segment 1015 Routing Security Considerations", draft-vyncke-6man- 1016 segment-routing-security-02 (work in progress), February 1017 2015. 1019 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1020 Requirement Levels", BCP 14, RFC 2119, March 1997. 1022 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1023 (IPv6) Specification", RFC 2460, December 1998. 1025 14.2. Informative References 1027 [I-D.filsfils-spring-segment-routing-use-cases] 1028 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1029 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1030 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1031 Crabbe, "Segment Routing Use Cases", draft-filsfils- 1032 spring-segment-routing-use-cases-01 (work in progress), 1033 October 2014. 1035 [I-D.ietf-spring-ipv6-use-cases] 1036 Brzozowski, J., Leddy, J., Leung, I., Previdi, S., 1037 Townsley, W., Martin, C., Filsfils, C., and R. Maglione, 1038 "IPv6 SPRING Use Cases", draft-ietf-spring-ipv6-use- 1039 cases-04 (work in progress), March 2015. 1041 [I-D.ietf-spring-segment-routing] 1042 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1043 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 1044 and E. Crabbe, "Segment Routing Architecture", draft-ietf- 1045 spring-segment-routing-01 (work in progress), February 1046 2015. 1048 [I-D.ietf-spring-segment-routing-mpls] 1049 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1050 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 1051 and E. Crabbe, "Segment Routing with MPLS data plane", 1052 draft-ietf-spring-segment-routing-mpls-00 (work in 1053 progress), December 2014. 1055 [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D. 1056 Zappala, "Source Demand Routing: Packet Format and 1057 Forwarding Specification (Version 1)", RFC 1940, May 1996. 1059 Authors' Addresses 1061 Stefano Previdi (editor) 1062 Cisco Systems, Inc. 1063 Via Del Serafico, 200 1064 Rome 00142 1065 Italy 1067 Email: sprevidi@cisco.com 1069 Clarence Filsfils 1070 Cisco Systems, Inc. 1071 Brussels 1072 BE 1074 Email: cfilsfil@cisco.com 1076 Brian Field 1077 Comcast 1078 4100 East Dry Creek Road 1079 Centennial, CO 80122 1080 US 1082 Email: Brian_Field@cable.comcast.com 1084 Ida Leung 1085 Rogers Communications 1086 8200 Dixie Road 1087 Brampton, ON L6T 0C1 1088 CA 1090 Email: Ida.Leung@rci.rogers.com