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

4.1. Relevant Part of SFC Architecture

The SFC architecture, as defined in [RFC7665], describes architectural components such as SF, classifier, and SFF. It describes the SFP as the logical path of an SFC. Forwarding traffic along such an SFP is the responsibility of the SFF. For this, the SFFs in a network maintain the requisite SFP forwarding information. Such SFP forwarding information is associated with a service path identifier (SPI) that is used to uniquely identify an SFP. The service forwarding state is represented by the Service Index (SI) and enables an SFF to identify which SFs of a given SFP should be applied, and in what order. The SFF also has information that allows it to forward packets to the next SFF after applying local SFs.¶

The operational steps to forward traffic are then as follows: Traffic arrives at an SFF from the network. The SFF determines the appropriate SF the traffic should be forwarded to via information contained in the SFC encapsulation. After SF processing, the traffic is returned to the SFF and, if needed, is forwarded to another SF associated with that SFF. If there is another non-local hop (i.e., to an SF with a different SFF) in the SFP, the SFF further encapsulates the traffic in the appropriate network transport protocol and delivers it to the network for delivery to the next SFF along the path. Related to this forwarding responsibility, an SFF should be able to interact with metadata.¶

4.2. Challenges with Current Framework

As outlined in previous sections, the SFP defines an ordered sequence of specific SF instances being used for the interaction between initiator and SFs along the SFP. These SFs are addressed by IP (or any L2/MAC) addresses and defined as next-hop information in the network locator maps of traversing SFF nodes.¶

As outlined in our use case, however, the service provider may want to provision SFC nodes based on dynamically spun-up SF instances so that these (now virtualized) SFs can be reached in the SFC domain using the SFC underlay layer.¶

Following the original model of SFC, any change in a specific execution point for a specific SF along the SFP will require a change of the SFP information (since the new SF execution point likely carries different IP or L2 address information) and possibly even the next-hop information in SFFs along the SFP. In case the availability of new SF instances is rather dynamic (e.g., through the use of container-based virtualization techniques), the current model and realization of SFC could lead to reducing the flexibility of service providers and increasing the management complexity incurred by the frequent changes of (service) forwarding information in the respective SFF nodes. This is because any change of the SFP (and possibly next-hop info) will need to go through suitable management cycles.¶

To address these challenges through a suitable solution, we identify the following requirements:¶

The next section outlines a solution to address the issue, allowing for keeping SFC information (represented in its SFP) intact while addressing the desired flexibility of the service provider.¶

5.1. General Idea

The general idea is two pronged. Firstly, we elevate the definition of an SFP onto the level of "name-based interactions" rather than limiting SFPs to Layer 2 or Layer 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 Layer 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 an SF along the nSFP. Note that the nSFP 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 SFs, and a typical nSFP 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 SFP 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 nSFP 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                 |
 +---------------------------------------------------------------+

5.3. Name-Based Network Locator Map (nNLM)

In order to forward a packet within an nSFP, we need to extend the NLM 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 NLM 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.¶

Alternatively, the extended NLM 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 NLM. 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.¶

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 SF into the nSFP. Such extended nSFFs would then be responsible for forwarding a packet in the SFC domain as per the definition of the (extended) nSFP.¶

In our example 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 is the name 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    |
                                                        +----------+

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 nSFF and the Name Resolver (NR).¶

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

The NR 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 serving the next hop of the SFP 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 SF 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 SF; 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:¶

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:

nSFF1 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 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 NR 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 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.¶

Step 10:

If the next hop is locally registered at the nSFF, it forwards the packet (+NSH) to the SF instance using suitable IP/MAC methods for doing so.¶

Step 11:

If the next hop is not locally registered at the nSFF, the outgoing nSFF adds 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.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

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

For the exchange of HTTP-based SF 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.¶

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

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

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

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

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