A Framework for Constructing
Service Function Chaining Systems Based on Segment RoutingHuawei Technologiesc.l@huawei.comSaudi Telecom CompanyRiyadhSaudi Arabiaaelsawaf.c@stc.com.saHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinahuruizhao@huawei.comHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinalizhenbin@huawei.comSPRING Working GroupSegment 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.Segment routing (SR) 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 . When segment routing is
deployed on IPv6 data plane, it is called SRv6 .Service Function Chaining (SFC) 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 . 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". 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.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.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 RouteSFPR: Service Function Path RouteFurther, this document makes use of the terms defined in and .As per , the architecture of SFC consists of
classifiers, Service Function Forwarders (SFFs), Service Functions (SFs)
and SFC Proxies. This is illustrated in Figure 1.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. .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 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.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. 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" , since it still maintains per-SFC
state on nodes. 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.As describe in , 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 servicesTo associate a segment with a service, service information, such as
Service Function Type (SFT), should be included in segment
distribution. specifies the
extensions to BGP-LS for discovery and advertisement of service
segments to enable setup of service programming paths using Segment
Routing.
extends SRv6 Node SID TLV
and SR-MPLS SID/ Label TLV 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. 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 . BGP control plane
of SRv6-based SFC still needs to be defined.IGP extensions are proposed by and . 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 . 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 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.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 .
The PCEP extension is defined in .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 SFC" proposes two
modes of SR based SFC:NSH-based SFC with SR-based transport tunnelSR-based SFC with Integrated NSH Service PlaneFor NSH-based SFC with SR-based transport tunnel, service
information is maintained by NSH while SR is only used for transport
between SFFs, so
can be used for this mode.To indicate NSH, an SFF label should be inserted as the
last label in the label stack in SR-MPLS. The control plane of SFF is
also described in . For
choosing/configuring SR as the transport tunnel, BGP route of SFF's
BGP Tunnel Encapsulation Attribute Type should be "SR TE Policy Type"
. For SR-based
SFC with Integrated NSH Service Plane, there is no control plane
solution as yet defined.Same as SFIR distribution, SFPR BGP distribution in NSH-based SFC
with SR-based transport tunnel is identical to the mechanism defined
in . PCEP
extension for SFPR distribution can reuse the NSH based SFC extension
defined in . For
SR-based SFC with Integrated NSH Service Plane, control plane solution
is to be added in other documents.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 . For SR-based SFC with
Integrated NSH Service Plane, control plane solution is to be added in
other document.This document does not require any IANA actions.This document does not introduce additional security requirements and
mechanisms.TBA