]> NTT docomo Business

Japan w.mishima@ntt.com

NTT docomo Business

Japan y.fukagawa@ntt.com

Routing SPRING SRv6 SFC This document describes the architecture of Segment Routing over IPv6 (SRv6) Service Function Chaining (SFC) with SR-aware functions. This architecture provides the following benefits:

• Comprehensive Management: a centralized controller for SFC, handling SR Policy, link-state, and network metrics.
• Simplicity: no SFC proxies, which reduces the number of nodes and address resource consumption.

Discussion Venues Discussion of this document takes place on the Source Packet Routing in Networking Working Group mailing list (spring@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Segment Routing over IPv6 (SRv6) enables packet steering through a set of instructions called a segment list. Each SR segment endpoint node provides SRv6 Endpoint Behaviors, including Prefix/Adjacency Segments, VPNs, and Binding Segments. Service Function Chaining (SFC) can be used in various scenarios (e.g. FW, IPS, IDS, NAT, and DPI). SFC based on Segment Routing (SR) is defined in , which describes some SRv6 Endpoint Behaviors, such as End.AS/AD/AM, are necessary for using SR-unaware functions. This document describes an architecture for SRv6 SFC with SR-aware functions, which provides comprehensive management of SRv6 network resources and services.

Terminology

Terminology Defined in Related RFCs and Internet-Drafts The following terms are used in this document as defined in the related RFCs and Internet-Drafts:

• SR, SR Domain, Segment ID (SID), SRv6, SR Policy, Prefix Segment, Adjacency Segment, Anycast Segment, Active Segment, and Distributed/Centralized/Hybrid Control Plane defined in .
• SR Source Node, Transit Node, and SR Segment Endpoint Node defined in .
• SRv6 Endpoint Behavior defined in .
• SFC, SFC Proxy, and Service Classification Function defined in .
• Service Segment, SR-Aware Service, SR-Unaware Service, End.AS, End.AD and End.AM defined in .
• Headend, Color, and Endpoint defined in .
• Quality of Service (QoS), Service Level Agreement (SLA), and Service Level Objective (SLO) defined in .
• Forwarding Plane, Control Plane, Management Plane, Application Plane defined in .
• Path Computation Client (PCC), Path Computation Element (PCE), and Traffic Engineering Database (TED) defined in .
• BGP Flow Specification defined in

Newly Defined Terminology The following terms are used in this document as defined below:

• Service Function Node: an SR segment endpoint node that provides SR-aware functions as service segments.
• SRv6 Controller: controls SRv6 Forwarding Plane, consisting of a PCE and a Classification Rule Controller.
• Classification Rule Controller: applies sets of SR Policy and flows to SR source nodes.
• Service Function Manager: configures network function instances, enables SR-aware functions as service segments, and collects network metrics.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Design Objectives and Assumptions

Goals/Objectives SRv6 SFC Architecture is designed with two main objectives:

• Comprehensive Management: a centralized controller for SFC, handling SR Policy, link-state, and network metrics. When providing SRv6 services, meeting SLAs for each customer is required. These SLAs consist of one or more SLOs such as availability, latency, and bandwidth. In an SRv6 SFC network, service segment provisioning, link-state collection, and SR Policy calculation are required to meet SLOs, respectively. outlines a hybrid control plane that merges a distributed control plane and a centralized control plane. In this hybrid control plane, forwarding information like Node/Adjacency SIDs are advertised mutually by distributed SR nodes via IGPs such as ISIS and OSPF, while other information like SR Policies, classification rules, and service segments are provided by a centralized controller and manager. Software-Defined Networking (SDN) provides centralized management of a network by a controller and a manager. Centralized management reduces operational costs through abstraction and automation. The SDN framework allows users to manage an SR domain without considering the details of a forwarding plane like a topology and node state. Operators can use an SRv6 controller to build SR Policies for SFC and QoS, manage the state of network functions, issue service segments automatically, and specify disaster recovery with protection.
• Simplicity: no SFC proxies, so that reduces nodes and address resource consumption. Network complexity increases operating costs. Generally, using a variety of protocols in a network raises operational costs, including designing, building, monitoring, and troubleshooting. Using an SFC proxy may increase forwarding overhead due to additional header manipulations.

Assumptions To achieve these objectives, this architecture is based on two main assumptions:

• Straightforward extension of the SRv6 network programming model The protocol used in this architecture is compatible with SRv6. This streamlines the operation of services like traffic steering, including SFC, redundancy, and local protection. Standardized protocols such as BGP, PCEP, IS-IS, OSPF, TI-LFA, and Anycast SID are used in this architecture. This architecture is SRv6 compliant, enabling support for SR-unaware functions, although SR-aware functions are expected to meet the objective.
• SDN framework compliance and comprehensive management of SRv6 SFC by controllers A controller is used to provide comprehensive management. To simplify building and operating, the controller uses standardized protocols and abstracted service interfaces. This also provides programmability by controlling policies that meet a user's intent including SFC and quality of service (QoS).

Overview of Architecture Figure 1 illustrates an overview of this architecture.

Overview of SRv6 SFC Architecture with SR-aware Functions

This architecture is based on and consists of forwarding plane, control plane, management plane, and application plane.

• Forwarding Plane: classifies packets and encapsulates SRH, forwards them, and applies SRv6 Endpoint Behavior.
  • Provides SR-aware function using End.AN.
  • Classifies flows and applies them to a TE application with PBR.
  • Ensures redundancy with anycast.
  • Provides local protection with Fast Reroute (FRR).
• Control Plane: makes decisions about packet forwarding and provides rules for a forwarding plane.
  • Collects link-state including SRv6 locators, prefixes, behaviors, and delays.
  • Calculates and provisions SR Policies.
  • Applies SR Policies to each flow by provisioning flow classification rules.
• Management Plane: deploys and monitors network functions and devices.
  • Sets up network functions.
  • Collects metrics of devices, network functions, and SFC services.
• Application Plane: provides user API for the control/management planes.
  • Offers an interface for operators or customers.
  • Applies intents defined in .

Each component communicates using standardized protocols. These are designed to be loosely coupled and cooperate by using an abstraction layer. This document suggests handling a control plane by application plane, but a detailed design of an application plane is out of the scope of this document. This is because application plane components and abstraction layers should be designed based on individual network utilization and operator intent. In the following sections, details of a forwarding plane, control plane, and management plane are explained.

Forwarding Plane A forwarding plane provides SFC through packet classification, SRv6 encapsulation, and forwarding. In this architecture, all forwarding plane components are located within the SR domain.

Forwarding Plane | Node |------------>| Node |------------>| Node |--> | | | | (S1) | | (S2) | | | +-----------+ +----------+ +----------+ | +--------------------------- SR domain ---------------------------+ ]]>

