1 Network Working Group S. Previdi, Ed.
2 Internet-Draft C. Filsfils
3 Intended status: Standards Track Cisco Systems, Inc.
4 Expires: June 12, 2015 B. Field
11 IPv6 Segment Routing Header (SRH)
12 draft-previdi-6man-segment-routing-header-05
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.
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].
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."
52 Previdi, et al. Expires June 12, 2015 [Page 1]
54 Internet-Draft IPv6 Segment Routing Header (SRH) December 2014
57 This Internet-Draft will expire on June 12, 2015.
61 Copyright (c) 2014 IETF Trust and the persons identified as the
62 document authors. All rights reserved.
64 This document is subject to BCP 78 and the IETF Trust's Legal
65 Provisions Relating to IETF Documents
66 (http://trustee.ietf.org/license-info) in effect on the date of
67 publication of this document. Please review these documents
68 carefully, as they describe your rights and restrictions with respect
69 to this document. Code Components extracted from this document must
70 include Simplified BSD License text as described in Section 4.e of
71 the Trust Legal Provisions and are provided without warranty as
72 described in the Simplified BSD License.
76 1. Structure of this document . . . . . . . . . . . . . . . . . 3
77 2. Segment Routing Documents . . . . . . . . . . . . . . . . . . 3
78 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
79 3.1. Data Planes supporting Segment Routing . . . . . . . . . 4
80 3.2. Illustration . . . . . . . . . . . . . . . . . . . . . . 4
81 4. Abstract Routing Model . . . . . . . . . . . . . . . . . . . 7
82 4.1. Segment Routing Global Block (SRGB) . . . . . . . . . . . 8
83 4.2. Traffic Engineering with SR . . . . . . . . . . . . . . . 9
84 4.3. Segment Routing Database . . . . . . . . . . . . . . . . 10
85 5. IPv6 Instantiation of Segment Routing . . . . . . . . . . . . 10
86 5.1. Segment Identifiers (SIDs) and SRGB . . . . . . . . . . . 10
87 5.1.1. Node-SID . . . . . . . . . . . . . . . . . . . . . . 11
88 5.1.2. Adjacency-SID . . . . . . . . . . . . . . . . . . . . 11
89 5.2. Segment Routing Extension Header (SRH) . . . . . . . . . 11
90 5.2.1. SRH and RFC2460 behavior . . . . . . . . . . . . . . 15
91 6. SRH Procedures . . . . . . . . . . . . . . . . . . . . . . . 15
92 6.1. Segment Routing Operations . . . . . . . . . . . . . . . 15
93 6.2. Segment Routing Node Functions . . . . . . . . . . . . . 16
94 6.2.1. Ingress SR Node . . . . . . . . . . . . . . . . . . . 16
95 6.2.2. Transit Non-SR Capable Node . . . . . . . . . . . . . 18
96 6.2.3. SR Intra Segment Transit Node . . . . . . . . . . . . 18
97 6.2.4. SR Segment Endpoint Node . . . . . . . . . . . . . . 18
98 6.3. FRR Flag Settings . . . . . . . . . . . . . . . . . . . . 18
99 7. SR and Tunneling . . . . . . . . . . . . . . . . . . . . . . 18
100 8. Example Use Case . . . . . . . . . . . . . . . . . . . . . . 19
101 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
102 10. Manageability Considerations . . . . . . . . . . . . . . . . 21
103 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21
104 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21
108 Previdi, et al. Expires June 12, 2015 [Page 2]
110 Internet-Draft IPv6 Segment Routing Header (SRH) December 2014
113 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
114 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
115 14.1. Normative References . . . . . . . . . . . . . . . . . . 21
116 14.2. Informative References . . . . . . . . . . . . . . . . . 21
117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
119 1. Structure of this document
121 Section 3 gives an introduction on SR for IPv6 networks.
123 Section 4 describes the Segment Routing abstract model.
125 Section 5 defines the Segment Routing Header (SRH) allowing
126 instantiation of SR over IPv6 dataplane.
128 Section 6 details the procedures of the Segment Routing Header.
130 2. Segment Routing Documents
132 Segment Routing terminology is defined in
133 [I-D.filsfils-spring-segment-routing].
135 Segment Routing use cases are described in
136 [I-D.filsfils-spring-segment-routing-use-cases].
138 Segment Routing IPv6 use cases are described in
139 [I-D.ietf-spring-ipv6-use-cases].
141 Segment Routing protocol extensions are defined in
142 [I-D.ietf-isis-segment-routing-extensions], and
143 [I-D.psenak-ospf-segment-routing-ospfv3-extension].
145 The security mechanisms of the Segment Routing Header (SRH) are
146 described in [I-D.vyncke-6man-segment-routing-security].
150 Segment Routing (SR), defined in
151 [I-D.filsfils-spring-segment-routing], allows a node to steer a
152 packet through a controlled set of instructions, called segments, by
153 prepending a SR header to the packet. A segment can represent any
154 instruction, topological or service-based. SR allows to enforce a
155 flow through any path (topological or service/application based)
156 while maintaining per-flow state only at the ingress node to the SR
157 domain. Segments can be derived from different components: IGP, BGP,
158 Services, Contexts, Locators, etc. The list of segment forming the
159 path is called the Segment List and is encoded in the packet header.
164 Previdi, et al. Expires June 12, 2015 [Page 3]
166 Internet-Draft IPv6 Segment Routing Header (SRH) December 2014
169 SR allows the use of strict and loose source based routing paradigms
170 without requiring any additional signaling protocols in the
171 infrastructure hence delivering an excellent scalability property.
173 The source based routing model described in
174 [I-D.filsfils-spring-segment-routing] is inherited from the ones
175 proposed by [RFC1940] and [RFC2460]. The source based routing model
176 offers the support for explicit routing capability.
178 3.1. Data Planes supporting Segment Routing
180 Segment Routing (SR), can be instantiated over MPLS
181 ([I-D.filsfils-spring-segment-routing-mpls]) and IPv6. This document
182 defines its instantiation over the IPv6 data-plane based on the use-
183 cases defined in [I-D.ietf-spring-ipv6-use-cases].
185 Segment Routing for IPv6 (SR-IPv6) is required in networks where MPLS
186 data-plane is not used or, when combined with SR-MPLS, in networks
187 where MPLS is used in the core and IPv6 is used at the edge (home
188 networks, datacenters).
190 This document defines a new type of Routing Header (originally
191 defined in [RFC2460]) called the Segment Routing Header (SRH) in
192 order to convey the Segment List in the packet header as defined in
193 [I-D.filsfils-spring-segment-routing]. Mechanisms through which
194 segment are known and advertised are outside the scope of this
199 In the context of Figure 1 where all the links have the same IGP
200 cost, let us assume that a packet P enters the SR domain at an
201 ingress edge router I and that the operator requests the following
202 requirements for packet P:
204 The local service S offered by node B must be applied to packet P.
206 The links AB and CE cannot be used to transport the packet P.
208 Any node N along the journey of the packet should be able to
209 determine where the packet P entered the SR domain and where it
210 will exit. The intermediate node should be able to determine the
211 paths from the ingress edge router to itself, and from itself to
212 the egress edge router.
214 Per-flow State for packet P should only be created at the ingress
220 Previdi, et al. Expires June 12, 2015 [Page 4]
222 Internet-Draft IPv6 Segment Routing Header (SRH) December 2014
225 The operator can forbid, for security reasons, anyone outside the
226 operator domain to exploit its intra-domain SR capabilities.
234 Figure 1: An illustration of SR properties
236 All these properties may be realized by instructing the ingress SR
237 edge router I to push the following abstract SR header on the packet
240 +---------------------------------------------------------------+
242 | Abstract SR Header | |
244 | {SD, SB, SS, SF, SE}, Ptr, SI, SE | Transported |
247 | +---------------------+ | |
249 +---------------------------------------------------------------+
251 Figure 2: Packet P at node I
253 The abstract SR header contains a source route encoded as a list of
254 segments {SD, SB, SS, SF, SE}, a pointer (Ptr) and the identification
255 of the ingress and egress SR edge routers (segments SI and SE).
257 A segment identifies a topological instruction or a service
258 instruction. A segment can either be global or local. The
259 instruction associated with a global segment is recognized and
260 executed by any SR-capable node in the domain. The instruction
261 associated with a local segment is only supported by the specific
262 node that originates it.
264 Let us assume some IGP (i.e.: ISIS and OSPF) extensions to define a
265 "Node Segment" as a global instruction within the IGP domain to
266 forward a packet along the shortest path to the specified node. Let
267 us further assume that within the SR domain illustrated in Figure 1,
268 segments SI, SD, SB, SE and SF respectively identify IGP node
269 segments to I, D, B, E and F.
271 Let us assume that node B identifies its local service S with local
276 Previdi, et al. Expires June 12, 2015 [Page 5]
278 Internet-Draft IPv6 Segment Routing Header (SRH) December 2014
281 With all of this in mind, let us describe the journey of the packet
284 The packet P reaches the ingress SR edge router. I pushes the SR
285 header illustrated in Figure 2 and sets the pointer to the first
286 segment of the list (SD).
288 SD is an instruction recognized by all the nodes in the SR domain
289 which causes the packet to be forwarded along the shortest path to D.
291 Once at D, the pointer is incremented and the next segment is
294 SB is an instruction recognized by all the nodes in the SR domain
295 which causes the packet to be forwarded along the shortest path to B.
297 Once at B, the pointer is incremented and the next segment is
300 SS is an instruction only recognized by node B which causes the
301 packet to receive service S.
303 Once the service applied, the next segment is executed (SF) which
304 causes the packet to be forwarded along the shortest path to F.
306 Once at F, the pointer is incremented and the next segment is
309 SE is an instruction recognized by all the nodes in the SR domain
310 which causes the packet to be forwarded along the shortest path to E.
312 E then removes the SR header and the packet continues its journey
313 outside the SR domain.
315 All of the requirements are met.
317 First, the packet P has not used links AB and CE: the shortest-path
318 from I to D is I-A-D, the shortest-path from D to B is D-B, the
319 shortest-path from B to F is B-C-F and the shortest-path from F to E
320 is F-E, hence the packet path through the SR domain is I-A-D-B-C-F-E
321 and the links AB and CE have been avoided.
323 Second, the service S supported by B has been applied on packet P.
325 Third, any node along the packet path is able to identify the service
326 and topological journey of the packet within the SR domain. For
327 example, node C receives the packet illustrated in Figure 3 and hence
328 is able to infer where the packet entered the SR domain (SI), how it
332 Previdi, et al. Expires June 12, 2015 [Page 6]
334 Internet-Draft IPv6 Segment Routing Header (SRH) December 2014
337 got up to itself {SD, SB, SS, SE}, where it will exit the SR domain
338 (SE) and how it will do so {SF, SE}.
340 +---------------------------------------------------------------+
344 | {SD, SB, SS, SF, SE}, Ptr, SI, SE | Transported |
349 +---------------------------------------------------------------+
351 Figure 3: Packet P at node C
353 Fourth, only node I maintains per-flow state for packet P. The
354 entire program of topological and service instructions to be executed
355 by the SR domain on packet P is encoded by the ingress edge router I
356 in the SR header in the form of a list of segments where each segment
357 identifies a specific instruction. No further per-flow state is
358 required along the packet path. The per-flow state is in the SR
359 header and travels with the packet. Intermediate nodes only hold
360 states related to the IGP global node segments and the local IGP
361 adjacency segments. These segments are not per-flow specific and
362 hence scale very well. Typically, an intermediate node would
363 maintain in the order of 100's to 1000's global node segments and in
364 the order of 10's to 100 of local adjacency segments. Typically the
365 SR IGP forwarding table is expected to be much less than 10000
368 Fifth, the SR header is inserted at the entrance to the domain and
369 removed at the exit of the operator domain. For security reasons,
370 the operator can forbid anyone outside its domain to use its intra-
371 domain SR capability.
373 4. Abstract Routing Model
375 At the entrance of the SR domain, the ingress SR edge router pushes
376 the SR header on top of the packet. At the exit of the SR domain,
377 the egress SR edge router removes the SR header.
379 The abstract SR header contains an ordered list of segments, a
380 pointer identifying the next segment to process and the
381 identifications of the ingress and egress SR edge routers on the path
382 of this packet. The pointer identifies the segment that MUST be used
383 by the receiving router to process the packet. This segment is
384 called the active segment.
388 Previdi, et al. Expires June 12, 2015 [Page 7]
390 Internet-Draft IPv6 Segment Routing Header (SRH) December 2014
393 A property of SR is that the entire source route of the packet,
394 including the identity of the ingress and egress edge routers is
395 always available with the packet. This allows for interesting
396 accounting and service applications.
398 We define three SR-header operations:
400 "PUSH": an SR header is pushed on an IP packet, or additional
401 segments are added at the head of the segment list. The pointer
402 is moved to the first entry of the added segments.
404 "NEXT": the active segment is completed, the pointer is moved to
405 the next segment in the list.
407 "CONTINUE": the active segment is not completed, the pointer is
410 In the future, other SR-header management operations may be defined.
412 As the packet travels through the SR domain, the pointer is
413 incremented through the ordered list of segments and the source route
414 encoded by the SR ingress edge node is executed.
416 A node processes an incoming packet according to the instruction
417 associated with the active segment.
419 Any instruction might be associated with a segment: for example, an
420 intra-domain topological strict or loose forwarding instruction, a
421 service instruction, etc.
423 At minimum, a segment instruction must define two elements: the
424 identity of the next-hop to forward the packet to (this could be the
425 same node or a context within the node) and which SR-header
426 management operation to execute.
428 Each segment is known in the network through a Segment Identifier
429 (SID). The terms "segment" and "SID" are interchangeable.
431 4.1. Segment Routing Global Block (SRGB)
433 In the SR abstract model, a segment is identified by a Segment
434 Routing Identifier (SID). The SR abstract model doesn't mandate a
435 specific format for the SID (IPv6 address or other formats).
437 In Segment Routing IPv6 the SID is an IPv6 address. Therefore, the
438 SRGB is materialized by the global IPv6 address space which
439 represents the set of IPv6 routable addresses in the SR domain. The
440 following rules apply:
444 Previdi, et al. Expires June 12, 2015 [Page 8]
446 Internet-Draft IPv6 Segment Routing Header (SRH) December 2014
449 o Each node of the SR domain MUST be configured with the Segment
450 Routing Global Block (SRGB).
452 o All global segments must be allocated from the SRGB. Any SR
453 capable node MUST be able to process any global segment advertised
454 by any other node within the SR domain.
456 o Any segment outside the SRGB has a local significance and is
457 called a "local segment". An SR-capable node MUST be able to
458 process the local segments it originates. An SR-capable node MUST
459 NOT support the instruction associated with a local segment
460 originated by a remote node.
462 4.2. Traffic Engineering with SR
464 An SR Traffic Engineering policy is composed of two elements: a flow
465 classification and a segment-list to prepend on the packets of the
468 In SR, this per-flow state only exists at the ingress edge node where
469 the policy is defined and the SR header is pushed.
471 It is outside the scope of the document to define the process that
472 leads to the instantiation at a node N of an SR Traffic Engineering
475 [I-D.filsfils-spring-segment-routing-use-cases] illustrates various
478 N is deriving this policy automatically (e.g. FRR).
480 N is provisioned explicitly by the operator.
482 N is provisioned by a controller or server (e.g.: SDN Controller).
484 N is provisioned by the operator with a high-level policy which is
485 mapped into a path thanks to a local CSPF-based computation (e.g.
486 affinity/SRLG exclusion).
488 N could also be provisioned by other means.
490 [I-D.filsfils-spring-segment-routing-use-cases] explains why the
491 majority of use-cases require very short segment-lists, hence
492 minimizing the performance impact, if any, of inserting and
493 transporting the segment list.
500 Previdi, et al. Expires June 12, 2015 [Page 9]
502 Internet-Draft IPv6 Segment Routing Header (SRH) December 2014
505 A SDN controller, which desires to instantiate at node N an SR
506 Traffic Engineering policy, collects the SR capability of node N such
507 as to ensure that the policy meets its capability.
509 4.3. Segment Routing Database
511 The Segment routing Database (SRDB) is a set of entries where each
512 entry is identified by a SID. The instruction associated with each
513 entry at least defines the identity of the next-hop to which the
514 packet should be forwarded and what operation should be performed on
515 the SR header (PUSH, CONTINUE, NEXT).
517 +---------+-----------+---------------------------------+
518 | Segment | Next-Hop | SR Header operation |
519 +---------+-----------+---------------------------------+
520 | Sk | M | CONTINUE |
522 | Sl | NAT Srvc | NEXT |
523 | Sm | FW srvc | NEXT |
525 | etc. | etc. | etc. |
526 +---------+-----------+---------------------------------+
528 Figure 4: SR Database
530 Each SR-capable node maintains its local SRDB. SRDB entries can
531 either derive from local policy or from protocol segment
534 5. IPv6 Instantiation of Segment Routing
536 5.1. Segment Identifiers (SIDs) and SRGB
538 Segment Routing, as described in
539 [I-D.filsfils-spring-segment-routing], defines Node-SID and
540 Adjacency-SID. When SR is used over IPv6 data-plane the following
543 The SRGB is the global IPv6 address space which represents the set of
544 IPv6 routable addresses in the SR domain.
546 Node SIDs are IPv6 addresses part of the SRGB (i.e.: routable
547 addresses). Adjacency-SIDs are IPv6 addresses which may not be part
548 of the global IPv6 address space.
556 Previdi, et al. Expires June 12, 2015 [Page 10]
558 Internet-Draft IPv6 Segment Routing Header (SRH) December 2014
563 The Node-SID identifies a node. With SR-IPv6 the Node-SID is an IPv6
564 prefix that the operator configured on the node and that is used as
565 the node identifier. Typically, in case of a router, this is the
566 IPv6 address of the node loopback interface. Therefore, SR-IPv6 does
567 not require any additional SID advertisement for the Node Segment.
568 The Node-SID is in fact the IPv6 address of the node.
572 In the SR architecture defined in
573 [I-D.filsfils-spring-segment-routing] the Adjacency-SID (or Adj-SID)
574 identifies a given interface and may be local or global (depending on
575 how it is advertised). A node may advertise one (or more) Adj-SIDs
576 allocated to a given interface so to force the forwarding of the
577 packet (when received with that particular Adj-SID) into the
578 interface regardless the routing entry for the packet destination.
579 The semantic of the Adj-SID is:
581 Send out the packet to the interface this prefix is allocated to.
583 When SR is applied to IPv6, any SID is in a global IPv6 address and
584 therefore, an Adj-SID has a global significance (i.e.: the IPv6
585 address representing the SID is a global address). In other words, a
586 node that advertises the Adj-SID in the form of a global IPv6 address
587 representing the link/adjacency the packet has to be forwarded to,
588 will apply to the Adj-SID a global significance.
590 Advertisement of Adj-SID may be done using multiple mechanisms among
591 which the ones described in ISIS and OSPF protocol extensions:
592 [I-D.ietf-isis-segment-routing-extensions] and
593 [I-D.psenak-ospf-segment-routing-ospfv3-extension]. The distinction
594 between local and global significance of the Adj-SID is given in the
595 encoding of the Adj-SID advertisement.
597 5.2. Segment Routing Extension Header (SRH)
599 A new type of the Routing Header (originally defined in [RFC2460]) is
600 defined: the Segment Routing Header (SRH) which has a new Routing
601 Type, (suggested value 4) to be assigned by IANA.
603 As an example, if an explicit path is to be constructed across a core
604 network running ISIS or OSPF, the segment list will contain SIDs
605 representing the nodes across the path (loose or strict) which,
606 usually, are the IPv6 loopback interface address of each node. If
607 the path is across service or application entities, the segment list
612 Previdi, et al. Expires June 12, 2015 [Page 11]
614 Internet-Draft IPv6 Segment Routing Header (SRH) December 2014
617 contains the IPv6 addresses of these services or application
620 The Segment Routing Header (SRH) is defined as follows:
624 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
625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
626 | Next Header | Hdr Ext Len | Routing Type | Segments Left |
627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
628 | First Segment | Flags | HMAC Key ID |
629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
631 | Segment List[0] (128 bits ipv6 address) |
634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
642 | Segment List[n] (128 bits ipv6 address) |
645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
647 | Policy List[0] (optional) |
650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
652 | Policy List[1] (optional) |
655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
657 | Policy List[2] (optional) |
660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
668 Previdi, et al. Expires June 12, 2015 [Page 12]
670 Internet-Draft IPv6 Segment Routing Header (SRH) December 2014
677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
681 o Next Header: 8-bit selector. Identifies the type of header
682 immediately following the SRH.
684 o Hdr Ext Len: 8-bit unsigned integer, is the length of the SRH
685 header in 8-octet units, not including the first 8 octets.
687 o Routing Type: TBD, to be assigned by IANA (suggested value: 4).
689 o Segments Left. Defined in [RFC2460], it contains the index, in
690 the Segment List, of the next segment to inspect. Segments Left
691 is decremented at each segment and it is used as an index in the
694 o First Segment: offset in the SRH, not including the first 8 octets
695 and expressed in 16-octet units, pointing to the last element of
696 the segment list, which is in fact the first segment of the
697 segment routing path.
699 o Flags: 16 bits of flags. Following flags are defined:
702 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
704 |C|P|R|R| Policy Flags |
705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
707 C-flag: Clean-up flag. Set when the SRH has to be removed from
708 the packet when packet reaches the last segment.
710 P-flag: Protected flag. Set when the packet has been rerouted
711 through FRR mechanism by a SR endpoint node. See Section 6.3
714 R-flags. Reserved and for future use.
716 Policy Flags. Define the type of the IPv6 addresses encoded
717 into the Policy List (see below). The following have been
724 Previdi, et al. Expires June 12, 2015 [Page 13]
726 Internet-Draft IPv6 Segment Routing Header (SRH) December 2014
729 Bits 4-6: determine the type of the first element after the
732 Bits 7-9: determine the type of the second element.
734 Bits 10-12: determine the type of the third element.
736 Bits 13-15: determine the type of the fourth element.
738 The following values are used for the type:
740 0x0: Not present. If value is set to 0x0, it means the
741 element represented by these bits is not present.
747 0x3: Original Source Address.
749 o HMAC Key ID and HMAC field, and their use are defined in
750 [I-D.vyncke-6man-segment-routing-security].
752 o Segment List[n]: 128 bit IPv6 addresses representing the nth
753 segment in the Segment List. The Segment List is encoded starting
754 from the last segment of the path. I.e., the first element of the
755 segment list (Segment List [0]) contains the last segment of the
756 path while the last segment of the Segment List (Segment List[n])
757 contains the first segment of the path. The index contained in
758 "Segments Left" identifies the current active segment.
760 o Policy List. Optional addresses representing specific nodes in
763 SR Ingress: a 128 bit generic identifier representing the
764 ingress in the SR domain (i.e.: it needs not to be a valid IPv6
767 SR Egress: a 128 bit generic identifier representing the egress
768 in the SR domain (i.e.: it needs not to be a valid IPv6
771 Original Source Address: IPv6 address originally present in the
772 SA field of the packet.
774 The segments in the Policy List are encoded after the segment list
775 and they are optional. If none are in the SRH, all bits of the
776 Policy List Flags MUST be set to 0x0.
780 Previdi, et al. Expires June 12, 2015 [Page 14]
782 Internet-Draft IPv6 Segment Routing Header (SRH) December 2014
785 5.2.1. SRH and RFC2460 behavior
787 The SRH being a new type of the Routing Header, it also has the same
790 SHOULD only appear once in the packet.
792 Only the router whose address is in the DA field of the packet
793 header MUST inspect the SRH.
795 Therefore, Segment Routing in IPv6 networks implies that the segment
796 identifier (i.e.: the IPv6 address of the segment) is moved into the
799 The DA of the packet changes at each segment termination/completion
800 and therefore the original DA of the packet MUST be encoded as the
801 last segment of the path.
803 As illustrated in Section 3.2, nodes that are within the path of a
804 segment will forward packets based on the DA of the packet without
805 inspecting the SRH. This ensures full interoperability between SR-
806 capable and non-SR-capable nodes.
810 In this section we describe the different procedures on the SRH.
812 6.1. Segment Routing Operations
814 When Segment Routing is instantiated over the IPv6 data plane the
817 o The segment list is encoded in the SRH.
819 o The active segment is in the destination address of the packet.
821 o The Segment Routing CONTINUE operation (as described in
822 [I-D.filsfils-spring-segment-routing]) is implemented as a
823 regular/plain IPv6 operation consisting of DA based forwarding.
825 o The NEXT operation is implemented through the update of the DA
826 with the value represented by the Next Segment field in the SRH.
828 o The PUSH operation is implemented through the insertion of the SRH
829 or the insertion of additional segments in the SRH segment list.
836 Previdi, et al. Expires June 12, 2015 [Page 15]
838 Internet-Draft IPv6 Segment Routing Header (SRH) December 2014
841 6.2. Segment Routing Node Functions
843 SR packets are forwarded to segments endpoints (i.e.: nodes whose
844 address is in the DA field of the packet). The segment endpoint,
845 when receiving a SR packet destined to itself, does:
849 o Determine the next active segment.
851 o Update the Segments Left field (or, if requested, remove the SRH
856 o Send the packet to the next segment.
858 The procedures applied to the SRH are related to the node function.
859 Following nodes functions are defined:
865 Transit SR Intra Segment Node.
869 6.2.1. Ingress SR Node
871 Ingress Node can be a router at the edge of the SR domain or a SR-
872 capable host. The ingress SR node may obtain the segment list by
875 Local path computation.
879 Interaction with an SDN controller delivering the path as a
882 Any other mechanism (mechanisms through which the path is acquired
883 are outside the scope of this document).
885 When creating the SRH (either at ingress node or in the SDN
886 controller) the following is done:
888 Next Header and Hdr Ext Len fields are set according to [RFC2460].
892 Previdi, et al. Expires June 12, 2015 [Page 16]
894 Internet-Draft IPv6 Segment Routing Header (SRH) December 2014
897 Routing Type field is set as TBD (SRH).
899 The Segment List is built with the FIRST segment of the path
900 encoded in the LAST element of the Segment List. Subsequent
901 segments are encoded on top of the first segment. Finally, the
902 LAST segment of the path is encoded in the FIRST element of the
903 Segment List. In other words, the Segment List is encoded in the
904 reverse order of the path.
906 The original DA of the packet is encoded as the last segment of
907 the path (encoded in the first element of the Segment List).
909 the DA of the packet is set with the value of the first segment
910 (found in the last element of the segment list).
912 the Segments Left field is set to n-1 where n is the number of
913 elements in the Segment List.
915 The packet is sent out towards the first segment (i.e.:
916 represented in the packet DA).
918 6.2.1.1. Security at Ingress
920 The procedures related to the Segment Routing security are detailed
921 in [I-D.vyncke-6man-segment-routing-security].
923 In the case where the SR domain boundaries are not under control of
924 the network operator (e.g.: when the SR domain edge is in a home
925 network), it is important to authenticate and validate the content of
926 any SRH being received by the network operator. In such case, the
927 security procedure described in
928 [I-D.vyncke-6man-segment-routing-security] is to be used.
930 The ingress node (e.g.: the host in the home network) requests the
931 SRH from a control system (e.g.: an SDN controller) which delivers
932 the SRH with its HMAC signature on it.
934 Then, the home network host can send out SR packets (with an SRH on
935 it) that will be validated at the ingress of the network operator
938 The ingress node of the network operator infrastructure, is
939 configured in order to validate the incoming SRH HMACs in order to
940 allow only packets having correct SRH according to their SA/DA
948 Previdi, et al. Expires June 12, 2015 [Page 17]
950 Internet-Draft IPv6 Segment Routing Header (SRH) December 2014
953 6.2.2. Transit Non-SR Capable Node
955 SR is interoperable with plain IPv6 forwarding. Any non SR-capable
956 node will forward SR packets solely based on the DA. There's no SRH
957 inspection. This ensures full interoperability between SR and non-SR
960 6.2.3. SR Intra Segment Transit Node
962 Only the node whose address is in DA inspects and processes the SRH
963 (according to [RFC2460]). An intra segment transit node is not in
964 the DA and its forwarding is based on DA and its SR-IPv6 FIB.
966 6.2.4. SR Segment Endpoint Node
968 The SR segment endpoint node is the node whose address is in the DA.
969 The segment endpoint node inspects the SRH and does:
971 1. IF DA = myself (segment endpoint)
972 2. IF Segments Left > 0 THEN
973 decrement Segments Left
974 update DA with Segment List[Segments Left]
975 3. ELSE IF Segments List[Segments Left] <> DA THEN
976 update DA with Segments List[Segments Left]
977 IF Clean-up bit is set THEN remove the SRH
978 4. ELSE give the packet to next PID (application)
980 5. Forward the packet out
982 6.3. FRR Flag Settings
984 A node supporting SR and doing Fast Reroute (as described in
985 [I-D.filsfils-spring-segment-routing-use-cases], when rerouting
986 packets through FRR mechanisms, SHOULD inspect the rerouted packet
987 header and look for the SRH. If the SRH is present, the rerouting
988 node SHOULD set the Protected bit on all rerouted packets.
992 Encapsulation can be realized in two different ways with SR-IPv6:
996 SRH with SA/DA original addresses.
998 Outer encapsulation tunneling is the traditional method where an
999 additional IPv6 header is prepended to the packet. The original IPv6
1000 header being encapsulated, everything is preserved and the packet is
1004 Previdi, et al. Expires June 12, 2015 [Page 18]
1006 Internet-Draft IPv6 Segment Routing Header (SRH) December 2014
1009 switched/routed according to the outer header (that could contain a
1012 SRH allows encoding both original SA and DA, hence an operator may
1013 decide to change the SA/DA at ingress and restore them at egress.
1014 This can be achieved without outer encapsulation, by changing SA/DA
1015 and encoding the original SA in the Policy List and in the original
1016 DA in the Segment List.
1020 A more detailed description of use cases are available in
1021 [I-D.ietf-spring-ipv6-use-cases]. In this section, a simple SR-IPv6
1022 example is illustrated.
1024 In the topology described in Figure 6 it is assumed an end-to-end SR
1025 deployment. Therefore SR is supported by all nodes from A to J.
1027 Home Network | Backbone | Datacenter
1029 | +---+ +---+ +---+ | +---+ |
1030 +---|---| C |---| D |---| E |---|---| I |---|
1031 | | +---+ +---+ +---+ | +---+ |
1032 | | | | | | | | +---+
1033 +---+ +---+ | | | | | | |--| X |
1034 | A |---| B | | +---+ +---+ +---+ | +---+ | +---+
1035 +---+ +---+ | | F |---| G |---| H |---|---| J |---|
1036 | +---+ +---+ +---+ | +---+ |
1043 Figure 6: Sample SR topology
1045 The following workflow applies to packets sent by host A and destined
1060 Previdi, et al. Expires June 12, 2015 [Page 19]
1062 Internet-Draft IPv6 Segment Routing Header (SRH) December 2014
1065 . Host A sends a request for a path to server X to the SDN
1066 controller or orchestration system.
1068 . The SDN controller/orchestrator builds a SRH with:
1069 . Segment List: C, F, J, X
1071 that satisfies the requirements expressed in the request
1072 by host A and based on policies applicable to host A.
1074 . Host A receives the SRH and insert it into the packet.
1080 . Segments Left: 3 (i.e.: Segment List size - 1)
1081 . PL: C (ingress), J (egress)
1082 Note that X is the last segment and C is the
1083 first segment (i.e.: the SL is encoded in the reverse
1087 . When packet arrives in C (first segment), C does:
1088 . Validate the HMAC of the SRH.
1089 . Decrement Segments Left by one: 2
1090 . Update the DA with the next segment found in
1091 Segment List[2]. DA is set to F.
1092 . Forward the packet to F.
1094 . When packet arrives in F (second segment), F does:
1095 . Decrement Segments Left by one: 1
1096 . Update the DA with the next segment found in
1097 Segment List[1]. DA is set to J.
1098 . Forward the packet to J.
1100 . Packet travels across G and H nodes which do plain
1101 IPv6 forwarding based on DA. No inspection of SRH needs
1102 to be done in these nodes. However, any SR capable node
1103 is allowed to set the Protected bit in case of FRR
1106 . When packet arrives in J (third segment), J does:
1107 . Decrement Segments Left by one: 0
1108 . Update the DA with the next segment found in
1109 Segment List[0]. DA is set to X.
1110 . If the cleanup bit is set, then node J will strip out
1111 the SRH from the packet.
1112 . Forward the packet to X.
1116 Previdi, et al. Expires June 12, 2015 [Page 20]
1118 Internet-Draft IPv6 Segment Routing Header (SRH) December 2014
1121 The packet arrives in the server that may or may not support SR. The
1122 return traffic, from server to host, may be sent using the same
1125 9. IANA Considerations
1129 10. Manageability Considerations
1133 11. Security Considerations
1135 Security mechanisms applied to Segment Routing over IPv6 networks are
1136 detailed in [I-D.vyncke-6man-segment-routing-security].
1140 The authors would like to thank Dave Barach, John Leddy, John
1141 Brzozowski, Pierre Francois, Nagendra Kumar, Mark Townsley, Christian
1142 Martin, Roberta Maglione, Eric Vyncke, James Connolly, David Lebrun
1143 and Fred Baker for their contribution to this document.
1145 13. Acknowledgements
1151 14.1. Normative References
1153 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1154 Requirement Levels", BCP 14, RFC 2119, March 1997.
1156 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
1157 (IPv6) Specification", RFC 2460, December 1998.
1159 14.2. Informative References
1161 [I-D.filsfils-spring-segment-routing]
1162 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
1163 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
1164 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
1165 "Segment Routing Architecture", draft-filsfils-spring-
1166 segment-routing-04 (work in progress), July 2014.
1172 Previdi, et al. Expires June 12, 2015 [Page 21]
1174 Internet-Draft IPv6 Segment Routing Header (SRH) December 2014
1177 [I-D.filsfils-spring-segment-routing-mpls]
1178 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
1179 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
1180 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
1181 "Segment Routing with MPLS data plane", draft-filsfils-
1182 spring-segment-routing-mpls-03 (work in progress), August
1185 [I-D.filsfils-spring-segment-routing-use-cases]
1186 Filsfils, C., Francois, P., Previdi, S., Decraene, B.,
1187 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
1188 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E.
1189 Crabbe, "Segment Routing Use Cases", draft-filsfils-
1190 spring-segment-routing-use-cases-01 (work in progress),
1193 [I-D.ietf-isis-segment-routing-extensions]
1194 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
1195 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
1196 Extensions for Segment Routing", draft-ietf-isis-segment-
1197 routing-extensions-03 (work in progress), October 2014.
1199 [I-D.ietf-spring-ipv6-use-cases]
1200 Brzozowski, J., Leddy, J., Leung, I., Previdi, S.,
1201 Townsley, W., Martin, C., Filsfils, C., and R. Maglione,
1202 "IPv6 SPRING Use Cases", draft-ietf-spring-ipv6-use-
1203 cases-03 (work in progress), November 2014.
1205 [I-D.psenak-ospf-segment-routing-ospfv3-extension]
1206 Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
1207 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
1208 Extensions for Segment Routing", draft-psenak-ospf-
1209 segment-routing-ospfv3-extension-02 (work in progress),
1212 [I-D.vyncke-6man-segment-routing-security]
1213 Vyncke, E. and S. Previdi, "IPv6 Segment Routing Header
1214 (SRH) Security Considerations", July 2014.
1216 [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D.
1217 Zappala, "Source Demand Routing: Packet Format and
1218 Forwarding Specification (Version 1)", RFC 1940, May 1996.
1228 Previdi, et al. Expires June 12, 2015 [Page 22]
1230 Internet-Draft IPv6 Segment Routing Header (SRH) December 2014
1233 Stefano Previdi (editor)
1235 Via Del Serafico, 200
1239 Email: sprevidi@cisco.com
1247 Email: cfilsfil@cisco.com
1252 4100 East Dry Creek Road
1253 Centennial, CO 80122
1256 Email: Brian_Field@cable.comcast.com
1260 Rogers Communications
1262 Brampton, ON L6T 0C1
1265 Email: Ida.Leung@rci.rogers.com