RFC 8677: Name-Based Service Function Forwarder (nSFF) Component within a Service Function Chaining (SFC) Framework

RFC 8677	Name-Based SFF	November 2019
Trossen, et al.	Informational	[Page]

Abstract

Adoption of cloud and fog technology allows operators to deploy a single "Service Function" (SF) to multiple "Execution locations". The decision to steer traffic to a specific location may change frequently based on load, proximity, etc. Under the current Service Function Chaining (SFC) framework, steering traffic dynamically to the different execution endpoints requires a specific "rechaining", i.e., a change in the service function path reflecting the different IP endpoints to be used for the new execution points. This procedure may be complex and take time. In order to simplify rechaining and reduce the time to complete the procedure, we discuss separating the logical Service Function Path (SFP) from the specific execution endpoints. This can be done by identifying the Service Functions using a name rather than a routable IP endpoint (or Layer 2 address). This document describes the necessary extensions, additional functions, and protocol details in SFF (Service Function Forwarder) to handle name-based relationships.¶

This document presents InterDigital's approach to name-based SFC. It does not represent IETF consensus and is presented here so that the SFC community may benefit from considering this mechanism and the possibility of its use in the edge data centers.¶

3. Example Use Case: 5G Control-Plane Services

We exemplify the need for chaining service functions at the level of a service name through a use case stemming from the current 3GPP Release 16 work on Service Based Architecture (SBA) [SDO-3GPP-SBA], [SDO-3GPP-SBA-ENHANCEMENT]. In this work, mobile network control planes are proposed to be realized by replacing the traditional network function interfaces with a fully service-based one. HTTP was chosen as the application-layer protocol for exchanging suitable service requests [SDO-3GPP-SBA]. With this in mind, the exchange between, for example, the 3GPP-defined (Rel. 15) Session Management Function (SMF) and the Access and Mobility Management Function (AMF) in a 5G control plane is being described as a set of web-service-like requests that are, in turn, embedded into HTTP requests. Hence, interactions in a 5G control plane can be modeled based on service function chains where the relationship is between the specific (IP-based) service function endpoints that implement the necessary service endpoints in the SMF and AMF. The service functions are exposed through URIs with work ongoing to define the used naming conventions for such URIs.¶

This move from a network function model (in pre-Release 15 systems of 3GPP) to a service-based model is motivated through the proliferation of data-center operations for mobile network control-plane services. In other words, typical IT-based methods to service provisioning, particularly that of virtualization of entire compute resources, are envisioned to being used in future operations of mobile networks. Hence, operators of such future mobile networks desire to virtualize service function endpoints and direct (control-plane) traffic to the most appropriate current service instance in the most appropriate (local) data center, such data center envisioned as being interconnected through a software-defined wide area network (SD-WAN). "Appropriate" here can be defined by topological or geographical proximity of the service initiator to the service function endpoint. Alternatively, network or service instance compute load can be used to direct a request to a more appropriate (in this case less loaded) instance to reduce possible latency of the overall request. Such data-center-centric operation is extended with the trend towards regionalization of load through a "regional office" approach, where micro data centers provide virtualizable resources that can be used in the service execution, creating a larger degree of freedom when choosing the "most appropriate" service endpoint for a particular incoming service request.¶

While the move to a service-based model aligns well with the framework of SFC, choosing the most appropriate service instance at runtime requires so-called "rechaining" of the SFC since the relationships in said SFC are defined through Layer 2 or 3 identifiers, which, in turn, are likely to be different if the chosen service instances reside in different parts of the network (e.g., in a regional data center).¶

Hence, when a traffic flow is forwarded over a service chain expressed as an SFC-compliant Service Function Path (SFP), packets in the traffic flow are processed by the various service function instances, with each service function instance applying a service function prior to forwarding the packets to the next network node. It is a service-layer concept and can possibly work over any Virtual network layer, Underlay network, or possibly over an IP or any Layer 2 technology. At the service layer, Service Functions are identified using a path identifier and an index. Eventually, this index is translated to an IP address (or MAC address) of the host where the service function is running. Because of this, any change-of-service function instance is likely to require a change of the path information since either the IP address (in the case of changing the execution from one data center to another) or MAC address will change due to the newly selected service function instance.¶