Figure 2 shows an example of SFC with two network functions. Firstly, the SR source node classifies the flow and encapsulates it with an SRH containing the segment list <S1, S2>. Next, the service function node (S1) receives the packet and applies a network function associated with an End.AN S1. Finally, the service function node (S2) receives the packet and also applies a network function associated End.AN S2, thus achieving SFC.

End.AN-based Service Segment Provisioning End.AN provides an SR-aware function. Functions with the same role MAY be assigned as the same service segment within the SR domain. By using Anycast SIDs, multiple nodes can be grouped as part of the same service segment. End.AN MAY have optional arguments. This can provide additional programmability by embedding network function instructions in the segment list. By using virtualized spaces within routers or on generic servers, network functions can be provided at any node in an SR domain. This allows for scaling and flexible redundancy of network functions.

When a Network Function Becomes Unavailable When a network function becomes unavailable, the node removes the SID from its routing table. If an anycast SID is used, packets are redirected to another node. If no other nodes are available, the node drops the packets and sends an ICMPv6 message (Type 1: Destination Unreachable, Code 0: no route to destination).

Anycast Segment The concept of the Anycast Segment is introduced in . In the SRv6 SFC, it realizes to provide the same network function segment as the same Anycast Segment. In such cases, the state between network functions MUST be shared mutually.

Fast Reroute The ordering of network functions in an SRv6 SFC is guaranteed by the segment list, even if an FRR occurs, When an FRR occurs, if the Active segment is an Anycast SID, it MAY be forwarded to another service function node. In such a case, since state synchronization may not have been completed, the network function MUST have a mechanism to handle rerouted packets, such as buffering to wait for synchronization.

Service Function Chains In this architecture, each SFC is represented as an SR Policy. The purpose or intent of each SR Policy can be identified using attributes such as color or name. In general, SFC is achieved by using loose source routing. If both SFC and QoS are desired, they can be achieved by using strict source routing or loose source routing with Flex-Algo SIDs.

