RFC 8459
Hierarchical Service Function Chaining (hSFC)
RFC 8459: Hierarchical Service Function Chaining (hSFC) 💖
Okay bestie, let's start with the basics 🎀
- RFC number: 8459
- Title: Hierarchical Service Function Chaining (hSFC) ✨
- Authors: D. Dolson (Sandvine), S. Homma (NTT), D. Lopez (Telefonica I+D), and M. Boucadair (Orange) 👯
- Category: Experimental 🧪
- Date: September 2018 📅
- ISSN: 2070-1721
- Stream: IETF, the Internet Engineering Task Force 🌐
- Obsoletes / Updates: the header doesn't list any, so this one doesn't obsolete or update anything 🙅♀️
Abstract 🌸
Hierarchical Service Function Chaining (hSFC) is a network architecture that lets an organization break a really big network into multiple domains of administration. It's giving divide and conquer 👑
The goals are to make a large-scale network easier to design, simpler to control, and friendly to independent functional groups inside big network operators. Main character energy for real 💅
Status of This Memo 📝
ngl, this part is a bit formal, but the main idea is that this document is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation 🔬
It defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you're curious 🤓
For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8459 🔗
Copyright Notice ©️
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved 💜
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at https://trustee.ietf.org/license-info. Those rules are the ones in effect on the date of publication, so read them carefully. They explain your rights and restrictions for this document 📜 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions. They're provided without warranty, as the Simplified BSD License describes 🎀
Table of Contents 🗺️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Experiment Goals . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Hierarchical Service Function Chaining (hSFC) . . . . . . . . 6
3.1. Upper Level . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Lower Levels . . . . . . . . . . . . . . . . . . . . . . 8
4. Internal Boundary Node (IBN) . . . . . . . . . . . . . . . . 10
4.1. IBN Path Configuration . . . . . . . . . . . . . . . . . 10
4.1.1. Flow-Stateful IBN . . . . . . . . . . . . . . . . . . 11
4.1.2. Encoding Upper-Level Paths in Metadata . . . . . . . 12
4.1.3. Using Unique Paths per Upper-Level Path . . . . . . . 13
4.1.4. Nesting Upper-Level NSH within Lower-Level NSH . . . 13
4.1.5. Stateful/Metadata Hybrid . . . . . . . . . . . . . . 14
4.2. Gluing Levels Together . . . . . . . . . . . . . . . . . 16
4.3. Decrementing Service Index . . . . . . . . . . . . . . . 16
4.4. Managing TTL . . . . . . . . . . . . . . . . . . . . . . 16
5. Subdomain Classifier . . . . . . . . . . . . . . . . . . . . 17
6. Control Plane Elements . . . . . . . . . . . . . . . . . . . 18
7. Extension for Adapting to NSH-Unaware Service Functions . . . 18
7.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.2. Requirements for an IBN . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9.1. Control Plane . . . . . . . . . . . . . . . . . . . . . . 21
9.2. Infinite Forwarding Loops . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Examples of Hierarchical Service Function Chaining . 24
A.1. Reducing the Number of Service Function Paths . . . . . . 24
A.2. Managing a Distributed DC Network . . . . . . . . . . . . 26
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 291. Introduction ✨
Okay so, Service Function Chaining (SFC) is a technique for prescribing differentiated traffic-forwarding policies inside an SFC-enabled domain 🦋 The whole SFC architecture is explained in detail in [RFC7665], so this doc doesn't repeat it. No need, bestie 💅
This document focuses on the tricky problem of implementing SFC across a large, geographically spread-out network. We're talking potentially millions of hosts and thousands of network-forwarding elements 🤯 It may also involve multiple operational teams with different functional responsibilities. We know some stateful Service Functions (SFs) need bidirectional traffic for transport-layer sessions, like NATs and firewalls 🔥 We also assume some Service Function Paths (SFPs) need to be picked based on the transport-layer coordinate. That's typically the 5-tuple: source IP address, source port number, destination IP address, destination port number, and transport protocol. The goal is "stickiness" to specific stateful SF instances 🧷
Hard problems get way easier when you break them into nested layers 🪆 So instead of one SFC control plane managing complete SFPs from one end of the network to the other, we split the network into smaller domains. Each one is run by its own SFC control plane component, all under the same administrative entity 🎀 How those components coordinate is covered later in this document 💜
Each subdomain may support a subset of the network applications or a subset of the users 🌸 Decomposing a network should be done with care so monitoring and troubleshooting stay easy for the network and its services as a whole 🧐 The criteria for splitting a domain into multiple SFC-enabled subdomains are beyond the scope of this document. They're deployment specific, so it's up to whoever is deploying it 🤷♀️
There's an example of simplifying a network with multiple SFC-enabled domains in [USE-CASES], if you want to see it in action 👀
We assume the SFC-aware nodes use the Network Service Header (NSH) [RFC8300] or a similar labeling mechanism. Examples are in Appendix A 🏷️
The SFC-enabled domains in this document are assumed to be under the control of a single organization, usually an operator. That means there's a strong trust relationship between the domains 🤝 The whole point of making multiple domains is to improve how a network gets operated. Domains run by different organizations, or interoperator considerations, are outside the scope of this document, so we're not going there today 🙅♀️
Last but not least, we introduce the concept of an Internal Boundary Node (IBN). This is the gateway that sits between the levels of the hierarchy 🚪 We also talk about options for actually building that function 🛠️
1.1. Experiment Goals 🧪
This document defines an architecture that aims to solve the complications you can run into when deploying SFC in large networks 😭 So a single network gets split into multiple subdomains, and each one is treated as an SFC-enabled domain. Levels of hierarchy are defined, and each level has its own SFC operations 🪜
To keep SFC operations consistent when multiple subdomains are involved, this document identifies and analyzes various options for IBNs that glue the layers together (Section 4.1) 🫶
Here's the honest tea: this document doesn't assume anything about (1) how subdomains are defined, (2) whether one or multiple IBNs are enabled per subdomain, (3) whether the same IBN is solicited at both the ingress and egress of a subdomain for the same flow, (4) the nature of the internal paths to reach SFs within a subdomain, or (5) the lack of deployment feedback. So it doesn't call for one recommended option to glue the SFC layers together 🙈
More experiments are needed to test and evaluate the different options. A recommendation for hSFC might show up in a future specification, once the results of implementing and deploying those options are available 🔮
It's not expected that every option discussed here will get implemented and deployed. If nobody implements an option, that lack of implementation might be read as a signal to recommend against it 💀
2. Terminology 📖
This document uses the terms defined in Section 1.4 of [RFC7665] and Section 1.3 of [RFC8300] 🧚
The following terms are defined:
- Upper-level domain: the entire network domain to be managed 👑
- Lower-level domain: a portion of the network, called a subdomain 🌷
- Internal Boundary Node (IBN): responsible for bridging packets between the upper and lower levels of SFC-enabled domains 🌉
3. Hierarchical Service Function Chaining (hSFC) 🌈
A hierarchy has multiple levels. The topmost level encompasses the entire network domain to be managed, and lower levels encompass portions of the network 🪜✨ The following subsections talk through these levels one at a time 💖
3.1. Upper Level 🌸
Okay bestie, let's look at Figure 1 ✨ A top-level network domain has SFC data plane pieces spread across a wide area, including:
- Classifiers (CFs)
- Service Function Forwarders (SFFs)
- Subdomains
+------------+
|Subdomain#1 |
| in DC1 |
+----+-------+
|
.---- SFF1 ------. +----+
+----+ / / | \--|CF#4|
--->|CF#1|--/---->' | \ +----+
+----+ / SC#1 | \
| | |
| V .------>|--->
| / / |
\ | / /
+----+ \ | / / +----+
|CF#2|---\ | / /---|CF#3|
+----+ '---- SFF2 ------' +----+
|
+----+-------+
|Subdomain#2 |
| in DC2 |
+------------+
Legend:
SC#1: Service Chain 1
DC: Data Center
Figure 1: Network-Wide View of Upper Level of HierarchySo one path goes from the edge classifier (CF#1) to SFF1, then into Subdomain#1 (living in Data Center 1), then back to SFF1, on to SFF2 (living in Data Center 2), then into Subdomain#2, then through SFF2 and out to the network egress 🦋
For clarity, we're leaving out the underlay network parts in the figure 🧚 We're just assuming an underlay network is there to give connectivity between the SFC data plane components.
Top-level SFPs carry packets from the classifiers through a set of SFFs and subdomains. What happens inside a subdomain stays opaque to the upper levels 🤫
We expect the system to have a top-level control plane in charge of configuring forwarding policies and traffic-classification rules 👑
The top-level Service Chaining control plane manages the end-to-end service chains and their service function paths, from network edge points to subdomains. It also configures the top-level classifiers at a coarse level (for example, based on source or destination host) so traffic goes along paths that transit the right subdomains 💅
Figure 1 shows one possible service chain going from the edge, through two subdomains, out to network egress. The top-level control plane does not configure traffic-classification rules or forwarding policies inside the subdomains. Main character energy for the top level, no notes 💀
At this network-wide level, the number of SFPs required is a linear function of the number of ways a packet has to traverse the different subdomains and exit the network. The various paths a packet can take inside a subdomain are not represented by separate network-wide SFPs. Instead, specific policies at each subdomain's ingress nodes bind flows to subdomain paths 🍓
Packets get classified at the network edge to pick the paths their subdomains are traversed by. At the ingress of each subdomain, packets are reclassified onto paths that direct them to the required SFs of that subdomain. At the egress of each subdomain, packets are returned to the top-level paths. Compare this with an approach where the top-level classifier has to pick paths that specify all of the SFs in every subdomain. Way more work, iykyk 🙈
Some SFs need bidirectional symmetry of paths (more on that in Section 5), so you should assume that. That means the classifiers at the top level must be configured with policies making sure outgoing packets take the reverse path of incoming packets through the subdomains 🫶
3.2. Lower Levels 🧚
Every subdomain in Figure 1 is an SFC-enabled domain ✨
Figure 2 shows a subdomain connected to an upper-level domain through an Internal Boundary Node (IBN). An IBN acts as an SFC-aware SF in the upper-level domain and as a classifier in the lower-level domain. So data packets entering the subdomain are already SFC encapsulated 💜 The IBN's whole job is to apply classification rules and direct packets onto the chosen local SFPs, which terminate at an egress IBN. Last step: the egress IBN restores packets to the original SFC shim and hands them off to SFFs 🎀
Each subdomain intersects only a subset of all the paths that are possible in the upper-level domain. An IBN only cares about upper-level paths that go through its own subdomain 🌈
Each subdomain will probably have a control plane that can run independently of the top-level control plane. It manages classification, forwarding paths, and so on, within the level of the subdomain, and the details stay opaque to the upper-level control elements. Section 4 has more on how an IBN behaves 🔥
The subdomain control plane configures the classification rules in the IBN, where SFC encapsulation of the top-level domain gets converted to and from SFC encapsulation of the lower-level domain. It also configures the forwarding rules in the SFFs of the subdomain 👑
+----+ +-----+ +----------------------+ +-----+
| | | SFF | | IBN 1 (in DC 1) | | SFF |
| |SC#1| | | +----------------+ | | |
->| |===============>| SFF |================>
| | +-----+ | +----------------+ | +-----+
| CF | | | ^ |
| | | v | |
| | |+--------------------+| Upper domain
| | ||CF, fwd/rev mapping ||
| | * * * * *|| and "glue" || * * * * *
| | * |+--------------------+| *
+----+ * | | | | | | Sub *
* +-o-o--------------o-o-+ domain*
* SC#2 | |SC#1 ^ ^ #1 *
* +-----+ | | | *
* | V | | *
* | +---+ +------+ | | *
* | |SFF|->|SF#1.1|--+ | *
* | +---+ +------+ | *
* V | *
* +---+ +------+ +---+ +------+ *
* |SFF|->|SF#2.1|->|SFF|->|SF#2.2| *
* +---+ +------+ +---+ +------+ *
* * * * * * * * * * * * * * * * * * * * * *
Legend:
*** Subdomain boundary
=== upper-level chain
--- lower-level chain
Figure 2: Example of a Subdomain within an Upper-Level DomainIf you want, the pattern can be applied recursively 🦋 For example, SF#1.1 in Figure 2 could itself be a subdomain of the subdomain. Hierarchy inception, periodt 🌀
4. Internal Boundary Node (IBN) 💅
As we mentioned in the last section, a network element called an "Internal Boundary Node" (or IBN) is responsible for bridging packets between the upper and lower layers of SFC-enabled domains. To the upper level it acts like an SF (see Section 3.1), and to the lower level it looks like a classifier and the end of a chain (see Section 3.2) 🫶
To get the benefits of hierarchy, the IBN should apply fine-grained traffic-classification rules at a lower level than the traffic passed to it. That means the number of SFPs within the lower level is greater than the number of SFPs arriving at the IBN 🍓
The IBN also terminates lower-level SFPs. This is because packets exiting lower-level SFPs have to be returned to the upper-level SFPs and forwarded to the next hop in the upper-level domain ✨
When different metadata schemes are used at different levels, the IBN has extra responsibilities. When packets enter the subdomain, the IBN translates upper-level metadata into lower-level metadata. When packets leave the subdomain at the end of lower-level SFPs, the IBN translates lower-level metadata back into upper-level metadata 🔥
Configuring IBNs properly is key to keeping the overall SFC operation consistent within a given domain that enables hSFC 💖 And the classification rules (or lack of them) in the IBN classifier can, of course, impact the upper levels 👀
4.1. IBN Path Configuration 🎀
The lower-level domain may be provisioned with valid upper-level paths, or it may allow any upper-level paths 🌸
When packets enter the subdomain, the Service Path Identifier (SPI) and Service Index (SI) are re-marked according to the path the (subdomain) classifier selects 🧚
At the end of an SFP in the subdomain, packets can be restored to their original upper-level SFP by using one of these methods:
- Saving the SPI and SI in transport-layer flow state (Section 4.1.1).
- Pushing the SPI and SI into a metadata header (Section 4.1.2).
- Using unique lower-level paths per upper-level path coordinates (Section 4.1.3).
- Nesting NSH headers, encapsulating the upper-level NSH headers within the lower-level NSH headers (Section 4.1.4).
- Saving the upper level with a flow identifier (ID) and placing an hSFC Flow ID into a metadata header (Section 4.1.5).
4.1.1. Flow-Stateful IBN ✨
Okay so an IBN can be flow aware 🦋, which means it can send packets back to the correct upper-level SFP based on the transport-layer coordinates (typically a 5-tuple) of the packets coming out of the lower-level SFPs. It's giving precision!
When packets come into the IBN on an upper-level path, the classifier digs into the encapsulated packets for IP and transport-layer (TCP, UDP, etc.) coordinates. Then it creates state indexed by some or all of those coordinates (typically {source-IP, destination-IP, source-port, destination-port, and transport protocol}). The state holds, at minimum, the critical fields of the encapsulating SFC header (SPI, SI, MD Type, flags). Extra stuff riding along in the packet, like metadata and TTL, can also be pulled out and saved as state. Heads up though: an SF in the subdomain might alter some fields of a packet, like the source IP address 👀.
Only the classifier and terminator functions of the subdomain can touch this state. The SFFs and SFs have no idea it exists 🙈. In fact, they might not even know they're inside a subdomain, and that's honestly so iconic for them.
One approach is to make sure packets get terminated at the end of the chain by the same IBN that classified them at the start of the chain. If a packet comes back through a different egress IBN, the state has to be synchronized between the IBNs. Main character energy means keeping things consistent 💅.
When a packet returns to the IBN at the end of a chain (which is the SFP-terminating node of the lower-level chain), the SFC header gets removed, the packet is parsed for flow-identifying information, and the state is retrieved from inside the IBN using that flow-identifying information as the index.
State cannot be created by packets arriving from the lower-level chain. So when no state can be found for those packets, they must be dropped 💀. No state, no entry, periodt.
This stateful approach only works with SFs that keep the transport coordinates of the packet. It can't be used with SFs that modify those coordinates (like NATs), or that otherwise create packets for new coordinates other than the ones they received (like an HTTP cache fetching content on behalf of the original flow). In both cases, the real problem is that the packets can't be forwarded when no state can be found for their transport-layer coordinates. Not me getting stuck on this 😭.
With a stateful approach, the state itself causes some issues, like how long the state should stick around, and whether it needs to be copied to other devices so the network stays highly available 🌈.
It's totally valid to treat the state as disposable after a failure, since every new packet arriving from the upper-level domain can recreate it. For example, if an IBN loses all of its flow state, the state gets recreated when an endpoint retransmits a TCP packet. Resilient queen behavior 👑.
If an SFC domain handles multiple network regions (like multiple private networks), the coordinates can be augmented with extra parameters, maybe using some metadata to identify the network region 🧚.
With this stateful approach, the subdomain's control plane doesn't have to modify its paths when the upper-level paths change. The complexity of the upper-level domain doesn't cause complexity in the lower-level domain. Low-key the dream 💜.
And since it doesn't depend on NSH in the lower-level domain, this flow-stateful approach can also be used with translation methods that convert NSH to other forwarding techniques (refer to Section 7) ✨.
4.1.2. Encoding Upper-Level Paths in Metadata 🎀
An IBN can push the upper-level SPI and SI (or an encoding of them) into a metadata field of the lower-level encapsulation. For example, it can put the upper-level path information into a metadata field of the NSH. When packets exit the lower-level path, the upper-level SPI and SI can be restored from the metadata pulled out of the packet. It's like a little note passed along for the ride 🍓.
This approach requires the SFs in the path to be capable of forwarding the metadata, and to attach metadata appropriately to any packets they inject for a flow.
Using a new metadata header might inflate the packet size when variable-length metadata (NSH MD Type 0x2) is used. Yikes, bloat alert 🙈.
It's conceivable that the MD Type 0x1 Fixed-Length Context Header field of the NSH isn't all relevant to the lower-level domain. In that case, 32 bits of the Fixed-Length Context Header field could be repurposed within the lower-level domain and restored when leaving. Resourceful and iconic 🦋.
If flags or TTL (see Section 4.4) from the original header also need to be saved, more metadata space will be used up.
With this metadata approach, the subdomain's control element doesn't have to modify paths when the upper-level paths change. The complexity of the upper-level domain doesn't increase complexity in the lower-level domain. Simple and slay 💅.
4.1.3. Using Unique Paths per Upper-Level Path 🧚
This approach assumes that the paths inside the subdomain are constrained so that an SPI (of the subdomain) unambiguously indicates the egress SPI and SI (of the upper domain). That way, the original path information can be restored at the subdomain egress from a look-up table using the subdomain SPI. It's basically a secret decoder ring 🔥.
Whenever the upper-level domain provisions a path via the lower-level domain, the lower-level domain's control plane must provision corresponding paths to traverse the lower-level domain.
The downside here is that the number of paths in the lower-level domain gets multiplied by the number of paths in the upper-level domain that traverse it. In other words, a subpath has to be created for every combination of upper SPI/SI and lower chain. The number of paths required for lower-level domains increases exponentially as the hierarchy gets deeper. Sis, that is a LOT 😭.
Another downside is that this approach requires the upper and lower levels to use the same metadata configuration.
And furthermore, this approach doesn't allow any information to be stashed away in state or embedded in metadata. For example, TTL modifications made by the lower level can't be hidden from the upper level. Transparency is the vibe, even when it's a lot 🌸.
4.1.4. Nesting Upper-Level NSH within Lower-Level NSH 🌈
When packets arrive at an IBN in the top-level domain, the classifier in the IBN figures out the path for the lower-level domain and pushes the new NSH header in front of the original NSH header. Stacking, but make it aesthetic 🎀.
As shown in Figure 3, the Lower-NSH header (used to forward packets in the lower-level domain) comes before the Upper-NSH header from the top-level domain:
+---------------------------------+
| Outer-Transport Encapsulation |
+---------------------------------+
| Lower-NSH Header |
+---------------------------------+
| Upper-NSH Header |
+---------------------------------+
| Original Packet |
+---------------------------------+Figure 3: Encapsulation of NSH within NSH
So the traffic with this stack of two NSH headers gets forwarded according to the Lower-NSH header inside the lower-level SFC domain. The Upper-NSH header is kept in the packets, but it isn't used for forwarding. At the last SFF of the lower-level domain's chain (which lives in the IBN), the Lower-NSH header is removed, and then the IBN forwards the packet to an SFF of the upper-level domain. In the top-level domain, the packet gets forwarded according to the Upper-NSH header. Passing the baton 🥹.
With this encapsulation, the Upper-NSH information gets carried along the whole length of the lower-level chain without any modification. Untouched and unbothered 💖.
The big benefit here is that it doesn't require any state in the IBN, or any configuration to encode fields in metadata. All the header fields, including flags and TTL, can be easily restored when the chains of the subdomain terminate ✨.
BUT, the downside is that it does require SFC-aware SFs in the lower-level domain to be able to parse multiple NSH layers. And if an SFC-aware SF injects packets, it must also be able to deal with adding the appropriate multiple layers of headers to those injected packets. Lowkey a lot of work for those SFs 🙈.
Also, by increasing packet overhead, nesting may lead to fragmentation or a decreased MTU in some networks 💀.
4.1.5. Stateful/Metadata Hybrid 🦋
The basic idea of this approach is for the IBN to save the upper-domain encapsulation information so it can be retrieved using a unique identifier, termed an "hSFC Flow ID". It's a hybrid, so it's the best of both worlds, honestly giving genius energy 👑.
The hSFC Flow ID gets placed, for example, in the NSH Fixed-Length Context Header field of the packet in the lower-level domain, as shown in Figure 4. Likewise, the hSFC Flow ID may be encoded as a Variable-Length Context Header field when MD Type 0x2 is used.
When packets exit the lower-level domain, the IBN uses the hSFC Flow ID to retrieve the appropriate NSH encapsulation for returning the packet to the upper domain. After that, the hSFC Flow ID Context Header gets stripped by the IBN. Clean exit, no trace 🧚.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hSFC Flow ID |
| Zero Padding or other fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: Storing hSFC Flow ID in Lower-Level NSH Fixed-Length Context Header Field ([RFC8300], Section 2.4)
Advantages of this approach include:
- It doesn't require state to be based on a 5-tuple, so it works with SFs that change the IP addresses or port numbers of a packet, like NATs. Goodbye 5-tuple drama 💅.
- It doesn't require all domains to have the same metadata scheme.
- It can be used to restore any upper-domain information, including metadata, flags, and TTL, not just the service path.
- The lower-level domain only requires a single item of metadata, no matter how many items of metadata are used in the upper domain. Minimalist serve 🌸.
- The SFC-related functionality required by this approach in an SFC-aware SF is able to preserve and apply metadata, which is a requirement that was already present in [RFC8300]. Already on the list, so no new homework 📚.
The disadvantages include the same ones as the other stateful approaches, including state timeout and synchronization, which were mentioned in Section 4.1.1. Same old state drama, new hybrid 🙄.
There may be a large number of unique NSH encapsulations to be stored, since the hSFC Flow ID must represent all of the bits in the upper-level encapsulation. This might eat up a lot of memory or cause out-of-memory situations, where hSFC Flow IDs can't be created, or old hSFC Flow IDs get discarded while they're still in use. Memory is not infinite, bestie 😭💀.
4.2. Gluing Levels Together ✨
Okay so the SPI or metadata that shows up in a packet the IBN receives can be used as input to reclassification and path selection inside a lower-level domain. Main character energy, right? 💅
Sometimes the meanings of the different path IDs and metadata have to be coordinated between domains so that end-to-end SFC operation actually works. Bestie, this part matters a lot 🫶
One way to do this is to use well-known identifier values in metadata, maintained in a global registry. Clean and simple 🧚
Another way is to use well-known labels for chain identifiers or metadata, which act as an indirection to the actual identifiers. The actual identifiers can be assigned by control-plane systems. For example, a subdomain classifier could have a policy, "if pathID = classA then chain packet to path 1234"; the upper-level controller would be expected to configure the concrete upper-level "pathID" for "classA". It's giving layers of abstraction, no cap 🌈
4.3. Decrementing Service Index 🦋
Because the IBN acts as an SFC-aware SF to the upper-level domain, it must decrement the Service Index in the NSH headers of the upper-level path. This operation should be undertaken when the packet is first received by the IBN, before applying any of the strategies of Section 4.1, immediately prior to classification. The IBN is literally the gatekeeper here 💖
4.4. Managing TTL 🎀
The NSH base header contains a TTL field [RFC8300]. There is a choice:
- a subdomain may appear as a pure service function, which should not decrement the TTL from the perspective of the upper-level domain, or
- all of the TTL changes within the subdomain may be visible to the upper-level domain.
Some readers may recognize this as a choice between "pipe" and "uniform" models, respectively [RFC3443]. Iykyk 🙈
The network operator should be given control of this behavior, choosing whether to expose the lower-level topology to the upper layer. An implementation may support per-packet policy, allowing some users to perform a layer-transcending trace route, for example. Ngl that's a whole vibe ✨
The choice affects whether the methods of restoring the paths in Section 4.1 restore a saved version of the TTL or propagate it with the packet. The method of Section 4.1.3 does not permit topology hiding. The other methods of Sections 4.1.1, 4.1.2, 4.1.4, and 4.1.5 have unique methods for restoring saved versions of the TTL. Each one handles it in its own way, periodt 💅
5. Subdomain Classifier 🌸
Within the subdomain (referring to Figure 2), as the classifier receives incoming packets, the upper-level encapsulation is treated according to one of the methods described in Section 4.1 to either statefully store, encode, or nest header information. The classifier then selects the path and metadata for the packet within the subdomain. The classifier is lowkey the hero of this whole section 👑
One of the goals of the hierarchical approach is to make it easy to have transport-flow-aware service chaining with bidirectional paths. For example, it is desired that for each TCP flow, the client-to-server packets traverse the same SF instances as the server-to-client packets, but in the opposite sequence. We call this "bidirectional symmetry". If bidirectional symmetry is required, it is the responsibility of the control plane to be aware of symmetric paths and configure the classifier to chain the traffic in a symmetric manner. Symmetry is everything, bestie 🦋
Another goal of the hierarchical approach is to simplify the mechanisms of scaling SFs in and out. All of the complexities of load-balancing among multiple SFs can be handled within a subdomain, under control of the classifier, allowing the upper-level domain to be oblivious to the existence of multiple SF instances. The upper level just doesn't need to know 🧚
Considering the requirements of bidirectional symmetry and load-balancing, it is useful to have all packets entering a subdomain be received by the same classifier or a coordinated cluster of classifiers. There are both stateful and stateless approaches to ensuring bidirectional symmetry. Two ways to get the same result, slay 💖
6. Control Plane Elements 👑
Although SFC control protocols have not yet been standardized (as of 2018), from the point of view of hierarchical service function chaining, we have these expectations:
- Each control-plane instance manages a single level of the hierarchy of a single domain.
- Each control plane is agnostic about other levels of the hierarchy. This aspect allows humans to reason about the system within a single domain and control-plane algorithms to use only domain-local inputs. Top-level control does not need visibility to subdomain policies, nor does subdomain control need visibility to upper-level policies. (Top-level control considers a subdomain as though it were an SF.)
- Subdomain control planes are agnostic about the control planes of other subdomains. This allows both humans and machines to manipulate subdomain policy without considering policies of other domains.
Recall that the IBN acts as an SFC-aware SF in the upper-level domain (receiving SF instructions from the upper-level control plane) and as a classifier in the lower-level domain (receiving classification rules from the subdomain control plane). In this view, it is the IBN that glues the layers together. The IBN is the ultimate bestie in the middle 🫶
These expectations are not intended to prohibit network-wide control. A control hierarchy can be envisaged to distribute information and instructions to multiple domains and subdomains. Control hierarchy is outside the scope of this document. That's a whole other story, for another day 🌈
7. Extension for Adapting to NSH-Unaware Service Functions 🦋
The hierarchical approach can be used for dividing networks into NSH-aware and NSH-unaware domains by converting NSH encapsulation to other forwarding techniques (e.g., 5-tuple-based forwarding with OpenFlow), as shown in Figure 5.
* * * * * * * * * * * * * * * * * *
* NSH-aware domain *
* +-------+ +-------+ *
* | SF#1 | | SF#5 | *
* +-o---o-+ +-o---o-+ *
* ^ | ^ | *
* +-|---|-+ +-|---|-+ *
* | |SFF| | | |SFF| | *
* +-|---|-+ +-|---|-+ *
* . | | . *
* +--+ / | | \ *
-->|CF|--' | | '------->
* +--+ v | *
* +---o-----------o---+ *
.*.*.*.*.| / | IBN | \ |*.*.*.
. +-o--o---------o--o-+ .
. | | ^ ^ .
. | +-+ +-+ | .
. +---+ v | +---+ .
. | +-o-----o-+ | .
. | | SF#2 | | .
. | +---------+ | .
. +--+ +--+ .
. | +---------+ | .
. v | v | .
. +-o---o-+ +-o---o-+ .
. | SF#3 | | SF#4 | .
. +-------+ +-------+ .
. NSH-unaware domain .
. . . . . . . . . . . . . . . . . .SF#1 and SF#5 are NSH aware; SF#2, SF#3, and SF#4 are NSH unaware. In the NSH-unaware domain, packets are conveyed in a format supported by SFs that are deployed there.
Figure 5: Dividing NSH-Aware and NSH-Unaware Domains
7.1. Purpose 💖
This approach is expected to facilitate service chaining in networks in which NSH-aware and NSH-unaware SFs coexist. Some examples of such situations are:
- In a period of transition from legacy SFs to NSH-aware SFs
- Supporting multitenancy
7.2. Requirements for an IBN 🎀
In this usage, an IBN classifier is required to have an NSH conversion table for applying packets to appropriate lower-level paths and returning packets to the correct upper-level paths. For example, the following methods would be used for saving/restoring upper-level path information:
- Saving SPI and SI in transport-layer flow state (refer to Section 4.1.1)
- Using unique lower-level paths per upper-level NSH coordinates (refer to Section 4.1.3)
Using the unique paths approach would be especially good for translating NSH to a different forwarding technique in the lower level. A single path in the upper level may be branched to multiple paths in the lower level such that any lower-level path is only used by one upper-level path. This allows unambiguous restoration to the upper-level path. Unambiguous = no confusion, no drama 🧚
In addition, an IBN might be required to convert metadata contained in the NSH to the format appropriate to the packet in the lower-level path. For example, some legacy SFs identify subscribers based on information about the network topology, such as the VLAN ID (VID), and the IBN would be required to create a VLAN to packets from metadata if the subscriber identifier is conveyed as metadata in upper-level domains.
Other fundamental functions required for an IBN (e.g., maintaining metadata of upper level or decrementing Service Index) are the same as in normal usage.
It is useful to permit metadata to be transferred between levels of a hierarchy. Metadata from an upper level may be useful within a subdomain, and a subdomain may augment metadata for consumption in an upper domain. However, allowing uncontrolled metadata between domains may lead to forwarding failures. Yikes, not the vibe 💀
In order to prevent SFs of lower-level SFC-enabled domains from supplying (illegitimate) metadata, IBNs may be instructed to only permit specific metadata types to exit the subdomain. Such control over the metadata in the upper level is the responsibility of the upper-level control plane. To limit unintentional metadata reaching SFs of lower-level SFC-enabled subdomains, IBNs may be instructed to only permit specific metadata types into the subdomain. Such control of metadata in the lower-level domain is the responsibility of the lower-level control plane.
8. IANA Considerations 🌈
This document has no IANA actions.
9. Security Considerations 💀
hSFC makes use of service chaining architecture; hence, it inherits the security considerations described in the architecture document [RFC7665].
Furthermore, hSFC inherits the security considerations of the data-plane protocols (e.g., NSH) and control-plane protocols used to realize the solution.
This document describes systems that may be managed by distinct teams that all belong to the same administrative entity. Subdomains must have consistent configurations in order to properly forward traffic. Any protocol designed to distribute the configurations must be secure from tampering. The means of preventing attacks from within a network must be enforced. For example, continuously monitoring the network may allow detecting such misbehaviors. hSFC adheres to the same security considerations as [RFC8300]. Those considerations must be taken into account.
The options in Sections 4.1.2 and 4.1.5 assume the use of a dedicated context header to store information to bind a flow to its upper-level SFP. Such a context header is stripped by the IBN of a subdomain before exiting a subdomain. Additional guards to prevent leaking unwanted context information when entering/exiting a subdomain are discussed in Section 7.2.
All of the systems and protocols must be secure from modification by untrusted agents.
9.1. Control Plane 🎀
okay so security for the control plane is its own whole thing bestie 💅 it lives in the control specs themselves, like [BGP-CONTROL], [PCEP-EXTENSIONS], or [RADIUS]. go read those when you're ready to lock things down 🔒✨
9.2. Infinite Forwarding Loops 🔁
okay this one is giving main character drama 😭 distributing policies across multiple domains can lead to forwarding loops, and that's the spicy part. NSH can actually detect loops (see Sections 4.3 and 4.4 of [RFC8300]) 🕵️♀️, but the way to keep your policies consistent has to be turned on at every level of a domain. in hSFC, the Control Elements at all levels are the ones responsible for stopping those unwanted loops. no loops in my house 🙅♀️💜
10. References 📚
10.1. Normative References
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<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, January 2018,
<https://www.rfc-editor.org/info/rfc8300>.10.2. Informative References
[BGP-CONTROL]
Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L.
Jalil, "BGP Control Plane for NSH SFC", Work in Progress,
draft-ietf-bess-nsh-bgp-control-plane-04, July 2018.
[PCEP-EXTENSIONS]
Wu, Q., Dhody, D., Boucadair, M., Jacquenet, C., and J.
Tantsura, "PCEP Extensions for Service Function Chaining
(SFC)", Work in Progress,
draft-wu-pce-traffic-steering-sfc-12, June 2017.
[RADIUS] Maglione, R., Trueba, G., and C. Pignataro, "RADIUS
Attributes for NSH", Work in Progress,
draft-maglione-sfc-nsh-radius-01, October 2016.
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
in Multi-Protocol Label Switching (MPLS) Networks",
RFC 3443, DOI 10.17487/RFC3443, January 2003,
<https://www.rfc-editor.org/info/rfc3443>.
[USE-CASES]
Kumar, S., Tufail, M., Majee, S., Captari, C., and S.
Homma, "Service Function Chaining Use Cases In Data
Centers", Work in Progress,
draft-ietf-sfc-dc-use-cases-06, February 2017.Appendix A. Examples of Hierarchical Service Function Chaining 🧚
okay the big hSFC glow-up is that it can cut your management complexity way down 📉✨ this appendix walks through examples that show exactly how.
A.1. Reducing the Number of Service Function Paths 💖
in this case hSFC simplifies service function chaining management by shrinking the number of SFPs. it's so clean 🫶
as shown in Figure 6, there are two domains that care about different things 👀: a Security Domain that picks SFs based on network conditions, and an Optimization Domain that picks SFs based on traffic protocol.
in this example there are five security functions deployed in the Security Domain. the Security Domain operator wants to enforce five different security policies, and the Optimization Domain operator wants to apply different optimizations (either cache or video optimization) to each of those two types of traffic. if we use flat SFC (normal branching), 10 SFPs are needed in each domain 😵. but if we use hSFC, only five SFPs in the Security Domain and two SFPs in the Optimization Domain are required, as shown in Figure 7 🎉.
in the flat model the number of SFPs is the product of the number of SFs in all of the domains 💀. in the hSFC model the number of SFPs is the sum of the number of SFs. for example, adding a "bypass" path in the Optimization Domain would make the flat model need 15 paths (five more) 😩, but the hSFC model only needs one more path in the Optimization Domain 🌸.
. . . . . . . . . . . . . . . . . . . . . . . . .
. Security Domain . . Optimization Domain .
. . . .
. +-1---[ ]----------------->[Cache ]------->
. | [ WAF ] . . .
. +-2-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-3---[Anti ]----------------->[Cache ]------->
. | [Virus] . . .
. +-4-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-5-->[ ]----------------->[Cache ]------->
[DPI]--->[CF]---| [ IPS ] . . .
. +-6-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-7-->[ ]----------------->[Cache ]------->
. | [ IDS ] . . .
. +-8-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-9-->[Traffic]--------------->[Cache ]------->
. | [Monitor] . . .
. +-10->[ ]--------------->[Video Opt.]---->
. . . . . . . . . . . . . . . . . . . . . . . . .
Legend:
IDS: Intrusion Detection System
IPS: Intrusion Prevention System
WAF: Web Application Firewall
DPI: Deep Packet Inspectionthe classifier must select paths that determine the combination of Security and Optimization concerns. 1:WAF+Cache, 2:WAF+VideoOpt, 3:AntiVirus+Cache, 4:AntiVirus+VideoOpt, 5:IPS+Cache, 6:IPS+VideoOpt, 7:IDS+Cache, 8:IDS+VideoOpt, 9:TrafficMonitor+Cache, 10:TrafficMonitor+VideoOpt
Figure 6: Flat SFC (Normal Branching) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Security Domain . . Optimization Domain .
. . . .
[CF]---->[ [CF] IBN ]---------->[ [CF] IBN ]---->
. | ^ . . | ^ .
. +----->[ WAF ]-----+ . . +-->[ Cache ]---------+ .
. | | . . | | .
. +-->[Anti-Virus]---+ . . +-->[Video Opt]-------+ .
. | | . . .
. +----->[ IPS ]-----+ . . . . . . . . . . . . . . . .
. | | .
. +----->[ IDS ]-----+ .
. | | .
. +-->[ Traffic ]----+ .
. [ Monitor ] .
. . . . . . . . . . . . . . . Figure 7: Simplified Path Management with hSFCA.2. Managing a Distributed DC Network 🌈
hierarchical SFC can be used to simplify inter-DC SFC management, and this is where it gets really iconic 👑. in the example of Figure 8 there's a central data center (Central DC) and multiple local data centers (Local DC#1, #2, #3) that are deployed in a geographically distributed manner. all of the data centers sit under a single administrative domain.
the central DC may have some service functions that the local DC needs, so the local DC needs to chain traffic via the central DC. this could be because:
- Some SFs are deployed as dedicated hardware appliances, and there is a desire to lower the cost (both CAPEX and OPEX) of deploying such SFs in all data centers.
- Some SFs are being trialed or introduced, or they otherwise handle a relatively small amount of traffic. It may be cheaper to manage these SFs in a single central data center and steer packets to the central data center than to manage these SFs in all data centers.
+-----------+
|Central DC |
+-----------+
^ ^ ^
| | |
.---|--|---|----.
/ / | | \
/ / | \ \
+-----+ / / | \ \ +-----+
|Local| | / | \ | |Local|
|DC#1 |--|--. | .----|----|DC#3 |
+-----+ | | | +-----+
\ | /
\ | /
\ | /
'----------------'
|
+-----+
|Local|
|DC#2 |
+-----+
Figure 8: Simplify Inter-DC SFC Managementfor large DC operators, one local DC may have tens of thousands of servers and hundreds of thousands of virtual machines 🤯. SFC can be used to manage user traffic. for example, SFC can be used to classify user traffic based on service type, DDoS state, etc.
in such a large-scale DC, using flat SFC is very complex, because it requires a super controller to configure all DCs 😩. for example, any changes to SFs or SFPs in the central DC (e.g., deploying a new SF) would require updates to all of the SFPs in the local DCs accordingly. furthermore, requirements for symmetric paths add additional complexity when flat SFC is used in this scenario.
conversely, if you use hierarchical SFC, each DC can be managed independently, which significantly reduces management complexity 🦋. SFPs between DCs can represent abstract notions without regard to details within DCs. independent controllers can be used for the top level (getting packets to pass the correct DCs) and local levels (getting packets to specific SF instances). the big brain move 🧠✨
Acknowledgements 🫶
the concept of Hierarchical Service Path Domains was introduced in "Analysis on Forwarding Methods for Service Chaining" (August 2016) as a means of improving scalability of service chaining in large networks 🌸.
the concept of nesting NSH headers within lower-level NSH was contributed by Ting Ao. the concept originally appeared in "Hierarchical SFC for DC Interconnection" (April 2016) as a means of creating hierarchical SFC in a data center 💜.
we thank Dapeng Liu for contributing the DC examples in the Appendix 🎀.
the Stateful/Metadata Hybrid section was contributed by Victor Wu ✨.
the authors would also like to thank the following individuals for providing valuable feedback:
Ron Parker
Christian Jacquenet
Jie Cao
Kyle Larosethanks to Ines Robles, Sean Turner, Vijay Gurbani, Ben Campbell, and Benjamin Kaduk for their review 🙌🍓.
Authors' Addresses 💌
David Dolson
Sandvine
Waterloo, ON
Canada
Email: ddolson@acm.org
Shunsuke Homma
NTT
3-9-11, Midori-cho
Musashino-shi, Tokyo 180-8585
Japan
Email: homma.shunsuke@lab.ntt.co.jp
Diego R. Lopez
Telefonica I+D
Don Ramon de la Cruz, 82
Madrid 28006
Spain
Phone: +34 913 129 041
Email: diego.r.lopez@telefonica.com
Mohamed Boucadair
Orange
Rennes 35000
France
Email: mohamed.boucadair@orange.com📦 where this page comes from
- ietf: rfc8459 2018-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms