Internet-Draft SRv6 SFC with SR-aware Functions September 2024
Mishima & Fukagawa Expires 8 March 2025 [Page]
Workgroup:
SPRING
Internet-Draft:
draft-watal-spring-srv6-sfc-sr-aware-functions-01
Published:
Intended Status:
Informational
Expires:
Authors:
W. Mishima
NTT Communications
Y. Fukagawa
NTT Communications

SRv6 SFC Architecture with SR-aware Functions

Abstract

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:

Discussion Venues

This note is to be removed before publishing as an RFC.

Discussion of this document takes place on the Source Packet Routing in Networking Working Group mailing list (spring@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spring/.

Source for this draft and an issue tracker can be found at https://https/github.com/watal.

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 https://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 8 March 2025.

Table of Contents

1. Introduction

Segment Routing over IPv6 (SRv6) [RFC8986] 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) [RFC7665] can be used in various scenarios (e.g. FW, IPS, IDS, NAT, and DPI). SFC based on Segment Routing (SR) is defined in [I-D.draft-ietf-spring-sr-service-programming], 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.

2. Terminology

2.2. Newly Defined Terminology

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

  • SRv6 Service Function Node: an SR segment endpoint node that provides SR-aware functions as service segments.

  • Classification Rule Controller: applies sets of SR Policy and flows to SR source nodes.

  • Service Function Controller: applies service segments to SRv6 service function nodes.

  • SRv6 Controller: controls SRv6 services comprehensively, consisting of a Service Function Controller, a PCE, and a Classification Rule Controller.

  • SRv6 Managers: manage SRv6 SFC infrastructure, consisting of a Virtualized Network Function (VNF) Manager, a Virtualized Infrastructure Manager (VIM), and a data collector of network metrics.

2.3. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Design Objectives and Assumptions

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

3.1. 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).

4. Overview of Architecture

Figure 1 illustrates an overview of this architecture.

 +------------------------------------------------+
 |               Application Plane                |
 +------------------------|-----------------------+
                          | Control Plane Northbound Interface
 +--- SRv6 Controller ----v-----------------------+
 | +--------------+ +-------------+ +-----------+ | +-----------+
 | |Classification| |    Path     | | Service   | | |  Service  |
 | |     Rule     | | Computation | | Function  | | |  Funtion  |
 | |  Controller  | |Element (PCE)| |Controller | | |  Managers |
 | +------|-------+ +-^---------|-+ +-----|-----+ | +-----|-----+
 +--------|-----------|---------|---------|-------+   Management
          |           |         |         |             Plane
         Control Plane Southbound Interfaces          Southbound
          |           |         |         |           Interface
 +--------|-----------|---------|---------|---------------|-------+
 | +------v-----------|---------v-+ +-----v---------------v-----+ |
 | |       SR Source Node /       | |       SRv6 Service        | |
 | |    Service Classification    |-|         Function          | |
 | |           Function           | |           Node            | |
 | +------------------------------+ +---------------------------+ |
 +--------------------------- SR domain --------------------------+
Figure 1: Overview of SRv6 SFC Architecture with SR-aware Functions

This architecture is based on SDN [RFC7426] separating the forwarding plane (FP), control plane (CP), management plane (MP), and application plane (AP). Each plane has the following roles:

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.

5. Forwarding Plane

A forwarding plane is responsible for providing SFC through packet classification, SRv6 encapsulation, and forwarding. In this architecture, all forwarding plane components are located within the SR domain.

 +----------------------------------------------------------------+
 | +--------------+             +--------+             +--------+ |
 | |  SR Source   | SRv6 Packet |  SRv6  | SRv6 Packet |  SRv6  | |
 | |     Node     |(S2,S1; SL:1)|Service |(S2,S1; SL:1)|Service | |