Per-Flow Encapsulation In an SR source node, which serves as the Service Classification Function, packets are classified on a per-flow basis using PBR and encapsulated with SR Policy. Therefore, the SR source node MUST be capable of identifying packets using at least a 5-tuple or even more detailed information. In this architecture, aiming for comprehensive management, the Service Classification Function has an API to communicate with the controller.

Control Plane A control plane sets up a forwarding plane by creating SR policies, including SFCs, and applying them to each flow.

Control Plane

The SRv6 Controller consists of the following two components:

• PCE: provides SR Policies that fulfill SFC/QoS requirements from the headend to the tailend and sends them to the SR source node.
• Classification Rule Controller: provides an Encapsulation Policy that corresponds to a specific flow and SR Policy, and sends them to the SR source node.

Path Computation Element (PCE) PCE is a controller that provides SR Policy. As an Active Stateful PCE, it establishes sessions with all PEs in an SR domain and manages SFCs. SR Policies MUST support both explicit and dynamic paths. For dynamic path computation, the Constrained Shortest Path First (CSPF) algorithm considers not only the SFC but also QoS constraints. The PCE builds a Traffic Engineering Database (TED) of the SR domain using BGP-LS and installs SR policies via PCEP or BGP SR Policy . To enable dynamic path calculation based on the state of service segments and Network Functions, the BGP-LS Service Segment extension is required.

Classification Rule Controller A Classification Rule Controller determines flows to apply specific SFC. The classification results are advertised to each SR source node as a set of flow, endpoints, and color with an extended protocol based on BGP Flowspec defined in .

Management Plane A management plane configures network function instances, enables SR-aware functions as service segments, monitors resources, and collects network metrics. The details of each manager are outside the scope of this document, as the southbound interface of the management plane may be different for each service and hardware architecture.

Management Plane

Figure 4 shows examples of managers that MAY be added to a management plane:

• Service Function Manager: provides an SID for a network service and manages this state.
• VNF Manager: manages the lifecycle of network functions.
  • It instantiates, configures, scales, heals, updates, and terminates network functions.
• VIM: manages virtualized compute, storage, and network resources.
  • In SRv6 SFC, a VIM MAY manage virtualized environments hosted on generic servers or within routers.
• Network Metrics Manager: collects metrics for SR Policy calculation and evaluation.
  • Metrics are collected from multiple data sources, including IPFIX, TCP statistics, and SRv6 path tracing .
  • Metrics can be used as input for PCE path computation.

Service Function Manager Service Function Manager enables and disables service segments of service function nodes. The Manager advertises the following parameters to each service function node:

• Behavior: End.AN
• SID: the SID of End.AN (in IPv6 Address format). If service segments support slicing, they are represented as Flex-Algo SIDs.
• Function Name: type of network function
• Action: enable
• TLV:
  • Specification of the Anycast Group: when deploying multiple Network Functions within the same context, it MUST use the Anycast Group TLV to indicate a shared anycast group SID.
  • Allows for the specification of unique parameters and context associated with a particular network function.

