A Framework for Constructing Service Function Chaining Systems Based on Segment Routing
Internet-Draft draft-li-spring-sr-sfc-control-plane-framework-10
Yuanyang Yin
China Telecom
Guangzhou
China
yinyuany@chinatelecom.cn
Cheng Li
Huawei Technologies
c.l@huawei.com
Ahmed El Sawaf
Saudi Telecom Company
Riyadh
Saudi Arabia
aelsawaf.c@stc.com.sa
Hongyi Huang
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
hongyi.huang@huawei.com
Zhenbin Li
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
lizhenbin@huawei.com
01 March 2024
SPRING Working Group
Segment Routing (SR) introduces a versatile methodology for defining end-to-end network paths by encoding sequences of topological sub-paths, known as "segments". This architecture can be deployed over both MPLS and IPv6 data planes, offering a flexible routing solution.
Service Function Chaining (SFC) supports the establishment of composite services through an ordered sequence of Service Functions (SFs) that are applied to packets or frames based on initial classification. SFC's implementation can utilize various underlying technologies, including the Network Service Header (NSH) and SR, to facilitate the creation and management of service chains.
This document presents a comprehensive control framework for developing SFC architectures using Segment Routing. It explores control plane solutions for the distribution of service function instance routes and service function paths, as well as techniques for directing packets into specific service function chains. The discussion encompasses both theoretical foundations and practical considerations for integrating SR into SFC deployments.
Introduction
Segment Routing (SR), as defined in [RFC8402], introduces a source routing paradigm that assigns a specific forwarding path for packets at the ingress node via an ordered list of directives, known as segments. SR's implementation varies with the underlying data plane: SR-MPLS [RFC8660] for MPLS and SRv6 [RFC8754] for IPv6.
Service Function Chaining (SFC), outlined in [RFC7665], facilitates the assembly of composite services through a sequenced application of Service Functions (SF) on packets or frames, triggered by classification processes.
Network Service Header (NSH) [RFC8300] provides a basis for SFC, enabling a "stateful SFC" by necessitating nodes along the Service Function Path (SFP) to maintain specific SFC states, such as mappings between the Service Path Identifier (SPI) and Service Index (SI) for subsequent forwarding actions. [RFC9015] introduces the use of BGP as a control plane mechanism for SFC architectures utilizing NSH and MPLS. It proposes a new BGP address family, the SFC AFI/SAFI, comprising two route types: Service Function Instance Route (SFIR) and Service Function Path Route (SFPR), facilitating the construction of NSH or MPLS-based SFCs with SFIR and SFPR data.
Alternatively, SFC can leverage SR for instantiation, where the SR source node explicitly embeds the forwarding path into packets. In SR-based SFC, an SFC is denoted by a SID list from the source SR node, potentially linked with service details (e.g., Deep Packet Inspection, DPI), obviating the need for maintaining per-SFC state along the SFP, hence termed "stateless SFC."
To deploy SR-based SFC, this document explores several mechanisms, including the distribution of SFIR and SFPR, as well as packet steering into an SFP. The review aims to establish a comprehensive framework for constructing an SFC system utilizing Segment Routing.
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.
Terminology
MPLS: Multiprotocol Label Switching.
SID: Segment Identifier.
SR: Segment Routing.
SR-MPLS: Segment Routing with MPLS data plane.
SRH: Segment Routing Header.
SFIR: Service Function Instance Route
SFPR: Service Function Path Route
Further, this document makes use of the terms defined in [RFC7665] and [I-D.ietf-spring-sr-service-programming].
Overview of SR Based SFC Control Plane
As per [RFC7665], the architecture of SFC consists of classifiers, Service Function Forwarders (SFFs), Service Functions (SFs) and SFC Proxies. This is illustrated in Figure 1.

                                      +-----+         +-----+   +-----+
                                      |     |         | SFC |   |     |
                                      | SF1 |         |Proxy|---| SF2 |
                                      +-----+         +-----+   +-----+
                                         |               |
    +--------------+                     |               |
    |   Service    |       SFC        +------+        +------+
    |Classification|  Encapsulation   | SFF1 |        | SFF2 |
--->|   Function   |+---------------->|      |--------|      |------->
    |              |                  |      |        |      |
    +--------------+                  +------+        +------+

         SFC-enabled Domain

                      Figure 1. SFC Architecture