Returning to our 5G control-plane example, a user's connection request to access an application server in the internet may start with signaling in the Control Plane to set up user-plane bearers. The connection request may flow through service functions over a service chain in the control plane, as deployed by a network operator. Typical SFs in a 5G control plane may include "RAN termination / processing", "Slice Selection Function", "AMF", and "SMF". A "Network Slice" is a complete logical network including Radio Access Network (RAN) and Core Network (CN). Distinct RAN and CN Slices may exist. A device may access multiple Network Slices simultaneously through a single RAN. The device may provide Network Slice Selection Assistance Information (NSSAI) parameters to the network to help it select a RAN and a Core Network part of a slice instance. Part of the control plane, the Common Control Network Function (CCNF), the Network Slice Selection Function (NSSF) is in charge of selecting core Network Slice instances. The Classifier, as described in SFC architecture, may reside in the user terminal or at the Evolved Node B (eNB). These service functions can be configured to be part of a Service Function Chain. We can also say that some of the configurations of the Service Function Path may change at the execution time. For example, the SMF may be relocated as the user moves and a new SMF may be included in the Service Function Path based on user location. Figure 1 shows the example Service Function Chain described here.¶

 
+------+   +---------+  +-----+   +-----+  
| User |   | Slice   |  |     |   |     |
| App  |-->| Control |->| AMF |-->| SMF |-->
| Fn   |   | Function|  |     |   |     |  
+------+   +---------+  +-----+   +-----+

Figure 1: Mapping SFC onto Service Function Execution Points along a Service Function Path

5. Name-Based Operation in SFF

5.1. General Idea

The general idea is two pronged. Firstly, we elevate the definition of a Service Function Path onto the level of "name-based interactions" rather than limiting SFPs to Layer 2 or 3 information only. Secondly, we extend the operations of the SFF to allow for forwarding decisions that take into account such name-based interaction while remaining backward compatible to the current SFC architecture as defined in [RFC7665]. In the following sections, we outline these two components of our solution.¶

If the next-hop information in the Network Locator Map (NLM) is described using an L2/L3 identifier, the name-based SFF (nSFF) may operate as described for [traditional] SFF, as defined in [RFC7665]. On the other hand, if the next-hop information in the NLM is described as a name, then the nSFF operates as described in the following sections.¶

In the following sections, we outline the two components of our solution.¶

5.2. Name-Based Service Function Path (nSFP)

The existing SFC framework is defined in [RFC7665]. Section 4 outlines that the SFP information is representing path information based on Layer 2 or 3 information, i.e., MAC or IP addresses, causing the aforementioned frequent adaptations in cases of execution-point changes. Instead, we introduce the notion of a "name-based service function path (nSFP)".¶

In today's networking terms, any identifier can be treated as a name, but we will illustrate the realization of a "Name-based SFP" through extended SFF operations (see Section 6) based on URIs as names and HTTP as the protocol of exchanging information. Here, URIs are being used to name for a Service Function along the nSFP. Note that the Name-based SFP approach is not restricted to HTTP (as the protocol) and URIs (as next-hop identifier within the SFP). Other identifiers such as an IP address itself can also be used and are interpreted as a "name" in the nSFP. IP addresses as well as fully qualified domain names forming complex URIs (uniform resource identifiers), such as www.example.com/service_name1, are all captured by the notion of "name" in this document.¶

Generally, nSFPs are defined as an ordered sequence of the "name" of Service Functions (SFs), and a typical name-based Service Function Path may look like: 192.0.x.x -> www.example.com -> www.example2.com/service1 -> www.example2.com/service2.¶

Our use case in Section 3 can then be represented as an ordered named sequence. An example for a session initiation that involves an authentication procedure, this could look like 192.0.x.x -> smf.example.org/session_initiate -> amf.example.org/auth -> smf.example.org/session_complete -> 192.0.x.x. (Note that this example is only a conceptual one since the exact nature of any future SBA-based exchange of 5G control-plane functions is yet to be defined by standardization bodies such as 3GPP).¶

In accordance with our use case in Section 3, any of these named services can potentially be realized through more than one replicated SF instance. This leads to making dynamic decisions on where to send packets along the SAME service function path information, being provided during the execution of the SFC. Through elevating the SFP onto the notion of name-based interactions, the SFP will remain the same even if those specific execution points change for a specific service interaction.¶

The following diagram in Figure 2 describes this name-based SFP concept and the resulting mapping of those named interactions onto (possibly) replicated instances.¶

 
 +---------------------------------------------------------------+
 |SERVICE LAYER                                                  |
 | 192.0.x.x --> www.example.com --> www.example2.com -->        |
 |                      ||              ||                       |
 +----------------------||--------------||-----------------------+
                        ||              ||
                        ||              ||
 +----------------------||--------------||-----------------------+
 | Underlay network     \/              \/                       |
 |               +--+ +--+ +--+    +--+ +--+ +--+                |
 |               |  | |  | |  |    |  | |  | |  |                |
 |               +--+ +--+ +--+    +--+ +--+ +--+                |
 |               Compute and       Compute and                   |
 |               storage nodes     storage nodes                 |
 +---------------------------------------------------------------+

Figure 2: Mapping SFC onto Service Function Execution Points along a Service Function Path Based on Virtualized Service Function Instance

5.3. Name-Based Network Locator Map (nNLM)

In order to forward a packet within a name-based SFP, we need to extend the network locator map as defined in [RFC8300] with the ability to consider name relations based on URIs as well as high-level transport protocols such as HTTP for means of SFC packet forwarding. Another example for SFC packet forwarding could be that of Constrained Application Protocol (CoAP).¶