-->|  / Service   |------------>|Function|------------>|Function|-->
 | |Classification|             |  Node  |             |  Node  | |
 | |   Function   |             |  (S1)  |             |  (S2)  | |
 | +--------------+             +--------+             +--------+ |
 +-------------------------- SR domain ---------------------------+
Figure 2: Forwarding Plane

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 SRv6 service function node (S1) receives the packet and applies a network function associated with an End.AN S1. Finally, the SRv6 service function node (S2) receives the packet and also applies a network function associated End.AN S2, thus achieving SFC.

5.1. 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.

5.1.1. When a Network Function Goes Down

If a network function experiences a failure, the associated route MUST be promptly removed. In the case of Anycast configuration, it MUST be gracefully rerouted to other nodes. Additionally, if no alternative nodes are available, consider either dropping the packet and sending an ICMP Destination Unreachable message or forwarding it as a pass-through.

5.1.2. Anycast Segment

The concept of the Anycast segment is introduced in [RFC8402]. 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.

5.1.3. 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 SRv6 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.

5.2. 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.

5.3. 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.

6. Control Plane

A control plane is responsible for enabling comprehensive management of SRv6 SFC. It enables SR-aware functions as service segments and specifies SR Policies including SFC for each flow. A control plane has a Northbound API to receive user requests and a Southbound API to manipulate a forwarding plane.

 +---------------- SRv6 Controller ----------------+
 | +--------------+ +-------------+ +------------+ |
 | |Classification| |    Path     | |  Service   | |
 | |     Rule     | | Computation | |  Function  | |
 | |  Controller  | |Element (PCE)| | Controller | |
 | +------|-------+ +-^---------|-+ +------|-----+ |
 +--------|-----------|---------|----------|-------+
   Classification link-state SR Policy Enable/Disable
        Rule       (BGP-LS) (PCEP/BGP) a Service Segment
   (BGP Flowspec)     |         |     (End.AN SID:S1)
 +--------|-----------|---------|----------|----------------------+
 | +------v-----------|---------v-+ +------v--------------------+ |
 | |       SR Source Node /       | |       SRv6 Service        | |
 | |    Service Classification    |-|         Function          | |
 | |           Function           | |           Node            | |
 | +------------------------------+ +---------------------------+ |
 +--------------------------- SR domain --------------------------+
Figure 3: Control Plane

The SRv6 Controller consists of the following three components:

6.1. Service Function Controller

Service Function Controller is responsible for enabling and disabling service segments of SRv6 service function nodes. To manage service segments, it utilizes the extensions provided in a BGP-LS service segment, as outlined in [I-D.draft-ietf-idr-bgp-ls-sr-service-segments] and TODO: draft-watal-idr-bgp-ls-sr-service-segments-enabler, and defines the following parameters:

  • Behavior: End.AN

  • SID: the SID of End.AN (in IPv6 Address format). Service segments that support slicing are specified here as Flex-Algo SIDs.

  • Function Name: type of network function

  • Action: enable

  • TLV:

    • Specification of the Anycast Segment Group: when deploying multiple Network Functions within the same context, it MUST use the Anycast Group TLV to specify the same anycast segment group SID.

    • Allows for the specification of unique parameters and context associated with a particular network function.

6.2. 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, Constrained Shortest Path First (CSPF) considers not only SFC but also QoS.

It acquires the Traffic Engineering Database (TED) of the SR domain using BGP-LS and deploys SR Policies via PCEP [RFC5440] or BGP SR Policy [I-D.draft-ietf-idr-segment-routing-te-policy]. The BGP-LS service segment is required to calculate dynamic paths based on the state of service segments and network functions.

6.3. 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 [I-D.draft-ietf-idr-ts-flowspec-srv6-policy].

7. Management Plane