In order to construct an SFC, SFIR and SFPR should be distributed to classifiers and SFFs. Also, the rules of steering packets into specific SFPs should be configured at the classifier. [RFC9015].
In SR, a source node can explicitly indicate the forwarding path for packets by inserting an ordered list of instructions. These packet steering policies, known as SR policy, can be installed by a central controller via BGP [I-D.ietf-idr-sr-policy-safi] or other mechanisms.
When SFC is constructed based on SR, SFPR and packet steering rules can be installed by SR policy at the ingress node, which plays the role of classifier in the SFC architecture. In other words, SFPR does not need to be distributed to all the nodes along the SFP. The architecture of SR based SFC is illustrated in Figure 2.

        +-----+                       +-----+         +-----+   +-----+
        |     |                       |     |         | SR  |   |     |
        |SR-C |                       | SF1 |         |Proxy|---| SF2 |
        +-----+                       +-----+         +-----+   +-----+
           |                             |               |
           |                             |               |
    +--------------+                  +------+        +------+
    |              |   SFC Encap/SR   | SFF1/|        | SFF2/|
--->|CF/SR ingress |+---------------->|  SR  |--------|  SR  |------->
    |              |                  |      |        |      |
    +--------------+                  +------+        +------+

         SFC-enabled Domain

                    Figure 2. SR based SFC architecture.

- CF/SR ingress: an SR ingress node plays the role of Classifier in the SFC architecture, and it connects to an SR controller, where the SR policies originate.
- SR-C: SR Controller (SR-C) is connected to the SR ingress node, and may be attached to any node in the network. SR-C is capable of discovering topology, and calculating constrained paths for SFCs.
- SFF/SR nodes: the SFF component in SFC architecture, which enables SR to steer packets to SFs.
- SFn: Service Functions, can be SR-aware or SR-unaware. If an SF is SR-unaware then SR proxy is needed.
- SR proxy: A proxy between SFF/SR nodes and SR-unaware SF.
There are two solutions to encode SFC in the SR data plane. [I-D.ietf-spring-sr-service-programming] defines data plane functionality required to implement service segments and achieve service programming in SR-enabled MPLS and IP networks. It can be termed "Stateless SFC" since no per-SFC state is maintained on the SR nodes along the SFP.
The second solution can be termed "Stateful SFC" [RFC9491], since it still maintains per-SFC state on nodes. [RFC9491]describes two modes of operation:
- NSH-based SFC with SR-based transport tunnel: SR is used as the transport tunnel to route packets between classifier and SFF or SFFs. Service plane routing relies on NSH.
- SR-based SFC with Integrated NSH Service Plane: The SFP is encoded within the SR segment-list, while the NSH only maintains the service plane context information, which will be used at NSH-aware SFs, and at SFFs as a pointer to cache SR segment-lists.
In order to support these data plane encodings, control plane mechanisms are required. The existing control plane mechanisms are shown in Table 1.
SR based SFC Control Plane Solutions
SR based SFC | SFIR | SFPR | Steering policy
Stateless | BGP BGP-LS IGP | BGP PCEP | BGP PCEP
NSH-based SFC with SR-based transport tunnel | BGP | BGP PCEP | BGP
SR-based SFC with Integrated NSH Service Plane | BGP BGP-LS IGP | BGP PCEP | BGP PCEP
Stateless SR Based SFC
As describe in [I-D.ietf-spring-sr-service-programming], service instances are associated with a segment, called a service SID. These service SIDs are leveraged as part of a SID-list to steer packets through the corresponding services
Service Function Instance Route Distribution
To associate a segment with a service, service information, such as Service Function Type (SFT), should be included in segment distribution. [I-D.dawra-idr-bgp-ls-sr-service-segments] specifies the extensions to BGP-LS for discovery and advertisement of service segments to enable setup of service programming paths using Segment Routing. [I-D.dawra-idr-bgp-ls-sr-service-segments] extends SRv6 Node SID TLV [RFC9514] and SR-MPLS SID/ Label TLV [RFC9085] to associate the Service SID Value with Service-related Information using Service Chaining Sub-TLV. The Service Chaining Sub-TLV contains information of Service SID value, Function Identifier (Static Proxy, Dynamic Proxy, Shared Memory Proxy, Masquerading Proxy, SR Aware Service Etc.), Service Type (DPI, Firewall, Classifier, LB etc.), Traffic Type (IPv4 OR IPv6 OR Ethernet) and Opaque Data (such as brand and version, other extra information). This extension works for both SR- MPLS and SRv6.
[RFC9015] proposes a BGP-based SFC control plane solution, and it works for SR-MPLS as well. Service function instance route distribution can use SFIR in SFC AFI/SAFI. SFPR and steering rules for the classifier can be distributed by SR policy, which is defined in [I-D.ietf-idr-sr-policy-safi]. BGP control plane of SRv6-based SFC still needs to be defined.
IGP extensions are proposed by [I-D.xu-lsr-isis-service-function-adv] and [I-D.xu-lsr-ospf-service-function-adv]. In IS-IS solution, SFFs within the SFC domain need to advertise each SF they are offering by using a new sub-TLV of the IS-IS Router CAPABILITY TLV [RFC7981]. This new sub-TLV is called Service Function sub-TLV, and it can appear multiple times within a given IS-IS Router CAPABILITY TLV or when more than one SF needs to be advertised. OSPF extensions are similar, and use the OSPF Router Information (RI) Opaque LSA [RFC7770] to carry Service Function sub-TLV.
However, due to IGP flooding issues, IGP extensions are not very appropriate, and the drafts have expired for a long time.
Service Function Path Route Distribution
With SR, the SFPR does not need to be distributed to nodes along the SFP but only to the ingress node. SFPR and steering rules for the classifier can be distributed by SR policy. The BGP extension is defined in [I-D.ietf-idr-sr-policy-safi]. The PCEP extension is defined in [I-D.ietf-pce-segment-routing-policy-cp].
Steer Packets into SFC
In SR, packet steering rules are learned through SR policy. Thus, there is no need to install other rules in the classifier, which is the SR source node.
Stateful SR Based SFC
"Stateful SFC" [RFC9491] proposes two modes of SR based SFC:
- NSH-based SFC with SR-based transport tunnel
- SR-based SFC with Integrated NSH Service Plane
Service Function Route Distribution
For NSH-based SFC with SR-based transport tunnel, service information is maintained by NSH while SR is only used for transport between SFFs, so [RFC9015] can be used for this mode.
To indicate NSH, an SFF label [RFC8596] should be inserted as the last label in the label stack in SR-MPLS. The control plane of SFF is also described in [RFC9015]. For choosing/configuring SR as the transport tunnel, BGP route of SFF's BGP Tunnel Encapsulation Attribute Type should be "SR TE Policy Type" [I-D.ietf-idr-sr-policy-safi]. For SR-based SFC with Integrated NSH Service Plane, there is no control plane solution as yet defined.
Service Function Path Route Distribution
Same as SFIR distribution, SFPR BGP distribution in NSH-based SFC with SR-based transport tunnel is identical to the mechanism defined in [RFC9015]. PCEP extension for SFPR distribution can reuse the NSH based SFC extension defined in [I-D.wu-pce-traffic-steering-sfc]. For SR-based SFC with Integrated NSH Service Plane, control plane solution is to be added in other documents.
Steer Packets into SFC
For NSH-based SFC with SR-based transport tunnel, it is the same with the NSH based SFC. The Classifier is responsible for determining to which packet flow a packet belongs (usually by inspecting the packet header), imposing an NSH, and initializing the NSH with the SPI of the selected SFP and the SI of its first hop [RFC9015]. For SR-based SFC with Integrated NSH Service Plane, control plane solution is to be added in other document.
IANA Considerations
This document does not require any IANA actions.
Security Considerations
This document does not introduce additional security requirements and mechanisms.
Acknowledgements
Many thanks for Ruizhao Hu's valuable comments and help.
References
Normative References
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
Informative References
[RFC8402]

