RFC 7498

(Part 1 of 3, more coming! 🎀)

RFC 7498: Problem Statement for Service Function Chaining ✨

Okay bestie, let's set the scene 💅 This is RFC 7498, called Problem Statement for Service Function Chaining, and it came out in April 2015. The authors are P. Quinn, Ed. from Cisco Systems, Inc. and T. Nadeau, Ed. from Brocade. Its category is Informational, which means it's published for information and is not a standards track spec 🙈 The ISSN is 2070-1721. Its header doesn't list any RFCs it obsoletes or updates, so no drama there 💖

Abstract

This document gives an overview of the problems that pop up when you deploy service functions (like firewalls, load balancers, and so on) in huge environments 🌸 The phrase "service function chaining" describes setting up an ordered list of instances of those service functions, and then "steering" traffic flows through them, in order 🦋

The set of enabled service function chains reflects what an operator offers as a service. It's designed alongside application delivery and service and network policy, so it's all connected ✨

The document also points out several key areas that the Service Function Chaining (SFC) working group is going to dig into. The goal is to guide its architecture and protocol work and the documents that come with it 🧚

Status of This Memo

Let's be clear about what this is: this document is not an Internet Standards Track specification. It's published for informational purposes 💜

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is eligible for any level of Internet Standard. See Section 2 of RFC 5741 for that 💅

For the latest status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7498 ✨

Copyright Notice