The extended Network Locator Map or name-based Network Locator Map (nNLM) is shown in Table 1 as an example for www.example.com being part of the nSFP. Such extended nNLM is stored at each SFF throughout the SFC domain with suitable information populated to the nNLM during the configuration phase.¶

Table 1: Name-Based Network Locator Map
SPI	SI	Next Hop(s)	Transport Encapsulation (TE)
10	255	192.0.2.1	VXLAN-gpe
10	254	198.51.100.10	GRE
10	253	www.example.com	HTTP
40	251	198.51.100.15	GRE
50	200	01:23:45:67:89:ab	Ethernet
15	212	Null (end of path)	None

Alternatively, the extended network locator map may be defined with implicit name information rather than explicit URIs as in Table 1. In the example of Table 2, the next hop is represented as a generic HTTP service without a specific URI being identified in the extended network locator map. In this scenario, the SFF forwards the packet based on parsing the HTTP request in order to identify the host name or URI. It retrieves the URI and may apply policy information to determine the destination host/service.¶

Table 2: Name-Based Network Locator Map with Implicit Name Information
SPI	SI	Next Hop(s)	Transport Encapsulation (TE)
10	255	192.0.2.1	VXLAN-gpe
10	254	198.51.100.10	GRE
10	253	HTTP Service	HTTP
40	251	198.51.100.15	GRE
50	200	01:23:45:67:89:ab	Ethernet
15	212	Null (end of path)	None

5.4. Name-Based Service Function Forwarder (nSFF)

It is desirable to extend the SFF of the SFC underlay to handle nSFPs transparently and without the need to insert any service function into the nSFP. Such extended name-based SFFs would then be responsible for forwarding a packet in the SFC domain as per the definition of the (extended) nSFP.¶

In our exemple realization for an extended SFF, the solution described in this document uses HTTP as the protocol of forwarding SFC packets to the next (name-based) hop in the nSFP. The URI in the HTTP transaction are the names in our nSFP information, which will be used for name-based forwarding.¶

Following our reasoning so far, HTTP requests (and more specifically, the plaintext-encoded requests above) are the equivalent of packets that enter the SFC domain. In the existing SFC framework, an IP payload is typically assumed to be a packet entering the SFC domain. This packet is forwarded to destination nodes using the L2 encapsulation. Any layer 2 network can be used as an underlay network. This notion is now extended to packets being possibly part of an entire higher-layer application such as HTTP requests. The handling of any intermediate layers, such as TCP and IP, is left to the realization of the (extended) SFF operations towards the next (named) hop. For this, we will first outline the general lifecycle of an SFC packet in the following subsection, followed by two examples for determining next-hop information in Section 6.2.3, finished up by a layered view on the realization of the nSFF in Section 6.2.4.¶

5.5. High-Level Architecture

+----------+
| SF1      |                 +--------+                  +------+ 
| instance |\                |   NR   |                  | SF2  | 
+----------+ \               +--------+                  +------+ 
              \                  ||                         ||
+------------+ \ +-------+   +---------+   +---------+   +-------+
| Classifier |---| nSFF1 |---|Forwarder|---|Forwarder|---| nSFF2 |    
+------------+   +-------+   +---------+   +---------+   +-------+
                                                            ||
                                                        +----------+ 
                                                        | Boundary |
                                                        |  node    |
                                                        +----------+

Figure 3: High-Level Architecture

The high-level architecture for name-based operation shown in Figure 3 is very similar to the SFC architecture as described in [RFC7665]. Two new functions are introduced, as shown in the above diagram: namely, the name-based Service Function Forwarder (nSFF) and the Name Resolver (NR).¶

nSFF (name-based Service Function Forwarder) is an extension of the existing SFF and is capable of processing SFC packets based on name-based Network Locator Map (nNLM) information, determining the next SF where the packet should be forwarded, and the required transport encapsulation. Like standard SFF operation, it adds transport encapsulation to the SFC packet and forwards it.¶

The Name Resolver is a new functional component, capable of identifying the execution endpoints, where a "named SF" is running, triggered by suitable resolution requests sent by the nSFF. Though this is similar to DNS function, it is not same. It does not use DNS protocols or data records. A new procedure to determine the suitable routing/forwarding information towards the Nsff (name-based SFF) serving the next hop of the SFP (Service Function Path) is used. The details are described later.¶

The other functional components, such as Classifier and SF, are the same as described in SFC architecture, as defined in [RFC7665], while the Forwarders shown in the above diagram are traditional Layer 2 switches.¶

5.6. Operational Steps

In the proposed solution, the operations are realized by the name-based SFF, called "nSFF". We utilize the high-level architecture in Figure 3 to describe the traversal between two service function instances of an nSFP-based transaction in an example chain of: 192.0.x.x -> SF1 (www.example.com) -> SF2 (www.example2.com) -> SF3 -> ... Service Function 3 (SF3)is assumed to be a classical Service Function; hence, existing SFC mechanisms can be used to reach it and will not be considered in this example.¶

