Receive-Only Service Function and External Service in SFC

Services in Service Function Chaining (SFC) usually operate in "inline" mode, where they process the received packets and return the packets to the Service Function Forwarder (SFF). Some services especially in the network security domain can buffer, inject or block certain packets, as well as proxy entire connections (). However, in general they still forward packets. also describes a special set of services that consume all packets sent to them. We refer to such behavior as "receive-only". A receive-only service could be a Service Function (SF) participating in SFC (), or it could be an External Service (ES) receiving packets from the SFF or another regular SF. This document describes proposals for designing SFC packet plane and control plane to incorporate receive-only services.

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 RFC 2119.

This document uses the terms as defined in RFC 7498, and . In addition the following terms are defined. A service operational mode where the service does not forward on packets that it receives. It is often known as "packet sink" as well. A Receive-Only Service Function participating in SFC as defined in , except that the SF operates in Receive-Only mode. A Receive-Only External Service not participating in SFC. Specifically, an RO ES is not an SF. It is not allocated with a Service Index (SI) in the Service Function Path (SFP). However, it receives packets from the SFF or an SF. An SFC Proxy () with extended capability to support Receive-Only SF. The SFC Proxy replicates and sends packets to the RO SF. The SFC encapsulation may be preserved if the RO SF is SFC aware. The Proxy forwards the original packets back to the SFF in the same way as a regular SF (e.g., with Service Index (SI) decremented in NSH). A unidirectional traffic stream identified by network layer attributes, specifically IP addresses and TCP/UDP ports for TCP/UDP traffic. A bidirectional traffic stream composed of two flows sharing the same network layer attributes.

A receive-only service may be a Service Function (SF) or External Service (ES) depending on whether the SFC administrator designs the service to be part of the SFC or not. In the following example, the IDS service is located between "DDoS Mitigator" and "Firewall" as part of an integrated security solution to protect the server (S). Packets from the client (C) must be examined by a chain of services before they reach the server. The three service functions, DDoS, IDS and Firewall, compose an SFC. Each SF including the IDS SF is allocated with a Service Index (SI) in the SFP. The IDS SF is a fundamental part of the service chain with the only exception that it does not egress packets. We refer to the IDS service as a Receive-Only SF (RO SF). There are other attributes for an RO SF. There is a limited number of location options for "IDS" to be deployed in an SFC. Once deployed, the location of "IDS" does not change usually unless the SFs are added to or removed from the SFC. Extending the SFC framework to RO SF enables a unified SFC policy model for SFC administrators. The administrator only needs to manage one set of policy that covers both RO and regular SFs, no matter how they handle packets.

"Packet Capture" for troubleshooting represents the other type of receive-only services that do not participate in SFC. The administrator may insert "Packet Capture" at any stage of an SFP. Packets may be captured before and/or after one or multiple SFs, which means there are many possible invocation points for "Packet Capture" in an SFP. The administrator may want to dynamically insert or remove "Packet Capture" based on the need for troubleshooting and threat analysis. When doing so, it is desired that the construction of the SFP is not affected. That is, the Service Path ID (SPID) and SI for each of the SFs in the SFP remain unchanged. Services with the above attributes receive SFC packets but are not listed in an SFC. They do not consume an SI in the SFP. We refer to such a service as a Receive-Only External Service (RO ES). An RO ES still requires support from SFC elements including SFF and SF for receiving packets. Because an RO ES does not send back packets, it must receive replication of the packets. Depending on the use cases and performance requirements, an SFF or SF may perform the packet replication for the RO ES. For example, a Packet Capture for troubleshooting purpose may tap on the SFF at one or more locations along the SFP (Figure 2). This document describes the necessary enhancements to the SFC framework for supporting RO ES.

A Receive-Only SF behaves the same way as a regular SF except that it does not forward packets. As a result, it must receive a copy of the packets while the original packets travel through the rest of the SFs in the SFP. Because an RO SF occupies an SI in the SFP, the SI of the original packet must be decremented after the packet passes the RO SF. Considering the fact that an RO SF does not forward packets and SFF is not designed to decrement SI, an Extended SFC Proxy is leveraged to perform the packet replication and SI decrement tasks on behalf of the RO SF. As shown in the Figure below, the Extended SFC Proxy makes a copy of the packet including the NSH and sends the copy to the RO SF-2. It decrements the SI of original packet and forwards that packet back to the SFF. This capability is an extension to the current SFC Proxy as defined in (). From the SFF's perspective, the combination of the Extended SFC Proxy and the RO SF behaves as a regular SF that processes and forwards packets with SI decremented. From the RO SF's perspective, the Extended SFC Proxy may be a logical component in the specific SFF implementation for efficiency.

