idnits 2.17.1 draft-previdi-6man-segment-routing-header-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (October 24, 2014) is 3471 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 555 -- Looks like a reference, but probably isn't: '1' on line 560 -- Looks like a reference, but probably isn't: '2' on line 565 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-02 == Outdated reference: A later version (-12) exists of draft-ietf-spring-ipv6-use-cases-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 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: April 27, 2015 B. Field 6 Comcast 7 I. Leung 8 Rogers Communications 9 October 24, 2014 11 IPv6 Segment Routing Header (SRH) 12 draft-previdi-6man-segment-routing-header-03 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 April 27, 2015. 50 Copyright Notice 52 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . 11 79 5.1.2. Adjacency-SID . . . . . . . . . . . . . . . . . . . . 11 80 5.2. Segment Routing Extension Header (SRH) . . . . . . . . . 11 81 5.2.1. SRH and RFC2460 behavior . . . . . . . . . . . . . . 14 82 5.2.2. SRH Optimization . . . . . . . . . . . . . . . . . . 15 83 6. SRH Procedures . . . . . . . . . . . . . . . . . . . . . . . 16 84 6.1. Segment Routing Operations . . . . . . . . . . . . . . . 16 85 6.2. Segment Routing Node Functions . . . . . . . . . . . . . 16 86 6.2.1. Ingress SR Node . . . . . . . . . . . . . . . . . . . 17 87 6.2.2. Transit Non-SR Capable Node . . . . . . . . . . . . . 18 88 6.2.3. SR Intra Segment Transit Node . . . . . . . . . . . . 18 89 6.2.4. SR Segment Endpoint Node . . . . . . . . . . . . . . 18 90 6.3. FRR Flag Settings . . . . . . . . . . . . . . . . . . . . 19 91 7. SR and Tunneling . . . . . . . . . . . . . . . . . . . . . . 19 92 8. Example Use Case . . . . . . . . . . . . . . . . . . . . . . 19 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 94 10. Manageability Considerations . . . . . . . . . . . . . . . . 22 95 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 96 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 97 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 98 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 14.1. Normative References . . . . . . . . . . . . . . . . . . 22 100 14.2. Informative References . . . . . . . . . . . . . . . . . 22 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 103 1. Structure of this document 105 Section 3 gives an introduction on SR for IPv6 networks. 107 Section 4 describes the Segment Routing abstract model. 109 Section 5 defines the Segment Routing Header (SRH) allowing 110 instantiation of SR over IPv6 dataplane. 112 Section 6 details the procedures of the Segment Routing Header. 114 2. Segment Routing Documents 116 Segment Routing terminology is defined in 117 [I-D.filsfils-spring-segment-routing]. 119 Segment Routing use cases are described in 120 [I-D.filsfils-spring-segment-routing-use-cases]. 122 Segment Routing IPv6 use cases are described in 123 [I-D.ietf-spring-ipv6-use-cases]. 125 Segment Routing protocol extensions are defined in 126 [I-D.ietf-isis-segment-routing-extensions], and 127 [I-D.psenak-ospf-segment-routing-ospfv3-extension]. 129 The security mechanisms of the Segment Routing Header (SRH) are 130 described in [I-D.vyncke-6man-segment-routing-security]. 132 3. Introduction 134 Segment Routing (SR), defined in 135 [I-D.filsfils-spring-segment-routing], allows a node to steer a 136 packet through a controlled set of instructions, called segments, by 137 prepending a SR header to the packet. A segment can represent any 138 instruction, topological or service-based. SR allows to enforce a 139 flow through any path (topological or service/application based) 140 while maintaining per-flow state only at the ingress node to the SR 141 domain. Segments can be derived from different components: IGP, BGP, 142 Services, Contexts, Locators, etc. The list of segment forming the 143 path is called the Segment List and is encoded in the packet header. 145 SR allows the use of strict and loose source based routing paradigms 146 without requiring any additional signaling protocols in the 147 infrastructure hence delivering an excellent scalability property. 149 The source based routing model described in 150 [I-D.filsfils-spring-segment-routing] is inherited from the ones 151 proposed by [RFC1940] and [RFC2460]. The source based routing model 152 offers the support for explicit routing capability. 154 3.1. Data Planes supporting Segment Routing 156 Segment Routing (SR), can be instantiated over MPLS 157 ([I-D.filsfils-spring-segment-routing-mpls]) and IPv6. This document 158 defines its instantiation over the IPv6 data-plane based on the use- 159 cases defined in [I-D.ietf-spring-ipv6-use-cases]. 161 Segment Routing for IPv6 (SR-IPv6) is required in networks where MPLS 162 data-plane is not used or, when combined with SR-MPLS, in networks 163 where MPLS is used in the core and IPv6 is used at the edge (home 164 networks, datacenters). 166 This document defines a new type of Routing Header (originally 167 defined in [RFC2460]) called the Segment Routing Header (SRH) in 168 order to convey the Segment List in the packet header as defined in 169 [I-D.filsfils-spring-segment-routing]. Mechanisms through which 170 segment are known and advertised are outside the scope of this 171 document. 173 3.2. Illustration 175 In the context of Figure 1 where all the links have the same IGP 176 cost, let us assume that a packet P enters the SR domain at an 177 ingress edge router I and that the operator requests the following 178 requirements for packet P: 180 The local service S offered by node B must be applied to packet P. 182 The links AB and CE cannot be used to transport the packet P. 184 Any node N along the journey of the packet should be able to 185 determine where the packet P entered the SR domain and where it 186 will exit. The intermediate node should be able to determine the 187 paths from the ingress edge router to itself, and from itself to 188 the egress edge router. 190 Per-flow State for packet P should only be created at the ingress 191 edge router. 193 The operator can forbid, for security reasons, anyone outside the 194 operator domain to exploit its intra-domain SR capabilities. 196 I---A---B---C---E 197 \ | / \ / 198 \ | / F 199 \|/ 200 D 202 Figure 1: An illustration of SR properties 204 All these properties may be realized by instructing the ingress SR 205 edge router I to push the following abstract SR header on the packet 206 P. 208 +---------------------------------------------------------------+ 209 | | | 210 | Abstract SR Header | | 211 | | | 212 | {SD, SB, SS, SF, SE}, Ptr, SI, SE | Transported | 213 | ^ | | Packet | 214 | | | | P | 215 | +---------------------+ | | 216 | | | 217 +---------------------------------------------------------------+ 219 Figure 2: Packet P at node I 221 The abstract SR header contains a source route encoded as a list of 222 segments {SD, SB, SS, SF, SE}, a pointer (Ptr) and the identification 223 of the ingress and egress SR edge routers (segments SI and SE). 225 A segment identifies a topological instruction or a service 226 instruction. A segment can either be global or local. The 227 instruction associated with a global segment is recognized and 228 executed by any SR-capable node in the domain. The instruction 229 associated with a local segment is only supported by the specific 230 node that originates it. 232 Let us assume some IGP (i.e.: ISIS and OSPF) extensions to define a 233 "Node Segment" as a global instruction within the IGP domain to 234 forward a packet along the shortest path to the specified node. Let 235 us further assume that within the SR domain illustrated in Figure 1, 236 segments SI, SD, SB, SE and SF respectively identify IGP node 237 segments to I, D, B, E and F. 239 Let us assume that node B identifies its local service S with local 240 segment SS. 242 With all of this in mind, let us describe the journey of the packet 243 P. 245 The packet P reaches the ingress SR edge router. I pushes the SR 246 header illustrated in Figure 2 and sets the pointer to the first 247 segment of the list (SD). 249 SD is an instruction recognized by all the nodes in the SR domain 250 which causes the packet to be forwarded along the shortest path to D. 252 Once at D, the pointer is incremented and the next segment is 253 executed (SB). 255 SB is an instruction recognized by all the nodes in the SR domain 256 which causes the packet to be forwarded along the shortest path to B. 258 Once at B, the pointer is incremented and the next segment is 259 executed (SS). 261 SS is an instruction only recognized by node B which causes the 262 packet to receive service S. 264 Once the service applied, the next segment is executed (SF) which 265 causes the packet to be forwarded along the shortest path to F. 267 Once at F, the pointer is incremented and the next segment is 268 executed (SE). 270 SE is an instruction recognized by all the nodes in the SR domain 271 which causes the packet to be forwarded along the shortest path to E. 273 E then removes the SR header and the packet continues its journey 274 outside the SR domain. 276 All of the requirements are met. 278 First, the packet P has not used links AB and CE: the shortest-path 279 from I to D is I-A-D, the shortest-path from D to B is D-B, the 280 shortest-path from B to F is B-C-F and the shortest-path from F to E 281 is F-E, hence the packet path through the SR domain is I-A-D-B-C-F-E 282 and the links AB and CE have been avoided. 284 Second, the service S supported by B has been applied on packet P. 286 Third, any node along the packet path is able to identify the service 287 and topological journey of the packet within the SR domain. For 288 example, node C receives the packet illustrated in Figure 3 and hence 289 is able to infer where the packet entered the SR domain (SI), how it 290 got up to itself {SD, SB, SS, SE}, where it will exit the SR domain 291 (SE) and how it will do so {SF, SE}. 293 +---------------------------------------------------------------+ 294 | | | 295 | SR Header | | 296 | | | 297 | {SD, SB, SS, SF, SE}, Ptr, SI, SE | Transported | 298 | ^ | | Packet | 299 | | | | P | 300 | +--------+ | | 301 | | | 302 +---------------------------------------------------------------+ 304 Figure 3: Packet P at node C 306 Fourth, only node I maintains per-flow state for packet P. The 307 entire program of topological and service instructions to be executed 308 by the SR domain on packet P is encoded by the ingress edge router I 309 in the SR header in the form of a list of segments where each segment 310 identifies a specific instruction. No further per-flow state is 311 required along the packet path. The per-flow state is in the SR 312 header and travels with the packet. Intermediate nodes only hold 313 states related to the IGP global node segments and the local IGP 314 adjacency segments. These segments are not per-flow specific and 315 hence scale very well. Typically, an intermediate node would 316 maintain in the order of 100's to 1000's global node segments and in 317 the order of 10's to 100 of local adjacency segments. Typically the 318 SR IGP forwarding table is expected to be much less than 10000 319 entries. 321 Fifth, the SR header is inserted at the entrance to the domain and 322 removed at the exit of the operator domain. For security reasons, 323 the operator can forbid anyone outside its domain to use its intra- 324 domain SR capability. 326 4. Abstract Routing Model 328 At the entrance of the SR domain, the ingress SR edge router pushes 329 the SR header on top of the packet. At the exit of the SR domain, 330 the egress SR edge router removes the SR header. 332 The abstract SR header contains an ordered list of segments, a 333 pointer identifying the next segment to process and the 334 identifications of the ingress and egress SR edge routers on the path 335 of this packet. The pointer identifies the segment that MUST be used 336 by the receiving router to process the packet. This segment is 337 called the active segment. 339 A property of SR is that the entire source route of the packet, 340 including the identity of the ingress and egress edge routers is 341 always available with the packet. This allows for interesting 342 accounting and service applications. 344 We define three SR-header operations: 346 "PUSH": an SR header is pushed on an IP packet, or additional 347 segments are added at the head of the segment list. The pointer 348 is moved to the first entry of the added segments. 350 "NEXT": the active segment is completed, the pointer is moved to 351 the next segment in the list. 353 "CONTINUE": the active segment is not completed, the pointer is 354 left unchanged. 356 In the future, other SR-header management operations may be defined. 358 As the packet travels through the SR domain, the pointer is 359 incremented through the ordered list of segments and the source route 360 encoded by the SR ingress edge node is executed. 362 A node processes an incoming packet according to the instruction 363 associated with the active segment. 365 Any instruction might be associated with a segment: for example, an 366 intra-domain topological strict or loose forwarding instruction, a 367 service instruction, etc. 369 At minimum, a segment instruction must define two elements: the 370 identity of the next-hop to forward the packet to (this could be the 371 same node or a context within the node) and which SR-header 372 management operation to execute. 374 Each segment is known in the network through a Segment Identifier 375 (SID). The terms "segment" and "SID" are interchangeable. 377 4.1. Segment Routing Global Block (SRGB) 379 In the SR abstract model, a segment is identified by a Segment 380 Routing Identifier (SID). The SR abstract model doesn't mandate a 381 specific format for the SID (IPv6 address or other formats). 383 In Segment Routing IPv6 the SID is an IPv6 address. Therefore, the 384 SRGB is materialized by the global IPv6 address space which 385 represents the set of IPv6 routable addresses in the SR domain. The 386 following rules apply: 388 o Each node of the SR domain MUST be configured with the Segment 389 Routing Global Block (SRGB). 391 o All global segments must be allocated from the SRGB. Any SR 392 capable node MUST be able to process any global segment advertised 393 by any other node within the SR domain. 395 o Any segment outside the SRGB has a local significance and is 396 called a "local segment". An SR-capable node MUST be able to 397 process the local segments it originates. An SR-capable node MUST 398 NOT support the instruction associated with a local segment 399 originated by a remote node. 401 4.2. Traffic Engineering with SR 403 An SR Traffic Engineering policy is composed of two elements: a flow 404 classification and a segment-list to prepend on the packets of the 405 flow. 407 In SR, this per-flow state only exists at the ingress edge node where 408 the policy is defined and the SR header is pushed. 410 It is outside the scope of the document to define the process that 411 leads to the instantiation at a node N of an SR Traffic Engineering 412 policy. 414 [I-D.filsfils-spring-segment-routing-use-cases] illustrates various 415 alternatives: 417 N is deriving this policy automatically (e.g. FRR). 419 N is provisioned explicitly by the operator. 421 N is provisioned by a controller or server (e.g.: SDN Controller). 423 N is provisioned by the operator with a high-level policy which is 424 mapped into a path thanks to a local CSPF-based computation (e.g. 425 affinity/SRLG exclusion). 427 N could also be provisioned by other means. 429 [I-D.filsfils-spring-segment-routing-use-cases] explains why the 430 majority of use-cases require very short segment-lists, hence 431 minimizing the performance impact, if any, of inserting and 432 transporting the segment list. 434 A SDN controller, which desires to instantiate at node N an SR 435 Traffic Engineering policy, collects the SR capability of node N such 436 as to ensure that the policy meets its capability. 438 4.3. Segment Routing Database 440 The Segment routing Database (SRDB) is a set of entries where each 441 entry is identified by a SID. The instruction associated with each 442 entry at least defines the identity of the next-hop to which the 443 packet should be forwarded and what operation should be performed on 444 the SR header (PUSH, CONTINUE, NEXT). 446 +---------+-----------+---------------------------------+ 447 | Segment | Next-Hop | SR Header operation | 448 +---------+-----------+---------------------------------+ 449 | Sk | M | CONTINUE | 450 | Sj | N | NEXT | 451 | Sl | NAT Srvc | NEXT | 452 | Sm | FW srvc | NEXT | 453 | Sn | Q | NEXT | 454 | etc. | etc. | etc. | 455 +---------+-----------+---------------------------------+ 457 Figure 4: SR Database 459 Each SR-capable node maintains its local SRDB. SRDB entries can 460 either derive from local policy or from protocol segment 461 advertisement. 463 5. IPv6 Instantiation of Segment Routing 465 5.1. Segment Identifiers (SIDs) and SRGB 467 Segment Routing, as described in 468 [I-D.filsfils-spring-segment-routing], defines Node-SID and 469 Adjacency-SID. When SR is used over IPv6 data-plane the following 470 applies. 472 The SRGB is the global IPv6 address space which represents the set of 473 IPv6 routable addresses in the SR domain. 475 Node SIDs are IPv6 addresses part of the SRGB (i.e.: routable 476 addresses). Adjacency-SIDs are IPv6 addresses which may not be part 477 of the global IPv6 address space. 479 5.1.1. Node-SID 481 The Node-SID identifies a node. With SR-IPv6 the Node-SID is an IPv6 482 prefix that the operator configured on the node and that is used as 483 the node identifier. Typically, in case of a router, this is the 484 IPv6 address of the node loopback interface. Therefore, SR-IPv6 does 485 not require any additional SID advertisement for the Node Segment. 486 The Node-SID is in fact the IPv6 address of the node. 488 5.1.2. Adjacency-SID 490 In the SR architecture defined in 491 [I-D.filsfils-spring-segment-routing] the Adjacency-SID (or Adj-SID) 492 identifies a given interface and may be local or global (depending on 493 how it is advertised). A node may advertise one (or more) Adj-SIDs 494 allocated to a given interface so to force the forwarding of the 495 packet (when received with that particular Adj-SID) into the 496 interface regardless the routing entry for the packet destination. 497 The semantic of the Adj-SID is: 499 Send out the packet to the interface this prefix is allocated to. 501 When SR is applied to IPv6, any SID is in a global IPv6 address and 502 therefore, an Adj-SID has a global significance (i.e.: the IPv6 503 address representing the SID is a global address). In other words, a 504 node that advertises the Adj-SID in the form of a global IPv6 address 505 representing the link/adjacency the packet has to be forwarded to, 506 will apply to the Adj-SID a global significance. 508 Advertisement of Adj-SID may be done using multiple mechanisms among 509 which the ones described in ISIS and OSPF protocol extensions: 510 [I-D.ietf-isis-segment-routing-extensions] and 511 [I-D.psenak-ospf-segment-routing-ospfv3-extension]. The distinction 512 between local and global significance of the Adj-SID is given in the 513 encoding of the Adj-SID advertisement. 515 5.2. Segment Routing Extension Header (SRH) 517 A new type of the Routing Header (originally defined in [RFC2460]) is 518 defined: the Segment Routing Header (SRH) which has a new Routing 519 Type, (suggested value 4) to be assigned by IANA. 521 As an example, if an explicit path is to be constructed across a core 522 network running ISIS or OSPF, the segment list will contain SIDs 523 representing the nodes across the path (loose or strict) which, 524 usually, are the IPv6 loopback interface address of each node. If 525 the path is across service or application entities, the segment list 526 contains the IPv6 addresses of these services or application 527 instances. 529 The Segment Routing Header (SRH) is defined as follows: 531 0 1 2 3 532 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 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Next Header | Hdr Ext Len | Routing Type | Next Segment | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Last Segment | Flags | HMAC Key ID | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | | 539 | Segment List[0] (128 bits ipv6 address) | 540 | | 541 | | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | | 544 | | 545 ... 546 | | 547 | | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | | 550 | Segment List[n] (128 bits ipv6 address) | 551 | | 552 | | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | | 555 | Policy List[0] (128 bits ipv6 address) | 556 | (optional) | 557 | | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | | 560 | Policy List[1] (128 bits ipv6 address) | 561 | (optional) | 562 | | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | | 565 | Policy List[2] (128 bits ipv6 address) | 566 | (optional) | 567 | | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | | 570 | | 571 | | 572 | HMAC (256 bits) | 573 | (optional) | 574 | | 575 | | 576 | | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 where: 581 o Next Header: 8-bit selector. Identifies the type of header 582 immediately following the SRH. 584 o Hdr Ext Len: 8-bit unsigned integer, is the length of the SRH 585 header in 8-octet units, not including the first 8 octets. 587 o Routing Type: TBD, to be assigned by IANA (suggested value: 4). 589 o Next Segment (originally defined as "Segments Left" in [RFC2460]): 590 index, in the Segment List, of the next active segment (according 591 to terminology defined in [I-D.filsfils-spring-segment-routing]) 592 in the SRH. Note that this differs from the semantic defined in 593 the Routing Header specification ([RFC2460] defines it as 594 "Segments Left"). Therefore, in the Segment Routing context, the 595 "Segments Left" field is renamed as "Next Segment". 597 o Last Segment: index, in the Segment List, of the next active 598 segment of the last segment of the path in the SRH. 600 o Flags: 16 bits of flags. Following flags are defined: 602 1 603 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 |C|P|R|R| Policy Flags | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 C-flag: Clean-up flag. Set when the SRH has to be removed from 609 the packet when packet reaches the last segment. 611 P-flag: Protected flag. Set when the packet has been rerouted 612 through FRR mechanism by a SR endpoint node. See Section 6.3 613 for more details. 615 R-flags. Reserved and for future use. 617 Policy List flags. Define the type of the IPv6 addresses 618 encoded into the Policy List (see below). The following have 619 been defined: 621 Bits 4-6: determine the type of the first element after the 622 segment list. 624 Bits 7-9: determine the type of the second element. 626 Bits 10-12: determine the type of the third element. 628 Bits 13-15: determine the type of the fourth element. 630 The following values are used for the type: 632 0x0: Not present. If value is set to 0x0, it means the 633 element represented by these bits is not present. 635 0x1: Ingress SR PE address. 637 0x2: Egress SR PE address. 639 0x3: Original Source Address. 641 o HMAC Key ID and HMAC field, and their use are defined in 642 [I-D.vyncke-6man-segment-routing-security]. 644 o Segment List[n]: 128 bit IPv6 addresses representing the nth 645 segment of the path. 647 o Policy List. Optional addresses representing specific nodes in 648 the SR path such as: 650 Ingress SR PE: IPv6 address representing the SR node which has 651 imposed the SRH (SR domain ingress). 653 Egress SR PE: IPv6 address representing the egress SR domain 654 node. 656 Original Source Address: IPv6 address originally present in the 657 SA field of the packet. 659 The segments in the Policy List are encoded after the segment list 660 and they are optional. If none are in the SRH, all bits of the 661 Policy List Flags MUST be set to 0x0. 663 5.2.1. SRH and RFC2460 behavior 665 The SRH being a new type of the Routing Header, it also has the same 666 properties: 668 SHOULD only appear once in the packet. 670 Only the router whose address is in the DA field of the packet 671 header MUST inspect the SRH. 673 Therefore, Segment Routing in IPv6 networks implies that the segment 674 identifier (i.e.: the IPv6 address of the segment) is moved into the 675 DA of the packet. 677 The DA of the packet changes at each segment termination/completion 678 and therefore the original DA of the packet MUST be encoded as the 679 last segment of the path. 681 As illustrated in Section 3.2, nodes that are within the path of a 682 segment will forward packets based on the DA of the packet without 683 inspecting the SRH. This ensures full interoperability between SR- 684 capable and non-SR-capable nodes. 686 5.2.2. SRH Optimization 688 In order to optimize the way the SRH and, more precisely, the Segment 689 List is processed by SR nodes, it is desirable that most of the 690 necessary information of the SL is placed at the top of the list so 691 to avoid reading the whole content of the SRH prior to make 692 forwarding decisions. 694 With this in mind, when the SRH is created and the segment list is 695 inserted, the order of the segments in the segment list is as 696 follows: 698 o The Next Segment field points to the next segment to be examined 699 (offset within the SRH). 701 o The first segment being encoded in the DA by the ingress node, it 702 doesn't need to sit in the first position of the list. 704 o Hence, the first element of the segment list is the second segment 705 of the path so that, when the packet reaches the end of the first 706 segment, the node inspecting the SRH will find the second segment 707 at the beginning of the segment list. 709 o The other segments of the path are encoded sequentially after the 710 second segment. 712 o The last segment of the path is the original DA address. 714 o The last segment in the Segment List is used to encode the first 715 segment. This segment will never be inspected anyway (at least 716 not for forwarding purposes). 718 6. SRH Procedures 720 In this section we describe the different procedures on the SRH. 722 6.1. Segment Routing Operations 724 When Segment Routing is instantiated over the IPv6 data plane the 725 following applies: 727 o The segment list is encoded in the SRH. 729 o The active segment is in the destination address of the packet. 731 o The Segment Routing CONTINUE operation (as described in 732 [I-D.filsfils-spring-segment-routing]) is implemented as a 733 regular/plain IPv6 operation consisting of DA based forwarding. 735 o The NEXT operation is implemented through the update of the DA 736 with the value represented by the Next Segment field in the SRH. 738 o The PUSH operation is implemented through the insertion of the SRH 739 or the insertion of additional segments in the SRH segment list. 741 6.2. Segment Routing Node Functions 743 SR packets are forwarded to segments endpoints (i.e.: nodes whose 744 address is in the DA field of the packet). The segment endpoint, 745 when receiving a SR packet destined to itself, does: 747 o Inspect the SRH. 749 o Determine the next segment. 751 o Update the SRH (or, if requested, remove the SRH from the packet). 753 o Update the DA. 755 o Send the packet to the next segment. 757 The procedures applied to the SRH are related to the node function. 758 Following nodes functions are defined: 760 Ingress SR Node. 762 Transit Non-SR Node. 764 Transit SR Intra Segment Node. 766 SR Endpoint Node. 768 6.2.1. Ingress SR Node 770 Ingress Node can be a router at the edge of the SR domain or a SR- 771 capable host. The ingress SR node may obtain the segment list by 772 either: 774 Local path computation. 776 Local configuration. 778 Interaction with an SDN controller delivering the path as a 779 complete SRH. 781 Any other mechanism (mechanisms through which the path is acquired 782 are outside the scope of this document). 784 When creating the SRH (either at ingress node or in the SDN 785 controller) the following is done: 787 Next Header and Hdr Ext Len fields are set according to [RFC2460]. 789 Routing Type field is set as TBD (SRH). 791 The DA of the packet is set with the address of the FIRST segment 792 of the path. 794 Next Segment field contains the offset of the SECOND segment of 795 the path which is encoded in the FIRST position of the segment 796 list. The segment list is encoded as follows: 798 The first element of the list contains the second segment (as 799 stated above). 801 All subsequent segments are encoded following the second 802 segment. 804 The original DA of the packet is encoded as the last segment of 805 the path (which is NOT the last segment of the segment list). 807 The last segment of the segment list is the FIRST segment of 808 the path. 810 Last Segment field contains the offset of the last segment of the 811 path (i.e.: the original DA of the packet). 813 The packet is sent out to the first segment. 815 6.2.1.1. Security at Ingress 817 The procedures related to the Segment Routing security are detailed 818 in [I-D.vyncke-6man-segment-routing-security]. 820 In the case where the SR domain boundaries are not under control of 821 the network operator (e.g.: when the SR domain edge is in a home 822 network), it is important to authenticate and validate the content of 823 any SRH being received by the network operator. In such case, the 824 security procedure described in 825 [I-D.vyncke-6man-segment-routing-security] is to be used. 827 The ingress node (e.g.: the host in the home network) requests the 828 SRH from a control system (e.g.: an SDN controller) which delivers 829 the SRH with its HMAC signature on it. 831 Then, the home network host can send out SR packets (with an SRH on 832 it) that will be validated at the ingress of the network operator 833 infrastructure. 835 The ingress node of the network operator infrastructure, is 836 configured in order to validate the incoming SRH HMACs in order to 837 allow only packets having correct SRH according to their SA/DA 838 addresses. 840 6.2.2. Transit Non-SR Capable Node 842 SR is interoperable with plain IPv6 forwarding. Any non SR-capable 843 node will forward SR packets solely based on the DA. There's no SRH 844 inspection. This ensures full interoperability between SR and non-SR 845 nodes. 847 6.2.3. SR Intra Segment Transit Node 849 Only the node whose address is in DA inspects and processes the SRH 850 (according to [RFC2460]). An intra segment transit node is not in 851 the DA and its forwarding is based on DA and its SR-IPv6 FIB. 853 6.2.4. SR Segment Endpoint Node 855 The SR segment endpoint node is the node whose address is in the DA. 856 The segment endpoint node inspects the SRH and does: 858 1. IF DA = myself (segment endpoint) 859 2. IF Next Segment <> Last Segment THEN 860 update DA with Next Segment 861 increment Next Segment 862 3. ELSE IF Last Segment <> DA THEN 863 update DA with Next Segment 864 IF Clean-up bit is set THEN remove the SRH 865 4. ELSE give the packet to next PID (application) 866 End of processing. 867 5. Forward the packet out 869 6.3. FRR Flag Settings 871 A node supporting SR and doing Fast Reroute (as described in 872 [I-D.filsfils-spring-segment-routing-use-cases], when rerouting 873 packets through FRR mechanisms, SHOULD inspect the rerouted packet 874 header and look for the SRH. If the SRH is present, the rerouting 875 node SHOULD set the Protected bit on all rerouted packets. 877 7. SR and Tunneling 879 Encapsulation can be realized in two different ways with SR-IPv6: 881 Outer encapsulation. 883 SRH with SA/DA original addresses. 885 Outer encapsulation tunneling is the traditional method where an 886 additional IPv6 header is prepended to the packet. The original IPv6 887 header being encapsulated, everything is preserved and the packet is 888 switched/routed according to the outer header (that could contain a 889 SRH). 891 SRH allows encoding both original SA and DA and therefore, hence an 892 operator may decide to change the SA/DA at ingress and restore them 893 at egress. This can be achieved without outer encapsulation, by 894 changing SA/DA and encoding the original values in the Segment List 895 (the last segment of the path being the original DA) and in the 896 Policy List (original SA). 898 8. Example Use Case 900 A more detailed description of use cases are available in 901 [I-D.ietf-spring-ipv6-use-cases]. In this section, a simple SR-IPv6 902 example is illustrated. 904 In the topology described in Figure 6 it is assumed an end-to-end SR 905 deployment. Therefore SR is supported by all nodes from A to J. 907 Home Network | Backbone | Datacenter 908 | | 909 | +---+ +---+ +---+ | +---+ | 910 +---|---| C |---| D |---| E |---|---| I |---| 911 | | +---+ +---+ +---+ | +---+ | 912 | | | | | | | | +---+ 913 +---+ +---+ | | | | | | |--| X | 914 | A |---| B | | +---+ +---+ +---+ | +---+ | +---+ 915 +---+ +---+ | | F |---| G |---| H |---|---| J |---| 916 | +---+ +---+ +---+ | +---+ | 917 | | 918 | +-----------+ 919 | SDN | 920 | Orch/Ctlr | 921 +-----------+ 923 Figure 6: Sample SR topology 925 The following workflow applies to packets sent by host A and destined 926 to server X. 928 . Host A sends a request for a path to server X to the SDN 929 controller or orchestration system. 931 . The SDN controller/orchestrator builds a SRH with: 932 . Segment List: C, F, J, X 933 . HMAC 934 that satisfies the requirements expressed in the request 935 by host A and based on policies applicable to host A. 937 . Host A receives the SRH and insert it into the packet. 938 The packet has now: 939 . SA: A 940 . DA: C 941 . SRH with 942 . SL: F,J,X,C 943 . PL: C (ingress), J (egress) 944 Note that X is the last segment and C is the 945 first segment (encoded at the end of the SL). 947 . When packet arrives in C (first segment), C does: 948 . Validate the HMAC of the SRH. 950 . Update the DA with the next segment (found in SRH): 951 DA is set to F. 952 . Forward the packet to F. 954 . Packet arrives in F which inspects the SRH and find the 955 next segment: 956 . DA is set to J. 958 . Packet travels across G and H nodes which do plain 959 IPv6 forwarding based on DA. No inspection of SRH needs 960 to be done in these nodes. However, any SR capable node 961 is allowed to set the Protected bit in case of FRR 962 protection. 964 . Packet arrives in J where two options are available 965 depending on the settings of the cleanup bit set in the 966 SRH: 967 . If the cleanup bit is set, then node J will strip out 968 the SRH from the packet, set the DA as X and send 969 the packet out. 970 . If the clean-up bit is not set, the DA is set to X 971 and the packet is sent out with the SRH. 973 The packet arrives in the server that may or may not support SR. The 974 return traffic, from server to host, may be sent using the same 975 procedures. 977 9. IANA Considerations 979 TBD 981 10. Manageability Considerations 983 TBD 985 11. Security Considerations 987 Security mechanisms applied to Segment Routing over IPv6 networks are 988 detailed in [I-D.vyncke-6man-segment-routing-security]. 990 12. Contributors 992 The authors would like to thank Dave Barach, John Leddy, John 993 Brzozowski, Pierre Francois, Nagendra Kumar, Mark Townsley, Christian 994 Martin, Roberta Maglione, James Connolly and David Lebrun for their 995 contribution to this document. 997 13. Acknowledgements 999 TBD 1001 14. References 1003 14.1. Normative References 1005 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1006 Requirement Levels", BCP 14, RFC 2119, March 1997. 1008 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1009 (IPv6) Specification", RFC 2460, December 1998. 1011 14.2. Informative References 1013 [I-D.filsfils-spring-segment-routing] 1014 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1015 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1016 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1017 "Segment Routing Architecture", draft-filsfils-spring- 1018 segment-routing-04 (work in progress), July 2014. 1020 [I-D.filsfils-spring-segment-routing-mpls] 1021 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1022 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1023 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1024 "Segment Routing with MPLS data plane", draft-filsfils- 1025 spring-segment-routing-mpls-03 (work in progress), August 1026 2014. 1028 [I-D.filsfils-spring-segment-routing-use-cases] 1029 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1030 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1031 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1032 Crabbe, "Segment Routing Use Cases", draft-filsfils- 1033 spring-segment-routing-use-cases-01 (work in progress), 1034 October 2014. 1036 [I-D.ietf-isis-segment-routing-extensions] 1037 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 1038 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 1039 Extensions for Segment Routing", draft-ietf-isis-segment- 1040 routing-extensions-02 (work in progress), June 2014. 1042 [I-D.ietf-spring-ipv6-use-cases] 1043 Brzozowski, J., Leddy, J., Leung, I., Previdi, S., 1044 Townsley, W., Martin, C., Filsfils, C., and R. Maglione, 1045 "IPv6 SPRING Use Cases", draft-ietf-spring-ipv6-use- 1046 cases-01 (work in progress), July 2014. 1048 [I-D.psenak-ospf-segment-routing-ospfv3-extension] 1049 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1050 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 1051 Extensions for Segment Routing", draft-psenak-ospf- 1052 segment-routing-ospfv3-extension-02 (work in progress), 1053 July 2014. 1055 [I-D.vyncke-6man-segment-routing-security] 1056 Vyncke, E. and S. Previdi, "IPv6 Segment Routing Header 1057 (SRH) Security Considerations", July 2014. 1059 [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D. 1060 Zappala, "Source Demand Routing: Packet Format and 1061 Forwarding Specification (Version 1)", RFC 1940, May 1996. 1063 Authors' Addresses 1064 Stefano Previdi (editor) 1065 Cisco Systems, Inc. 1066 Via Del Serafico, 200 1067 Rome 00142 1068 Italy 1070 Email: sprevidi@cisco.com 1072 Clarence Filsfils 1073 Cisco Systems, Inc. 1074 Brussels 1075 BE 1077 Email: cfilsfil@cisco.com 1079 Brian Field 1080 Comcast 1081 4100 East Dry Creek Road 1082 Centennial, CO 80122 1083 US 1085 Email: Brian_Field@cable.comcast.com 1087 Ida Leung 1088 Rogers Communications 1089 8200 Dixie Road 1090 Brampton, ON L6T 0C1 1091 CA 1093 Email: Ida.Leung@rci.rogers.com