According to the SFC lifecycle, as defined in [RFC7665], based on our example chain above, the traffic originates from a Classifier or another SFF on the left. The traffic is processed by the incoming nSFF1 (on the left side) through the following steps. The traffic exits at nSFF2.¶

Step 1:: At nSFF1, the following nNLM is assumed:¶

Table 3: nNLM at nSFF1
SPI	SI	Next Hop(s)	Transport Encapsulation (TE)
10	255	192.0.2.1	VXLAN-gpe
10	254	198.51.100.10	GRE
10	253	www.example.com	HTTP
10	252	www.example2.com	HTTP
40	251	198.51.100.15	GRE
50	200	01:23:45:67:89:ab	Ethernet
15	212	Null (end of path)	None

Step 2:: nSFF1 removes the previous transport encapsulation (TE) for any traffic originating from another SFF or classifier (traffic from an SF instance does not carry any TE and is therefore directly processed at the nSFF).¶
Step 3:: nSFF1 then processes the Network Service Header (NSH) information, as defined in [RFC8300], to identify the next SF at the nSFP level by mapping the NSH information to the appropriate entry in its nNLM (see Table 3) based on the provided SPI/SI information in the NSH (see Section 4) in order to determine the name-based identifier of the next-hop SF. With such nNLM in mind, the nSFF searches the map for SPI = 10 and SI = 253. It identifies the next hop as = www.example.com and HTTP as the protocol to be used. Given that the next hop resides locally, the SFC packet is forwarded to the SF1 instance of www.example.com. Note that the next hop could also be identified from the provided HTTP request, if the next-hop information was identified as a generic HTTP service, as defined in Section 5.3.¶
Step 4:: The SF1 instance then processes the received SFC packet according to its service semantics and modifies the NSH by setting SPI = 10 and SI = 252 for forwarding the packet along the SFP. It then forwards the SFC packet to its local nSFF, i.e., nSFF1.¶
Step 5:: nSSF1 processes the NSH of the SFC packet again, now with the NSH modified (SPI = 10, SI = 252) by the SF1 instance. It retrieves the next-hop information from its nNLM in Table 3 to be www.example2.com. Due to this SF not being locally available, the nSFF consults any locally available information regarding routing/forwarding towards a suitable nSFF that can serve this next hop.¶
Step 6:: If such information exists, the Packet (plus the NSH information) is marked to be sent towards the nSFF serving the next hop based on such information in Step 8.¶
Step 7:: If such information does not exist, nSFF1 consults the Name Resolver (NR) to determine the suitable routing/forwarding information towards the identified nSFF serving the next hop of the SFP. For future SFC packets towards this next hop, such resolved information may be locally cached, avoiding contacting the Name Resolver for every SFC packet forwarding. The packet is now marked to be sent via the network in Step 8.¶
Step 8:: Utilizing the forwarding information determined in Steps 6 or 7, nSFF1 adds the suitable transport encapsulation (TE) for the SFC packet before forwarding via the forwarders in the network towards the next nSFF22.¶
Step 9:: When the Packet (+NSH+TE) arrives at the outgoing nSFF2, i.e., the nSFF serving the identified next hop of the SFP, it removes the TE and processes the NSH to identify the next-hop information. At nSFF2 the nNLM in Table 4 is assumed. Based on this nNLM and NSH information where SPI = 10 and SI = 252, nSFF2 identifies the next SF as www.example2.com.¶

Table 4: nNLM at SFF2
SPI	SI	Next Hop(s)	Transport Encapsulation (TE)
10	252	www.example2.com	HTTP
40	251	198.51.100.15	GRE
50	200	01:23:45:67:89:ab	Ethernet
15	212	Null (end of path)	None

Step 12:: If the next hop is locally registered at the nSFF, it forwards the packet (+NSH) to the service function instance using suitable IP/MAC methods for doing so.¶
Step 13:: If the next hop is not locally registered at the nSFF, the outgoing nSFF adds a new TE information to the packet and forwards the packet (+NSH+TE) to the next SFF or boundary node, as shown in Table 4.¶

6. nSFF Forwarding Operations

This section outlines the realization of various nSFF forwarding operations in Section 5.6. Although the operations in Section 5 utilize the notion of name-based transactions in general, we exemplify the operations here in Section 5 specifically for HTTP-based transactions to ground our description into a specific protocol for such name-based transaction. We will refer to the various steps in each of the following subsections.¶

6.1. nSFF Protocol Layers

