Network Working Group C. Filsfils, Ed. Internet-Draft S. Previdi, Ed. Intended status: Standards Track A. Bashandy Expires: December 30, 2013 Cisco Systems, Inc. B. Decraene S. Litkowski Orange M. Horneffer Deutsche Telekom I. Milojevic Telekom Srbija R. Shakir British Telecom S. Ytti TDC Oy W. Henderickx Alcatel-Lucent J. Tantsura Ericsson E. Crabbe Google, Inc. June 28, 2013 Segment Routing Architecture draft-filsfils-rtgwg-segment-routing-00 Abstract Segment Routing (SR) leverages the source routing and tunneling paradigms. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. A segment can have a local semantic to an SR node or global within an SR domain. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the SR domain. The Segment Routing architecture can be directly applied to the MPLS dataplane with no change on the forwarding plane. It requires minor extension to the existing link-state routing protocols. Segment Routing can also be applied to IPv6 with a new type of routing extension header. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Filsfils, et al. Expires December 30, 2013 [Page 1] Internet-Draft Segment Routing June 2013 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." This Internet-Draft will expire on December 30, 2013. Copyright Notice Copyright (c) 2013 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. Filsfils, et al. Expires December 30, 2013 [Page 2] Internet-Draft Segment Routing June 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Illustration . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Properties . . . . . . . . . . . . . . . . . . . . . . . . 8 1.4. Companion Documents . . . . . . . . . . . . . . . . . . . 9 1.5. Relationship with MPLS and IPv6 . . . . . . . . . . . . . 9 2. Abstract Routing Model . . . . . . . . . . . . . . . . . . . . 10 2.1. Traffic Engineering with SR . . . . . . . . . . . . . . . 12 2.2. Segment Routing Database . . . . . . . . . . . . . . . . . 13 3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 13 3.1. Illustration . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 14 3.1.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 15 3.1.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 15 3.1.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . 15 3.1.5. Example 5 . . . . . . . . . . . . . . . . . . . . . . 16 3.2. IGP Segment Terminology . . . . . . . . . . . . . . . . . 16 3.2.1. IGP Segment, IGP SID . . . . . . . . . . . . . . . . . 16 3.2.2. IGP-Prefix Segment, Prefix-SID . . . . . . . . . . . . 17 3.2.3. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . 17 3.2.4. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . 17 3.2.5. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . 18 3.2.6. Finally . . . . . . . . . . . . . . . . . . . . . . . 18 3.3. IGP Segment Allocation, Advertisement and SRDB Maintenance . . . . . . . . . . . . . . . . . . . . . . . 19 3.3.1. Prefix-SID . . . . . . . . . . . . . . . . . . . . . . 19 3.3.2. Adj-SID . . . . . . . . . . . . . . . . . . . . . . . 20 3.4. Inter-Area Considerations . . . . . . . . . . . . . . . . 22 3.5. IGP Mirroring Context Segment . . . . . . . . . . . . . . 22 4. Service Segments . . . . . . . . . . . . . . . . . . . . . . . 23 5. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 10. Manageability Considerations . . . . . . . . . . . . . . . . . 25 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 13.1. Normative References . . . . . . . . . . . . . . . . . . . 25 13.2. Informative References . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Filsfils, et al. Expires December 30, 2013 [Page 3] Internet-Draft Segment Routing June 2013 1. Introduction In this section, we illustrate the key properties of the SR architecture, introduce the companion documents to this note and relate SR to the MPLS and IPv6 architectures. Section 2 defines the SR abstract routing model. Section 3 defines the IGP-based segments. Section 4 defines the Service Segments. Section 5 and Section 6 define the instantiations of SR in MPLS and IPv6. 1.1. 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 itsef to the egress edge router. Per-flow State for packet P should only be created at the ingress edge router. State for packet P can only be created at the ingress edge router. 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 SR header on the packet P. Filsfils, et al. Expires December 30, 2013 [Page 4] Internet-Draft Segment Routing June 2013 +---------------------------------------------------------------+ | | | | SR Header | | | | | | {SD, SB, SS, SF, SE}, Ptr, SI, SE | Transported | | ^ | | Packet | | | | | P | | +---------------------+ | | | | | +---------------------------------------------------------------+ Figure 2: Packet P at node I The 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 is a 32-bit identification either for 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 ISIS/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. 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. Filsfils, et al. Expires December 30, 2013 [Page 5] Internet-Draft Segment Routing June 2013 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 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 Filsfils, et al. Expires December 30, 2013 [Page 6] Internet-Draft Segment Routing June 2013 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. 1.2. Terminology The following terminology is defined: +---------------+---------------------------------------------------+ | Term | Definition | +---------------+---------------------------------------------------+ | Segment | A segment that identifies an instruction | +---------------+---------------------------------------------------+ | SID | A 32-bit identification for a segment | +---------------+---------------------------------------------------+ | Segment List | Ordered list of segments encoding the topological | | | and service source route of the packet | +---------------+---------------------------------------------------+ | Active | The segment that MUST be used by the receiving | | Segment | router to process the packet. It is identified | | | by the pointer | +---------------+---------------------------------------------------+ | SR-Pointer or | In the SR header, it indicates the active segment | | pointer | in the segment list | +---------------+---------------------------------------------------+ | Global | The related instruction is supported by all the | | Segment | SR-capable nodes in the local domain | +---------------+---------------------------------------------------+ | SRGB | SR Global Block: the set of global segments in | | | the local SR domain | +---------------+---------------------------------------------------+ | Local Segment | The related instruction is supported only by the | | | node originating it | Filsfils, et al. Expires December 30, 2013 [Page 7] Internet-Draft Segment Routing June 2013 | IGP Segment | The generic names for a segment attached to a | | or IGP SID | piece of information advertised by a link-state | | | IGP, e.g. an IGP prefix or an IGP adjacency | +---------------+---------------------------------------------------+ | IGP-Prefix | An IGP-Prefix Segment is an IGP segment attached | | Segment or | to an IGP prefix. An IGP-Prefix Segment is | | Prefix-SID | always global within the SR/IGP domain and | | | identifies the ECMP-aware shortest-path computed | | | by the IGP to the related prefix. The Prefix-SID | | | is the SID of the IGP-Prefix Segment | +---------------+---------------------------------------------------+ | IGP-Node | An IGP-Node Segment is a an IGP-Prefix Segment | | Segment or | which identifies a specific router (e.g. a | | Node Segment | loopback). The terms "Node Segment" or Node-SID" | | or Node-SID | are often used as an abbreviation | +---------------+---------------------------------------------------+ | IGP-Anycast | An IGP-Anycast Segment is an IGP-prefix segment | | Segment or | which does not identify a specific router, but a | | Anycast | set of routers. The terms "Anycast Segment" or | | Segment or | "Anycast-SID" are often used as an abbreviation | | Anycast-SID | | +---------------+---------------------------------------------------+ | IGP-Adjacency | An IGP-Adjacency Segment is an IGP segment | | Segment or | attached to an unidirectional adjacency or a set | | Adjacency | of unidirectional adjacencies. An IGP-Adjacency | | Segment or | Segment is local to the node which advertises it | | Adj-SID | | +---------------+---------------------------------------------------+ | SRDB | The SR Database. Each entry is indexed by a | | | segment value. Each entry must list the SR | | | header operation to apply and the next-hop to | | | forward the packet to | +---------------+---------------------------------------------------+ | SR Header | Push, Continue and Next are operations applied on | | Operation | the SR segment list | +---------------+---------------------------------------------------+ Table 1: Segment Routing Terminology 1.3. Properties Assuming a packet flow F entering an SR domain at ingress SR edge router I, the properties offered by the SR architecture are: Per-Flow state for F is only maintained by node I. Filsfils, et al. Expires December 30, 2013 [Page 8] Internet-Draft Segment Routing June 2013 Any topological path through the SR domain can be enforced. Any chain of services through the SR domain can be enforced. Any mix of topological paths and chain of services can be enforced. Any node along the flow path can determine where flow entered the SR domain, how it got up to that node, where it will exit the SR domain and how it will get there. 1.4. Companion Documents This document defines the SR architecture, its routing model, the IGP-based segments and the service segments. Use cases are described in [draft-filsfils-rtgwg-segment-routing-use-cases-00]. IS-IS protocol extensions for Segment Routing are described in [draft-previdi-isis-segment-routing-extensions-00]. OSPF protocol extensions for Segment Routing are defined in [draft-psenak-ospf-segment-routing-extensions-00]. The PCEP protocol extensions for Segment Routing are defined in [draft-msiva-pce-pcep-segment-routing-extensions-00]. In the future, it is expected that Section 5 and Section 6 of this document be removed and submitted as independent documents, respectively as instantiations of SR in MPLS and IPv6. In the future, we will submit a SR-FRR specific document. 1.5. Relationship with MPLS and IPv6 The source routing model is inherited from the one proposed by [RFC2460]. The notion of abstract segment identifier which can represent any instruction is inherited from MPLS ([RFC3031]). Deployment experiences has shown the need to limit the number of per- flow states maintained in the network while preserving information on the topological and service journey of a packet (e.g. the ingress to the domain for accounting/billing purpose). The main differences from the IPv6 source route model are: Filsfils, et al. Expires December 30, 2013 [Page 9] Internet-Draft Segment Routing June 2013 The source route is encoded as an ordered list of segments instead of IP addresses. A segment can represent any instruction either a service or a topological path. Topologically, the path to an IP address is often limited to the shortest-path to that address. A segment can represent any path (e.g. an adjacency segment forces a packet to a nexthop through a specific adjacency even if the shortest-path to the next-hop does not use that adjacency). The ingress and egress egde routers are identified and always available, allowing for interesting accounting and policy applications. The source route functionality cannot be controlled from outside the SR domain. The main differences from the MPLS model are: Global segments are introduced (e.g. IGP node segments). LDP and RSVP MPLS signaling protocols are not required. If present, SR can coexist and interwork with LDP and RSVP.[draft-filsfils-rtgwg-segment-routing-use-cases-00]. Per-flow states are only maintained at the ingress edge router. SR can be instantiated on the IPv6 dataplane. Section 6 details the new routing extension header which carry all the elements of the abstract SR header. All the SR properties are preserved. SR can be instantiated on the MPLS dataplane. In Section 5, we explain that the information present in the SR abstract header is encoded as a stack of labels. The notion of pointer and full segment list containing the full history of the path from ingress to egress edge routers is thus lost in the MPLS instantiation of SR. However all the other SR properties are preserved and especially the MPLS dataplane can be reused without any change. 2. Abstract Routing Model Segment Routing (SR) leverages the source routing and tunneling paradigms. 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. Filsfils, et al. Expires December 30, 2013 [Page 10] Internet-Draft Segment Routing June 2013 The 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. A property of the architecture 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 or inter-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), a value allocated from the 32-bit Segment IDentifier space. The first 16 values are reserved. The terms "segment" and "SID" are interchangeable. Within an SR domain, all the SR-capable nodes are configured with the Filsfils, et al. Expires December 30, 2013 [Page 11] Internet-Draft Segment Routing June 2013 Segment Routing Global Block (SRGB). The SRGB is a subset of the 32- bit SID space. SRGB can be a non-contiguous set of segments. 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. 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. 2.1. 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 the SR architecture, this per-flow state only exists at the ingress egde router whether 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. [draft-filsfils-rtgwg-segment-routing-use-cases-00] illustrates various alternatives: N is deriving this policy automatically (e.g. FRR). N is provisioned explicitly by the operator. N is provisioned by a stateful PCE server. 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). Any architecture that involves the insertion of information onto a packet involves performance consideration. [draft-filsfils-rtgwg-segment-routing-use-cases-00]explains why the majority of use-cases require very short segment-lists. A stateful PCE server, 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 Filsfils, et al. Expires December 30, 2013 [Page 12] Internet-Draft Segment Routing June 2013 [draft-msiva-pce-pcep-segment-routing-extensions-00]. 2.2. Segment Routing Database The Segment routing Database (SRDB) is a set of entries where each entry is identified by a segment value. 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 or from protocol segment advertisement. The next section will detail segment advertisement by IGP protocols." 3. Link-State IGP Segments Within a link-state IGP domain, an SR-capable IGP node advertises segments for its attached prefixes and adjacencies. These segments are called IGP segments or IGP SIDs. They play a key role in the Segment Routing architecture and use-cases [draft-filsfils-rtgwg-segment-routing-use-cases-00] as they enable the expression of any topological path throughout the IGP domain. Such a topological path is either expressed as a single IGP segment or a list of multiple IGP segments. In the first sub-section, we introduce a terminology for a set of IGP segments which are very frequently seen in the SR use-cases. The second sub-section details the IGP segment allocation and SRDB construction rules. 3.1. Illustration Assuming the network diagram of Figure 5 and the IP address and IGP Segment allocation of Figure 6, the following examples can be Filsfils, et al. Expires December 30, 2013 [Page 13] Internet-Draft Segment Routing June 2013 constructed. +--------+ / \ R1-----R2----------R3-----R8 | \ / | | +--R4--+ | | | +-----R5-----+ Figure 5: IGP Segments - Illustration +-----------------------------------------------------------+ | IP address allocated by the operator: | | 192.0.2.1/32 as a loopback of R1 | | 192.0.2.2/32 as a loopback of R2 | | 192.0.2.3/32 as a loopback of R3 | | 192.0.2.4/32 as a loopback of R4 | | 192.0.2.5/32 as a loopback of R5 | | 192.0.2.8/32 as a loopback of R8 | | 198.51.100.9/32 as an anycast loopback of R4 | | 198.51.100.9/32 as an anycast loopback of R5 | | | | SRGB defined by the operator as 1000-5000 | | | | Global IGP SID allocated by the operator: | | 1001 allocated to 192.0.2.1/32 | | 1002 allocated to 192.0.2.2/32 | | 1003 allocated to 192.0.2.3/32 | | 1004 allocated to 192.0.2.4/32 | | 1008 allocated to 192.0.2.8/32 | | 2009 allocated to 198.51.100.9/32 | | | | Local IGP SID allocated dynamically by R2 | | for its "north" adjacency to R3: 9001 | | for its "north" adjacency to R3: 9003 | | for its "south" adjacency to R3: 9002 | | for its "south" adjacency to R3: 9003 | +-----------------------------------------------------------+ Figure 6: IGP Address and Segment Allocation - Illustration 3.1.1. Example 1 R1 may send a packet P1 to R8 simply by pushing an SR header with segment list {1008}. 1008 is a global IGP segment attached to the IP prefix 192.0.2.8/32. Its semantic is global within the IGP domain: any router forwards a Filsfils, et al. Expires December 30, 2013 [Page 14] Internet-Draft Segment Routing June 2013 packet received with active segment 1008 to the next-hop along the ECMP-aware shortest-path to the related prefix. In conclusion, the path followed by P1 is R1-R2--R3-R8. The ECMP- awareness ensures that the traffic be load-shared between any ECMP path, in this case the two north and south links between R2 and R3. 3.1.2. Example 2 R1 may send a packet P2 to R8 by pushing an SR header with segment list {1002, 9001, 1008}. 1002 is a global IGP segment attached to the IP prefix 192.0.2.2/32. Its semantic is global within the IGP domain: any router forwards a packet received with active segment 1002 to the next-hop along the shortest-path to the related prefix. 9001 is a local IGP segment attached by node R2 to its north link to R3. Its semantic is local to node R2: R2 switches a packet received with active segment 9001 towards the north link to R3. In conclusion, the path followed by P2 is R1-R2-north-link-R3-R8. 3.1.3. Example 3 R1 may send a packet P3 along the same exact path as P1 using a different segment list {1002, 9003, 1008}. 9003 is a local IGP segment attached by node R2 to both its north and south links to R3. Its semantic is local to node R2: R2 switches a packet received with active segment 9003 towards either the north or south links to R3 (e.g. per-flow loadbalancing decision). In conclusion, the path followed by P3 is R1-R2-any-link-R3-R8. 3.1.4. Example 4 R1 may send a packet P4 to R8 while avoiding the links between R2 and R3 by pushing an SR header with segment list {1004, 1008}. 1004 is a global IGP segment attached to the IP prefix 192.0.2.4/32. Its semantic is global within the IGP domain: any router forwards a packet received with active segment 1004 to the next-hop along the shortest-path to the related prefix. In conclusion, the path followed by P4 is R1-R2-R4-R3-R8. Filsfils, et al. Expires December 30, 2013 [Page 15] Internet-Draft Segment Routing June 2013 3.1.5. Example 5 R1 may send a packet P5 to R8 while avoiding the links between R2 and R3 while still benefitting from all the remaining shortest paths (via R4 and R5) by pushing an SR header with segment list {2009, 1008}. 2009 is a global IGP segment attached to the anycast IP prefix 198.51.100.9/32. Its semantic is global within the IGP domain: any router forwards a packet received with active segment 2009 to the next-hop along the shortest-path to the related prefix. In conclusion, the path followed by P5 is either R1-R2-R4-R3-R8 or R1-R2-R5-R3-R8 . 3.2. IGP Segment Terminology 3.2.1. IGP Segment, IGP SID The terms "IGP Segment" and "IGP SID" are the generic names for a segment attached to a piece of information advertised by a link-state IGP, e.g. an IGP prefix or an IGP adjacency. The IGP signaling extension to advertise an IGP segment includes the G-Flag indicating whether the IGP segment is global or local. IGP-SID +--+--+ / | \ Prefix-SID x Adj-SID +----+---+ / | \ Node-SID y Anycast-SID Figure 7: IGP SID Terminology The IGP Segment terminology is introduced to ease the documentation of SR use-cases and hence does not propose a name for any possible variation of IGP segment supported by the architecture. For example, y in Figure 7 could represent a local IGP segment attached to an IGP Prefix. This variation, while supported by the SR architecture is not seen in the SR use-cases and hence does not receive a specific name. In Figure 5 and Figure 6, SIDs 1001, 1002, 1003, 1004, 1008, 2009, 9001, 9002 and 9003 are called IGP SIDs. Filsfils, et al. Expires December 30, 2013 [Page 16] Internet-Draft Segment Routing June 2013 3.2.2. IGP-Prefix Segment, Prefix-SID An IGP-Prefix Segment is an IGP segment attached to an IGP prefix. An IGP-Prefix Segment is always global within the SR/IGP domain and identifies the ECMP-aware shortest-path computed by the IGP to the related prefix. The G-Flag MUST be set. The Prefix-SID is the SID of the IGP-Prefix Segment. A packet injected anywhere within the SR/IGP domain with an active Prefix-SID will be forwarded along the shortest-path to that prefix. The IGP signaling extension for IGP-Prefix segment includes the P-Flag. A Node N advertising a Prefix-SID SID-R for its attached prefix R resets the P-Flag to allow its connected neighbors to perform the NEXT operation while processing SID-R. This behavior is equivalent to Pen-ultimate Hop Popping in MPLS. When set, the neighbors of N must perform the CONTINUE operation while processing SID-R. While the architecture allows to attach a local segment to an IGP prefix, we specifically assume that when the terms "IGP-Prefix Segment" and "Prefix-SID" are used then the segment is global (the SID is allocated from the SRGB). This is consistent with [draft-filsfils-rtgwg-segment-routing-use-cases-00] as all the described use-cases require global segments attached to IGP prefix. In Figure 5 and Figure 6, SIDs 1001, 1002, 1003, 1004, 1008, 2009 are called Prefix-SIDs. 3.2.3. IGP-Node Segment, Node-SID An IGP-Node Segment is a an IGP-Prefix Segment which identifies a specific router (e.g. a loopback). The terms "Node Segment" or "Node-SID" are often used as an abbreviation. A "Node Segment" or "Node-SID" is fundamental to the SR architecture. From anywhere in the network, it enforces the ECMP-aware shortest- path forwarding of the packet towards the related node as explained in [draft-filsfils-rtgwg-segment-routing-use-cases-00]. In Figure 5 and Figure 6, SIDs 1001, 1002, 1003, 1004 and 1008 are called Node-SIDs. 3.2.4. IGP-Anycast Segment, Anycast SID An IGP-Anycast Segment is an IGP-prefix segment which does not identify a specific router, but a set of routers. The terms "Anycast Segment" or "Anycast-SID" are often used as an abbreviation. Filsfils, et al. Expires December 30, 2013 [Page 17] Internet-Draft Segment Routing June 2013 An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware shortest-path forwarding towards the closest node of the anycast set. This is useful to express macro-engineering policies as described in [draft-filsfils-rtgwg-segment-routing-use-cases-00]. In Figure 5 and Figure 6, SID 2009 is called Anycast SID. 3.2.5. IGP-Adjacency Segment, Adj-SID An IGP-Adjacency Segment is an IGP segment attached to an unidirectional adjacency or a set of unidirectional adjacencies. An IGP-Adjacency Segment is local to the node which advertises it. The SID of the IGP-Adjacency Segment is called the Adj-SID. The G-Flag must be reset. The adjacency is formed by the local node (i.e.: the node advertising the adjacency in the IGP) and the remote node (i.e.: the other end of the adjacency). The local node MUST be an IGP node. The remote node MAY be: An adjacent IGP node (i.e.: an IGP neighbor). A non-adjacent neighbor (e.g.: a Forwarding Adjacency, [RFC4206]). A virtual neighbor outside the IGP domain (e.g.: an interface connecting another AS) as defined in [RFC5316]. A packet injected anywhere within the SR/IGP domain with a segment list {SN, SNL}, where SN is the Node-SID of node N and SNL is an Adj- Sid attached by node N to its adjacency over link L, will be forwarded along the shortest-path to N and then be switched by N, without any IP shortest-path consideration, towards link L. If the Adj-Sid identifies a set of adjacencies, then the node N load- balances the traffic along the various members of the set. An "IGP Adjacency Segment" or "Adj-SID" enforces the switching of the packet from a note towards a defined interface or set of interfaces. This is key to theoretically prove that any path can be expressed as a list of segments as explained in [draft-filsfils-rtgwg-segment-routing-use-cases-00]. In Figure 5 and Figure 6, SIDs 9001, 9002 and 9003 are called Adj- SIDs. 3.2.6. Finally Figure 8 summarizes the different terms that can be used to refer to the SID's used in the example illustrated by Figure 5 and Figure 6. Filsfils, et al. Expires December 30, 2013 [Page 18] Internet-Draft Segment Routing June 2013 "Y" means that the term can be used to refer to the SID, "N" means that the term cannot be used to refer to the SID. +---------------------------------------------------------------+ | SID | IGP SID | Prefix-SID | Node-SID| Anycast SID| Adj-SID | | Value | | | | | | +---------------------------------------------------------------+ | 1001 | Y | Y | Y | N | N | | 1002 | Y | Y | Y | N | N | | 1003 | Y | Y | Y | N | N | | 1004 | Y | Y | Y | N | N | | 1005 | Y | Y | Y | N | N | | 1008 | Y | Y | Y | N | N | | 2009 | Y | Y | N | Y | N | | 9001 | Y | N | N | N | Y | | 9002 | Y | N | N | N | Y | | 9003 | Y | N | N | N | Y | +---------------------------------------------------------------+ Figure 8: Terminology Example 3.3. IGP Segment Allocation, Advertisement and SRDB Maintenance 3.3.1. Prefix-SID Multiple Prefix-SID's may be allocated to the same IGP Prefix (e.g. for class of service purpose). Typically a single Prefix-SID is allocated to an IGP Prefix. A Prefix-SID is allocated from the SRGB according to a similar process to IP address allocation. Typically the Prefix-SID is allocated by policy by the operator (or NMS) and the SID very rarely changes. The allocation process MUST NOT allocate the same Prefix-SID to different IP prefixes. If a node learns a Prefix-SID having a value that falls outside the locally configured SRGB range, then the node MUST NOT use the Prefix- SID and SHOULD issue an error log warning for misconfiguration. The required IGP protocol extensions are defined in [draft-previdi-isis-segment-routing-extensions-00] and [draft-psenak-ospf-segment-routing-extensions-00]. A node N attaching a Prefix-SID SID-R to its attached prefix R MUST maintain the following SRDB entry: Filsfils, et al. Expires December 30, 2013 [Page 19] Internet-Draft Segment Routing June 2013 Incoming Active Segment: SID-R Ingress Operation: NEXT Egress interface: NULL A remote node M MUST maintain the following SRDB entry for any learned Prefix-SID SID-R attached to IP prefix R: Incoming Active Segment: SID-R Ingress Operation: If the next-hop of R is the originator of R and instructed to remove the active segment: NEXT Else: CONTINUE Egress interface: the interface towards the next-hop along the shortest-path to prefix R. 3.3.2. Adj-SID The Adjacency Segment SID (Adj-SID) identifies a unidirectional adjacency or a set of unidirectional adjacencies. A node SHOULD allocate one Adj-SIDs for each of its adjacencies. A node MAY allocate multiple Adj-SIDs to the same adjacency. A node MAY allocate the same Adj-SID to multiple adjacencies. Adjacency suppression MUST NOT be performed by the IGP. A node MUST install an SRDB entry for any Adj-SID of value V attached to data-link L: Incoming Active Segment: V Operation: NEXT Egress Interface: L When associated to a Forwarding Adjacency ([RFC4206]), the Adj-SID MAY also include the necessary information in order to describe the path to the remote end of the Forwarding Adjacency in the form of an Explicit Route Object. The Adj-SID implies, from the router advertising it, the forwarding of the packet through the adjacency identified by the Adj-SID, regardless its IGP/SPF cost. In other words, the use of Adjacency Segments overrides the routing decision made by SPF algorithm. 3.3.2.1. Parallel Adjacencies Adj-SIDs can be used in order to represent a set of parallel interfaces between two adjacent routers. For example, SID 9003 in figures 5 and 6 identify the set of interfaces between R2 and R3. A node MUST install an SRDB entry for any locally originated Adjacency Segment (Adj-SID) of value W attached to a set of link B Filsfils, et al. Expires December 30, 2013 [Page 20] Internet-Draft Segment Routing June 2013 with: Incoming Active Segment: W Ingress Operation: NEXT Egress interface: loadbalance between any data-link within set B 3.3.2.2. LAN Adjacency Segments In LAN subnetworks, link-state protocols define the concept of Designated Router (DR, in OSPF) or Designated Intermediate System (DIS, in IS-IS) that conduct flooding in broadcast subnetworks and that describe the LAN topology in a special routing update (OSPF Type2 LSA or IS-IS Pseudonode LSP). The difficulty with LANs is that each router only advertises its connectivity to the DR/DIS and not to each other individual nodes in the LAN. Therefore, additional protocol mechanisms (IS-IS and OSPF) are necessary in order for each router in the LAN to advertise an Adj-SID associated to each neighbor in the LAN. These extensions are defined in [draft-previdi-isis-segment-routing-extensions-00] and [draft-psenak-ospf-segment-routing-extensions-00]. 3.3.2.3. External Adjacencies Considerations IGPs have been extended in order to advertise virtual adjacencies that represent external links ([RFC5316]). Segment Routing allows to allocate an Adj-SID to these external links. AS1 ) ( AS2 IGP-1 ) eBGP ( IGP-2 ) ( B------C--)-------(--F-----G / | ) ( | | S---A/ | ) ( | | \ | ) ( | | \D------E--)-------(--H-----I----Z ) ( ) ( Figure 9: External Adjacency Example In the diagram above, C advertises in the IGP an adjacency to peer F of AS2 together with an associated Adj-SID. When S wants to force an inter-domain path to Z via the peering link CF, S encapsulates the packets with the list {Prefix-SID(C), Adj-SID(C,F, AS2)}. [draft-filsfils-rtgwg-segment-routing-use-cases-00] provides an external-adjacency use-case. Filsfils, et al. Expires December 30, 2013 [Page 21] Internet-Draft Segment Routing June 2013 3.4. Inter-Area Considerations In the following example diagram we assume an IGP deployed using areas and where SR has been deployed. ! ! ! ! B------C-----F----G-----K / | | | S---A/ | | | \ | | | \D------I----------J-----L----Z (192.0.2.1/32, Node-SID: 150) ! ! Area-1 ! Backbone ! Area 2 ! area ! Figure 10: Inter-Area Topology Example In area 2, node Z allocates Node-SID 150 to his local prefix 192.0.2.1/32. ABRs G and J will propagate the prefix into the backbone area by creating a new instance of the prefix according to normal inter-area/level IGP propagation rules. Nodes C and I will apply the same behavior when leaking prefixes from the backbone area down to area 1. Therefore, node S will see prefix 192.0.2.1/32 with Prefix-SID 150 and advertised by nodes C and I. It therefore results that a Prefix-SID remains attached to its related IGP Prefix through the inter-area process. When node S sends traffic to 192.0.2.1/32, it pushes Node-SID(150) as active segment and forward it to A. When packet arrives at ABR I (or C), the ABR forwards the packet according to the active segment (Node-SID(150)). Forwarding continues across area borders, using the same Node-SID(150), until the packet reaches its destination. When an ABR propagates a prefix from one area to another it MUST set the R-Flag. 3.5. IGP Mirroring Context Segment It is beneficial for an IGP node to be able to advertise its ability to process traffic originally destined to another IGP node, called the Mirrored node and identified by an IP address or a Node-SID, provided that a "Mirroring Context" segment be inserted in the segment list prior to any service segment local to the mirrored node. Filsfils, et al. Expires December 30, 2013 [Page 22] Internet-Draft Segment Routing June 2013 [draft-filsfils-rtgwg-segment-routing-use-cases-00] illustrates such a use-case where two IGP nodes offer the same set of services (e.g. BGP VPN) and mirror each other upon their failure. A similar behavior is described in [I-D.minto-rsvp-lsp-egress-fast-protection]. IS-IS and OSPF Router Capability extensions are described in [draft-previdi-isis-segment-routing-extensions-00] and [draft-psenak-ospf-segment-routing-extensions-00]. 4. Service Segments A service segment refers to a service offered by a node (e.g. firewall, vpn, etc.). Further informations will be included in future revisions. 5. MPLS The 20 right-most bits of the segment are encoded as a label. This implies that, in the MPLS instantiation, the SID values are allocated within a reduced 20-bit space out of the 32-bit SID space. A list of segments is represented as a stack of labels. The active segment is the top label. The CONTINUE operation is implemented as an MPLS swap operation where the outgoing label value is equal to the incoming label value. The NEXT operation is implemented as an MPLS pop operation. The PUSH operation is implemented as an MPLS push of a label stack. The SRGB label space is allocated to Segment Routing. The SR operator manages the SRGB space as a registry and ensures the unique allocation of the global resource. A local segment is a locally allocated label. In conclusion: There are no changes in the operations of the data-plane currently used in MPLS networks. Filsfils, et al. Expires December 30, 2013 [Page 23] Internet-Draft Segment Routing June 2013 The SR solution can co-exist and interwork with other MPLS control-plane protocols, see [draft-filsfils-rtgwg-segment-routing-use-cases-00] for more details. In the MPLS instantiation, as the packet travels through the SR domain, the stack is depleted and the segment list history is gradually lost. 6. IPv6 The text will be added in future revision. 7. OAM SR offers an interesting capability to monitor SR domains: Any path can be monitored by setting the segment list accordingly. A path can be expressed with ECMP-awareness or not. The probe travels along the desired path while staying at the forwarding level. A monitoring system is able to check any element of the entire SR domain, even if it located multiple hops away. Some elements of the SR/OAM functionality will require standardization and a related independent draft will eventually be submitted. SR/OAM use-cases are described in [draft-filsfils-rtgwg-segment-routing-use-cases-00]. 8. Multicast The text will be added in future revision. 9. IANA Considerations TBD Filsfils, et al. Expires December 30, 2013 [Page 24] Internet-Draft Segment Routing June 2013 10. Manageability Considerations TBD 11. Security Considerations TBD 12. Acknowledgements We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre Francois, Thomas Telkamp, Les Ginsberg, Ruediger Geib and Hannes Gredler for their contribution to the content of this document. 13. References 13.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. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, December 2008. 13.2. Informative References [I-D.minto-rsvp-lsp-egress-fast-protection] Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP egress fast-protection", draft-minto-rsvp-lsp-egress-fast-protection-02 (work in progress), April 2013. [draft-filsfils-rtgwg-segment-routing-use-cases-00] Filsfils, C., "Segment Routing Use Cases", May 2013. Filsfils, et al. Expires December 30, 2013 [Page 25] Internet-Draft Segment Routing June 2013 [draft-msiva-pce-pcep-segment-routing-extensions-00] Filsfils, C. and S. Sivabalan, "PCEP Extensions for Segment Routing", May 2013. [draft-previdi-isis-segment-routing-extensions-00] Previdi, S., Filsfils, C., and A. Bashandy, "IS-IS Segment Routing Extensions", May 2013. [draft-psenak-ospf-segment-routing-extensions-00] Psenak, P. and S. Previdi, "OSPF Segment Routing Extensions", May 2013. Authors' Addresses Clarence Filsfils (editor) Cisco Systems, Inc. Brussels, BE Email: cfilsfil@cisco.com Stefano Previdi (editor) Cisco Systems, Inc. Via Del Serafico, 200 Rome 00142 Italy Email: sprevidi@cisco.com Ahmed Bashandy Cisco Systems, Inc. 170, West Tasman Drive San Jose, CA 95134 US Email: bashandy@cisco.com Bruno Decraene Orange FR Email: bruno.decraene@orange.com Filsfils, et al. Expires December 30, 2013 [Page 26] Internet-Draft Segment Routing June 2013 Stephane Litkowski Orange FR Email: stephane.litkowski@orange.com Martin Horneffer Deutsche Telekom Hammer Str. 216-226 Muenster 48153 DE Email: Martin.Horneffer@telekom.de Igor Milojevic Telekom Srbija Takovska 2 Belgrade RS Email: igormilojevic@telekom.rs Rob Shakir British Telecom London UK Email: rob.shakir@bt.com Saku Ytti TDC Oy Mechelininkatu 1a TDC 00094 FI Email: saku@ytti.fi Filsfils, et al. Expires December 30, 2013 [Page 27] Internet-Draft Segment Routing June 2013 Wim Henderickx Alcatel-Lucent Copernicuslaan 50 Antwerp 2018 BE Email: wim.henderickx@alcatel-lucent.com Jeff Tantsura Ericsson 300 Holger Way San Jose, CA 95134 US Email: Jeff.Tantsura@ericsson.com Edward Crabbe Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 US Email: edc@google.com Filsfils, et al. Expires December 30, 2013 [Page 28]