Normative References The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols. Cisco Systems, Inc. China Mobile Cisco Systems, Inc. Bell Canada Huawei Orange Mellanox AT&T Nokia Universita di Roma "Tor Vergata" This document defines data plane functionality required to implement service segments and achieve service programming in SR-enabled MPLS and IPv6 networks, as described in the Segment Routing architecture. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. This document describes the principles of traffic engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks and the networks that support IP networking and to provide a common basis for the development of traffic-engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational networks are also discussed. This work was first published as RFC 3272 in May 2002. This document obsoletes RFC 3272 by making a complete update to bring the text in line with best current practices for Internet traffic engineering and to include references to the latest relevant work in the IETF. Software-Defined Networking (SDN) refers to a new approach for network programmability, that is, the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces. SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane. This separation allows faster innovation cycles at both planes as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what the layer structure is in an SDN architecture, and how layers interface with each other. This document, a product of the IRTF Software-Defined Networking Research Group (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer-reviewed literature, the RFC series, and relevant documents by other standards organizations. This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK] This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification. This document obsoletes both RFC 5575 and RFC 7674. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Intent and Intent-Based Networking are taking the industry by storm. At the same time, terms related to Intent-Based Networking are often used loosely and inconsistently, in many cases overlapping and confused with other concepts such as "policy." This document clarifies the concept of "intent" and provides an overview of the functionality that is associated with it. The goal is to contribute towards a common and shared understanding of terms, concepts, and functionality that can be used as the foundation to guide further definition of associated research and engineering problems and their solutions. This document is a product of the IRTF Network Management Research Group (NMRG). It reflects the consensus of the research group, having received many detailed and positive reviews by research group participants. It is published for informational purposes. Huawei Technologies Cisco Systems Cisco Systems Microsoft Google This document introduces a BGP SAFI with two NLRIs to advertise a candidate path of a Segment Routing (SR) Policy. An SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. An SR Policy consists of one or more candidate paths, each consisting of one or more segment lists. A headend may be provisioned with candidate paths for an SR Policy via several different mechanisms, e.g., CLI, NETCONF, PCEP, or BGP. This document specifies how BGP may be used to distribute SR Policy candidate paths. It defines sub-TLVs for the Tunnel Encapsulation Attribute for signaling information about these candidate paths. This documents updates RFC9012 with extensions to the Color Extended Community to support additional steering modes over SR Policy. LinkedIn Cisco Systems Cisco Systems Cisco Systems Bell Canada AT&T Orange Ericsson Capitalonline Futurewei Technologies Huawei Technologies Service functions are deployed as, physical or virtualized elements along with network nodes or on servers in data centers. Segment Routing (SR) brings in the concept of segments which can be topological or service instructions. Service segments are SR segments that are associated with service functions. SR Policies are used for the setup of paths for steering of traffic through service functions using their service segments. BGP Link-State (BGP-LS) enables distribution of topology information from the network to a controller or an application in general so it can learn the network topology. This document specifies the extensions to BGP-LS for the advertisement of service functions along their associated service segments. The BGP-LS advertisement of service function information along with the network nodes that they are attached to, or associated with, enables controllers compute and setup service paths in the network. China Mobile China Mobile Huawei Technologies Verizon Communications Inc. Huawei Technologies BGP Flow Specification version 1 (FSv1), defined in [RFC8955], [RFC8956] and [RFC9117] has been proposed to distribute BGP [RFC4271] FlowSpec NLRI to FlowSpec clients to mitigate (distributed) denial- of-service attacks, and to provide traffic filtering in the context of a BGP/MPLS VPN service. Recently, traffic steering applications in the context of SR-MPLS and SRv6 using FlowSpec are being used in networks. This document introduces the usage of BGP FSv1 to steer packets into an SR Policy. Cisco Systems, Inc. Cisco Systems, Inc. Cisco Systems, Inc. Broadcom Swisscom Alibaba, Inc SoftBank Goldman Sachs Arrcus Path Tracing provides a record of the packet path as a sequence of interface ids. In addition, it provides a record of end-to-end delay, per-hop delay, and load on each egress interface along the packet delivery path. Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop- by-Hop extension header. Path Tracing supports fine grained timestamp. It has been designed for linerate hardware implementation in the base pipeline.

Appendix A. Implementation Experience Note to the RFC Editor: Please remove this appendix before publication as an RFC. This appendix is informative and non-normative. Several components of the architecture have been implemented and validated in IETF Hackathons. A.1. Flow-based Service Classification The following functionality has been implemented in GoBGP:

• Advertisement of classification rules using BGP Flowspec extensions for SRv6 Policy.

A.2. SR Policy Computation and Provisioning The following functionality has been implemented in Pola PCE:

• Centralized SR Policy computation for SFC using a stateful PCE.
• Support for explicit and dynamic SRv6 Policies with loose source routing.

A.3. Service Segment Advertisement The following functionality has been implemented in GoBGP and ExaBGP:

• Advertisement of VNF and End.AN information using BGP-LS Service Segment extensions.

A.4. Service and Infrastructure Management The following functionality has been implemented using OpenStack and Ansible:

• Deployment of VNFs.
• Provisioning of SRv6 End.AN behaviors.

Acknowledgments The authors would like to thank Mitsuru Maruyama, Katsuhiro Sebayashi, Yuma Ito, and Taisei Tanabe for their valuable reviews. This work was partially supported by NICT commissioned research (No. JPJ012368C03101) and JST CRONOS (No. JPMJCS24N9).