Segment Routing Architecture
C. Filsfils, Ed.
S. Previdi, Ed.
L. Ginsberg
B. Decraene
S. Litkowski
R. Shakir
July 2018
RFC 8402
DOI 10.17487/RFC8402
[RFC8660]

Segment Routing with the MPLS Data Plane
A. Bashandy, Ed.
C. Filsfils, Ed.
S. Previdi
B. Decraene
S. Litkowski
R. Shakir
December 2019
RFC 8660
DOI 10.17487/RFC8660
[RFC7665]

Service Function Chaining (SFC) Architecture
J. Halpern, Ed.
C. Pignataro, Ed.
October 2015
RFC 7665
DOI 10.17487/RFC7665
[RFC8300]

Network Service Header (NSH)
P. Quinn, Ed.
U. Elzur, Ed.
C. Pignataro, Ed.
January 2018
RFC 8300
DOI 10.17487/RFC8300
[I-D.ietf-spring-sr-service-programming]

Service Programming with Segment Routing
Francois Clad
Cisco Systems, Inc.
Xiaohu Xu
China Mobile
Clarence Filsfils
Cisco Systems, Inc.
Daniel Bernier
Bell Canada
Cheng Li
Huawei
Bruno Decraene
Orange
Shaowen Ma
Mellanox
Chaitanya Yadlapalli
AT&T
Wim Henderickx
Nokia
Stefano Salsano
Universita di Roma "Tor Vergata"
20 February 2024
Internet-Draft draft-ietf-spring-sr-service-programming-09
[I-D.ietf-idr-sr-policy-safi]

