| Network Working Group S. Previdi, Ed. |
| Internet-Draft C. Filsfils |
| Intended status: Standards Track Cisco Systems, Inc. |
| Expires: June 12, 2015 B. Field |
| Comcast |
| I. Leung |
| Rogers Communications |
| December 9, 2014 |
| |
| |
| IPv6 Segment Routing Header (SRH) |
| draft-previdi-6man-segment-routing-header-05 |
| |
| Abstract |
| |
| Segment Routing (SR) allows a node to steer a packet through a |
| controlled set of instructions, called segments, by prepending a SR |
| header to the packet. A segment can represent any instruction, |
| topological or service-based. SR allows to enforce a flow through |
| any path (topological, or application/service based) while |
| maintaining per-flow state only at the ingress node to the SR domain. |
| |
| Segment Routing can be applied to the IPv6 data plane with the |
| addition of a new type of Routing Extension Header. This draft |
| describes the Segment Routing Extension Header Type and how it is |
| used by SR capable nodes. |
| |
| Requirements Language |
| |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| document are to be interpreted as described in RFC 2119 [RFC2119]. |
| |
| Status of This Memo |
| |
| This Internet-Draft is submitted in full conformance with the |
| provisions of BCP 78 and BCP 79. |
| |
| Internet-Drafts are working documents of the Internet Engineering |
| Task Force (IETF). Note that other groups may also distribute |
| working documents as Internet-Drafts. The list of current Internet- |
| Drafts is at http://datatracker.ietf.org/drafts/current/. |
| |
| Internet-Drafts are draft documents valid for a maximum of six months |
| and may be updated, replaced, or obsoleted by other documents at any |
| time. It is inappropriate to use Internet-Drafts as reference |
| material or to cite them other than as "work in progress." |
| |
| |
| |
| |
| Previdi, et al. Expires June 12, 2015 [Page 1] |
| |
| Internet-Draft IPv6 Segment Routing Header (SRH) December 2014 |
| |
| |
| This Internet-Draft will expire on June 12, 2015. |
| |
| Copyright Notice |
| |
| Copyright (c) 2014 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |
| |
| This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |
| carefully, as they describe your rights and restrictions with respect |
| to this document. Code Components extracted from this document must |
| include Simplified BSD License text as described in Section 4.e of |
| the Trust Legal Provisions and are provided without warranty as |
| described in the Simplified BSD License. |
| |
| Table of Contents |
| |
| 1. Structure of this document . . . . . . . . . . . . . . . . . 3 |
| 2. Segment Routing Documents . . . . . . . . . . . . . . . . . . 3 |
| 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 |
| 3.1. Data Planes supporting Segment Routing . . . . . . . . . 4 |
| 3.2. Illustration . . . . . . . . . . . . . . . . . . . . . . 4 |
| 4. Abstract Routing Model . . . . . . . . . . . . . . . . . . . 7 |
| 4.1. Segment Routing Global Block (SRGB) . . . . . . . . . . . 8 |
| 4.2. Traffic Engineering with SR . . . . . . . . . . . . . . . 9 |
| 4.3. Segment Routing Database . . . . . . . . . . . . . . . . 10 |
| 5. IPv6 Instantiation of Segment Routing . . . . . . . . . . . . 10 |
| 5.1. Segment Identifiers (SIDs) and SRGB . . . . . . . . . . . 10 |
| 5.1.1. Node-SID . . . . . . . . . . . . . . . . . . . . . . 11 |
| 5.1.2. Adjacency-SID . . . . . . . . . . . . . . . . . . . . 11 |
| 5.2. Segment Routing Extension Header (SRH) . . . . . . . . . 11 |
| 5.2.1. SRH and RFC2460 behavior . . . . . . . . . . . . . . 15 |
| 6. SRH Procedures . . . . . . . . . . . . . . . . . . . . . . . 15 |
| 6.1. Segment Routing Operations . . . . . . . . . . . . . . . 15 |
| 6.2. Segment Routing Node Functions . . . . . . . . . . . . . 16 |
| 6.2.1. Ingress SR Node . . . . . . . . . . . . . . . . . . . 16 |
| 6.2.2. Transit Non-SR Capable Node . . . . . . . . . . . . . 18 |
| 6.2.3. SR Intra Segment Transit Node . . . . . . . . . . . . 18 |
| 6.2.4. SR Segment Endpoint Node . . . . . . . . . . . . . . 18 |
| 6.3. FRR Flag Settings . . . . . . . . . . . . . . . . . . . . 18 |
| 7. SR and Tunneling . . . . . . . . . . . . . . . . . . . . . . 18 |
| 8. Example Use Case . . . . . . . . . . . . . . . . . . . . . . 19 |
| 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 |
| 10. Manageability Considerations . . . . . . . . . . . . . . . . 21 |
| 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 |
| 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 |
| |
| |
| |
| Previdi, et al. Expires June 12, 2015 [Page 2] |
| |
| Internet-Draft IPv6 Segment Routing Header (SRH) December 2014 |
| |
| |
| 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 |
| 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 |
| 14.1. Normative References . . . . . . . . . . . . . . . . . . 21 |
| 14.2. Informative References . . . . . . . . . . . . . . . . . 21 |
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 |
| |
| 1. Structure of this document |
| |
| Section 3 gives an introduction on SR for IPv6 networks. |
| |
| Section 4 describes the Segment Routing abstract model. |
| |
| Section 5 defines the Segment Routing Header (SRH) allowing |
| instantiation of SR over IPv6 dataplane. |
| |
| Section 6 details the procedures of the Segment Routing Header. |
| |
| 2. Segment Routing Documents |
| |
| Segment Routing terminology is defined in |
| [I-D.filsfils-spring-segment-routing]. |
| |
| Segment Routing use cases are described in |
| [I-D.filsfils-spring-segment-routing-use-cases]. |
| |
| Segment Routing IPv6 use cases are described in |
| [I-D.ietf-spring-ipv6-use-cases]. |
| |
| Segment Routing protocol extensions are defined in |
| [I-D.ietf-isis-segment-routing-extensions], and |
| [I-D.psenak-ospf-segment-routing-ospfv3-extension]. |
| |
| The security mechanisms of the Segment Routing Header (SRH) are |
| described in [I-D.vyncke-6man-segment-routing-security]. |
| |
| 3. Introduction |
| |
| Segment Routing (SR), defined in |
| [I-D.filsfils-spring-segment-routing], allows a node to steer a |
| packet through a controlled set of instructions, called segments, by |
| prepending a SR header to the packet. A segment can represent any |
| instruction, topological or service-based. SR allows to enforce a |
| flow through any path (topological or service/application based) |
| while maintaining per-flow state only at the ingress node to the SR |
| domain. Segments can be derived from different components: IGP, BGP, |
| Services, Contexts, Locators, etc. The list of segment forming the |
| path is called the Segment List and is encoded in the packet header. |
| |
| |
| |
| |
| Previdi, et al. Expires June 12, 2015 [Page 3] |
| |
| Internet-Draft IPv6 Segment Routing Header (SRH) December 2014 |
| |
| |
| SR allows the use of strict and loose source based routing paradigms |
| without requiring any additional signaling protocols in the |
| infrastructure hence delivering an excellent scalability property. |
| |
| The source based routing model described in |
| [I-D.filsfils-spring-segment-routing] is inherited from the ones |
| proposed by [RFC1940] and [RFC2460]. The source based routing model |
| offers the support for explicit routing capability. |
| |
| 3.1. Data Planes supporting Segment Routing |
| |
| Segment Routing (SR), can be instantiated over MPLS |
| ([I-D.filsfils-spring-segment-routing-mpls]) and IPv6. This document |
| defines its instantiation over the IPv6 data-plane based on the use- |
| cases defined in [I-D.ietf-spring-ipv6-use-cases]. |
| |
| Segment Routing for IPv6 (SR-IPv6) is required in networks where MPLS |
| data-plane is not used or, when combined with SR-MPLS, in networks |
| where MPLS is used in the core and IPv6 is used at the edge (home |
| networks, datacenters). |
| |
| This document defines a new type of Routing Header (originally |
| defined in [RFC2460]) called the Segment Routing Header (SRH) in |
| order to convey the Segment List in the packet header as defined in |
| [I-D.filsfils-spring-segment-routing]. Mechanisms through which |
| segment are known and advertised are outside the scope of this |
| document. |
| |
| 3.2. Illustration |
| |
| In the context of Figure 1 where all the links have the same IGP |
| cost, let us assume that a packet P enters the SR domain at an |
| ingress edge router I and that the operator requests the following |
| requirements for packet P: |
| |
| The local service S offered by node B must be applied to packet P. |
| |
| The links AB and CE cannot be used to transport the packet P. |
| |
| Any node N along the journey of the packet should be able to |
| determine where the packet P entered the SR domain and where it |
| will exit. The intermediate node should be able to determine the |
| paths from the ingress edge router to itself, and from itself to |
| the egress edge router. |
| |
| Per-flow State for packet P should only be created at the ingress |
| edge router. |
| |
| |
| |
| |
| Previdi, et al. Expires June 12, 2015 [Page 4] |
| |
| Internet-Draft IPv6 Segment Routing Header (SRH) December 2014 |
| |
| |
| The operator can forbid, for security reasons, anyone outside the |
| operator domain to exploit its intra-domain SR capabilities. |
| |
| I---A---B---C---E |
| \ | / \ / |
| \ | / F |
| \|/ |
| D |
| |
| Figure 1: An illustration of SR properties |
| |
| All these properties may be realized by instructing the ingress SR |
| edge router I to push the following abstract SR header on the packet |
| P. |
| |
| +---------------------------------------------------------------+ |
| | | | |
| | Abstract SR Header | | |
| | | | |
| | {SD, SB, SS, SF, SE}, Ptr, SI, SE | Transported | |
| | ^ | | Packet | |
| | | | | P | |
| | +---------------------+ | | |
| | | | |
| +---------------------------------------------------------------+ |
| |
| Figure 2: Packet P at node I |
| |
| The abstract SR header contains a source route encoded as a list of |
| segments {SD, SB, SS, SF, SE}, a pointer (Ptr) and the identification |
| of the ingress and egress SR edge routers (segments SI and SE). |
| |
| A segment identifies a topological instruction or a service |
| instruction. A segment can either be global or local. The |
| instruction associated with a global segment is recognized and |
| executed by any SR-capable node in the domain. The instruction |
| associated with a local segment is only supported by the specific |
| node that originates it. |
| |
| Let us assume some IGP (i.e.: ISIS and OSPF) extensions to define a |
| "Node Segment" as a global instruction within the IGP domain to |
| forward a packet along the shortest path to the specified node. Let |
| us further assume that within the SR domain illustrated in Figure 1, |
| segments SI, SD, SB, SE and SF respectively identify IGP node |
| segments to I, D, B, E and F. |
| |
| Let us assume that node B identifies its local service S with local |
| segment SS. |
| |
| |
| |
| Previdi, et al. Expires June 12, 2015 [Page 5] |
| |
| Internet-Draft IPv6 Segment Routing Header (SRH) December 2014 |
| |
| |
| With all of this in mind, let us describe the journey of the packet |
| P. |
| |
| The packet P reaches the ingress SR edge router. I pushes the SR |
| header illustrated in Figure 2 and sets the pointer to the first |
| segment of the list (SD). |
| |
| SD is an instruction recognized by all the nodes in the SR domain |
| which causes the packet to be forwarded along the shortest path to D. |
| |
| Once at D, the pointer is incremented and the next segment is |
| executed (SB). |
| |
| SB is an instruction recognized by all the nodes in the SR domain |
| which causes the packet to be forwarded along the shortest path to B. |
| |
| Once at B, the pointer is incremented and the next segment is |
| executed (SS). |
| |
| SS is an instruction only recognized by node B which causes the |
| packet to receive service S. |
| |
| Once the service applied, the next segment is executed (SF) which |
| causes the packet to be forwarded along the shortest path to F. |
| |
| Once at F, the pointer is incremented and the next segment is |
| executed (SE). |
| |
| SE is an instruction recognized by all the nodes in the SR domain |
| which causes the packet to be forwarded along the shortest path to E. |
| |
| E then removes the SR header and the packet continues its journey |
| outside the SR domain. |
| |
| All of the requirements are met. |
| |
| First, the packet P has not used links AB and CE: the shortest-path |
| from I to D is I-A-D, the shortest-path from D to B is D-B, the |
| shortest-path from B to F is B-C-F and the shortest-path from F to E |
| is F-E, hence the packet path through the SR domain is I-A-D-B-C-F-E |
| and the links AB and CE have been avoided. |
| |
| Second, the service S supported by B has been applied on packet P. |
| |
| Third, any node along the packet path is able to identify the service |
| and topological journey of the packet within the SR domain. For |
| example, node C receives the packet illustrated in Figure 3 and hence |
| is able to infer where the packet entered the SR domain (SI), how it |
| |
| |
| |
| Previdi, et al. Expires June 12, 2015 [Page 6] |
| |
| Internet-Draft IPv6 Segment Routing Header (SRH) December 2014 |
| |
| |
| got up to itself {SD, SB, SS, SE}, where it will exit the SR domain |
| (SE) and how it will do so {SF, SE}. |
| |
| +---------------------------------------------------------------+ |
| | | | |
| | SR Header | | |
| | | | |
| | {SD, SB, SS, SF, SE}, Ptr, SI, SE | Transported | |
| | ^ | | Packet | |
| | | | | P | |
| | +--------+ | | |
| | | | |
| +---------------------------------------------------------------+ |
| |
| Figure 3: Packet P at node C |
| |
| Fourth, only node I maintains per-flow state for packet P. The |
| entire program of topological and service instructions to be executed |
| by the SR domain on packet P is encoded by the ingress edge router I |
| in the SR header in the form of a list of segments where each segment |
| identifies a specific instruction. No further per-flow state is |
| required along the packet path. The per-flow state is in the SR |
| header and travels with the packet. Intermediate nodes only hold |
| states related to the IGP global node segments and the local IGP |
| adjacency segments. These segments are not per-flow specific and |
| hence scale very well. Typically, an intermediate node would |
| maintain in the order of 100's to 1000's global node segments and in |
| the order of 10's to 100 of local adjacency segments. Typically the |
| SR IGP forwarding table is expected to be much less than 10000 |
| entries. |
| |
| Fifth, the SR header is inserted at the entrance to the domain and |
| removed at the exit of the operator domain. For security reasons, |
| the operator can forbid anyone outside its domain to use its intra- |
| domain SR capability. |
| |
| 4. Abstract Routing Model |
| |
| At the entrance of the SR domain, the ingress SR edge router pushes |
| the SR header on top of the packet. At the exit of the SR domain, |
| the egress SR edge router removes the SR header. |
| |
| The abstract SR header contains an ordered list of segments, a |
| pointer identifying the next segment to process and the |
| identifications of the ingress and egress SR edge routers on the path |
| of this packet. The pointer identifies the segment that MUST be used |
| by the receiving router to process the packet. This segment is |
| called the active segment. |
| |
| |
| |
| Previdi, et al. Expires June 12, 2015 [Page 7] |
| |
| Internet-Draft IPv6 Segment Routing Header (SRH) December 2014 |
| |
| |
| A property of SR is that the entire source route of the packet, |
| including the identity of the ingress and egress edge routers is |
| always available with the packet. This allows for interesting |
| accounting and service applications. |
| |
| We define three SR-header operations: |
| |
| "PUSH": an SR header is pushed on an IP packet, or additional |
| segments are added at the head of the segment list. The pointer |
| is moved to the first entry of the added segments. |
| |
| "NEXT": the active segment is completed, the pointer is moved to |
| the next segment in the list. |
| |
| "CONTINUE": the active segment is not completed, the pointer is |
| left unchanged. |
| |
| In the future, other SR-header management operations may be defined. |
| |
| As the packet travels through the SR domain, the pointer is |
| incremented through the ordered list of segments and the source route |
| encoded by the SR ingress edge node is executed. |
| |
| A node processes an incoming packet according to the instruction |
| associated with the active segment. |
| |
| Any instruction might be associated with a segment: for example, an |
| intra-domain topological strict or loose forwarding instruction, a |
| service instruction, etc. |
| |
| At minimum, a segment instruction must define two elements: the |
| identity of the next-hop to forward the packet to (this could be the |
| same node or a context within the node) and which SR-header |
| management operation to execute. |
| |
| Each segment is known in the network through a Segment Identifier |
| (SID). The terms "segment" and "SID" are interchangeable. |
| |
| 4.1. Segment Routing Global Block (SRGB) |
| |
| In the SR abstract model, a segment is identified by a Segment |
| Routing Identifier (SID). The SR abstract model doesn't mandate a |
| specific format for the SID (IPv6 address or other formats). |
| |
| In Segment Routing IPv6 the SID is an IPv6 address. Therefore, the |
| SRGB is materialized by the global IPv6 address space which |
| represents the set of IPv6 routable addresses in the SR domain. The |
| following rules apply: |
| |
| |
| |
| Previdi, et al. Expires June 12, 2015 [Page 8] |
| |
| Internet-Draft IPv6 Segment Routing Header (SRH) December 2014 |
| |
| |
| o Each node of the SR domain MUST be configured with the Segment |
| Routing Global Block (SRGB). |
| |
| o All global segments must be allocated from the SRGB. Any SR |
| capable node MUST be able to process any global segment advertised |
| by any other node within the SR domain. |
| |
| o Any segment outside the SRGB has a local significance and is |
| called a "local segment". An SR-capable node MUST be able to |
| process the local segments it originates. An SR-capable node MUST |
| NOT support the instruction associated with a local segment |
| originated by a remote node. |
| |
| 4.2. Traffic Engineering with SR |
| |
| An SR Traffic Engineering policy is composed of two elements: a flow |
| classification and a segment-list to prepend on the packets of the |
| flow. |
| |
| In SR, this per-flow state only exists at the ingress edge node where |
| the policy is defined and the SR header is pushed. |
| |
| It is outside the scope of the document to define the process that |
| leads to the instantiation at a node N of an SR Traffic Engineering |
| policy. |
| |
| [I-D.filsfils-spring-segment-routing-use-cases] illustrates various |
| alternatives: |
| |
| N is deriving this policy automatically (e.g. FRR). |
| |
| N is provisioned explicitly by the operator. |
| |
| N is provisioned by a controller or server (e.g.: SDN Controller). |
| |
| N is provisioned by the operator with a high-level policy which is |
| mapped into a path thanks to a local CSPF-based computation (e.g. |
| affinity/SRLG exclusion). |
| |
| N could also be provisioned by other means. |
| |
| [I-D.filsfils-spring-segment-routing-use-cases] explains why the |
| majority of use-cases require very short segment-lists, hence |
| minimizing the performance impact, if any, of inserting and |
| transporting the segment list. |
| |
| |
| |
| |
| |
| |
| Previdi, et al. Expires June 12, 2015 [Page 9] |
| |
| Internet-Draft IPv6 Segment Routing Header (SRH) December 2014 |
| |
| |
| A SDN controller, which desires to instantiate at node N an SR |
| Traffic Engineering policy, collects the SR capability of node N such |
| as to ensure that the policy meets its capability. |
| |
| 4.3. Segment Routing Database |
| |
| The Segment routing Database (SRDB) is a set of entries where each |
| entry is identified by a SID. The instruction associated with each |
| entry at least defines the identity of the next-hop to which the |
| packet should be forwarded and what operation should be performed on |
| the SR header (PUSH, CONTINUE, NEXT). |
| |
| +---------+-----------+---------------------------------+ |
| | Segment | Next-Hop | SR Header operation | |
| +---------+-----------+---------------------------------+ |
| | Sk | M | CONTINUE | |
| | Sj | N | NEXT | |
| | Sl | NAT Srvc | NEXT | |
| | Sm | FW srvc | NEXT | |
| | Sn | Q | NEXT | |
| | etc. | etc. | etc. | |
| +---------+-----------+---------------------------------+ |
| |
| Figure 4: SR Database |
| |
| Each SR-capable node maintains its local SRDB. SRDB entries can |
| either derive from local policy or from protocol segment |
| advertisement. |
| |
| 5. IPv6 Instantiation of Segment Routing |
| |
| 5.1. Segment Identifiers (SIDs) and SRGB |
| |
| Segment Routing, as described in |
| [I-D.filsfils-spring-segment-routing], defines Node-SID and |
| Adjacency-SID. When SR is used over IPv6 data-plane the following |
| applies. |
| |
| The SRGB is the global IPv6 address space which represents the set of |
| IPv6 routable addresses in the SR domain. |
| |
| Node SIDs are IPv6 addresses part of the SRGB (i.e.: routable |
| addresses). Adjacency-SIDs are IPv6 addresses which may not be part |
| of the global IPv6 address space. |
| |
| |
| |
| |
| |
| |
| |
| Previdi, et al. Expires June 12, 2015 [Page 10] |
| |
| Internet-Draft IPv6 Segment Routing Header (SRH) December 2014 |
| |
| |
| 5.1.1. Node-SID |
| |
| The Node-SID identifies a node. With SR-IPv6 the Node-SID is an IPv6 |
| prefix that the operator configured on the node and that is used as |
| the node identifier. Typically, in case of a router, this is the |
| IPv6 address of the node loopback interface. Therefore, SR-IPv6 does |
| not require any additional SID advertisement for the Node Segment. |
| The Node-SID is in fact the IPv6 address of the node. |
| |
| 5.1.2. Adjacency-SID |
| |
| In the SR architecture defined in |
| [I-D.filsfils-spring-segment-routing] the Adjacency-SID (or Adj-SID) |
| identifies a given interface and may be local or global (depending on |
| how it is advertised). A node may advertise one (or more) Adj-SIDs |
| allocated to a given interface so to force the forwarding of the |
| packet (when received with that particular Adj-SID) into the |
| interface regardless the routing entry for the packet destination. |
| The semantic of the Adj-SID is: |
| |
| Send out the packet to the interface this prefix is allocated to. |
| |
| When SR is applied to IPv6, any SID is in a global IPv6 address and |
| therefore, an Adj-SID has a global significance (i.e.: the IPv6 |
| address representing the SID is a global address). In other words, a |
| node that advertises the Adj-SID in the form of a global IPv6 address |
| representing the link/adjacency the packet has to be forwarded to, |
| will apply to the Adj-SID a global significance. |
| |
| Advertisement of Adj-SID may be done using multiple mechanisms among |
| which the ones described in ISIS and OSPF protocol extensions: |
| [I-D.ietf-isis-segment-routing-extensions] and |
| [I-D.psenak-ospf-segment-routing-ospfv3-extension]. The distinction |
| between local and global significance of the Adj-SID is given in the |
| encoding of the Adj-SID advertisement. |
| |
| 5.2. Segment Routing Extension Header (SRH) |
| |
| A new type of the Routing Header (originally defined in [RFC2460]) is |
| defined: the Segment Routing Header (SRH) which has a new Routing |
| Type, (suggested value 4) to be assigned by IANA. |
| |
| As an example, if an explicit path is to be constructed across a core |
| network running ISIS or OSPF, the segment list will contain SIDs |
| representing the nodes across the path (loose or strict) which, |
| usually, are the IPv6 loopback interface address of each node. If |
| the path is across service or application entities, the segment list |
| |
| |
| |
| |
| Previdi, et al. Expires June 12, 2015 [Page 11] |
| |
| Internet-Draft IPv6 Segment Routing Header (SRH) December 2014 |
| |
| |
| contains the IPv6 addresses of these services or application |
| instances. |
| |
| The Segment Routing Header (SRH) is defined as follows: |
| |
| |
| 0 1 2 3 |
| 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 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Next Header | Hdr Ext Len | Routing Type | Segments Left | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | First Segment | Flags | HMAC Key ID | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| | Segment List[0] (128 bits ipv6 address) | |
| | | |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| | | |
| ... |
| | | |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| | Segment List[n] (128 bits ipv6 address) | |
| | | |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| | Policy List[0] (optional) | |
| | | |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| | Policy List[1] (optional) | |
| | | |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| | Policy List[2] (optional) | |
| | | |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| | | |
| | | |
| | HMAC (256 bits) | |
| |
| |
| |
| Previdi, et al. Expires June 12, 2015 [Page 12] |
| |
| Internet-Draft IPv6 Segment Routing Header (SRH) December 2014 |
| |
| |
| | (optional) | |
| | | |
| | | |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| where: |
| |
| o Next Header: 8-bit selector. Identifies the type of header |
| immediately following the SRH. |
| |
| o Hdr Ext Len: 8-bit unsigned integer, is the length of the SRH |
| header in 8-octet units, not including the first 8 octets. |
| |
| o Routing Type: TBD, to be assigned by IANA (suggested value: 4). |
| |
| o Segments Left. Defined in [RFC2460], it contains the index, in |
| the Segment List, of the next segment to inspect. Segments Left |
| is decremented at each segment and it is used as an index in the |
| segment list. |
| |
| o First Segment: offset in the SRH, not including the first 8 octets |
| and expressed in 16-octet units, pointing to the last element of |
| the segment list, which is in fact the first segment of the |
| segment routing path. |
| |
| o Flags: 16 bits of flags. Following flags are defined: |
| |
| 1 |
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |C|P|R|R| Policy Flags | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| C-flag: Clean-up flag. Set when the SRH has to be removed from |
| the packet when packet reaches the last segment. |
| |
| P-flag: Protected flag. Set when the packet has been rerouted |
| through FRR mechanism by a SR endpoint node. See Section 6.3 |
| for more details. |
| |
| R-flags. Reserved and for future use. |
| |
| Policy Flags. Define the type of the IPv6 addresses encoded |
| into the Policy List (see below). The following have been |
| defined: |
| |
| |
| |
| |
| |
| Previdi, et al. Expires June 12, 2015 [Page 13] |
| |
| Internet-Draft IPv6 Segment Routing Header (SRH) December 2014 |
| |
| |
| Bits 4-6: determine the type of the first element after the |
| segment list. |
| |
| Bits 7-9: determine the type of the second element. |
| |
| Bits 10-12: determine the type of the third element. |
| |
| Bits 13-15: determine the type of the fourth element. |
| |
| The following values are used for the type: |
| |
| 0x0: Not present. If value is set to 0x0, it means the |
| element represented by these bits is not present. |
| |
| 0x1: SR Ingress. |
| |
| 0x2: SR Egress. |
| |
| 0x3: Original Source Address. |
| |
| o HMAC Key ID and HMAC field, and their use are defined in |
| [I-D.vyncke-6man-segment-routing-security]. |
| |
| o Segment List[n]: 128 bit IPv6 addresses representing the nth |
| segment in the Segment List. The Segment List is encoded starting |
| from the last segment of the path. I.e., the first element of the |
| segment list (Segment List [0]) contains the last segment of the |
| path while the last segment of the Segment List (Segment List[n]) |
| contains the first segment of the path. The index contained in |
| "Segments Left" identifies the current active segment. |
| |
| o Policy List. Optional addresses representing specific nodes in |
| the SR path such as: |
| |
| SR Ingress: a 128 bit generic identifier representing the |
| ingress in the SR domain (i.e.: it needs not to be a valid IPv6 |
| address). |
| |
| SR Egress: a 128 bit generic identifier representing the egress |
| in the SR domain (i.e.: it needs not to be a valid IPv6 |
| address). |
| |
| Original Source Address: IPv6 address originally present in the |
| SA field of the packet. |
| |
| The segments in the Policy List are encoded after the segment list |
| and they are optional. If none are in the SRH, all bits of the |
| Policy List Flags MUST be set to 0x0. |
| |
| |
| |
| Previdi, et al. Expires June 12, 2015 [Page 14] |
| |
| Internet-Draft IPv6 Segment Routing Header (SRH) December 2014 |
| |
| |
| 5.2.1. SRH and RFC2460 behavior |
| |
| The SRH being a new type of the Routing Header, it also has the same |
| properties: |
| |
| SHOULD only appear once in the packet. |
| |
| Only the router whose address is in the DA field of the packet |
| header MUST inspect the SRH. |
| |
| Therefore, Segment Routing in IPv6 networks implies that the segment |
| identifier (i.e.: the IPv6 address of the segment) is moved into the |
| DA of the packet. |
| |
| The DA of the packet changes at each segment termination/completion |
| and therefore the original DA of the packet MUST be encoded as the |
| last segment of the path. |
| |
| As illustrated in Section 3.2, nodes that are within the path of a |
| segment will forward packets based on the DA of the packet without |
| inspecting the SRH. This ensures full interoperability between SR- |
| capable and non-SR-capable nodes. |
| |
| 6. SRH Procedures |
| |
| In this section we describe the different procedures on the SRH. |
| |
| 6.1. Segment Routing Operations |
| |
| When Segment Routing is instantiated over the IPv6 data plane the |
| following applies: |
| |
| o The segment list is encoded in the SRH. |
| |
| o The active segment is in the destination address of the packet. |
| |
| o The Segment Routing CONTINUE operation (as described in |
| [I-D.filsfils-spring-segment-routing]) is implemented as a |
| regular/plain IPv6 operation consisting of DA based forwarding. |
| |
| o The NEXT operation is implemented through the update of the DA |
| with the value represented by the Next Segment field in the SRH. |
| |
| o The PUSH operation is implemented through the insertion of the SRH |
| or the insertion of additional segments in the SRH segment list. |
| |
| |
| |
| |
| |
| |
| Previdi, et al. Expires June 12, 2015 [Page 15] |
| |
| Internet-Draft IPv6 Segment Routing Header (SRH) December 2014 |
| |
| |
| 6.2. Segment Routing Node Functions |
| |
| SR packets are forwarded to segments endpoints (i.e.: nodes whose |
| address is in the DA field of the packet). The segment endpoint, |
| when receiving a SR packet destined to itself, does: |
| |
| o Inspect the SRH. |
| |
| o Determine the next active segment. |
| |
| o Update the Segments Left field (or, if requested, remove the SRH |
| from the packet). |
| |
| o Update the DA. |
| |
| o Send the packet to the next segment. |
| |
| The procedures applied to the SRH are related to the node function. |
| Following nodes functions are defined: |
| |
| Ingress SR Node. |
| |
| Transit Non-SR Node. |
| |
| Transit SR Intra Segment Node. |
| |
| SR Endpoint Node. |
| |
| 6.2.1. Ingress SR Node |
| |
| Ingress Node can be a router at the edge of the SR domain or a SR- |
| capable host. The ingress SR node may obtain the segment list by |
| either: |
| |
| Local path computation. |
| |
| Local configuration. |
| |
| Interaction with an SDN controller delivering the path as a |
| complete SRH. |
| |
| Any other mechanism (mechanisms through which the path is acquired |
| are outside the scope of this document). |
| |
| When creating the SRH (either at ingress node or in the SDN |
| controller) the following is done: |
| |
| Next Header and Hdr Ext Len fields are set according to [RFC2460]. |
| |
| |
| |
| Previdi, et al. Expires June 12, 2015 [Page 16] |
| |
| Internet-Draft IPv6 Segment Routing Header (SRH) December 2014 |
| |
| |
| Routing Type field is set as TBD (SRH). |
| |
| The Segment List is built with the FIRST segment of the path |
| encoded in the LAST element of the Segment List. Subsequent |
| segments are encoded on top of the first segment. Finally, the |
| LAST segment of the path is encoded in the FIRST element of the |
| Segment List. In other words, the Segment List is encoded in the |
| reverse order of the path. |
| |
| The original DA of the packet is encoded as the last segment of |
| the path (encoded in the first element of the Segment List). |
| |
| the DA of the packet is set with the value of the first segment |
| (found in the last element of the segment list). |
| |
| the Segments Left field is set to n-1 where n is the number of |
| elements in the Segment List. |
| |
| The packet is sent out towards the first segment (i.e.: |
| represented in the packet DA). |
| |
| 6.2.1.1. Security at Ingress |
| |
| The procedures related to the Segment Routing security are detailed |
| in [I-D.vyncke-6man-segment-routing-security]. |
| |
| In the case where the SR domain boundaries are not under control of |
| the network operator (e.g.: when the SR domain edge is in a home |
| network), it is important to authenticate and validate the content of |
| any SRH being received by the network operator. In such case, the |
| security procedure described in |
| [I-D.vyncke-6man-segment-routing-security] is to be used. |
| |
| The ingress node (e.g.: the host in the home network) requests the |
| SRH from a control system (e.g.: an SDN controller) which delivers |
| the SRH with its HMAC signature on it. |
| |
| Then, the home network host can send out SR packets (with an SRH on |
| it) that will be validated at the ingress of the network operator |
| infrastructure. |
| |
| The ingress node of the network operator infrastructure, is |
| configured in order to validate the incoming SRH HMACs in order to |
| allow only packets having correct SRH according to their SA/DA |
| addresses. |
| |
| |
| |
| |
| |
| |
| Previdi, et al. Expires June 12, 2015 [Page 17] |
| |
| Internet-Draft IPv6 Segment Routing Header (SRH) December 2014 |
| |
| |
| 6.2.2. Transit Non-SR Capable Node |
| |
| SR is interoperable with plain IPv6 forwarding. Any non SR-capable |
| node will forward SR packets solely based on the DA. There's no SRH |
| inspection. This ensures full interoperability between SR and non-SR |
| nodes. |
| |
| 6.2.3. SR Intra Segment Transit Node |
| |
| Only the node whose address is in DA inspects and processes the SRH |
| (according to [RFC2460]). An intra segment transit node is not in |
| the DA and its forwarding is based on DA and its SR-IPv6 FIB. |
| |
| 6.2.4. SR Segment Endpoint Node |
| |
| The SR segment endpoint node is the node whose address is in the DA. |
| The segment endpoint node inspects the SRH and does: |
| |
| 1. IF DA = myself (segment endpoint) |
| 2. IF Segments Left > 0 THEN |
| decrement Segments Left |
| update DA with Segment List[Segments Left] |
| 3. ELSE IF Segments List[Segments Left] <> DA THEN |
| update DA with Segments List[Segments Left] |
| IF Clean-up bit is set THEN remove the SRH |
| 4. ELSE give the packet to next PID (application) |
| End of processing. |
| 5. Forward the packet out |
| |
| 6.3. FRR Flag Settings |
| |
| A node supporting SR and doing Fast Reroute (as described in |
| [I-D.filsfils-spring-segment-routing-use-cases], when rerouting |
| packets through FRR mechanisms, SHOULD inspect the rerouted packet |
| header and look for the SRH. If the SRH is present, the rerouting |
| node SHOULD set the Protected bit on all rerouted packets. |
| |
| 7. SR and Tunneling |
| |
| Encapsulation can be realized in two different ways with SR-IPv6: |
| |
| Outer encapsulation. |
| |
| SRH with SA/DA original addresses. |
| |
| Outer encapsulation tunneling is the traditional method where an |
| additional IPv6 header is prepended to the packet. The original IPv6 |
| header being encapsulated, everything is preserved and the packet is |
| |
| |
| |
| Previdi, et al. Expires June 12, 2015 [Page 18] |
| |
| Internet-Draft IPv6 Segment Routing Header (SRH) December 2014 |
| |
| |
| switched/routed according to the outer header (that could contain a |
| SRH). |
| |
| SRH allows encoding both original SA and DA, hence an operator may |
| decide to change the SA/DA at ingress and restore them at egress. |
| This can be achieved without outer encapsulation, by changing SA/DA |
| and encoding the original SA in the Policy List and in the original |
| DA in the Segment List. |
| |
| 8. Example Use Case |
| |
| A more detailed description of use cases are available in |
| [I-D.ietf-spring-ipv6-use-cases]. In this section, a simple SR-IPv6 |
| example is illustrated. |
| |
| In the topology described in Figure 6 it is assumed an end-to-end SR |
| deployment. Therefore SR is supported by all nodes from A to J. |
| |
| Home Network | Backbone | Datacenter |
| | | |
| | +---+ +---+ +---+ | +---+ | |
| +---|---| C |---| D |---| E |---|---| I |---| |
| | | +---+ +---+ +---+ | +---+ | |
| | | | | | | | | +---+ |
| +---+ +---+ | | | | | | |--| X | |
| | A |---| B | | +---+ +---+ +---+ | +---+ | +---+ |
| +---+ +---+ | | F |---| G |---| H |---|---| J |---| |
| | +---+ +---+ +---+ | +---+ | |
| | | |
| | +-----------+ |
| | SDN | |
| | Orch/Ctlr | |
| +-----------+ |
| |
| Figure 6: Sample SR topology |
| |
| The following workflow applies to packets sent by host A and destined |
| to server X. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Previdi, et al. Expires June 12, 2015 [Page 19] |
| |
| Internet-Draft IPv6 Segment Routing Header (SRH) December 2014 |
| |
| |
| . Host A sends a request for a path to server X to the SDN |
| controller or orchestration system. |
| |
| . The SDN controller/orchestrator builds a SRH with: |
| . Segment List: C, F, J, X |
| . HMAC |
| that satisfies the requirements expressed in the request |
| by host A and based on policies applicable to host A. |
| |
| . Host A receives the SRH and insert it into the packet. |
| The packet has now: |
| . SA: A |
| . DA: C |
| . SRH with |
| . SL: X, J, F, C |
| . Segments Left: 3 (i.e.: Segment List size - 1) |
| . PL: C (ingress), J (egress) |
| Note that X is the last segment and C is the |
| first segment (i.e.: the SL is encoded in the reverse |
| path order). |
| . HMAC |
| |
| . When packet arrives in C (first segment), C does: |
| . Validate the HMAC of the SRH. |
| . Decrement Segments Left by one: 2 |
| . Update the DA with the next segment found in |
| Segment List[2]. DA is set to F. |
| . Forward the packet to F. |
| |
| . When packet arrives in F (second segment), F does: |
| . Decrement Segments Left by one: 1 |
| . Update the DA with the next segment found in |
| Segment List[1]. DA is set to J. |
| . Forward the packet to J. |
| |
| . Packet travels across G and H nodes which do plain |
| IPv6 forwarding based on DA. No inspection of SRH needs |
| to be done in these nodes. However, any SR capable node |
| is allowed to set the Protected bit in case of FRR |
| protection. |
| |
| . When packet arrives in J (third segment), J does: |
| . Decrement Segments Left by one: 0 |
| . Update the DA with the next segment found in |
| Segment List[0]. DA is set to X. |
| . If the cleanup bit is set, then node J will strip out |
| the SRH from the packet. |
| . Forward the packet to X. |
| |
| |
| |
| Previdi, et al. Expires June 12, 2015 [Page 20] |
| |
| Internet-Draft IPv6 Segment Routing Header (SRH) December 2014 |
| |
| |
| The packet arrives in the server that may or may not support SR. The |
| return traffic, from server to host, may be sent using the same |
| procedures. |
| |
| 9. IANA Considerations |
| |
| TBD |
| |
| 10. Manageability Considerations |
| |
| TBD |
| |
| 11. Security Considerations |
| |
| Security mechanisms applied to Segment Routing over IPv6 networks are |
| detailed in [I-D.vyncke-6man-segment-routing-security]. |
| |
| 12. Contributors |
| |
| The authors would like to thank Dave Barach, John Leddy, John |
| Brzozowski, Pierre Francois, Nagendra Kumar, Mark Townsley, Christian |
| Martin, Roberta Maglione, Eric Vyncke, James Connolly, David Lebrun |
| and Fred Baker for their contribution to this document. |
| |
| 13. Acknowledgements |
| |
| TBD |
| |
| 14. References |
| |
| 14.1. Normative References |
| |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |
| |
| [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 |
| (IPv6) Specification", RFC 2460, December 1998. |
| |
| 14.2. Informative References |
| |
| [I-D.filsfils-spring-segment-routing] |
| Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., |
| Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., |
| Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, |
| "Segment Routing Architecture", draft-filsfils-spring- |
| segment-routing-04 (work in progress), July 2014. |
| |
| |
| |
| |
| |
| Previdi, et al. Expires June 12, 2015 [Page 21] |
| |
| Internet-Draft IPv6 Segment Routing Header (SRH) December 2014 |
| |
| |
| [I-D.filsfils-spring-segment-routing-mpls] |
| Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., |
| Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., |
| Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, |
| "Segment Routing with MPLS data plane", draft-filsfils- |
| spring-segment-routing-mpls-03 (work in progress), August |
| 2014. |
| |
| [I-D.filsfils-spring-segment-routing-use-cases] |
| Filsfils, C., Francois, P., Previdi, S., Decraene, B., |
| Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., |
| Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. |
| Crabbe, "Segment Routing Use Cases", draft-filsfils- |
| spring-segment-routing-use-cases-01 (work in progress), |
| October 2014. |
| |
| [I-D.ietf-isis-segment-routing-extensions] |
| Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., |
| Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS |
| Extensions for Segment Routing", draft-ietf-isis-segment- |
| routing-extensions-03 (work in progress), October 2014. |
| |
| [I-D.ietf-spring-ipv6-use-cases] |
| Brzozowski, J., Leddy, J., Leung, I., Previdi, S., |
| Townsley, W., Martin, C., Filsfils, C., and R. Maglione, |
| "IPv6 SPRING Use Cases", draft-ietf-spring-ipv6-use- |
| cases-03 (work in progress), November 2014. |
| |
| [I-D.psenak-ospf-segment-routing-ospfv3-extension] |
| Psenak, P., Previdi, S., Filsfils, C., Gredler, H., |
| Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 |
| Extensions for Segment Routing", draft-psenak-ospf- |
| segment-routing-ospfv3-extension-02 (work in progress), |
| July 2014. |
| |
| [I-D.vyncke-6man-segment-routing-security] |
| Vyncke, E. and S. Previdi, "IPv6 Segment Routing Header |
| (SRH) Security Considerations", July 2014. |
| |
| [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D. |
| Zappala, "Source Demand Routing: Packet Format and |
| Forwarding Specification (Version 1)", RFC 1940, May 1996. |
| |
| Authors' Addresses |
| |
| |
| |
| |
| |
| |
| |
| Previdi, et al. Expires June 12, 2015 [Page 22] |
| |
| Internet-Draft IPv6 Segment Routing Header (SRH) December 2014 |
| |
| |
| Stefano Previdi (editor) |
| Cisco Systems, Inc. |
| Via Del Serafico, 200 |
| Rome 00142 |
| Italy |
| |
| Email: sprevidi@cisco.com |
| |
| |
| Clarence Filsfils |
| Cisco Systems, Inc. |
| Brussels |
| BE |
| |
| Email: cfilsfil@cisco.com |
| |
| |
| Brian Field |
| Comcast |
| 4100 East Dry Creek Road |
| Centennial, CO 80122 |
| US |
| |
| Email: Brian_Field@cable.comcast.com |
| |
| |
| Ida Leung |
| Rogers Communications |
| 8200 Dixie Road |
| Brampton, ON L6T 0C1 |
| CA |
| |
| Email: Ida.Leung@rci.rogers.com |