A packet goes through the following steps in the above example: SFF receives the packet from SF-1 with SPID=10 and SI=254 SFF looks up in its forwarding table and finds Extended SFC Proxy for SF-2 to be the next hop. SFF sends the packet to SF-2's Proxy. Extended SFC Proxy replicates the packet and sends the copy to SF-2 which is an RO SF. The copy has SI=254 Extended SFC Proxy decrements the SI of the original packet and sends the packet back to SFF. The packet now has SI=253 SFF looks up the next service function, SF-3, in its forwarding table based on the SPID and SI from Extended SFC Proxy. SFF sends the packet to SF-3.

A Receive-Only External Service still receives a copy of the packets designated to it even if it is not listed in the SFP. For some use cases such as capturing a file content for sandbox analysis, packet data replication may be conducted by an SF capable of identifying file boundary in the packet stream. The RO ES would be associated with the SF and receives packet data from the SF directly. Alternatively, for use cases such as generic packet capture for troubleshooting, the SFF may carry out the packet replication and forwarding work. Higher performance may be achieved with hardware based SFF.

When an RO ES receives packets from the SFF, it may be attached to the SFF at multiple locations along the SFP. The location may be indicated by a (SPID, SI) pair and programmed into the SFF's forwarding table. The SFF performs packet replication when the packet needs to be sent to the RO ES (SFC Proxy cannot be used because RO ES is not an SF). The SI of the original packet MUST NOT be affected by the fact that a copy is being sent to the RO ES. The following figure illustrates an example with SFF performing packet replication.

Here is a sample packet flow involving an Receive-Only External Service: SFF receives the packet from SF-1 with SPID=10 and SI=254 SFF looks up the next service function, SF-2, in its forwarding table. The forwarding entry also indicates an RO ES at this location. SFF replicates the packet and sends a copy of the packet including NSH to ES-1. The original packet is not changed. SFF sends the original packet to SF-2.

An RO SF such as IDS is specified the same way as a regular SF in the SFC Classification Policy. For example, the SFC in Figure 1 contains the following SFs: SFC - DDoS : [IDS] : Firewall When the SFC is converted to an SFP, the combination of Extended SFC Proxy and the IDS RO SF presents as a regular SF in the SFP as depicted in Figure 3. The SFP comprises of the following: SFP - DDoS : SFC Proxy for [IDS] : Firewall The SFC Control Plane also provisions the Extended SFC Proxy to send the replicated packet to the [IDS] SF. The provisioning message is outside the scope of this document.

An RO ES is not provisioned by SFC Classification Policy. Implementation may choose to use a dedicated policy for an RO ES such as "Packet Capture Policy". The policy for RO ES may be configured into a regular SF when the SF performs replication for the RO ES. In the scenario where SFF performs packet replication, the RO ES policy may be evaluated by the SFC Control Plane. The SFC Control Plane programs the replication locations into the SFF, as indicated by (SPID, SI) pairs. Figure 6 below illustrates a control plane flow for setting packet replication in the SFF for an RO ES.

SFC Control Plane evaluates the RO ES policy and determines the location(s) for SFF to perform packet replication and send packets to RO ES. SFC Control Plane uses C2 Control Plane-SFF interface () to update the SFF forwarding table with replication entries to RO ES.

An RO SF MUST NOT send received packets back to the Extended SFC Proxy.

The Extended SFC Proxy for an RO SF carries the following additional capabilities compared with a regular SFC Proxy: Packet replication Preserving the SFC encapsulation in the copy of the packet when the RO SF is SFC aware The Extended SFC Proxy MUST discard any packets from the RO SF to prevent duplicated packets to the SFF. When preserved, the NSH SPID/SI in the packet copy sent to RO SF MUST not change. The NSH SI in the original packet forwarded back to the SFF MUST be decremented.

An RO ES should have proper transport with the data source, either the SF or SFF. If it receives replicated packets from the SFF, the RO ES should comply with the transport as specified for the SFC, similar to that between a regular SF and the SFF. An RO ES MUST NOT send received packets back to the data source.

There is not any special requirement for the SFF to support an RO SF. The Extended SFC Proxy performs packet replication and other regular SF tasks on behalf of the RO SF.

The following figure illustrates a sample SFF forwarding table when the SFF carries out the packet replication task for RO ES. The "copy" column in the forwarding table is used to decide whether a copy or the original packet should be sent to the next hop (SF or ES). Entries for the RO ES have the "copy" field set.

In order to support RO ES, implementation of an SFF SHOULD support the following capabilities: Packer replication Discarding any packets returned by an RO ES Additional capabilities for receive-only support include the following: Replicating a portion of the packet (e.g. headers only) Filtering selected packets to be replicated to receive-only service Sending collective statistics in place of raw packet data Producing Netflow/IPFIX and other events Those capabilities are beyond the scope of this document.

Even if an RO SF is required not to send packets back to the Extended SFC Proxy, the implementation of Extended SFC Proxy SHOULD handle packets from an RO SF gracefully without causing exceptions or duplicated packets in the SFP.

Authors would like to thank Jeremy Felix and Jay Iyer for their contributions, and Jim Guichard, Paul Quinn and Joel Halpern for their review and comments.

This document includes no request to IANA.