RFC 7665
Service Function Chaining (SFC) Architecture
Title Block and the Gist ✨
Okay bestie, let's get you set up with the basics first 💖 This RFC is called Service Function Chaining (SFC) Architecture, and it's RFC 7665 🎀
The authors are J. Halpern (Ed.) from Ericsson and C. Pignataro (Ed.) from Cisco 💅 It was published in October 2015, it's Informational (so not a Standards Track spec, just here to share the vibes 🌸), and it doesn't obsolete or update any other RFCs. It's part of the ISSN 2070-1721 series 🦋
Abstract ✨
This doc describes an architecture for specifying, creating, and maintaining Service Function Chains (SFCs) in a network 🧚 It covers the architectural concepts, principles, and components used to build composite services through SFC deployments, with a focus on the stuff that'll be standardized at the IETF 💜 And quick heads-up: it does not propose solutions, protocols, or extensions to existing protocols 🙈
Status of This Memo 📝
This doc is not an Internet Standards Track spec. It's published for informational purposes 🌈
It's a product of the IETF, it represents the consensus of the IETF community, got public review, and was approved for publication by the IESG 🫶 Not every IESG-approved document is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 if you want the deets 💅
For the current status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7665 ✨
Copyright Notice 💖
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved 🎀
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as of the publication date. Read those carefully, bestie, because they spell out your rights and restrictions 🥹 Any Code Components pulled out of this doc have to include Simplified BSD License text (see Section 4.e of the Trust Legal Provisions) and come without warranty, as described in the Simplified BSD License 🔥
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Specification of Requirements . . . . . . . . . . . . . . 5
1.4. Definition of Terms . . . . . . . . . . . . . . . . . . . 6
2. Architectural Concepts . . . . . . . . . . . . . . . . . . . 8
2.1. Service Function Chains . . . . . . . . . . . . . . . . . 8
2.2. Service Function Chain Symmetry . . . . . . . . . . . . . 9
2.3. Service Function Paths . . . . . . . . . . . . . . . . . 10
2.3.1. Service Function Chains, Service Function Paths, and
Rendered Service Path . . . . . . . . . . . . . . . . 11
3. Architecture Principles . . . . . . . . . . . . . . . . . . . 12
4. Core SFC Architecture Components . . . . . . . . . . . . . . 13
4.1. SFC Encapsulation . . . . . . . . . . . . . . . . . . . . 14
4.2. Service Function (SF) . . . . . . . . . . . . . . . . . . 15
4.3. Service Function Forwarder (SFF) . . . . . . . . . . . . 15
4.3.1. Transport-Derived SFF . . . . . . . . . . . . . . . . 17
4.4. SFC-Enabled Domain . . . . . . . . . . . . . . . . . . . 17
4.5. Network Overlay and Network Components . . . . . . . . . 18
4.6. SFC Proxy . . . . . . . . . . . . . . . . . . . . . . . . 18
4.7. Classification . . . . . . . . . . . . . . . . . . . . . 19
4.8. Reclassification and Branching . . . . . . . . . . . . . 19
4.9. Shared Metadata . . . . . . . . . . . . . . . . . . . . . 20
5. Additional Architectural Concepts . . . . . . . . . . . . . . 21
5.1. The Role of Policy . . . . . . . . . . . . . . . . . . . 21
5.2. SFC Control Plane . . . . . . . . . . . . . . . . . . . . 21
5.3. Resource Control . . . . . . . . . . . . . . . . . . . . 22
5.4. Infinite Loop Detection and Avoidance . . . . . . . . . . 23
5.5. Load-Balancing Considerations . . . . . . . . . . . . . . 23
5.6. MTU and Fragmentation Considerations . . . . . . . . . . 24
5.7. SFC OAM . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.8. Resilience and Redundancy . . . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Normative References . . . . . . . . . . . . . . . . . . 29
7.2. Informative References . . . . . . . . . . . . . . . . . 29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 321. Introduction 🌸
Lots of end-to-end services need a bunch of service functions 💅 Think traditional network service functions like firewalls and traditional IP Network Address Translators (NATs), plus application-specific functions too ✨ Defining an ordered set of service functions and then "steering" traffic through them is what's called Service Function Chaining (SFC) 🦋
This doc describes the architecture used to create and keep up Service Function Chains (SFCs) in a network 🧚 It covers the architectural concepts, principles, and components, focusing on the stuff that'll be standardized at the IETF 💜 SFCs make composite services possible, built from one or more service functions 🎀
The issues with deploying end-to-end service function chains are covered in [RFC7498] 📖 That includes abstract sets of service functions, their ordering constraints (which together make a composite service), and the steering of traffic flows through those functions 🫶
Right now, service function deployment models are pretty static 😭 They're tied to network topology and physical resources, which makes it super hard (or impossible) for an operator to roll out new services or spin up service function chains on the fly 💀 This architecture is a model that fixes those problems, like topological independence and configuration complexity 👑
1.1. Scope 🎯
This doc defines the architecture for Service Function Chaining (SFC) as standardized in the IETF 💖 The SFC architecture is built on topological independence from the underlying forwarding topology 🌈
Here's how it goes: packets get classified on ingress so they can be handled by the required set of Service Functions (SFs) in the SFC-enabled domain 🔥 Then they're forwarded through that set of functions, and each function processes them in turn 🦋 Packets can get reclassified as a result of that processing 🌸
This architecture doesn't depend on how the network is planned to be used or on the deployment context 🧚 So it works for fixed and mobile networks, and it's useful in lots of data center applications too 💜
It's assumed to apply to a single network administrative domain 🎀 You could apply the architectural principles and components to inter-domain SFCs, but those are left for future study 🥹
1.2. Assumptions ✨
Here are the assumptions made:
- There's no standard definition or characterization that applies to all SFs, so the architecture treats each SF as an opaque processing element 🫥
- There's no global or standard list of SFs enabled in a given administrative domain 🌍 The set of SFs enabled in a domain depends on the currently active services, which can change over time and with the networking environment 🔄
- There's no global or standard SF chaining logic 🙅♀️ The ordered set of SFs needed to deliver a given service is specific to each administrative entity 🏢
- The chaining of SFs and the criteria to invoke them are specific to each administrative entity that operates an SF-enabled domain 👑
- Several SF chaining policies can be applied at the same time within an administrative domain to meet various business requirements 💅
- The underlay is assumed to give the necessary connectivity to interconnect the Service Function Forwarders (SFFs; see Section 1.4) 🌐 The architecture doesn't constrain how that connectivity is realized, except that it must have the required bandwidth, latency, and jitter to support the SFC 📶
- No assumption is made about how Forwarding Information Bases (FIBs) and Routing Information Bases (RIBs) of involved nodes get populated 🤷♀️
- How to bind traffic to a given SF chain is policy-based 🎀
1.3. Specification of Requirements 📜
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 💜
Part 1 of 7. More parts coming, so stay tuned, bestie 🦋✨
1.4. Definition of Terms 📖
Network Service: okay so a network service is an offering an operator provides, delivered using one or more service functions 💖. It can also be called a "composite service" 🎀. In this document, "service" is used to mean "network service" 💅.
Note: bestie, beyond this document "service" is totally overloaded 🙈. To some people a service is an offering made of several elements inside the operator's network 🌸. For others, a service (or specifically a network service) is a discrete element, like a "firewall" 🔥. Traditionally, services in that second sense host a set of service functions and have a network locator where they're hosted 🧚.
Classification: locally instantiated matching of traffic flows against policy, so the required set of network service functions can be applied afterwards 👑. The policy may be customer/network/service specific 🦋.
Classifier: an element that performs Classification 💅.
Service Function Chain (SFC): an SFC defines an ordered set of abstract service functions and ordering constraints that must be applied to packets and/or frames and/or flows selected as a result of classification 🌈. An example of an abstract service function is "a firewall" 🧱. The implied order may not be a linear progression, because the architecture allows SFCs that copy to more than one branch 🌿. It also allows cases where there's flexibility in the order the service functions need to be applied, which is so iconic 🪄. "Service chain" is often used as shorthand for service function chain ✨.
Service Function (SF): a function responsible for specific treatment of received packets 🫶. An SF can act at various layers of a protocol stack (e.g., at the network layer or other OSI layers) 🌐. As a logical component, an SF can be realized as a virtual element or be embedded in a physical network element 💜. One or more SFs can be embedded in the same network element, and multiple occurrences of the service function can exist in the same administrative domain 🍓.
One or more service functions can be involved in delivering added-value services 💫. A non-exhaustive list of abstract service functions includes: firewalls, WAN and application acceleration, Deep Packet Inspection (DPI), Lawful Intercept (LI), server load balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296], HOST_ID injection, HTTP Header Enrichment functions, and TCP optimizer 🧁.
An SF may be SFC encapsulation aware (meaning it receives and acts on information in the SFC encapsulation) or unaware (meaning data forwarded to the SF doesn't contain the SFC encapsulation) 🎭. These are often referred to as "SFC aware" and "SFC unaware", respectively 🫧.
Service Function Forwarder (SFF): a service function forwarder is responsible for forwarding traffic to one or more connected service functions according to information carried in the SFC encapsulation 🚦. It also handles traffic coming back from the SF 🔁. On top of that, an SFF is responsible for delivering traffic to a classifier when needed and supported, transporting traffic to another SFF (in the same or a different type of overlay), and terminating the Service Function Path (SFP) 🏁.
Metadata: provides the ability to exchange context information between classifiers and SFs, and among SFs 📝.
Service Function Path (SFP): the service function path is a constrained specification of where packets assigned to a certain service function path must go 🛤️. It can be constrained so much that it identifies the exact locations, or it can be less specific 🔍. The SFP provides a level of indirection between the fully abstract notion of a service chain (a sequence of abstract service functions to be delivered) and the fully specified notion of exactly which SFFs/SFs the packet will visit when it actually traverses the network 🪜. By letting the control components specify this level of indirection, the operator may control the degree of SFF/SF selection authority that's delegated to the network 🎛️.
SFC Encapsulation: the SFC encapsulation provides, at a minimum, SFP identification, and it's used by SFC-aware functions, such as the SFF and SFC-aware SFs 📦. The SFC encapsulation is not used for network packet forwarding 🙅. In addition to SFP identification, the SFC encapsulation carries metadata, including data-plane context information 🧠.
Rendered Service Path (RSP): within an SFP, packets themselves are of course transmitted from and to specific places in the network, visiting a specific sequence of SFFs and SFs 🗺️. That sequence of actual visits by a packet to specific SFFs and SFs in the network is known as the Rendered Service Path (RSP) 👣. This definition is included here for use by later documents, such as when solutions may need to discuss the actual sequence of locations the packets visit 📚.
SFC-Enabled Domain: a network or region of a network that implements SFC 🏰. An SFC-enabled domain is limited to a single network administrative domain 🔒.
SFC Proxy: removes and inserts SFC encapsulation on behalf of an SFC-unaware service function 🎁. SFC proxies are logical elements 🪞.
2. Architectural Concepts ✨
The following sections describe the foundational concepts of service function chaining and the SFC architecture 🏗️.
Service function chaining enables the creation of composite (network) services that consist of an ordered set of SFs that must be applied to packets and/or frames and/or flows selected as a result of classification 💎. Each SF is referenced using an identifier that is unique within an SF-enabled domain 🪪.
Service function chaining is a concept that provides for more than just the application of an ordered set of SFs to selected traffic 🙌. Instead, it describes a method for deploying SFs in a way that enables dynamic ordering and topological independence of those SFs, as well as the exchange of metadata between participating entities 🌟.
2.1. Service Function Chains 🔗
In most networks, services are constructed as abstract sequences of SFs that represent SFCs 🧩. At a high level, an SFC is an abstracted view of a service that specifies the set of required SFs as well as the order in which they must be executed 📋. Graphs, as illustrated in Figure 1, define an SFC, where each graph node represents the required existence of at least one abstract SF 📊. Those graph nodes (SFs) can be part of zero, one, or many SFCs 🌀. A given graph node (SF) can appear one time or multiple times in a given SFC 🔂.
SFCs can start from the origination point of the service function graph (i.e., node 1 in Figure 1), or from any subsequent node in the graph 🚀. As shown, SFs may therefore become branching nodes in the graph, with those SFs selecting edges that move traffic to one or more branches 🌳. The top and middle graphs depict such a case, where a second classification event occurs after node 2, and a new graph is selected (i.e., node 3 instead of node 6) 🔀. The bottom graph highlights the concept of a cycle, in which a given SF (e.g., node 7 in the depiction) can be visited more than once within a given service chain 🎡. An SFC can have more than one terminus 🏁.
,-+-. ,---. ,---. ,---.
/ \ / \ / \ / \
( 1 )+--->( 2 )+---->( 6 )+---->( 8 )
\ / \ / \ / \ /
`---' `---' `---' `---'
,-+-. ,---. ,---. ,---. ,---.
/ \ / \ / \ / \ / \
( 1 )+--->( 2 )+---->( 3 )+---->( 7 )+---->( 9 )
\ / \ / \ / \ / \ /
`---' `---' `---' `---' `---'
,-+-. ,---. ,---. ,---. ,---.
/ \ / \ / \ / \ / \
( 1 )+--->( 7 )+---->( 8 )+---->( 4 )+---->( 7 )
\ / \ / \ / \ / \ /
`---' `---' `---' `---' `---'
Figure 1: Service Function Chain GraphsThe concepts of classification, reclassification, and branching are covered in subsequent sections of this architecture (see Sections 4.7 and 4.8) 🧠.
2.2. Service Function Chain Symmetry 🪞
SFCs may be unidirectional or bidirectional 🔄. A unidirectional SFC requires that traffic be forwarded through the ordered SFs in one direction (sf1 -> sf2 -> sf3) 🚆. A bidirectional SFC, on the other hand, requires a symmetric path (sf1 -> sf2 -> sf3 and sf3 -> sf2 -> sf1), and the SF instances are the same in opposite directions 🪄. A hybrid SFC has attributes of both unidirectional and bidirectional SFCs 🌗. That is to say, some SFs require symmetric traffic, whereas other SFs don't process reverse traffic or are independent of the corresponding forward traffic 🫠.
SFCs may contain cycles, which means traffic may need to traverse one or more SFs within an SFC more than once 🎠. Solutions will need to ensure suitable disambiguation for such situations 🧭.
The architectural allowance that's made for SFPs that delegate choice to the network, deciding which SFs and/or SFFs a packet will visit, creates potential issues here 😬. A solution that allows such delegation needs to also describe how it ensures that those service chains requiring service function chain symmetry can achieve that 🫶.
Further, there are state trade-offs in symmetry 🎢. Symmetry may be realized in several ways, depending on the SFF and classifier functionality 🧃. In some cases, "mirrored" classification (i.e., from Source to Destination and from Destination to Source) policy may be deployed 🪞. In others, shared state between classifiers may be used to ensure that symmetric flows are correctly identified, then steered along the required SFP 🤝. At a high level, there are various common cases. In a non-exhaustive way, there can be, for example:
- A single classifier (or a small number of classifiers), in which case both incoming and outgoing flows could be recognized at the same classifier, so the synchronization would be feasible by internal mechanisms internal to the classifier 🏠.
- Stateful classifiers where several classifiers may be clustered and share state 👯.
- Fully distributed classifiers, where synchronization needs to be provided through unspecified means 🌌.
- A classifier that learns state from the egress packets/flows, which is then used to provide state for the return packets/flow 📬.
- Symmetry may also be provided by stateful forwarding logic in the SFF in some implementations 🛠️.
This is a non-comprehensive list of common cases 💜.
2.3. Service Function Paths 💖
Okay so, a Service Function Path (SFP) is basically the mechanism service chaining uses to express the result of applying more granular policy and operational constraints to the abstract requirements of a service chain (SFC). 🦋 This architecture does NOT mandate how specific an SFP has to be, bestie. Within the same SFC-enabled domain, some SFPs can be fully specified, picking exactly which SFF and which SF packets using that SFP are going to visit ✨, while other SFPs can be super vague and just defer to the SFF on the exact sequence of steps used to realize the SFC 💅. The specificity can be anywhere in between those extremes. It's giving flexibility 🌈
As an example of that in-between vibe 🎀, there could be two SFPs tied to one SFC. One SFP says any order of SFF and SF is fine as long as it stays within Data Center 1, and the second SFP gives the same latitude but only within Data Center 2. 🏢🍓
So the policies and logic of SFP selection or creation (depending on the solution) basically produce a constrained version of the original SFC 🧚. And since multiple policies can apply to different traffic that uses the same SFC, it also follows that a single SFC can have multiple SFPs associated with it. Main character energy for sure 👑
The architecture lets the same SF be reachable through multiple SFFs 🦋. In those cases, some SFPs can constrain which SFF is used to reach which SF, while others leave that decision up to the SFF itself 💜.
Further, the architecture allows two or more SFs to be attached to the same SFF, and possibly connected through internal means that allow more effective communication 🫶. In these cases, some solutions or deployments might use some form of internal inter-process or inter-VM messaging (communication behind the virtual switching element) that is optimized for that environment ⭐. This MUST be coordinated with the SFF so it can properly do its job 🔥. The implementation details of these mechanisms are out of scope for this document 🙈, and they can span a whole spectrum of methods: for example, situations that list all next-hops explicitly 📋, others where a list of possible next-hops is provided and the selection is local 🧭, or cases with just an identifier where all resolution is local 🌸.
This architecture also allows the same SF to be part of multiple SFPs 💅✨.
2.3.1. Service Function Chains, Service Function Paths, and Rendered Service Path 🎀
Let's do an example of this progressive refinement, okay? 🦋 Consider a Service Function Chain (SFC) that says packets using this chain should be delivered to a firewall and a caching engine 🔥.
A Service Function Path (SFP) can refine that, and remember this architecture does NOT mandate how specific an SFP has to be 💅. It might specify that the firewall and caching engine are both in a specific data center (e.g., in DC1) 🏢, or it might specify exactly which instance of each firewall and caching engine gets used 🎯.
The Rendered Service Path (RSP) is the actual sequence of SFFs and SFs the packets will really visit 🧚. So if the SFP picked the DC, the RSP would be more specific 💜. Literally the most zoomed-in version 🔍✨
3. Architecture Principles 🌈
Service function chaining is predicated on several key architectural principles, and honestly they're all iconic 👑:
- Topological independence: No changes to the underlay network forwarding topology -- implicit, or explicit -- are needed to deploy and invoke SFs or SFCs. 🌸
- Plane separation: Dynamic realization of SFPs is separated from packet handling operations (e.g., packet forwarding). 🦋
- Classification: Traffic that satisfies classification rules is forwarded according to a specific SFP. For example, classification can be as simple as an explicit forwarding entry that forwards all traffic from one address into the SFP. Multiple classification points are possible within an SFC (i.e., forming a service graph), thus enabling changes/updates to the SFC by SFs. 💅
Classification can occur at varying degrees of granularity; for example, classification can use a 5-tuple, a transport port or set of ports, part of the packet payload, it can be the result of high-level inspections, or it can come from external systems. 🔍
- Shared Metadata: Metadata/context data can be shared amongst SFs and classifiers, between SFs, and between external systems and SFs (e.g., orchestration). 🫶
One use of metadata is to provide and share the result of classification (that occurs within the SFC-enabled domain, or external to it) along an SFP. For example, an external repository might provide user/subscriber information to a service chain classifier. This classifier could in turn impose that information in the SFC encapsulation for delivery to the requisite SFs. The SFs could in turn utilize the user/subscriber information for local policy decisions. Metadata can also share SF output along the SFP. ✨
- Service definition independence: The SFC architecture does not depend on the details of SFs themselves. 🧚
- Service function chain independence: The creation, modification, or deletion of an SFC has no impact on other SFCs. The same is true for SFPs. 💖
- Heterogeneous control/policy points: The architecture allows SFs to use independent mechanisms (out of scope for this document) to populate and resolve local policy and (if needed) local classification criteria. 🎀
4. Core SFC Architecture Components 🧩
The SFC Architecture is built out of architectural building blocks that are logical components 💜: classifiers, Service Function Forwarders (SFFs), the Service Functions (SFs) themselves, and SFC proxies. While this architecture describes functionally distinct logical components and promotes transport independence, they could be realized and combined in various ways in deployed products, and could be combined with an overlay 🦋.
They are interconnected using the SFC encapsulation. This results in a high-level logical architecture of an SFC-enabled domain that comprises:
o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. +--------------+ +------------------~~~
. | Service | SFC | Service +---+ +---+
. |Classification| Encapsulation | Function |sf1|...|sfn|
+---->| Function |+---------------->| Path +---+ +---+
. +--------------+ +------------------~~~
. SFC-enabled Domain
o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 2: Service Function Chain ArchitectureThe following subsections provide details on each logical component that form the basis of the SFC architecture. A detailed overview of how some of these architectural components interact is provided in Figure 3:
+----------------+ +----------------+
| SFC-aware | | SFC-unaware |
|Service Function| |Service Function|
+-------+--------+ +-------+--------+
| |
SFC Encapsulation No SFC Encapsulation
| SFC |
+---------+ +----------------+ Encapsulation +---------+
|SFC-Aware|-----------------+ \ +------------|SFC Proxy|
| SF | ... ----------+ \ \ / +---------+
+---------+ \ \ \ /
+-------+--------+
| SF Forwarder |
| (SFF) |
+-------+--------+
|
SFC Encapsulation
|
... SFC-enabled Domain ...
|
Network Overlay Transport
|
_,....._
,-' `-.
/ `.
| Network |
`. /
`.__ __,-'
`''''
Figure 3: SFC Architecture Components After Initial ClassificationPlease note that the depiction in Figure 3 shows packets after initial classification, and therefore includes the SFC encapsulation. Although not included in Figure 3, the classifier is an SFC architectural component. 🔍
4.1. SFC Encapsulation 🎁
The SFC encapsulation enables service function path selection. It also enables the sharing of metadata/context information when such metadata exchange is required 🫶.
The SFC encapsulation carries explicit information used to identify the SFP. However, the SFC encapsulation is NOT a transport encapsulation itself: it is not used to forward packets within the network fabric 🙅♀️. If packets need to flow between separate physical platforms, the SFC encapsulation relies on an outer network transport. Transit forwarders -- such as router and switches -- forward SFC encapsulated packets based on the outer (non-SFC) encapsulation 🚚.
One of the key architecture principles of SFC is that the SFC encapsulation remain transport independent. As such, any network transport protocol MAY be used to carry the SFC encapsulated traffic 💖.
4.2. Service Function (SF) 🧚
The concept of an SF evolves; rather than being viewed as a bump in the wire, an SF becomes a resource within a specified administrative domain that is available for consumption as part of a composite service ✨. SFs send/receive data to/from one or more SFFs. SFC-aware SFs receive this traffic with the SFC encapsulation 🦋.
While the SFC architecture defines the concept and specifies some characteristics of a new encapsulation -- the SFC encapsulation -- and several logical components for the construction of SFCs, existing SF implementations may not have the capabilities to act upon or fully integrate with the new SFC encapsulation. In order to provide a mechanism for such SFs to participate in the architecture, an SFC proxy function is defined (see Section 4.6) 🎀. The SFC proxy acts as a gateway between the SFC encapsulation and SFC-unaware SFs. The integration of SFC-unaware service functions is discussed in more detail in the SFC proxy section 💅.
This architecture allows an SF to be part of multiple SFPs and SFCs 👑.
4.3. Service Function Forwarder (SFF) 💅
okay so the SFF is the one doing the forwarding work 🚚 It takes packets and/or frames from the network and sends them to one or more SFs tied to that SFF, using the info in the SFC encapsulation. Then the traffic from the SFs comes back to the same SFF, which is the one that puts it back onto the network. Some SFs, like firewalls, could also just consume a packet 🧱💀
All the SFFs and their SFs together make a service-plane overlay 🦋 and both SFC-aware SFs and SFC-unaware SFs live in there. Inside this service plane, the SFF is what connects the different SFs that form a service function path. Main character energy ✨
SFFs keep the SFP forwarding info they need 📚 That info is tied to a service path identifier, which is how you uniquely identify an SFP. The service forwarding state lets an SFF figure out which SFs of a given SFP should be applied, and in what order, as traffic flows through that SFP. Now, even if it looks like the SFF only has one way to deliver a given SF, there might be multiple choices that the SFP constraints still allow 🌈
If there are multiple choices, the SFF has to keep all packets of a given flow handled the same way 🫶 because the SF may well be stateful, and that's a whole mood. The SFF can also keep handling consistent based on other stuff on top of a flow, like a subscriber, session, or application instance identification 🎀
The SFF also has the info it needs to forward packets to the next SFF after applying its local service functions 🌸 Again, there might only be one option, but the architecture lets there be multiple choices for the next SFF. Just like with SFs, the solution needs to make sure the behavior for specific flows (see the Rendered Service Path) stays stable 🔒 Choosing available SFs and next SFFs can get interwoven when one SFF supports multiple distinct service functions and the same service function is available at multiple SFFs. Solutions need to be clear about what's allowed in these cases 📝
Even when the SFF does use multiple choices, whether to go with flow-specific mechanisms or coarser-grained ones to keep specific flows stable is up to the specific solutions and implementations 🧁
The SFF component has the following primary responsibilities:
- SFP forwarding: Traffic arrives at an SFF from the network. The SFF figures out the appropriate SF to send the traffic to using info in the SFC encapsulation. After SF processing, the traffic goes back to the SFF and, if needed, gets forwarded to another SF tied to that SFF. If there's another non-local (i.e., different SFF) hop in the SFP, the SFF further encapsulates the traffic in the appropriate network transport protocol and delivers it to the network so it can reach the next SFF on the path 🚀 Related to this forwarding job, an SFF should be able to interact with metadata 🏷️
- Terminating SFPs: An SFC is completely executed when traffic has gone through all the required SFs in a chain 🏁 When traffic reaches the SFF after the last SF has finished with it, the final SFF knows from the service forwarding state that the SFC is complete. The SFF removes the SFC encapsulation and sends the packet back to the network for forwarding 👑
- Maintaining flow state: In some cases, the SFF may be stateful 🧠 It creates flows and stores flow-centric info. This state can be used for a range of SFP-related tasks, like making sure all packets in a given flow get consistent treatment, ensuring symmetry, or for state-aware SFC Proxy functionality (see Section 4.8) 💜
4.3.1. Transport-Derived SFF 🛤️
SFP forwarding, as described above, directly depends on using the service path info in the SFC encapsulation 📦 But existing implementations might not be able to act on the SFC encapsulation. These platforms can choose to use existing transport info, if it can be arranged, to provide explicit service path info 🧩
This still gives the same architectural behavior and meaning for SFP forwarding and service function paths ✨ It's the responsibility of the control components to make sure the transport path that gets executed in this case is fully aligned with the path identified by the info in the service chaining encapsulation 🎯
4.4. SFC-Enabled Domain 🏰
Specific features might need to be enforced at the boundaries of an SFC-enabled domain, for example to avoid leaking SFC info 🚧 Using the term "node" to refer generically to an entity that performs a set of functions, in this context an SFC boundary node is a node that connects one SFC-enabled domain to a node that's either located in another SFC-enabled domain or in a domain that's SFC-unaware 🌉
An SFC boundary node can act as egress or ingress 🔁 An SFC Egress Node is an SFC boundary node that handles traffic leaving the SFC-enabled domain it belongs to. Such a node is required to remove any info specific to the SFC Domain, typically the SFC encapsulation 🧹 Also, from a privacy perspective, an SFC Egress Node is required to make sure any sensitive info added as part of SFC gets removed 🔐 In this context, info may be sensitive because of network concerns or end-customer concerns 👀 An SFC Ingress Node is an SFC boundary node that handles traffic entering the SFC-enabled domain 🚪 In most solutions and deployments this will need to include a classifier, and it'll be responsible for adding the SFC encapsulation to the packet 🏷️
An SFC Proxy and its corresponding SFC-unaware service function (see Figure 3) are inside the SFC-enabled domain 🫧
4.5. Network Overlay and Network Components 🌐
Underneath the SFF there are components responsible for performing the transport (overlay) forwarding 🛣️ They don't consult the SFC encapsulation or inner payload for this forwarding. They only consult the outer-transport encapsulation for transport (overlay) forwarding 🙈
4.6. SFC Proxy 🪞
So for the SFC architecture to support SFC-unaware SFs (e.g., legacy service functions), a logical SFC proxy function may be used 🧓 This function sits between an SFF and one or more SFs that the SFF is directing traffic to (see Figure 3) 🧚
The proxy accepts packets from the SFF on behalf of the SF 🤝 It removes the SFC encapsulation, and then uses a local attachment circuit to deliver packets to SFC-unaware SFs. It also receives packets back from the SF, reapplies the SFC encapsulation, and returns them to the SFF for processing along the service function path 🔄
So from the SFF's point of view, the SFC proxy looks like part of an SFC-aware SF 👀
Communication details between the SFF and the SFC Proxy are the same as those between the SFF and an SFC-aware SF. The details of that aren't part of this architecture 📭 The details of the communication methods over the local attachment circuit between the SFC proxy and the SFC-unaware SF depend on the specific behaviors and capabilities of that SFC-unaware SF, so they're also out of scope for this architecture 🙅♀️
Specifically, for traffic received from the SFF that's intended for the SF the proxy is representing, the SFC proxy:
- Removes the SFC encapsulation from SFC encapsulated packets. 🧼
- Identifies the required SF to be applied based on available info, including that carried in the SFC encapsulation. 🔍
- Selects the appropriate outbound local attachment circuit through which the next SF for this SFP is reachable. This is derived from the identification of the SF carried in the SFC encapsulation, and it may include local techniques. Examples of a local attachment circuit include, but are not limited to, VLAN, IP-in-IP, Layer 2 Tunneling Protocol version 3 (L2TPv3), Generic Routing Encapsulation (GRE), and Virtual eXtensible Local Area Network (VXLAN) 🛤️
- Forwards the original payload via the selected local attachment circuit to the appropriate SF. 📨
When traffic is returned from the SF:
- Applies the required SFC encapsulation. The determination of the encapsulation details may be inferred by the local attachment circuit through which the packet and/or frame was received, via packet classification, or through other local policy. In some cases, packet ordering or modification by the SF may necessitate additional classification in order to reapply the correct SFC encapsulation 🎁
- Delivers the packet with the SFC encapsulation to the SFF, just like what would happen with packets returned from an SFC-aware SF 💌
4.7. Classification 🎯
Traffic from the network that satisfies classification criteria gets directed into an SFP and forwarded to the requisite service function(s) 🚦 Classification is handled by a service classification function, and the initial classification happens at the ingress to the SFC domain 🛂 How granular the initial classification is depends on the capabilities of the classifier and the requirements of the SFC policy 🔎 For instance, classification might be relatively coarse: all packets from this port are subject to SFC policy X and directed into SFP A 🚪 Or it might be quite granular: all packets matching this 5-tuple are subject to SFC policy Y and directed into SFP B 🔬
As a consequence of the classification decision, the appropriate SFC encapsulation is imposed on the data, and a suitable SFP is selected or created 🧵 Classification results in attaching the traffic to a specific SFP 📌
4.8. Reclassification and Branching 🌿
The SFC architecture supports reclassification (or non-initial classification) as well 🙌 As packets traverse an SFP, reclassification may occur -- typically performed by a classification function co-resident with a service function 🔀 Reclassification may result in selecting a new SFP, updating the associated metadata, or both 🆕 This is referred to as "branching" 🌳
For example, an initial classification results in the selection of SFP A: DPI_1 --> SLB_8. But when the DPI service function runs, attack traffic is detected at the application layer 🚨 DPI_1 reclassifies the traffic as attack and alters the service path to SFP B, which includes a firewall for policy enforcement, dropping the traffic: DPI_1 --> FW_4. After FW_4, surviving traffic would be returned to the original SFF 🧯 In this simple example, the DPI service function reclassifies the traffic based on local application layer classification capabilities that weren't available during the initial classification step 🧠✨
When traffic arrives after being steered through an SFC-unaware SF, the SFC Proxy must perform reclassification of the traffic to determine the SFP 🫠 The SFC Proxy is concerned with re-attaching info for SFC-unaware SFs, and a stateful SFC Proxy simplifies this classification to a flow lookup 💖
4.9. Shared Metadata 💖
okay so sharing metadata is literally how the network and the SFs get to gossip 🫢 the network can hand useful info to the SFs, SFs can pass info to each other, and service-derived info can go back to the network. some SFCs don't need any metadata exchange at all, which is totally fine 🌸 the SFC infrastructure is what makes this shared data possible along the SFP ✨ metadata has a few main jobs:
- lets elements that normally operate independently (e.g., as "ships in the night") actually talk to each other 🚢💕
- encodes info about the network and/or the data so it can be used later on in the SFP 🧠
- creates an identifier that SFs can use for policy binding 🎀
context info can come from a few places:
- external sources 🌍
- network node classification 🖥️
- service function classification 🧚
5. Additional Architectural Concepts 🦋
there are a bunch of issues that solutions need to deal with, and the architecture gives them direction without making every call for them 💅 this section walks through some of those concepts, bestie 🫶
5.1. The Role of Policy 👑
ngl a LOT of how service chains behave comes down to operator and per-customer policy 📋 this architecture is built so that policy stuff stays separate from the data plane and the control logic 🙌
so the assumption is that the service chaining control plane is the one that creates the service paths 🛤️ and the service chaining data plane is what delivers classified packets along those chains to the right service functions 📦
policy shows up in other places too 👀 policies and policy engines can keep an eye on service functions to decide whether more (or fewer) instances are needed 📈 when that happens, those decisions can nudge the control logic into changing SFP placement or packet classification rules 🔄
operator service policy, usually handled by Operations or Business Support Systems (OSS or BSS), is a big one too 🏢 it often decides which service functions are even available 🧰 it also decides which sequences of functions are valid and which ones get used or offered 🔗
then there's offering service chains to customers and letting them pick one 💁♀️ that's driven by a mix of operator and customer policies, using the right portals together with the OSS and BSS tools 🪄 those picks then feed into the service chaining control logic, which sets up the correct packet classification rules 🎯
5.2. SFC Control Plane 🧠
the SFC control plane is part of the overall SFC architecture, and this section just gives you the high-level functions 🫶 the detailed definition of the SFC control plane is out of scope for this document, so don't look for it here 🙈
the control plane is in charge of building SFPs 🏗️ translating SFCs into forwarding paths ➡️ and passing path info to participating nodes so they can get the forwarding behavior needed to build the service overlay 🌸 for example, an SFC construction can be static, where you pick exactly which SFFs and which SFs from those SFFs to use 📌 or it can be dynamic, where the network makes some or all of those SFF or SF choices itself to deliver the selected service chain within the constraints the service path represents 🦋
in the SFC architecture, SFs are treated as resources 💎 the control plane manages and communicates their capabilities, availability, and location in ways that fit the transport and SFC operations being used 📡 the control plane is also the one responsible for creating the context (more on that below) 🧩 it can be distributed (using new or existing control-plane protocols), centralized, or a mix of both ✨
the SFC control plane provides the following functionality:
- a whole-SFC-enabled-domain view of every available service function resource, plus the network locators they can be reached through 🗺️
- uses SFC policy to build service function chains and their associated SFPs 🛠️
- selects specific SFs for a requested SFC, either statically (using specific SFs) or dynamically (using service explicit SFs at the moment traffic gets delivered to them) 🎯
- provides the SFC data-plane info needed by the SFC architecture components, especially the SFF 💌
- provides the metadata and usage info classifiers need, so they can in turn supply that metadata for the right packets in the data plane 🏷️
- when needed, provides information (including policy information) to other SFC elements so they can correctly interpret metadata 📖
5.3. Resource Control 🧃
the SFC system may be responsible for managing all the resources the SFC components need to function 🛠️ that includes network constraints used to plan and choose network path(s) between service function forwarders, the communication paths between SFFs and their attached SFs 🛣️ and the characteristics of the nodes themselves, like memory, number of virtual interfaces, routes, and the instantiation, configuration, and deletion of SFs 💻
the SFC system will also be required to reflect policy decisions about resource control, as expressed by other components in the system 📣
all of these are part of the big picture, but they're beyond the scope of this architecture 🙃
5.4. Infinite Loop Detection and Avoidance 🔁
this SFC architecture is built on being topologically independent from the underlying forwarding topology 🗺️ so a service topology gets created by service function paths, or by the local decisions of the service function forwarders based on the constraints in the SFP 🧩 because of the overlay constraints, the packet-forwarding path may need to visit the same SFF multiple times, and in some less common cases it may even need to visit the same SF more than once 🌀 the Service Chaining solution needs to allow these limited, policy-compliant loops 💜 but solutions also have to make sure that indefinite and unbounded loops can't form, because those would eat up unbounded resources without delivering any value 💀
so basically, this architecture requires the solution to prevent infinite service function loops, even when service functions get invoked multiple times in the same SFP 🛑
5.5. Load-Balancing Considerations ⚖️
supporting function elasticity and high availability shouldn't overly complicate SFC or cause unnecessary scalability problems 🌈
in the simplest case, there's only one function in the SFP (the next hop is either the destination address of the flow or the appropriate next hop to that destination), and honestly you could argue there's no need for SFC at all 🤷♀️
when the classifier is separate from the single function, or a function at the terminal address needs a sub-prefix (finer-grained address info) or per-subscriber metadata, there's still just one SFP (the metadata changes but the SFP doesn't), no matter how many potential terminal addresses the flow has 🧁 this is the simple load balancer case, and you can see it in Figure 4 🦋
+---+ +---++--->web server
source+-->|sff|+-->|sf1|+--->web server
+---+ +---++--->web server
Figure 4: Simple Load Balancingby extrapolation, if the intermediary functions within a chain had similar "elastic" behaviors, we don't need separate chains to handle that 🙌 as long as the traffic comes back together at a common next hop after the point of elasticity, we're good 🫶
Figure 5 shows a chain of five service functions between the traffic source and its destination 🔗
+---+ +---+ +---+ +---+ +---+ +---+
|sf2| |sf2| |sf3| |sf3| |sf4| |sf4|
+---+ +---+ +---+ +---+ +---+ +---+
| | | | | |
+-----+-----+ +-----+-----+
| |
+ +
+---+ +---+ +---+ +---+ +---+
source+-->|sff|+-->|sff|+--->|sff|+--->|sff|+-->|sff|+-->destination
+---+ +---+ +---+ +---+ +---+
+ + +
| | |
+---+ +---+ +---+
|sf1| |sf3| |sf5|
+---+ +---+ +---+
Figure 5: Load Balancingthis would be represented as one service function path: sf1 -> sf2 -> sf3 -> sf4 -> sf5 🛤️ the SFF is a logical element, and it may be made up of one or multiple components 🧩 in this architecture, the SFF may handle load distribution based on policy 🎀
you can also see that the same service function may be reachable through multiple SFFs, as discussed earlier 👀 choosing which SFF to use to reach sf3 may be done by the control logic when defining the SFP, or it may be left to the SFFs themselves, depending on policy, solution, and deployment constraints 🤔 if it's left to the SFFs, then it needs to be assured that exactly one SFF takes responsibility for steering traffic through sf3 💁♀️ one boss only, periodt 👑
5.6. MTU and Fragmentation Considerations 📦
this architecture says that extra info has to be added to packets to identify service function paths, and often to carry metadata too 🏷️ it also expects transport info to be added so packets can travel along service function paths, at least between service function forwarders 🚚 all that added info makes packets bigger for service chaining, and those additions could push packet size past the MTU supported on some or all of the media in the service chaining domain 😬
that kind of size increase can cause real operational MTU problems 🥺 requiring fragmentation and reassembly in an SFF would be a massive processing increase, and it might be impossible with some transports 💀 expecting service functions to deal with packets fragmented by the SFC function might be a lot to ask, even when fragmentation is possible 😭 so at the very least, solutions need to pay attention to the size cost of their approach ⚠️ there may be other or additional means available, but any solution needs to weigh the trade-offs ⚖️
these considerations apply to any generic architecture that increases the header size, not just this one 📏
there are also more specific MTU considerations: effects on Path MTU Discovery (PMTUD), plus deployment considerations 🔍 deployments within a single administrative control, or even a single data center complex, have more flexibility for dealing with larger packets, and can deploy existing mitigations that lower the likelihood of fragmentation or discard 🏰✨
Okay bestie, picking up right where we left off ✨
5.7. SFC OAM 🔍
Operations, Administration, and Maintenance (OAM) tools are literally part of the architecture 💖
OAM tools are an integral part of the architecture, no cap 🫶 They do a bunch of jobs, including fault detection and isolation, and performance management. For example, there are so many perks to SFP liveness detection: status reporting, support for resiliency operations and policies, and an enhanced ability to balance load. It's giving main character energy 💅
Service function paths build a services topology, and OAM does its thing inside that service layer 🌈 SFC OAM also follows the same architectural principles as SFC in general. For example: topological independence (which includes being able to run OAM over various overlay technologies) and classification-based policy. Iconic, right? 🦋
We can split the SFC OAM architecture into two parts:
- In-band: OAM packets follow the same path and share fate with user packets, within the service topology. They also follow the architectural principle of consistent policy identifiers, and they use the same path IDs as the service chain data packets. Load balancing and SFC encapsulation with packet forwarding are especially important here 🎀
- Out-of-band: Reporting that goes beyond the actual data plane. An additional layer beyond the data-plane OAM allows for extra alerting and measurements 🔥
This architecture prescribes end-to-end SFP OAM functions, which implies that SFF has to understand whether an in-band packet is an OAM packet or a user packet 👀 However, service function validation is outside the scope of this architecture, and application-level OAM is not something this architecture prescribes. Not me saying "that's a different vibe" 🙈
Some of the detailed functions SFC OAM performs include: fault detection and isolation in a service function path or a service function; verification that connectivity using SFPs is both effective and directing packets to the intended service functions; service path tracing; diagnostic and fault isolation; alarm reporting; performance measurement; locking and testing of service functions; validation with the control plane (see Section 5.2); and also allowing for vendor-specific as well as experimental functions. SFC should leverage and, if needed, extend relevant existing OAM mechanisms ✨ Glow-up era for OAM, periodt 🧚
5.8. Resilience and Redundancy 🛡️
Failing gracefully is the whole move 💅
As a practical operational requirement, any service chaining solution needs to be able to respond effectively, and usually very quickly, to failure conditions. These might be failures of connectivity in the network between SFFs, failures of SFFs, or failures of SFs. Per-SF state (like stateful-firewall state, for example) is the responsibility of the SF, and this architecture doesn't address it 🙌
There are multiple techniques for this. Solutions can describe both what they require and what they allow to address failure. Solutions can make use of flexible specificity of service function paths, if the SFF can be given enough information in a timely fashion to do this 🌸 Solutions can also use MAC- or IP-level redundancy mechanisms such as Virtual Router Redundancy Protocol (VRRP). And particularly for SF failures, load balancers co-located with the SFF, or as part of the service function delivery mechanism, can provide that robustness 💜
Similarly, operational requirements imply resilience in the face of load changes. Mechanisms for managing virtual machines (for example monitoring, instantiating, loading images, providing configuration to SFC control, deleting, and so on) are out of scope for this architecture 🫠 But solutions can be aided by describing how they make use of scaling mechanisms, and they totally are 🍓
6. Security Considerations 🔐
Please read this part, it's serious bestie 😭
The architecture described here is different from the current model, and moving to the new model could lead to different security arrangements and modeling. In the SFC architecture, a relatively static, topologically-dependent deployment model is replaced with chaining of sets of service functions. This can change the flow of data through the network, so the security and privacy considerations of the protocol and deployment will need to be reevaluated in light of the new model 💀
Security considerations apply to the realization of this architecture, in particular to the documents that will define protocols. Such realizations ought to provide means to protect against security and privacy attacks in the areas described here 🛡️
Building from the categorization of [RFC7498], we can largely divide the security considerations into four areas:
Service Overlay: Underneath the service function forwarders, the components responsible for transport forwarding consult the outer-transport encapsulation for underlay forwarding. Transport mechanisms used should satisfy the security requirements of the specific SFC deployment. These requirements typically include varying degrees of traffic separation and protection against different attacks (e.g., spoofing, man-in-the-middle, brute-force, or insertion attacks). They can also include authenticity and integrity checking, and/or confidentiality provisions, for both the network overlay transport and the traffic it encapsulates 🌊
Boundaries: Specific requirements may need to be enforced at the boundaries of an SFC-enabled domain. These include, for example, avoiding leaks of SFC information and protecting the borders against various forms of attacks. If untrusted parties can inject packets that will be treated as properly classified for service chaining, there is a large range of attacks that can be mounted against the resulting system. Depending on deployment details, these likely include spoofing packets from users and creating DDoS and reflection attacks of various kinds 🚨 So, when transport mechanisms are selected for use with SFC, they MUST ensure that outside parties cannot inject SFC packets that will be accepted for processing into the domain. This border security MUST include any tunnels to other domains. If those tunnels are to be used for SFC without reclassification, then the tunnel MUST include additional techniques to ensure the integrity and validity of such packets 🔒
Classification: Classification is used at the ingress edge of an SFC-enabled domain. Policy for this classification is done using a plurality of methods, and whatever method is used needs to consider a range of security issues. These include appropriate authentication and authorization of classification policy, potential confidentiality issues of that policy, protection against corruption, and proper application of policy with needed segregation of application. This includes proper controls on the policies that drive the application of the SFC encapsulation and associated metadata to packets. Similar issues need to be addressed if classification is performed within a service chaining domain, i.e., reclassification 🕵️♀️
SFC Encapsulation: The SFC encapsulation provides, at a minimum, SFP identification, and carries metadata. An operator may consider the SFC Metadata as sensitive. From a privacy perspective, a user may be concerned about the operator revealing data about (and not belonging to) the customer. Therefore, solutions should consider whether there is a risk of sensitive information slipping out of the operator's control. Issues of information exposure should also consider flow analysis. Further, when a specific metadata element is defined, it should be carefully considered whether origin authentication is needed for it 👀
A classifier may have privileged access to information about a packet, or inside a packet (see Section 3, item 4, and Section 4.9), that is then communicated in the metadata. The threat of leaking this private data needs to be mitigated [RFC6973]. As one example, if private data is represented by an identifier, then a new identifier can be allocated, such that the mapping from the private data to the new identifier is not broadly shared 🫣
Some metadata added to and carried in SFC packets is sensitive for various reasons, including potentially revealing personally identifying information. Realizations of the architecture MUST protect such information so that it is handled with suitable care and precautions against inappropriate dissemination. This can have implications for the data plane, the control plane, or both. Data-plane protocol definitions for SFC can include suitable provisions to protect such information for use when handling sensitive information, with packet or SFP granularity. Equally, the control mechanisms used with SFC can have provisions to determine that such mechanisms are available, and to ensure that they are used when needed. Inability to do so needs to result in error indications to appropriate management systems. In particular, when the control systems know that sensitive information may potentially be added to packets at certain points on certain service chains, the control mechanism MUST verify that appropriate protective treatment of NSH information is available from the point where the information is added to the point where it will be removed. If such mechanisms are unavailable, error notifications SHOULD be generated 🚫
Additionally, SFC OAM functions need to not negatively affect the security considerations of an SFC-enabled domain 💅
Finally, all entities (software or hardware) interacting with the service chaining mechanisms need to provide means of security against malformed or poorly configured (deliberate or not) protocol constructs and loops. These considerations are largely the same as those in any network, particularly an overlay network. Stay safe out there, bestie 🫶
7. References 📚
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.Almost there, we've got a few more parts to go 🌈💜
7.2. Informative References ✨
Okay, now the fun reading list 📚 These are the extra docs the spec points to for background. Here they are, exactly as written:
[Boucadair2014]
Boucadair, M., Jacquenet, C., Parker, R., Lopez, D.,
Guichard, J., and C. Pignataro, "Service Function
Chaining: Framework & Architecture", Work in Progress,
draft-boucadair-sfc-framework-02, February 2014.
[Quinn2014]
Quinn, P. and J. Halpern, "Service Function Chaining (SFC)
Architecture", Work in Progress, draft-quinn-sfc-arch-05,
May 2014.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
DOI 10.17487/RFC3022, January 2001,
<http://www.rfc-editor.org/info/rfc3022>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
<http://www.rfc-editor.org/info/rfc6296>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<http://www.rfc-editor.org/info/rfc6973>.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
Service Function Chaining", RFC 7498,
DOI 10.17487/RFC7498, April 2015,
<http://www.rfc-editor.org/info/rfc7498>.Acknowledgments 🫶
The editors want to thank a huge crew for their thorough reviews and super useful comments: Sam Aldrin, Alia Atlas, Nicolas Bouthors, Stewart Bryant, Linda Dunbar, Alla Goldner, Ken Gray, Barry Greene, Anil Gunturu, David Harrington, Shunsuke Homma, Dave Hood, Chris Inacio, Nagendra Kumar, Hongyu Li, Andrew Malis, Guy Meador III, Kengo Naito, Thomas Narten, Ron Parker, Reinaldo Penno, Naiming Shen, Xiaohu Xu, and Lucy Yong. Iconic behaviour 👑
This document was made by merging two earlier documents, so the acknowledgments from those documents are listed below too 🧚
From "Service Function Chaining (SFC) Architecture" [Quinn2014]
The authors would like to thank David Ward, Abhijit Patra, Nagaraj Bagepalli, Darrel Lewis, Ron Parker, Lucy Yong, and Christian Jacquenet for their review and comments 💜
From "Service Function Chaining (SF) - Framework and Architecture" [Boucadair2014]:
Many thanks to D. Abgrall, D. Minodier, Y. Le Goff, D. Cheng, R. White, and B. Chatras for their review and comments 🌸
Contributors 🎀
Okay so, this document is literally the result of merging two previous documents, and this section gives credit to everyone who brought important ideas and text that shaped this architecture. No cap, they all deserve it ✨
The authors of "Service Function Chaining (SFC) - Framework and Architecture" [Boucadair2014] were:
- Mohamed Boucadair
- Christian Jacquenet
- Ron Parker
- Diego R. Lopez
- Jim Guichard
- Carlos Pignataro
The contributors were:
- Parviz Yegani
- Paul Quinn
- Linda Dunbar
The authors of "Service Function Chaining (SFC) Architecture" [Quinn2014] were:
- Paul Quinn (editor)
- Joel Halpern (editor)
The contributors were:
- Puneet Agarwal
- Andre Beliveau
- Kevin Glavin
- Ken Gray
- Jim Guichard
- Surendra Kumar
- Darrel Lewis
- Nic Leymann
- Rajeev Manur
- Thomas Nadeau
- Carlos Pignataro
- Michael Smith
- Navindra Yadav
Authors' Addresses 💌
Joel Halpern (editor) Ericsson Email: jmh@joelhalpern.com
Carlos Pignataro (editor) Cisco Systems, Inc. Email: cpignata@cisco.com
That's the whole spec, bestie! 🌈💖 Thank you for reading every single word with me 🫶
📦 where this page comes from
- ietf: rfc7665 2015-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms