From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8459.txt | 1627 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1627 insertions(+) create mode 100644 doc/rfc/rfc8459.txt (limited to 'doc/rfc/rfc8459.txt') diff --git a/doc/rfc/rfc8459.txt b/doc/rfc/rfc8459.txt new file mode 100644 index 0000000..1662dc5 --- /dev/null +++ b/doc/rfc/rfc8459.txt @@ -0,0 +1,1627 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Dolson +Request for Comments: 8459 Sandvine +Category: Experimental S. Homma +ISSN: 2070-1721 NTT + D. Lopez + Telefonica I+D + M. Boucadair + Orange + September 2018 + + + Hierarchical Service Function Chaining (hSFC) + +Abstract + + Hierarchical Service Function Chaining (hSFC) is a network + architecture allowing an organization to decompose a large-scale + network into multiple domains of administration. + + The goals of hSFC are to make a large-scale network easier to design, + simpler to control, and supportive of independent functional groups + within large network operators. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are candidates for any level of + Internet Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8459. + + + + + + + + + + + +Dolson, et al. Experimental [Page 1] + +RFC 8459 hSFC September 2018 + + +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 + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dolson, et al. Experimental [Page 2] + +RFC 8459 hSFC September 2018 + + +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 . . . . . . . . . . . . . . . . . . . . . . . 29 + + + + + + + + + + + + + + + + +Dolson, et al. Experimental [Page 3] + +RFC 8459 hSFC September 2018 + + +1. Introduction + + Service Function Chaining (SFC) is a technique for prescribing + differentiated traffic-forwarding policies within an SFC-enabled + domain. The SFC architecture is described in detail in [RFC7665] and + is not repeated here. + + This document focuses on the difficult problem of implementing SFC + across a large, geographically dispersed network, potentially + comprised of millions of hosts and thousands of network-forwarding + elements and which may involve multiple operational teams (with + varying functional responsibilities). We recognize that some + stateful Service Functions (SFs) require bidirectional traffic for + transport-layer sessions (e.g., NATs, firewalls). We assume that + some Service Function Paths (SFPs) need to be selected on the basis + of transport-layer coordinate (typically, the 5-tuple of source IP + address, source port number, destination IP address, destination port + number, and transport protocol) stickiness to specific stateful SF + instances. + + Difficult problems are often made easier by decomposing them in a + hierarchical (nested) manner. So, instead of considering a single + SFC control plane that can manage (create, withdraw, supervise, etc.) + complete SFPs from one end of the network to the other, we decompose + the network into smaller domains operated by as many SFC control + plane components (under the same administrative entity). + Coordination between such components is further discussed 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 + to ease monitoring and troubleshooting of the network and services as + a whole. The criteria for decomposing a domain into multiple SFC- + enabled subdomains are beyond the scope of this document. These + criteria are deployment specific. + + An example of simplifying a network by using multiple SFC-enabled + domains is further discussed in [USE-CASES]. + + We assume the SFC-aware nodes use the Network Service Header (NSH) + [RFC8300] or a similar labeling mechanism. Examples are described in + Appendix A. + + The SFC-enabled domains discussed in this document are assumed to be + under the control of a single organization (an operator, typically), + such that there is a strong trust relationship between the domains. + The intention of creating multiple domains is to improve the ability + + + + +Dolson, et al. Experimental [Page 4] + +RFC 8459 hSFC September 2018 + + + to operate a network. It is outside of the scope of this document to + consider domains operated by different organizations or dwell on + interoperator considerations. + + We introduce the concept of an Internal Boundary Node (IBN) that acts + as a gateway between the levels of the hierarchy. We also discuss + options for realizing this function. + +1.1. Experiment Goals + + This document defines an architecture that aims to solve + complications that may be encountered when deploying SFC in large + networks. A single network is therefore decomposed into multiple + subdomains, each treated as an SFC-enabled domain. Levels of + hierarchy are defined, together with SFC operations that are specific + to each level. In order to ensure consistent SFC operations when + multiple subdomains are involved, this document identifies and + analyzes various options for IBNs to glue the layers together + (Section 4.1). + + Because it does not make any assumptions 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, this document does not call for a recommended option to + glue the SFC layers together. + + Further experiments are required to test and evaluate the different + options. A recommendation for hSFC might be documented in a future + specification when the results of implementation and deployment of + the aforementioned options are available. + + It is not expected that all the options discussed in this document + will be implemented and deployed. The lack of an implementation + might be seen as a signal to recommend against a given option. + + + + + + + + + + + + + + + +Dolson, et al. Experimental [Page 5] + +RFC 8459 hSFC September 2018 + + +2. Terminology + + This document makes use of the terms defined in Section 1.4 of + [RFC7665] and Section 1.3 of [RFC8300]. + + The following terms are defined: + + o Upper-level domain: the entire network domain to be managed. + + o Lower-level domain: a portion of the network (called a subdomain). + + o Internal Boundary Node (IBN): is responsible for bridging packets + between 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. These levels are discussed in the following + subsections. + +3.1. Upper Level + + Considering the example depicted in Figure 1, a top-level network + domain includes SFC data plane components distributed over a wide + area, including: + + o Classifiers (CFs) + + o Service Function Forwarders (SFFs) + + o Subdomains + + + + + + + + + + + + + + + + + + + +Dolson, et al. Experimental [Page 6] + +RFC 8459 hSFC September 2018 + + + +------------+ + |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 Hierarchy + + One path is shown from edge classifier (CF#1) to SFF1 to Subdomain#1 + (residing in Data Center 1) to SFF1 to SFF2 (residing in Data Center + 2) to Subdomain#2 to SFF2 to network egress. + + For the sake of clarity, components of the underlay network are not + shown; an underlay network is assumed to provide connectivity between + SFC data plane components. + + Top-level SFPs carry packets from classifiers through a set of SFFs + and subdomains, with the operations within subdomains being opaque to + the upper levels. + + We expect the system to include a top-level control plane having + responsibility for configuring forwarding policies and traffic- + classification rules. + + The top-level Service Chaining control plane manages end-to-end + service chains and associated service function paths from network + edge points to subdomains. It also configures top-level classifiers + + + + +Dolson, et al. Experimental [Page 7] + +RFC 8459 hSFC September 2018 + + + at a coarse level (e.g., based on source or destination host) to + forward traffic along paths that will transit across appropriate + subdomains. + + Figure 1 shows one possible service chain passing from the edge + through two subdomains to network egress. The top-level control + plane does not configure traffic-classification rules or forwarding + policies within the subdomains. + + At this network-wide level, the number of SFPs required is a linear + function of the number of ways in which a packet is required to + traverse different subdomains and egress the network. Note that the + various paths that may be followed within a subdomain are not + represented by distinct network-wide SFPs; specific policies at the + ingress nodes of each subdomain bind flows to subdomain paths. + + Packets are classified at the edge of the network to select the paths + by which subdomains are to be traversed. At the ingress of each + subdomain, packets are reclassified to paths directing them to the + required SFs of the subdomain. At the egress of each subdomain, + packets are returned to the top-level paths. Contrast this with an + approach requiring the top-level classifier to select paths to + specify all of the SFs in each subdomain. + + It should be assumed that some SFs require bidirectional symmetry of + paths (see more in Section 5). Therefore, the classifiers at the top + level must be configured with policies ensuring outgoing packets take + the reverse path of incoming packets through subdomains. + +3.2. Lower Levels + + Each of the subdomains in Figure 1 is an SFC-enabled domain. + + Figure 2 shows a subdomain interfaced with an upper-level domain by + means of 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. As such, data packets entering the subdomain are + already SFC encapsulated. Also, it is the purpose of the IBN to + apply classification rules and direct the packets to the selected + local SFPs terminating at an egress IBN. Finally, the egress IBN + restores packets to the original SFC shim and hands them off to SFFs. + + Each subdomain intersects a subset of the total paths that are + possible in the upper-level domain. An IBN is concerned with upper- + level paths, but only those traversing its subdomain. + + + + + + +Dolson, et al. Experimental [Page 8] + +RFC 8459 hSFC September 2018 + + + Each subdomain is likely to have a control plane that can operate + independently of the top-level control plane, managing + classification, forwarding paths, etc., within the level of the + subdomain, with the details being opaque to the upper-level control + elements. Section 4 provides more details about the behavior of an + IBN. + + The subdomain control plane configures the classification rules in + the IBN, where SFC encapsulation of the top-level domain is converted + to/from SFC encapsulation of the lower-level domain. The subdomain + control plane 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 Domain + + If desired, the pattern can be applied recursively. For example, + SF#1.1 in Figure 2 could be a subdomain of the subdomain. + + + + + +Dolson, et al. Experimental [Page 9] + +RFC 8459 hSFC September 2018 + + +4. Internal Boundary Node (IBN) + + As mentioned in the previous section, a network element termed an + "Internal Boundary Node" (or IBN) is responsible for bridging packets + between upper and lower layers of SFC-enabled domains. It behaves as + an SF to the upper level (Section 3.1) and looks like a classifier + and end of chain to the lower level (Section 3.2). + + To achieve the benefits of hierarchy, the IBN should be applying + fine-grained traffic-classification rules at a lower level than the + traffic passed to it. This means that the number of SFPs within the + lower level is greater than the number of SFPs arriving to the IBN. + + The IBN is also the termination of lower-level SFPs. This is because + the packets exiting lower-level SFPs must 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 further responsibilities: when packets enter the subdomain, the + IBN translates upper-level metadata into lower-level metadata; and + when packets leave the subdomain at the termination of lower-level + SFPs, the IBN translates lower-level metadata into upper-level + metadata. + + Appropriately configuring IBNs is key to ensuring the consistency of + the overall SFC operation within a given domain that enables hSFC. + Classification rules (or lack thereof) in the IBN classifier can, of + course, impact upper levels. + +4.1. IBN Path Configuration + + The lower-level domain may be provisioned with valid upper-level + paths or 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 selected + by the (subdomain) classifier. + + At the termination of an SFP in the subdomain, packets can be + restored to an original upper-level SFP by implementing one of these + methods: + + 1. Saving the SPI and SI in transport-layer flow state + (Section 4.1.1). + + 2. Pushing the SPI and SI into a metadata header (Section 4.1.2). + + + + + +Dolson, et al. Experimental [Page 10] + +RFC 8459 hSFC September 2018 + + + 3. Using unique lower-level paths per upper-level path coordinates + (Section 4.1.3). + + 4. Nesting NSH headers, encapsulating the upper-level NSH headers + within the lower-level NSH headers (Section 4.1.4). + + 5. 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 + + An IBN can be flow aware, returning packets to the correct upper- + level SFP on the basis, for example, of the transport-layer + coordinates (typically, a 5-tuple) of packets exiting the lower-level + SFPs. + + When packets are received by the IBN on an upper-level path, the + classifier parses encapsulated packets for IP and transport-layer + (TCP, UDP, etc.) coordinates. State is created, indexed by some or + all transport coordinates (typically, {source-IP, destination-IP, + source-port, destination-port, and transport protocol}). The state + contains, at minimum, the critical fields of the encapsulating SFC + header (SPI, SI, MD Type, flags); additional information carried in + the packet (metadata, TTL) may also be extracted and saved as state. + Note that some fields of a packet may be altered by an SF of the + subdomain (e.g., source IP address). + + Note that this state is only accessed by the classifier and + terminator functions of the subdomain. Neither the SFFs nor SFs have + knowledge of this state; in fact they may be agnostic about being in + a subdomain. + + One approach is to ensure that packets are terminated at the end of + the chain at the same IBN that classified the packet at the start of + the chain. If the packet is returned to a different egress IBN, + state must be synchronized between the IBNs. + + 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 is + removed, the packet is parsed for flow-identifying information, and + state is retrieved from within the IBN using the flow-identifying + information as index. + + State cannot be created by packets arriving from the lower-level + chain; when state cannot be found for such packets, they must be + dropped. + + + + + +Dolson, et al. Experimental [Page 11] + +RFC 8459 hSFC September 2018 + + + This stateful approach is limited to use with SFs that retain the + transport coordinates of the packet. This approach cannot be used + with SFs that modify those coordinates (e.g., NATs) or otherwise + create packets for new coordinates other than those received (e.g., + as an HTTP cache might do to retrieve content on behalf of the + original flow). In both cases, the fundamental problem is the + inability to forward packets when state cannot be found for the + packet transport-layer coordinates. + + In the stateful approach, there are issues caused by having state, + such as how long the state should be maintained as well as whether + the state needs to be replicated to other devices to create a highly + available network. + + It is valid to consider the state to be disposable after failure, + since it can be recreated by each new packet arriving from the upper- + level domain. For example, if an IBN loses all flow state, the state + is recreated by an endpoint retransmitting a TCP packet. + + If an SFC domain handles multiple network regions (e.g., multiple + private networks), the coordinates may be augmented with additional + parameters, perhaps using some metadata to identify the network + region. + + In this stateful approach, it is not necessary for the subdomain's + control plane to modify paths when upper-level paths are changed. + The complexity of the upper-level domain does not cause complexity in + the lower-level domain. + + Since it doesn't depend on NSH in the lower-level domain, this flow- + stateful approach can be applied to translation methods of converting + 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 encoding thereof) into + a metadata field of the lower-level encapsulation (e.g., placing + 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 retrieved from the packet. + + This approach requires the SFs in the path to be capable of + forwarding the metadata and appropriately attaching metadata to any + packets injected for a flow. + + Using a new metadata header may inflate packet size when variable- + length metadata (NSH MD Type 0x2) is used. + + + + +Dolson, et al. Experimental [Page 12] + +RFC 8459 hSFC September 2018 + + + It is conceivable that the MD Type 0x1 Fixed-Length Context Header + field of the NSH is not all relevant to the lower-level domain. In + this case, 32 bits of the Fixed-Length Context Header field could be + repurposed within the lower-level domain and restored when leaving. + + If flags or TTL (see Section 4.4) from the original header also need + to be saved, more metadata space will be consumed. + + In this metadata approach, it is not necessary for the subdomain's + control element to modify paths when upper-level paths are changed. + The complexity of the upper-level domain does not increase complexity + in the lower-level domain. + +4.1.3. Using Unique Paths per Upper-Level Path + + This approach assumes that paths within the subdomain are constrained + so that an SPI (of the subdomain) unambiguously indicates the egress + SPI and SI (of the upper domain). This allows the original path + information to be restored at subdomain egress from a look-up table + using the subdomain SPI. + + Whenever the upper-level domain provisions a path via the lower-level + domain, the lower-level domain control plane must provision + corresponding paths to traverse the lower-level domain. + + A downside of this approach is that the number of paths in the lower- + level domain is multiplied by the number of paths in the upper-level + domain that traverse the lower-level domain. That is, a subpath must + be created for each combination of upper SPI/SI and lower chain. The + number of paths required for lower-level domains will increase + exponentially as hierarchy becomes deep. + + A further downside of this approach is that it requires upper and + lower levels to utilize the same metadata configuration. + + Furthermore, this approach does not allow any information to be + stashed away in state or embedded in metadata. For example, the TTL + modifications by the lower level cannot be hidden from the upper + level. + +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 determines the path for the lower-level domain and pushes + the new NSH header in front of the original NSH header. + + + + + + +Dolson, et al. Experimental [Page 13] + +RFC 8459 hSFC September 2018 + + + As shown in Figure 3, the Lower-NSH header used to forward packets in + the lower-level domain precedes 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 + + The traffic with this stack of two NSH headers is to be forwarded + according to the Lower-NSH header in the lower-level SFC domain. The + Upper-NSH header is preserved in the packets but not used for + forwarding. At the last SFF of the chain of the lower-level domain + (which resides in the IBN), the Lower-NSH header is removed from the + packet, and then the packet is forwarded by the IBN to an SFF of the + upper-level domain. The packet will be forwarded in the top-level + domain according to the Upper-NSH header. + + With such encapsulation, Upper-NSH information is carried along the + extent of the lower-level chain without modification. + + A benefit of this approach is that it does not require state in the + IBN or configuration to encode fields in metadata. All header + fields, including flags and TTL, are easily restored when the chains + of the subdomain terminate. + + However, the downside is that it does require SFC-aware SFs in the + lower-level domain to be able to parse multiple NSH layers. If an + SFC-aware SF injects packets, it must also be able to deal with + adding appropriate multiple layers of headers to injected packets. + + By increasing packet overhead, nesting may lead to fragmentation or + decreased MTU in some networks. + +4.1.5. Stateful/Metadata Hybrid + + The basic idea of this approach is for the IBN to save upper domain + encapsulation information such that it can be retrieved by a unique + identifier, termed an "hSFC Flow ID". + + + + + +Dolson, et al. Experimental [Page 14] + +RFC 8459 hSFC September 2018 + + + The hSFC Flow ID is 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, 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. The hSFC Flow ID Context Header is then + stripped by the IBN. + + 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: + + o It does not 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, + such as NATs. + + o It does not require all domains to have the same metadata scheme. + + o It can be used to restore any upper-domain information, including + metadata, flags, and TTL, not just the service path. + + o The lower-level domain only requires a single item of metadata + regardless of the number of items of metadata used in the upper + domain. + + o 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]. + + Disadvantages include those of other stateful approaches, including + state timeout and synchronization, mentioned in Section 4.1.1. + + + + + + + +Dolson, et al. Experimental [Page 15] + +RFC 8459 hSFC September 2018 + + + There may be a large number of unique NSH encapsulations to be + stored, given that the hSFC Flow ID must represent all of the bits in + the upper-level encapsulation. This might consume a lot of memory or + + create out-of-memory situations in which hSFC Flow IDs cannot be + created or old hSFC Flow IDs are discarded while still in use. + +4.2. Gluing Levels Together + + The SPI or metadata included in a packet received by the IBN may be + used as input to reclassification and path selection within a lower- + level domain. + + In some cases, the meanings of the various path IDs and metadata must + be coordinated between domains for the sake of proper end-to-end SFC + operation. + + One approach is to use well-known identifier values in metadata, + maintained in a global registry. + + Another approach is to use well-known labels for chain identifiers or + metadata, 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". + +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. + +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. + + + + + +Dolson, et al. Experimental [Page 16] + +RFC 8459 hSFC September 2018 + + + Some readers may recognize this as a choice between "pipe" and + "uniform" models, respectively [RFC3443]. + + 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. + + 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. + +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. + + 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. + + 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. + + 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. + + + + + + + +Dolson, et al. Experimental [Page 17] + +RFC 8459 hSFC September 2018 + + +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: + + o Each control-plane instance manages a single level of the + hierarchy of a single domain. + + o 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.) + + o 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. + + 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. + +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. + + + + + + + + + + + + +Dolson, et al. Experimental [Page 18] + +RFC 8459 hSFC September 2018 + + + * * * * * * * * * * * * * * * * * * + * 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: + + o In a period of transition from legacy SFs to NSH-aware SFs + + o Supporting multitenancy + + + + +Dolson, et al. Experimental [Page 19] + +RFC 8459 hSFC September 2018 + + +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: + + o Saving SPI and SI in transport-layer flow state (refer to + Section 4.1.1) + + o 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. + + 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. + + 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. + + + + + + + +Dolson, et al. Experimental [Page 20] + +RFC 8459 hSFC September 2018 + + + 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 + + Security considerations related to the control plane are discussed in + the corresponding control specification documents (e.g., + [BGP-CONTROL], [PCEP-EXTENSIONS], or [RADIUS]). + + + + + + +Dolson, et al. Experimental [Page 21] + +RFC 8459 hSFC September 2018 + + +9.2. Infinite Forwarding Loops + + Distributing policies among multiple domains may lead to forwarding + loops. NSH supports the ability to detect loops (as described in + Sections 4.3 and 4.4 of [RFC8300]), but the means of ensuring the + consistency of the policies should be enabled at all levels of a + domain. Within the context of hSFC, it is the responsibility of the + Control Elements at all levels to prevent such (unwanted) loops. + +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, + . + + [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., + "Network Service Header (NSH)", RFC 8300, + DOI 10.17487/RFC8300, January 2018, + . + +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, + . + + + + + + + +Dolson, et al. Experimental [Page 22] + +RFC 8459 hSFC September 2018 + + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dolson, et al. Experimental [Page 23] + +RFC 8459 hSFC September 2018 + + +Appendix A. Examples of Hierarchical Service Function Chaining + + The advantage of hSFC compared with normal or flat service function + chaining is that it can reduce the management complexity + significantly. This section discusses examples that show those + advantages. + +A.1. Reducing the Number of Service Function Paths + + In this case, hSFC is used to simplify service function chaining + management by reducing the number of SFPs. + + As shown in Figure 6, there are two domains, each with different + concerns: a Security Domain that selects SFs based on network + conditions and an Optimization Domain that selects 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 the + five different security policies, and the Optimization Domain + operator wants to apply different optimizations (either cache or + video optimization) to each of these two types of traffic. If we use + flat SFC (normal branching), 10 SFPs are needed in each domain. In + contrast, if we use hSFC, only five SFPs in Security Domain and two + SFPs in Optimization Domain will be 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 cause the flat model to require 15 + paths (five more) but cause the hSFC model to require one more path + in the Optimization Domain. + + + + + + + + + + + + + + + + + + + +Dolson, et al. Experimental [Page 24] + +RFC 8459 hSFC September 2018 + + + . . . . . . . . . . . . . . . . . . . . . . . . . + . 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 Inspection + + The 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) + + + + + + + + + + + + + +Dolson, et al. Experimental [Page 25] + +RFC 8459 hSFC September 2018 + + + . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . + . 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 hSFC + +A.2. Managing a Distributed DC Network + + Hierarchical service function chaining can be used to simplify inter- + DC SFC management. In the example of Figure 8, there is 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 are under a single administrative domain. + + The central DC may have some service functions that the local DC + needs, such that the local DC needs to chain traffic via the central + DC. This could be because: + + o 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. + + o 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. + + + + + + + + + + + + +Dolson, et al. Experimental [Page 26] + +RFC 8459 hSFC September 2018 + + + +-----------+ + |Central DC | + +-----------+ + ^ ^ ^ + | | | + .---|--|---|----. + / / | | \ + / / | \ \ + +-----+ / / | \ \ +-----+ + |Local| | / | \ | |Local| + |DC#1 |--|--. | .----|----|DC#3 | + +-----+ | | | +-----+ + \ | / + \ | / + \ | / + '----------------' + | + +-----+ + |Local| + |DC#2 | + +-----+ + + + Figure 8: Simplify Inter-DC SFC Management + + For 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, requiring 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 using hierarchical SFC, each DC can be managed + independently to significantly reduce 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). + + + + + + + + +Dolson, et al. Experimental [Page 27] + +RFC 8459 hSFC September 2018 + + +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 Larose + + Thanks to Ines Robles, Sean Turner, Vijay Gurbani, Ben Campbell, and + Benjamin Kaduk for their review. + + + + + + + + + + + + + + + + + + + + + + + + + +Dolson, et al. Experimental [Page 28] + +RFC 8459 hSFC September 2018 + + +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 + + + + + + + + + + + + + + + + +Dolson, et al. Experimental [Page 29] + -- cgit v1.2.3