| Internet-Draft | NSH extensions for distributed SFC | March 2022 |
| Bernardos & Mourad | Expires 22 September 2022 | [Page] |
Service function chaining (SFC) allows the instantiation of an ordered set of service functions and subsequent "steering" of traffic through them. In order to set up and maintain SFC instances, a control plane is required, which typically is centralized. In certain environments, such as fog computing ones, such centralized control might not be feasible, calling for distributed SFC control solutions. This document specifies several NSH extensions to provide in-band SFC control signaling.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 22 September 2022.¶
Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Virtualization of functions provides operators with tools to deploy new services much faster, as compared to the traditional use of monolithic and tightly integrated dedicated machinery. As a natural next step, mobile network operators need to re-think how to evolve their existing network infrastructures and how to deploy new ones to address the challenges posed by the increasing customers' demands, as well as by the huge competition among operators. All these changes are triggering the need for a modification in the way operators and infrastructure providers operate their networks, as they need to significantly reduce the costs incurred in deploying a new service and operating it. Some of the mechanisms that are being considered and already adopted by operators include: sharing of network infrastructure to reduce costs, virtualization of core servers running in data centers as a way of supporting their load-aware elastic dimensioning, and dynamic energy policies to reduce the monthly electricity bill. However, this has proved to be tough to put in practice, and not enough. Indeed, it is not easy to deploy new mechanisms in a running operational network due to the high dependency on proprietary (and sometime obscure) protocols and interfaces, which are complex to manage and often require configuring multiple devices in a decentralized way.¶
Service Functions are widely deployed and essential in many networks. These Service Functions provide a range of features such as security, WAN acceleration, and server load balancing. Service Functions may be instantiated at different points in the network infrastructure such as data center, the WAN, the RAN, and even on mobile nodes.¶
Service functions (SFs), also referred to as VNFs, or just functions, are hosted on compute, storage and networking resources. The hosting environment of a function is called Service Function Provider or NFVI-PoP (using ETSI NFV terminology).¶
Services are typically formed as a composition of SFs (VNFs), with each SF providing a specific function of the whole service. Services also referred to as Network Services (NS), according to ETSI terminology.¶
With the arrival of virtualization, the deployment model for service function is evolving to one where the traffic is steered through the functions wherever they are deployed (functions do not need to be deployed in the traffic path anymore). For a given service, the abstracted view of the required service functions and the order in which they are to be applied is called a Service Function Chain (SFC). An SFC is instantiated through selection of specific service function instances on specific network nodes to form a service graph: this is called a Service Function Path (SFP). The service functions may be applied at any layer within the network protocol stack (network layer, transport layer, application layer, etc.).¶
The concept of fog computing has emerged driven by the Internet of Things (IoT) due to the need of handling the data generated from the end-user devices. The term fog is referred to any networked computational resource in the continuum between things and cloud. A fog node may therefore be an infrastructure network node such as an eNodeB or gNodeB, an edge server, a customer premises equipment (CPE), or even a user equipment (UE) terminal node such as a laptop, a smartphone, or a computing unit on-board a vehicle, robot or drone.¶
In fog computing, the functions composing an SFC are hosted on resources that are inherently heterogeneous, volatile and mobile [I-D.bernardos-sfc-fog-ran]. This means that resources might appear and disappear, and the connectivity characteristics between these resources may also change dynamically. These scenarios call for distributed SFC control solutions, where there are SFC pseudo controllers, enabling autonomous SFC self-orchestration capabilities. The concept of SFC pseudo controller (P-CTRL) is described in [I-D.bernardos-sfc-distributed-control], as well different procedures for their discovery and initialization.¶
This document specifies several NSH extensions to provide in-band SFC control signaling.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶
The following terms used in this document are defined by the IETF in [RFC7665]:¶
The following terms are used in this document:¶
o
node B |
+--------|-+ F1+-·-·-+F2+-·-·-+F3 SFC
| ········ |
| |P-CTRL| |
| ········ |
+-·-·-+F2 |
o / +---+------+ ________
| · · _( )_
+--------|-+ / / _( +--------+ )_
| | · · (_ | C-CTRL | _)
| | / / (_+--------+_)
| |· | (________)
| +-·-·/ ·
| F1 | | ( (oo) )
+----------+ · o /\ ········
node A | | /\/\ |P-CTRL|
+-----·--|-+ /\/\/\········
| | | /\/ \/\ F3
| · | node D
| | |
| + |
| |
+----------+
node C
Figure 1 shows an exemplary scenario to show the use of the new NSH extensions. In this scenario, there is no mobility, so nodes are not moving out of radio coverage. In this scenario, at a given point in time the service demands increase, which requires F2 (running at node B) and F3 (running at node D) to have more resources allocated, as otherwise the service would not meet the required SLA. This is detected by the P-CTRL through service-specific local OAM monitoring. Once detected the need of scaling up the resources at nodes B and D, P-CTRL notifies this through in-band signaling in the actual data packets processed by the SFC. This is shown in Figure 2. Note that the use of in-band signaling provides a more efficient way of conveying the signaling, as well as supports multiple NS lifecycle management operations (even addressing different nodes) to be conveyed in a single message.¶
+--------+ +--------+ +--------+
| F1@A | | F2@B | | F3@D |
+--------+ +--------+ +--------+
+--------+ +--------+ +--------+
|Transp. | |Transp. | |Transp. |
| header | | header | | header |
+--------+ +--------+ +--------+
| NSH | | NSH | | NSH |
| header | | header | | header |
| F3@D | | F3@D | | F3@D |
|scale up| |scale up| |scale up|
| F2@B | | F2@B | | |
|scale up| |scale up| | |
+--------+ +--------+ +--------+ +--------+ +--------+
| Packet | | Packet | | Packet | | Packet | | Packet |
+--------+ +--------+ +--------+ +--------+ +--------+
===> ===> ===> ===> ===>
The NS lifecycle management commands conveyed in the NSH are transported as a new NSH metadata (MD) type (e.g., Type 3, as current NSH specifications only support 2 types), as shown next:¶
0 1 2 3 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Variable-Length NS lifecycle management commands ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
The format of the new variable-length field for NS lifecycle management commands is shown next:¶
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NS lifecycle cmd | Type |U| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable-Length Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
NS lifecycle cmd: the NS lifecycle management command. This is a non-limiting list of the commands:¶
N/A.¶
The work in this draft has been partially supported by the H2020 5Growth (Grant 856709) and 5G-DIVE projects (Grant 859881).¶