Internet-Draft SR based SFC Control Plane April 2022
Li, et al. Expires 24 October 2022 [Page]
Workgroup:
SPRING Working Group
Internet-Draft:
draft-li-spring-sr-sfc-control-plane-framework-06
Published:
Intended Status:
Informational
Expires:
Authors:
C. Li
Huawei Technologies
A. Sawaf
Saudi Telecom Company
R. Hu
Huawei Technologies
Z. Li
Huawei Technologies

A Framework for Constructing Service Function Chaining Systems Based on Segment Routing

Abstract

Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological sub-paths, called "segments". Segment routing architecture can be implemented over an MPLS data plane as well as an IPv6 data plane.

Service Function Chaining (SFC) provides support for the creation of composite services that consist of an ordered set of Service Functions (SF) that are to be applied to packets and/or frames selected as a result of classification.

SFC can be implemented based on several technologies, such as Network Service Header (NSH) and SR. This document describes a framework for constructing SFC based on Segment Routing. The document reviews the control plane solutions for route distribution of service function instance and service function path, and steering packets into a service function chain.

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 24 October 2022.

Table of Contents

1. Introduction

Segment routing (SR) [RFC8402] is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node by inserting an ordered list of instructions, called segments. When segment routing is deployed on MPLS data plane, it is called SR- MPLS [RFC8660]. When segment routing is deployed on IPv6 data plane, it is called SRv6 [RFC8754].

Service Function Chaining (SFC) [RFC7665] provides an architecture that supports the creation of composite service that consist of an ordered set of Service Functions (SF) that are to be applied to packets and/or frames selected as a result of classification.

SFC can be implemented based on Network Service Header [RFC8300]. In NSH-based SFC, per-SFC state, such as a mapping between Service Path Identifier (SPI) and Service Index (SI) to next-hop forwarding, needs to be maintained on nodes along the Service Function Path(SFP), and it can therefore, be termed as "stateful SFC". [I-D.ietf-bess-nsh-bgp-control-plane] defines the use of BGP as a control plane for networks that support SFC based on NSH and MPLS. The document introduces a new BGP address family called the SFC AFI/SAFI with two route types: Service Function Instance Route (SFIR) and Service Function Path Route (SFPR). An NSH or MPLS based SFC can be constructed based on the information of SFIR and SFPR.

SFC can also be instantiated based on SR. In SR, the forwarding path is explicitly encoded into the packets on the SR source node. In SR-based SFC, an SFC can be represented by a SID list explicitly indicated by the source SR node. The SID in SID list may need to be associated with service information in order to indicate network service, such as Deep Packet Inspection (DPI). Therefore, no per-SFC state needs to be maintained along with the SFP, and it can therefore be termed "stateless SFC".

In order to construct SR-based SFC, several mechanisms are proposed, including the mechanisms of SFIR and SFPR distribution, as well as the mechanism of steering packets into an SFP. This document reviews these solutions to describe a framework for the construction of an SFC system based on Segment Routing.

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

1.2. 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].

2. 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. [I-D.ietf-bess-nsh-bgp-control-plane].

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-segment-routing-te-policy] 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.

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" [I-D.ietf-spring-nsh-sr], since it still maintains per-SFC state on nodes. [I-D.ietf-spring-nsh-sr]describes two modes of operation:

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      |   SFIR    |    SFPR   | Steering policy|
 +-------------------+-----------+-----------+----------------+
 |                   |   BGP     |    BGP    |      BGP       |
 |Stateless          |   BGP-LS  |    PCEP   |      PCEP      |
 |                   |   IGP     |           |                |
 +-------------------+-----------+-----------+----------------+
 |NSH-based SFC      |   BGP     |    BGP    |      BGP       |
 |with SR-based      |           |    PCEP   |                |
 |transport tunnel   |           |           |                |
 |                   |           |           |                |
 |                   |           |           |                |
 +-------------------+-----------+-----------+----------------+
 |SR-based SFC       |   BGP     |    BGP    |      BGP       |
 |with Integrated    |   BGP-LS  |    PCEP   |      PCEP      |
 |NSH Service Plane  |   IGP     |           |                |
 |                   |           |           |                |
 +-------------------+-----------+-----------+----------------+
          Table 1. SR based SFC Control Plane Solutions

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

3.1. 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 [I-D.ietf-idr-bgpls-srv6-ext] and SR-MPLS SID/ Label TLV [I-D.ietf-idr-bgp-ls-segment-routing-ext] 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.

[I-D.ietf-bess-nsh-bgp-control-plane] 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-segment-routing-te-policy]. BGP control plane of SRv6-based SFC still needs to be defined.

IGP extensions are proposed by [I-D.xu-isis-service-function-adv] and [I-D.xu-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 [RFC4971]. 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 [RFC4970] 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.

3.2. 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-segment-routing-te-policy]. The PCEP extension is defined in [I-D.ietf-pce-segment-routing-policy-cp].

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

4. Stateful SR Based SFC

"Stateful SFC" [I-D.ietf-spring-nsh-sr] proposes two modes of SR based SFC:

4.1. 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 [I-D.ietf-bess-nsh-bgp-control-plane] can be used for this mode.

