Reorganize source tree to use single autotools instance

Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23
Signed-off-by: Damjan Marion <damarion@cisco.com>

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