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, 0 insertions, 1265 deletions
diff --git a/src/vnet/sr/rfc_draft_05.txt b/src/vnet/sr/rfc_draft_05.txt deleted file mode 100644 index bc41c181ea4..00000000000 --- a/src/vnet/sr/rfc_draft_05.txt +++ /dev/null @@ -1,1265 +0,0 @@ -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 |