Advertising Segment Routing Policies in BGP
Stefano Previdi
Huawei Technologies
Clarence Filsfils
Cisco Systems
Ketan Talaulikar
Cisco Systems
Paul Mattes
Microsoft
Dhanendra Jain
Google
4 February 2024
Internet-Draft draft-ietf-idr-sr-policy-safi-00
[RFC9015]

BGP Control Plane for the Network Service Header in Service Function Chaining
A. Farrel
J. Drake
E. Rosen
J. Uttaro
L. Jalil
June 2021
RFC 9015
DOI 10.17487/RFC9015
[RFC9491]

Integration of the Network Service Header (NSH) and Segment Routing for Service Function Chaining (SFC)
J. Guichard, Ed.
J. Tantsura, Ed.
November 2023
RFC 9491
DOI 10.17487/RFC9491
[I-D.dawra-idr-bgp-ls-sr-service-segments]

BGP-LS Advertisement of Segment Routing Service Segments
Gaurav Dawra
LinkedIn
Clarence Filsfils
Cisco Systems
Ketan Talaulikar
Cisco Systems
Francois Clad
Cisco Systems
Daniel Bernier
Bell Canada
Jim Uttaro
AT&T
Bruno Decraene
Orange
Hani Elmalky
Ericsson
Xiaohu Xu
Capitalonline
Jim Guichard
Futurewei Technologies
Cheng Li
Huawei Technologies
17 August 2021
Internet-Draft draft-dawra-idr-bgp-ls-sr-service-segments-06
[RFC9514]

Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6)
G. Dawra
C. Filsfils
K. Talaulikar, Ed.
M. Chen
D. Bernier
B. Decraene
December 2023
RFC 9514
DOI 10.17487/RFC9514
[RFC9085]

Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing
S. Previdi
K. Talaulikar, Ed.
C. Filsfils
H. Gredler
M. Chen
August 2021
RFC 9085
DOI 10.17487/RFC9085
[I-D.xu-lsr-isis-service-function-adv]

Advertising Service Functions Using IS-IS
Xiaohu Xu
China Mobile
Hongyi Huang
Huawei
Himanshu C. Shah
Ciena
Luis M. Contreras
Telefonica I+D
9 March 2023
Internet-Draft draft-xu-lsr-isis-service-function-adv-00
[I-D.xu-lsr-ospf-service-function-adv]

Advertising Service Functions Using OSPF
Xiaohu Xu
China Mobile
Hongyi Huang
Huawei
Himanshu C. Shah
Ciena
Luis M. Contreras
Telefonica I+D
9 March 2023
Internet-Draft draft-xu-lsr-ospf-service-function-adv-00
[RFC7770]

Extensions to OSPF for Advertising Optional Router Capabilities
A. Lindem, Ed.
N. Shen
JP. Vasseur
R. Aggarwal
S. Shaffer
February 2016
RFC 7770
DOI 10.17487/RFC7770
[RFC7981]

IS-IS Extensions for Advertising Router Information
L. Ginsberg
S. Previdi
M. Chen
October 2016
RFC 7981
DOI 10.17487/RFC7981
[RFC8754]

IPv6 Segment Routing Header (SRH)
C. Filsfils, Ed.
D. Dukes, Ed.
S. Previdi
J. Leddy
S. Matsushima
D. Voyer
March 2020
RFC 8754
DOI 10.17487/RFC8754
[I-D.ietf-pce-segment-routing-policy-cp]

PCEP Extensions for SR Policy Candidate Paths
Mike Koldychev
Cisco Systems, Inc.
Siva Sivabalan
Ciena Corporation
Colby Barth
Juniper Networks, Inc.
Shuping Peng
Huawei Technologies
Hooman Bidgoli
Nokia
9 February 2024
Internet-Draft draft-ietf-pce-segment-routing-policy-cp-14
[RFC8596]

MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH)
A. Malis
S. Bryant
J. Halpern
W. Henderickx
June 2019
RFC 8596
DOI 10.17487/RFC8596
[I-D.wu-pce-traffic-steering-sfc]

PCEP Extensions for Service Function Chaining (SFC)
Qin Wu
Huawei
Dhruv Dhody
Huawei
Mohamed Boucadair
Orange
Christian Jacquenet
Orange
Jeff Tantsura
30 June 2017
Internet-Draft draft-wu-pce-traffic-steering-sfc-12