Copyright (c) 2015 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 (http://trustee.ietf.org/license-info), as in effect on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document 🫶 Any 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 described in the Simplified BSD License 💀

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Definition of Terms . . . . . . . . . . . . . . . . . . .   3
2.  Problem Space . . . . . . . . . . . . . . . . . . . . . . . .   5
  2.1.  Topological Dependencies  . . . . . . . . . . . . . . . .   5
  2.2.  Configuration Complexity  . . . . . . . . . . . . . . . .   6
  2.3.  Constrained High Availability . . . . . . . . . . . . . .   6
  2.4.  Consistent Ordering of Service Functions  . . . . . . . .   6
  2.5.  Application of Service Policy . . . . . . . . . . . . . .   6
  2.6.  Transport Dependence  . . . . . . . . . . . . . . . . . .   7
  2.7.  Elastic Service Delivery  . . . . . . . . . . . . . . . .   7
  2.8.  Traffic Selection Criteria  . . . . . . . . . . . . . . .   7
  2.9.  Limited End-to-End Service Visibility . . . . . . . . . .   7
  2.10. Classification/Reclassification per Service Function  . .   7
  2.11. Symmetric Traffic Flows . . . . . . . . . . . . . . . . .   8
  2.12. Multi-vendor Service Functions  . . . . . . . . . . . . .   8
3.  Service Function Chaining . . . . . . . . . . . . . . . . . .   8
  3.1.  Service Overlay . . . . . . . . . . . . . . . . . . . . .   8
  3.2.  Service Classification  . . . . . . . . . . . . . . . . .   9
  3.3.  SFC Encapsulation . . . . . . . . . . . . . . . . . . . .   9
4.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
5.  Informative References  . . . . . . . . . . . . . . . . . . .  11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  11
Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1. Introduction ✨

Delivering end-to-end services usually takes a bunch of service functions. Some are traditional network ones, like firewalls and server load balancers, and some are application-specific, like HTTP header manipulation 🎀 A service function can live inside an isolated user (like a tenant), or it can be shared across lots of users or user groups 🌈

Right now, the way people deploy service functions is often tightly tied to network topology and physical resources. That makes deployments pretty rigid and static 🙈 All that static-ness hugely reduces, and in lots of cases completely limits, an operator's ability to add new services or change existing services and/or service functions. And there's a domino effect too: changing one element of a service function chain often affects the other elements in the chain and/or the network elements used to build it 💀

This is especially rough in elastic service environments, where physical or virtual service functions or network elements need to be created, destroyed, or moved pretty quickly ⚡ Moving to virtual platforms also means you need an agile service insertion model. It has to support elastic, very granular service delivery, changes after the fact, and moving service functions and application workloads around the existing network 🦋 That insertion model also has to keep the network and service policies, and it has to make it easy to bind service policy to granular information, like per-subscriber state 💜

This document lays out the problems with the existing service deployment models for Service Function Chaining (SFC), which people often just call "service chaining." In this document, the two terms are used interchangeably 🫶 Section 3 of this document highlights three key areas of WG focus for investigating solutions to the current problems. The document highlights three key areas of WG focus for addressing the issues it raises, and those areas will form the basis for the possible WG solutions to the current problems 🧚

1.1. Definition of Terms 💅

Here's the glossary, bestie 📖

Classification: Locally instantiated matching of traffic flows against policy, so the required set of network service functions can be applied afterward. The policy may be customer-specific, network-specific, or service-specific 🌸

Network Overlay: A logical network built over an existing network (the underlay), using virtual links or packet encapsulation 🦋

Network Service: An offering from an operator that's delivered using one or more service functions. It may also be called a composite service. In this document, "service" is used to mean a "network service" 💖

Note: Outside this document, the word "service" gets overloaded and means different things. To some people, a service is an offering made of several elements inside the operator's network. To others, a service (or more 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 🙈

Service Function: A function that's responsible for specific treatment of received packets. A service function can act at various layers of a protocol stack, like the network layer or other OSI layers. As a logical component, it can be realized as a virtual element or be embedded in a physical network element. One or more service functions can be embedded in the same network element, and multiple occurrences of the same service function can exist in the same administrative domain 👑

Here's a non-exhaustive list of service functions: firewalls, WAN and application acceleration, Deep Packet Inspection (DPI), server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header enrichment functions, and TCP optimizers 🌈 The generic term "L4-L7 services" is often used to describe many service functions 🎀

Service Function Chain (SFC): A service function chain defines an ordered or partially ordered set of abstract service functions (SFs) and the ordering constraints that must be applied to packets, frames, and/or flows selected as a result of classification. An example of an abstract service function is a firewall. The implied order doesn't have to be a straight line, because the architecture allows SFCs that copy to more than one branch, and it also allows cases where the order in which service functions get applied can be flexible 🦋 The term "service chain" is often used as shorthand for "service function chain" ✨

Service Overlay: An overlay network created to forward data to the required service functions 🧚

Service Topology: The service overlay connectivity forms a service topology 💜

2. Problem Space 🔥

Here are the aspects of existing service deployments that are problematic and that the SFC working group aims to fix 💅

2.1. Topological Dependencies 🌸

Network service deployments are often coupled to network topology, whether that topology is physical, virtualized, or a hybrid of the two 🙈 For example, using a firewall means traffic has to flow through it. That usually means putting the firewall on the network path (often by creating VLANs) or designing the network topology so traffic gets steered through it 💀 That dependency puts constraints on service delivery, can stop the operator from making the best use of service resources, and reduces flexibility. It limits scale, capacity, and redundancy across network resources 😭

These topologies only exist to "insert" the service function, meaning they make sure traffic goes through it. From a native packet delivery perspective, they aren't required 🦋 For example, firewalls often need an "in" and an "out" Layer 2 segment, and adding a new firewall means changing the topology (adding new Layer 2 segments and/or IP subnets) 🎀

As more service functions get added, often with strict ordering, topology changes are needed in "front" of and "behind" each service function. That leads to complicated network changes and device configuration. In these topologies, all traffic goes through the same strict order, whether or not a given service function needs to be applied to it 🌈

Topological coupling also limits where service functions can be placed and how they're selected. Service functions are "fixed" in place by topology. So placement and selection that take network topology information into account, like load, new links, or traffic engineering, often aren't possible 💖

A common example is web servers that use a server load balancer as their default gateway. When the web service responds to traffic that isn't load-balanced (like administrative or backup operations), all of the server's traffic has to traverse the load balancer. That forces network administrators to build complex routing schemes or add extra interfaces to provide an alternate topology 👑

2.2. Configuration Complexity

okay so topological dependencies have a knock-on effect that's honestly a whole mess 😭 Deploying service function chains gets complicated fast. Even something simple, like swapping the order of the service functions in a chain, means changing the logical and/or physical topology 💀 Operators get nervous about touching the network once services are installed, configured, and running in production, because they're scared of misconfiguration and the downtime that comes with it 🙈 So deployments end up super static. And changes can't happen quickly enough, since they often need manual intervention or slow provisioning systems 🐢

2.3. Constrained High Availability

ngl this one is so real 🫶 Traffic reaches many service functions based on network topology, so the alternate or redundant service functions have to live in the same topology as the primary service. The result? Availability of service functions gets boxed in by topology 📦

2.4. Consistent Ordering of Service Functions

okay so service functions are usually independent. SF1 through SFn (service function_1 to service function_n) are unrelated to each other, and the service layer has no idea that SF1 comes before SF2 🤷‍♀️ But to an administrator, a lot of service functions have a strict ordering that absolutely has to be in place. The problem is there's no consistent way to impose and verify that ordering across the service functions delivering a given service. And changing the order of a deployed chain is complex and cumbersome, which is not it 😩

2.5. Application of Service Policy

this one is giving "topology is not enough" energy 💅 Service functions depend on topology info, like VLANs or packet classification/reclassification, to pick their service policy (aka the service-function-specific action they take). But topology information is getting less viable because of scaling, tenancy, and complexity. Topology-centric info often doesn't tell the service functions enough, so each function has to do its own more granular classification 🧐 In other words, the topology info isn't granular enough, and its meaning gets overloaded 🌀

2.6. Transport Dependence

service functions can and will show up in networks with all kinds of transports, including underlays and overlays like Ethernet, Generic Routing Encapsulation (GRE), Virtual eXtensible Local Area Network (VXLAN), MPLS, and more 🦋 Because service functions are coupled to topology, they might have to support a bunch of different transport encapsulations, or else there needs to be a transport gateway function sitting in the middle. Chaotic but make it make sense 🌈

2.7. Elastic Service Delivery

the current state of the art for adding or removing service functions mostly revolves around VLANs and routing changes 🎀 So rapidly changing deployed service capacity (up or down) can be really hard to pull off, because VLAN and/or routing modifications come with a lot of risk and complexity 😵‍💫

2.8. Traffic Selection Criteria

traffic selection is kinda coarse, bestie 😭 All traffic on a particular segment goes through all the service functions, whether or not that traffic actually needs service enforcement. This happens largely because service deployment is topological: the forwarding topology decides how (and what) data goes through which service function(s) 🗺️ Some deployments get more granular traffic selection using policy routing or access control filtering. But that makes the configs operationally complex and it's still relatively coarse and inflexible 🙃

2.9. Limited End-to-End Service Visibility

troubleshooting service-related issues is a whole process that needs both network-specific and service-specific expertise 🕵️‍♀️ It gets especially intense when service function chains span multiple data centers or cross administrative boundaries. On top of that, the physical and virtual environments (network and service) can be super different in terms of topology, and that topological variance makes everything harder 💀

2.10. Classification/Reclassification per Service Function

classification happens at each service function, independently of the service functions applied before it 🔁 Why? Because there are limited mechanisms for sharing detailed classification info between services. The classification functionality also tends to differ between service functions, and they may not use the classification results from other service functions at all 🙈

2.11. Symmetric Traffic Flows

service function chains can be unidirectional or bidirectional, depending on what state the service functions need 🔄 In a unidirectional chain, traffic passes through a set of service functions in one forwarding direction only. Bidirectional chains need traffic to pass through the set of service functions in both forwarding directions. A lot of common service functions, like DPI and firewalls, often need bidirectional chaining so flow state stays consistent 🔥

Existing deployment models take a static approach to setting up forward and reverse associations of service function chains. Most of the time, that means complex configuration on every network device throughout the SFC 😩 The same complex network config has to be in place for both "directions" of traffic, which basically doubles the configuration and the testing that goes with it 💀 And if only partial symmetry is needed (only some services in the chain need symmetry), it gets even messier. The operator has to make sure the exceptions, meaning the services that don't need the symmetric flow, are handled correctly with unique configuration for their requirements 🧩

2.12. Multi-vendor Service Functions

deploying service functions from multiple vendors usually means you need per-vendor expertise 🧑‍💻 Insertion models differ, common attributes are few, and inter-vendor service functions don't share information. So standards are needed to make sure everything interoperates 🫶

3. Service Function Chaining ✨

service function chaining is all about fixing the problems we just talked about with service deployment 💖 Specifically, the SFC working group is going to investigate solutions that address the following elements.

3.1. Service Overlay

service function chaining uses a service-specific overlay that creates the service topology 🧚 The service overlay gives service function connectivity, built "on top" of the existing network topology. It lets operators use whatever overlay or underlay they like to create a path between service functions, and to place service functions wherever they're needed in the network 🌸

Inside the service topology, service functions can be seen as resources to consume, and you can build an arbitrary topology to connect those resources in the order you require 👑 Adding new service functions to the topology is easy, and no underlying network changes are needed. Lastly, the service overlay can provide the service-specific info needed for troubleshooting service-related issues 🔍

3.2. Service Classification

classification is how traffic gets selected to enter a service overlay 🎯 How granular it gets depends on device capabilities, customer requirements, and the services offered. Initial classification decides which service function chain the traffic needs to go through. Subsequent classification can be used inside a given chain to change the sequence of service functions applied ✨ Symmetric classification makes sure the forward and reverse chains are both in place. And asymmetric chains (relative to the required service function) can also be achieved through service classification 🦋

3.3. SFC Encapsulation

the SFC encapsulation is what makes a service chain possible in the data plane, and it can carry info about the chain, like chain identification and OAM status 💜

It also carries data-plane metadata, which lets info get exchanged between logical classification points and service functions (and vice versa), and between service functions themselves 🎀 Metadata is not used as forwarding information to deliver packets along the service overlay, so don't go looking for routing in there 🙅‍♀️

Metadata can include the result of antecedent classification and/or info from external sources. Service functions use metadata, as required, to make localized policy decisions 🧠

Beyond sharing info, metadata helps tackle several of the issues from Section 2, most notably by decoupling policy from the network topology, and by removing the need for classification (and reclassification) per service function, as described in Section 2.10. It's giving main character energy 👑

A common approach to service metadata creates a foundation for interoperability between service functions, regardless of vendor. That's the whole vibe, periodt 💅

4. Security Considerations ✨

okay bestie, so this problem statement doesn't introduce any protocols 🫶 but when we think about service function chaining, the three main areas the WG has been looking into (see Section 3) have security stuff that deserves real attention 🔒💅

Service Overlay 🦋

The service overlay is built on existing transport protocols (e.g., MPLS, VXLAN) 🌸 so it's subject to the security specifics of whichever transport gets picked. ngl that's just how it goes. If an operator needs authenticity and/or confidentiality in the service overlay, a transport (e.g., IPsec) that provides that functionality can be used 🔐✨

Classification 🎀

okay this one is giving main character energy 👑 because classification is what selects the right service overlay and the required service encapsulation details, so the classification policy has to be both accurate and trusted 💯 Getting the policy out to an SFC edge node (a node that forms the logical boundary of an SFC domain) can be done in a bunch of different ways 🧚, depending on the operator's existing provisioning practices and security posture 💜

Also, traffic entering the SFC domain and getting classified might be encrypted 🙈, which limits how granular the classification can be. How much pervasive encryption gets used depends on the type of traffic, the environment, and how much control the operator has 🌈 For example, a large enterprise can mandate how its users use encryption, whereas a broadband provider likely can't do that 😭

The use of encrypted traffic does NOT obviate the need for SFC, nor the problems with current deployment models described in this document 💀 Instead, when encrypted traffic has to be classified, the granularity of that classification must adapt 🔥 In those cases, service overlay selection might happen using outer (i.e., unencrypted) header information (in the presence of encryption) or external information about the packets 🦋

SFC Encapsulation 🍓

As described in Section 3, the SFC encapsulation carries information about the SFC and data-plane metadata 🧚 Depending on the environment and security posture, the SFC encapsulation might need to be authenticated and/or encrypted 🔐 Using an appropriate overlay transport (as described above) can provide data-plane confidentiality and authenticity 💖

The exchange of SFC encapsulation data, such as metadata, MUST originate from trusted source(s) 🚨 Also, if needed, authentication and confidentiality protection SHOULD be provided during the exchange to the various SFC nodes 🫶

SFC and Multi-tenancy 👑

If tenant isolation is required in an SFC deployment, an appropriate network transport overlay that provides adequate isolation and identification can be used 🌸 Tenancy might also be used when selecting the appropriate service chain 💅 However, as already stated, the network overlay is still REQUIRED to provide transport isolation ✨ How SF deployment works and whether specific SFs get allocated per tenant is outside the scope of this document 🙈

The SFC Architecture document [SFC-ARCH] gives a much more complete review of the security implications of a full SFC architecture 📚💜

5. Informative References 📚

[RFC3022] : Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, 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, April 2011, <http://www.rfc-editor.org/info/rfc6146>. 🧚

[SFC-ARCH] : Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", Work in Progress, draft-ietf-sfc-architecture-07, March 2015. 🦋

Acknowledgments 🫶

The authors would like to thank David Ward, Rex Fernando, David McDysan, Jamal Hadi Salim, Charles Perkins, Andre Beliveau, Joel Halpern, and Jim French for their reviews and comments 💖

Additionally, the authors would like to thank the IESG and Benjamin Kaduk for their detailed reviews and suggestions ✨

Contributors 🌈

The following people are active contributors to this document and have provided review, content and concepts (listed alphabetically by surname):

Puneet Agarwal Broadcom EMail: pagarwal@broadcom.com

Mohamed Boucadair France Telecom EMail: mohamed.boucadair@orange.com

Abhishek Chauhan Citrix EMail: Abhishek.Chauhan@citrix.com

Uri Elzur Intel EMail: uri.elzur@intel.com

Kevin Glavin Riverbed EMail: Kevin.Glavin@riverbed.com

Ken Gray Cisco Systems EMail: kegray@cisco.com

Jim Guichard Cisco Systems EMail:jguichar@cisco.com

Christian Jacquenet France Telecom EMail: christian.jacquenet@orange.com

Surendra Kumar Cisco Systems EMail: smkumar@cisco.com

Nic Leymann Deutsche Telekom EMail: n.leymann@telekom.de

Darrel Lewis Cisco Systems EMail: darlewis@cisco.com

Rajeev Manur Broadcom EMail:rmanur@broadcom.com

Brad McConnell Rackspace EMail: bmcconne@rackspace.com

Carlos Pignataro Cisco Systems EMail: cpignata@cisco.com

Michael Smith Cisco Systems EMail: michsmit@cisco.com

Navindra Yadav Cisco Systems EMail: nyadav@cisco.com

Authors' Addresses 💌

Paul Quinn (editor) Cisco Systems, Inc.

EMail: paulq@cisco.com

Thomas Nadeau (editor) Brocade

EMail: tnadeau@lucidvision.com