Figure 4 shows the protocol layers based on the high-level architecture in Figure 3.¶

                                             
+-------+  +------+----+                              +----+-----+
|App    |  |      |    |   +--------+                 |    |     |
|HTTP   |  |-------->  |   |  NR    |                 |nSFF----->|--
|TCP    |->| TCP  |nSFF|   +---/\---+                 |    | TCP | |
|IP     |  | IP   |    |       ||                     |    | IP  | |
+-------+  +------+----+  +---------+   +---------+   +----------+ |
|   L2  |  |      L2   |->|Forwarder|-->|Forwarder|-->|   L2     | | 
+-------+  +------+----+  +---------+   +---------+   +----------+ | 
  SF1           nSFF1                                     nSFF2    |                             
                                              +-------+            |
                                              | App   |/           |
                                              | HTTP  | -----------+
                                              | TCP   |\
                                              | IP    |
                                              | L2    |
                                              +-------+
                                                SF2

Figure 4: Protocol Layers

The nSFF component here is shown as implementing a full incoming/outgoing TCP/IP protocol stack towards the local service functions, while implementing the nSFF-NR and nSFF-nSFF protocols based on the descriptions in Section 6.2.3.¶

For the exchange of HTTP-based service function transactions, the nSFF terminates incoming TCP connections as well as outgoing TCP connections to local SFs, e.g., the TCP connection from SF1 terminates at nSFF1, and nSFF1 may store the connection information such as socket information. It also maintains the mapping information for the HTTP request such as originating SF, destination SF, and socket ID. nSFF1 may implement sending keep-alive messages over the socket to maintain the connection to SF1. Upon arrival of an HTTP request from SF1, nSFF1 extracts the HTTP Request and forwards it towards the next node as outlined in Section 6.2. Any returning response is mapped onto the suitable open socket (for the original request) and sent towards SF1.¶

At the outgoing nSFF2, the destination SF2/Host is identified from the HTTP request message. If no TCP connection exists to the SF2, a new TCP connection is opened towards the destination SF2 and the HTTP request is sent over said TCP connection. The nSFF2 may also save the TCP connection information (such as socket information) and maintain the mapping of the socket information to the destination SF2. When an HTTP response is received from SF2 over the TCP connection, nSFF2 extracts the HTTP response, which is forwarded to the next node. nSFF2 may maintain the TCP connection through keep-alive messages.¶

6.2. nSFF Operations

In this section, we present three key aspects of operations for the realization of the steps in Section 5.6, namely, (i) the registration of local SFs (for Step 3 in Section 5.6), (ii) the forwarding of SFC packets to and from local SFs (for Steps 3, 4, and 10 in Section 5.6), (iii) the forwarding to a remote SF (for Steps 5, 6, and 7 in Section 5.6) and to the NR as well as (iv) for the lookup of a suitable remote SF (for Step 7 in Section 5.6). We also cover aspects of maintaining local lookup information for reducing lookup latency and other issues.¶

6.2.1. Forwarding between nSFFs and nSFF-NR

Forwarding between the distributed nSFFs as well as between nSFF and NR is realized over the operator network via a path-based approach. A path-based approach utilizes path information provided by the source of the packet for forwarding said packet in the network. This is similar to segment routing albeit differing in the type of information provided for such source-based forwarding as described in this section. In this approach, the forwarding information to a remote nSFF or the NR is defined as a "path identifier" (pathID) of a defined length where said "Length" field indicates the full pathID length. The payload of the packet is defined by the various operations outlined in the following subsections, resulting in an overall packet being transmitted. With this, the generic forwarding format (GFF) for transport over the operator network is defined in Figure 5 with the length field defining the length of the pathID provided.¶

+---------+-----------------+------------------------//------------+
|         |                 |                       //             |
| Length  | Path ID         |  Payload             //              |
|(12 bits)|                 |                     //               |
+---------+-----------------+--------------------//----------------+

Figure 5: Generic Forwarding Format (GFF)

Length (12 bits): Defines the length of the pathID, i.e., up to 4096 bits¶
Path ID (): Variable-length field, Bit field derived from IPv6 source and destination address¶

For the pathID information, solutions such as those in [Reed2016] can be used. Here, the IPv6 source and destination addresses are used to realize a so-called path-based forwarding from the incoming to the outgoing nSFF or the NR. The forwarders in Figure 4 are realized via SDN (software-defined networking) switches, implementing an AND/CMP operation based on arbitrary wildcard matching over the IPv6 source and destination addresses as outlined in [Reed2016]. Note that in the case of using IPv6 address information for path-based forwarding, the step of removing the transport encapsulation at the outgoing nSFF in Figure 4 is realized by utilizing the provided (existing) IP header (which was used for the purpose of the path-based forwarding in [Reed2016]) for the purpose of next-hop forwarding such as that of IP-based routing. As described in Step 8 of the extended nSFF operations, this forwarding information is used as traffic encapsulation. With the forwarding information utilizing existing IPv6 information, IP headers are utilized as Transport Encapsulation (TE) in this case. The next-hop nSFF (see Figure 4) will restore the IP header of the packet with the relevant IP information used to forward the SFC packet to SF2, or it will create suitable TE information to forward the information to another nSFF or boundary node. Forwarding operations at the intermediary forwarders, i.e., SDN switches, examine the pathID information through a flow-matching rule in which a specific switch-local output port is represented through the specific assigned bit position in the pathID. Upon a positive match in said rule, the packet is forwarded on said output port.¶