A management plane is responsible for configuring network function instances, monitoring resources, and collecting 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.

 +----------------- SRv6 Manager ------------------+
 | +--------------+ +--------------+ +-----------+ |
 | | Virtualized  | |     VNF      | |  Network  | |
 | |Infrastructure| |   Manager    | |  Metric   | |
 | |   Manager    | |              | |  Manager  | |
 | +------^-------+ +------^-------+ +-----^-----+ |
 +--------|----------------|---------------|-------+
          |                |               |
        Management Plane Southbound Interfaces
          |                |               |
 +--------|----------------|---------------|-------+
 | +------|----------------v---------------|-----+ |
 | |                  SR Service                 | |
 | |                   Function                  | |
 | |                     Node                    | |
 | +---------------------------------------------+ |
 +------------------- SR domain -------------------+
Figure 4: Management Plane

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

8. Normative References

[I-D.draft-filsfils-spring-path-tracing]
Filsfils, C., Abdelsalam, A., Camarillo, P., Yufit, M., Graf, T., Su, Y., Matsushima, S., Valentine, M., and Dhamija, "Path Tracing in SRv6 networks", Work in Progress, Internet-Draft, draft-filsfils-spring-path-tracing-05, , <https://datatracker.ietf.org/doc/html/draft-filsfils-spring-path-tracing-05>.
[I-D.draft-ietf-idr-bgp-ls-sr-service-segments]
Dawra, G., Filsfils, C., Talaulikar, K., Clad, F., Bernier, D., Uttaro, J., Decraene, B., Elmalky, H., Xu, X., Guichard, J., and C. Li, "BGP-LS Advertisement of Segment Routing Service Segments", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-ls-sr-service-segments-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-sr-service-segments-02>.
[I-D.draft-ietf-idr-segment-routing-te-policy]
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., and D. Jain, "Advertising Segment Routing Policies in BGP", Work in Progress, Internet-Draft, draft-ietf-idr-segment-routing-te-policy-26, , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-26>.
[I-D.draft-ietf-idr-ts-flowspec-srv6-policy]
Wenying, J., Liu, Y., Zhuang, S., Mishra, G. S., and S. Chen, "Traffic Steering using BGP FlowSpec with SR Policy", Work in Progress, Internet-Draft, draft-ietf-idr-ts-flowspec-srv6-policy-04, , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-ts-flowspec-srv6-policy-04>.
[I-D.draft-ietf-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and S. Salsano, "Service Programming with Segment Routing", Work in Progress, Internet-Draft, draft-ietf-spring-sr-service-programming-10, , <https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-service-programming-10>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5440]
Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, , <https://www.rfc-editor.org/rfc/rfc5440>.
[RFC7426]
Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, , <https://www.rfc-editor.org/rfc/rfc7426>.
[RFC7665]
Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, , <https://www.rfc-editor.org/rfc/rfc7665>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8402]
Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, , <https://www.rfc-editor.org/rfc/rfc8402>.
[RFC8754]
Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, , <https://www.rfc-editor.org/rfc/rfc8754>.
[RFC8955]
Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, , <https://www.rfc-editor.org/rfc/rfc8955>.
[RFC8986]
Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, , <https://www.rfc-editor.org/rfc/rfc8986>.
[RFC9256]
Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, , <https://www.rfc-editor.org/rfc/rfc9256>.
[RFC9315]
Clemm, A., Ciavaglia, L., Granville, L. Z., and J. Tantsura, "Intent-Based Networking - Concepts and Definitions", RFC 9315, DOI 10.17487/RFC9315, , <https://www.rfc-editor.org/rfc/rfc9315>.
[RFC9522]
Farrel, A., Ed., "Overview and Principles of Internet Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522, , <https://www.rfc-editor.org/rfc/rfc9522>.

Acknowledgments

The authors would like to acknowledge the review and inputs from Mitsuru Maruyama, Katsuhiro Sebayashi, Yuma Ito, and Taisei Tanabe. We partially obtained the research results from NICT's commissioned research No. JPJ012368C03101.

Authors' Addresses

Wataru Mishima
NTT Communications
Japan
Yuta Fukagawa
NTT Communications
Japan