diff options
Diffstat (limited to 'src/vnet/sr/rfc_draft_05.txt')
| -rw-r--r-- | src/vnet/sr/rfc_draft_05.txt | 1265 |
1 files changed, 1265 insertions, 0 deletions
diff --git a/src/vnet/sr/rfc_draft_05.txt b/src/vnet/sr/rfc_draft_05.txt new file mode 100644 index 00000000000..bc41c181ea4 --- /dev/null +++ b/src/vnet/sr/rfc_draft_05.txt @@ -0,0 +1,1265 @@ +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 |