Alternatively, the solution in [BIER-MULTICAST] suggests using a so-called BIER (Binary Indexed Explicit Replication) underlay. Here, the nSFF would be realized at the ingress to the BIER underlay, injecting the SFC packet header (plus the Network Service Header (NSH)) with BIER-based traffic encapsulation into the BIER underlay with each of the forwarders in Figure 4 being realized as a so-called Bit-Forwarding Router (BFR) [RFC8279].¶

6.2.1.1. Transport Protocol Considerations

Given that the proposed solution operates at the "named-transaction" level, particularly for HTTP transactions, forwarding between nSFFs and/or NR SHOULD be implemented via a transport protocol between nSFFs and/or NR in order to provide reliability, segmentation of large GFF packets, and flow control, with the GFF in Figure 5 being the basic forwarding format for this.¶

Note that the nSFFs act as TCP proxies at ingress and egress, thus terminating incoming and initiating outgoing HTTP sessions to SFs.¶

Figure 6 shows the packet format being used for the transmission of data, being adapted from the TCP header. Segmentation of large transactions into single transport protocol packets is realized through maintaining a "Sequence number". A "Checksum" is calculated over a single data packet with the ones-complement TCP checksum calculation being used. The "Window Size" field indicates the current maximum number of transport packets that are allowed in-flight by the egress nSFF. A data packet is sent without a "Data" field to indicate the end of the (e.g., HTTP) transaction.¶

Note that, in order to support future named transactions based on other application protocols, such as Constrained Application Protocol (CoAP), future versions of the transport protocol MAY introduce a "Type" field that indicates the type of application protocol being used between SF and nSFF with "Type" 0x01 proposed for HTTP. This is being left for future study.¶


    |         16 bits       |        16 bits       |
    +----------------------------------------------+
    |              Sequence number                 |
    +----------------------------------------------+
    |       Checksum        |      Window Size     |
    +----------------------------------------------+
    |                      ...                     |
    |                Data (Optional)               |
    +----------------------------------------------+

Figure 6: Transport Protocol Data Packet Format

Given the path-based forwarding being used between nSFFs, the transport protocol between nSFFs utilizes negative acknowledgements from the egress nSFF towards the ingress nSFF. The transport protocol negative Acknowledgment (NACK) packet carries the number of NACKs as well as the specific sequence numbers being indicated as lost in the "NACK number" field(s) as shown in Figure 7.¶


    |         16 bits       |        16 bits       |
    +----------------------------------------------+
    |    Number of NACKs    |                      +
    +----------------------------------------------+
    |                   NACK number                |
    +----------------------------------------------+
    +                ... NACK Number               +
    +----------------------------------------------+

Figure 7: Transport Protocol NACK Packet Format

If the indicated number of NACKs in a received NACK packet is nonzero, the ingress nSFF will retransmit all sequence numbers signaled in the packet while decreasing its congestion window size for future transmissions.¶

If the indicated number of NACKs in a received NACK packet is zero, it will indicate the current congestion window as being successfully (and completely) being transmitted, increasing the congestion window size if smaller than the advertised "Window Size" in Figure 6.¶

The maintenance of the congestion window is subject to realization at the ingress nSFF and left for further study in nSFF realizations.¶

6.2.2. SF Registration

As outlined in Steps 3 and 10 of Section 5.6, the nSFF needs to determine if the SF derived from the Name-Based Network Locator (nNLM) is locally reachable or whether the packet needs to be forwarded to a remote SFF. For this, a registration mechanism is provided for such local SF with the local nSFF. Two mechanisms can be used for this:¶

(1): SF-initiated: We assume that the SF registers its Fully Qualified Domain Name (FQDN) to the local nSFF. As local mechanisms, we foresee that either a REST-based interface over the link-local link or configuration of the nSFF (through configuration files or management consoles) can be utilized. Such a local registration event leads to the nSFF to register the given FQDN with the NR in combination with a system-unique nSFF identifier that is being used for path computation purposes in the NR. For the registration, the packet format in Figure 8 is used (inserted as the payload in the GFF of Figure 5 with the pathID towards the NR).¶

+---------+-----------------+------------------+
|         |                 |                  |
|   R/D   |   hash(FQDN)    |  nSFF_ID         |
| (1 bit) |   (16 bits)     |  (8 bits)        |
+---------+-----------------+------------------+

Figure 8: Registration Packet Format

R/D: 1-bit length (0 for Register, 1 for Deregister)¶
hash(FQDN): 16-bit length for a hash over the FQDN of the SF¶
nSFF_ID: 8 bit for a system-unique identifier for the SFF related to the SF.¶

We assume that the pathID towards the NR is known to the nSFF through configuration means.¶

The NR maintains an internal table that associates the hash(FQDN), the nSFF_id information as well as the pathID information being used for communication between nSFF and NR. The nSFF locally maintains a mapping of registered FQDNs to IP addresses for the latter using link-local private IP addresses.¶