To indicate NSH, an SFF label [I-D.ietf-mpls-sfc-encapsulation] should be inserted as the last label in the label stack in SR-MPLS. The control plane of SFF is also described in [I-D.ietf-bess-nsh-bgp-control-plane]. 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-segment-routing-te-policy]. For SR-based SFC with Integrated NSH Service Plane, there is no control plane solution as yet defined.

4.2. 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 [I-D.ietf-bess-nsh-bgp-control-plane]. 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.

4.3. 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 [I-D.ietf-bess-nsh-bgp-control-plane]. For SR-based SFC with Integrated NSH Service Plane, control plane solution is to be added in other document.

5. IANA Considerations

This document does not require any IANA actions.

6. Security Considerations

This document does not introduce additional security requirements and mechanisms.

7. Acknowledgements

TBA

8. References

8.1. Normative References

[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/info/rfc2119>.
[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/info/rfc8174>.

8.2. Informative References

[I-D.dawra-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-dawra-idr-bgp-ls-sr-service-segments-06, , <https://www.ietf.org/archive/id/draft-dawra-idr-bgp-ls-sr-service-segments-06.txt>.
[I-D.ietf-bess-nsh-bgp-control-plane]
Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. Jalil, "BGP Control Plane for the Network Service Header in Service Function Chaining", Work in Progress, Internet-Draft, draft-ietf-bess-nsh-bgp-control-plane-18, , <https://www.ietf.org/archive/id/draft-ietf-bess-nsh-bgp-control-plane-18.txt>.
[I-D.ietf-idr-bgp-ls-segment-routing-ext]
Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., and M. Chen, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-ls-segment-routing-ext-18, , <https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ls-segment-routing-ext-18.txt>.
[I-D.ietf-idr-bgpls-srv6-ext]
Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., Bernier, D., and B. Decraene, "BGP Link State Extensions for SRv6", Work in Progress, Internet-Draft, draft-ietf-idr-bgpls-srv6-ext-09, , <https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-srv6-ext-09.txt>.
[I-D.ietf-idr-segment-routing-te-policy]
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., Jain, D., and S. Lin, "Advertising Segment Routing Policies in BGP", Work in Progress, Internet-Draft, draft-ietf-idr-segment-routing-te-policy-17, , <https://www.ietf.org/archive/id/draft-ietf-idr-segment-routing-te-policy-17.txt>.
[I-D.ietf-mpls-sfc-encapsulation]
Malis, A. G., Bryant, S., Halpern, J. M., and W. Henderickx, "MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH)", Work in Progress, Internet-Draft, draft-ietf-mpls-sfc-encapsulation-04, , <https://www.ietf.org/archive/id/draft-ietf-mpls-sfc-encapsulation-04.txt>.
[I-D.ietf-pce-segment-routing-policy-cp]
Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. Bidgoli, "PCEP extension to support Segment Routing Policy Candidate Paths", Work in Progress, Internet-Draft, draft-ietf-pce-segment-routing-policy-cp-07, , <https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-07.txt>.
[I-D.ietf-spring-nsh-sr]
Guichard, J. N. and J. Tantsura, "Integration of Network Service Header (NSH) and Segment Routing for Service Function Chaining (SFC)", Work in Progress, Internet-Draft, draft-ietf-spring-nsh-sr-11, , <https://www.ietf.org/archive/id/draft-ietf-spring-nsh-sr-11.txt>.
[I-D.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-05, , <https://www.ietf.org/archive/id/draft-ietf-spring-sr-service-programming-05.txt>.
[I-D.wu-pce-traffic-steering-sfc]
Wu, Q., Dhody, D., Boucadair, M., Jacquenet, C., and J. Tantsura, "PCEP Extensions for Service Function Chaining (SFC)", Work in Progress, Internet-Draft, draft-wu-pce-traffic-steering-sfc-12, , <https://www.ietf.org/archive/id/draft-wu-pce-traffic-steering-sfc-12.txt>.
[I-D.xu-isis-service-function-adv]
Xu, X., Wu, N., Shah, H., and L. M. Contreras, "Advertising Service Functions Using IS-IS", Work in Progress, Internet-Draft, draft-xu-isis-service-function-adv-05, , <https://www.ietf.org/archive/id/draft-xu-isis-service-function-adv-05.txt>.
[I-D.xu-ospf-service-function-adv]
Xu, X., Wu, N., Shah, H., and L. M. Contreras, "Advertising Service Functions Using OSPF", Work in Progress, Internet-Draft, draft-xu-ospf-service-function-adv-02, , <https://www.ietf.org/archive/id/draft-xu-ospf-service-function-adv-02.txt>.
[RFC4970]
Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, , <https://www.rfc-editor.org/info/rfc4970>.
[RFC4971]
Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", RFC 4971, DOI 10.17487/RFC4971, , <https://www.rfc-editor.org/info/rfc4971>.
[RFC7665]
Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, , <https://www.rfc-editor.org/info/rfc7665>.
[RFC8300]
Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, , <https://www.rfc-editor.org/info/rfc8300>.
[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/info/rfc8402>.
[RFC8660]
Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, , <https://www.rfc-editor.org/info/rfc8660>.
[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/info/rfc8754>.

Authors' Addresses

Cheng Li
Huawei Technologies
Ahmed El Sawaf
Saudi Telecom Company
Riyadh
Saudi Arabia
Ruizhao Hu
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Zhenbin Li
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China