(2): Orchestration-based: In this mechanism, we assume that SFC to be orchestrated and the chain to be provided through an orchestration template with FQDN information associated to a compute/storage resource that is being deployed by the orchestrator. We also assume knowledge at the orchestrator of the resource topology. Based on this, the orchestrator can now use the same REST-based protocol defined in option 1 to instruct the NR to register the given FQDN, as provided in the template, at the nSFF it has identified as being the locally servicing nSFF, provided as the system-unique nSFF identifier.¶

6.2.3. Local SF Forwarding

There are two cases of local SF forwarding, namely, the SF sending an SFC packet to the local nSFF (incoming requests) or the nSFF sending a packet to the SF (outgoing requests) as part of Steps 3 and 10 in Section 5.6. In the following, we outline the operation for HTTP as an example-named transaction.¶

As shown in Figure 4, incoming HTTP requests from SFs are extracted by terminating the incoming TCP connection at their local nSFFs at the TCP level. The nSFF MUST maintain a mapping of open TCP sockets to HTTP requests (utilizing the URI of the request) for HTTP response association.¶

For outgoing HTTP requests, the nSFF utilizes the maintained mapping of locally registered FQDNs to link-local IP addresses (see Section 6.2.2, option 1). Hence, upon receiving an SFC packet from a remote nSFF (in Step 9 of Section 5.6), the nSFF determines the local existence of the SF through the registration mechanisms in Section 6.2.2. If said SF does exist locally, the HTTP (+NSH) packet, after stripping the TE, is sent to the local SF as Step 10 in Section 5.6 via a TCP-level connection. Outgoing nSFFs SHOULD keep TCP connections open to local SFs for improving SFC packet delivery in subsequent transactions.¶

6.2.4. Handling of HTTP Responses

When executing Steps 3 and 10 in Section 5.6, the SFC packet will be delivered to the locally registered next hop. As part of the HTTP protocol, responses to the HTTP request will need to be delivered on the return path to the originating nSFF (i.e., the previous hop). For this, the nSFF maintains a list of link-local connection information, e.g., sockets to the local SF and the pathID on which the request was received. Once receiving the response, nSFF consults the table to determine the pathID of the original request, forming a suitable GFF-based packet to be returned to the previous nSFF.¶

When receiving the HTTP response at the previous nSFF, the nSFF consults the table of (locally) open sockets to determine the suitable local SF connection, mapping the received HTTP response URI to the stored request URI. Utilizing the found socket, the HTTP response is forwarded to the locally registered SF.¶

6.2.5. Remote SF Forwarding

In Steps 5, 6, 7, and 8 of Section 5.6, an SFC packet is forwarded to a remote nSFF based on the nNLM information for the next hop of the nSFP. Section 6.2.5.1 handles the case of suitable forwarding information to the remote nSFF not existing, therefore consulting the NR to obtain suitable information. Section 6.2.5.2 describes the maintenance of forwarding information at the local nSFF. Section 6.2.5.3 describes the update of stale forwarding information. Note that the forwarding described in Section 6.2.1 is used for the actual forwarding to the various nSFF components. Ultimately, Section 6.2.5.4 describes the forwarding to the remote nSFF via the forwarder network.¶

6.2.5.1. Remote SF Discovery

The nSFF communicates with the NR for two purposes: namely, the registration and discovery of FQDNs. The packet format for the former was shown in Figure 6 in Section 6.2.2, while Figure 9 outlines the packet format for the discovery request.¶

+--------------+-------------+ +--------+-----------------//--------+
|              |             | |        |                //         |
|   hash(FQDN) |  nSFF_ID    | | Length | pathID        //          |
|   (16 bits)  |  (8 bits)   | |(4 bits)|              //           |     
+--------------+-------------+ +--------+-------------//------------+
        Path Request                     Path Response

Figure 9: Discovery Packet Format

For Path Request:¶

hash(FQDN): 16-bit length for a hash over the FQDN of the SF¶
nSFF_ID: 8 bit for a system-unique identifier for the SFF related to the SF¶

For Path Response:¶

Length (4 bits): Defines the length of the pathID¶
Path ID (): Variable-length field, Bit field derived from IPv6 source and destination address¶

A path to a specific FQDN is requested by sending a hash of the FQDN to the NR together with its nSFF_id, receiving as a response a pathID with a length identifier. The NR SHOULD maintain a table of discovery requests that map discovered (hash of) FQDN to the nSFF_id that requested it and the pathID that is being calculated as a result of the discovery request.¶

The discovery request for an FQDN that has not previously been served at the nSFF (or for an FQDN whose pathID information has been flushed as a result of the update operations in Section 6.2.5.3) results in an initial latency incurred by this discovery through the NR, while any SFC packet sent over the same SFP in a subsequent transaction will utilize the nSFF-local mapping table. Such initial latency can be avoided by prepopulating the FQDN-pathID mapping proactively as part of the overall orchestration procedure, e.g., alongside the distribution of the nNLM information to the nSFF.¶

6.2.5.2. Maintaining Forwarding Information at Local nSFF

Each nSFF MUST maintain an internal table that maps the (hash of the) FQDN information to a suitable pathID information. As outlined in Step 7 of Section 5.6, if a suitable entry does not exist for a given FQDN, the pathID information is requested with the operations in Section 6.2.5.1 and the suitable entry is locally created upon receiving a reply with the forwarding operation being executed as described in Section 6.2.1.¶

If such an entry does exist (i.e., Step 6 of Section 5.6), the pathID is locally retrieved and used for the forwarding operation in Section 6.2.1.¶

6.2.5.3. Updating Forwarding Information at nSFF

The forwarding information maintained at each nSFF (see Section 6.2.5.2) might need to be updated for three reasons:¶

An existing SF is no longer reachable: In this case, the nSFF with which the SF is locally registered deregisters the SF explicitly at the NR by sending the packet in Figure 6 with the hashed FQDN and the R/D bit set to 1 (for deregister).¶
Another SF instance has become reachable in the network (and, therefore, might provide a better alternative to the existing SF): In this case, the NR has received another packet with a format defined in Figure 7 but a different nSFF_id value.¶
Links along paths might no longer be reachable: The NR might use a suitable southbound interface to transport networks to detect link failures, which it associates to the appropriate pathID bit position.¶

For this purpose, the packet format in Figure 10 is sent from the NR to all affected nSFFs, using the generic format in Figure 5.¶


+---------+-----------------+--------------//----+
|         |                 |             //     |
|   Type  |     #IDs        |  IDs       //      |
| (1 bit) |    (8 bits)     |           //       |
+---------+-----------------+----------//--------+

Figure 10: Path Update Format

Type: 1-bit length (0 for Nsff ID, 1 for Link ID)¶
#IDs: 8-bit length for number of IDs in the list¶
IDs: List of IDs (Nsff ID or Link ID)¶

The pathID to the affected nSFFs is computed as the binary OR over all pathIDs to those nSFF_ids affected where the pathID information to the affected nSFF_id values is determined from the NR-local table maintained in the registration/deregistration operation of Section 6.2.2.¶

The pathID may include the type of information being updated (e.g., node identifiers of leaf nodes or link identifiers for removed links). The node identifier itself may be a special identifier to signal "ALL NODES" as being affected. The node identifier may signal changes to the network that are substantial (e.g., parallel link failures). The node identifier may trigger (e.g., recommend) purging of the entire path table (e.g., rather than the selective removal of a few nodes only).¶

It will include the information according to the type. The included information may also be related to the type and length information for the number of identifiers being provided.¶

In cases 1 and 2, the Type bit is set to 1 (type nSFF_id) and the affected nSFFs are determined by those nSFFs that have previously sent SF discovery requests, utilizing the optional table mapping previously registered FQDNs to nSFF_id values. If no table mapping the (hash of) FQDN to nSFF_id is maintained, the update is sent to all nSFFs. Upon receiving the path update at the affected nSFF, all appropriate nSFF-local mapping entries to pathIDs for the hash(FQDN) identifiers provided will be removed, leading to a new NR discovery request at the next remote nSFF forwarding to the appropriate FQDN.¶

In case 3, the Type bit is set to 0 (type linkID) and the affected nSFFs are determined by those nSFFs whose discovery requests have previously resulted in pathIDs that include the affected link, utilizing the optional table mapping previously registered FQDNs to pathID values (see Section 6.2.5.1). Upon receiving the node identifier information in the path update, the affected nSFF will check its internal table that maps FQDNs to pathIDs to determine those pathIDs affected by the link problems and remove path information that includes the received node identifier(s). For this, the pathID entries of said table are checked against the linkID values provided in the ID entry of the path update through a binary AND/CMP operation to check the inclusion of the link in the pathIDs to the FQDNs. If any pathID is affected, the FQDN-pathID entry is removed, leading to a new NR discovery request at the next remote nSFF forwarding to the appropriate FQDN.¶

6.2.5.4. Forwarding to Remote nSFF

Once Steps 5, 6, and 7 in Section 5.6 are being executed, Step 8 finally sends the SFC packet to the remote nSFF, utilizing the pathID returned in the discovery request (Section 6.2.5.1) or retrieved from the local pathID mapping table. The SFC packet is placed in the payload of the generic forwarding format in Figure 5 together with the pathID, and the nSFF eventually executes the forwarding operations in Section 6.2.1.¶

RFC 8677

Name-Based Service Function Forwarder (nSFF) Component within a Service Function Chaining (SFC) Framework

Abstract

Status of This Memo

Copyright Notice

Table of Contents

1. Introduction

2. Terminology

3. Example Use Case: 5G Control-Plane Services

4. Background

4.1. Relevant Part of SFC Architecture

4.2. Challenges with Current Framework