Requirements for Service Function Chaining
draft-boucadair-chaining-requirements-01

Abstract

This document identifies the requirements for the Service Function Chaining.

Requirements Language

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 [RFC2119].

Status of This Memo

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 http://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 February 23, 2014.

Copyright Notice

Copyright (c) 2013 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 (http://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.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Detailed Requirements List
• 4. IANA Considerations
• 5. Security Considerations
• 6. Acknowledgements
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

1. Introduction

This document identifies the requirements for the Service Function Chaining (SFC).

The overall problem space is described in [I-D.quinn-nsc-problem-statement]. The Service Chaining Framework is documented in [I-D.boucadair-network-function-chaining].

2. Terminology

The reader should be familiar with the terms defined in [I-D.boucadair-network-function-chaining].

3. Detailed Requirements List

The following set of functional requirements should be considered for the design of the Service Function Chaining solution:

REQ#1:

The solution MUST NOT make any assumption on whether Service Functions (SF) are deployed directly on physical hardware, as one or more Virtual Machines, or any combination thereof.

REQ#2:

The solution MUST NOT make any assumption on whether Service Functions each reside on a separate addressable Network Element, are co-resident on a single addressable Network Element, or any combination thereof.

REQ#3:

The solution MUST NOT require any IANA registry to store the list of Service Functions.

REQ#4:

The solution MUST NOT assume predefined chains of particular Service Functions. In particular, the solution MUST NOT require any IANA registry to store typical Service Function Chains.

REQ#5:

The identification of instantiated Service Function Chains is local to each administrative domain; it is policy-based and deployment-specific.

REQ#6:

The solution MUST allow a Service Function to be embedded in multiple devices (e.g., servers).

1. This is used for load-balancing, load-sharing, prevent from failures (e.g., hot or cold standby protection mechanism), accommodate planned maintenance operations, etc.
2. How these multiple devices are involved in the service delivery is deployment-specific.

REQ#7:

The solution MUST allow for multiple Service Chains to be simultaneously enforced within an administrative domain.

REQ#8:

The solution MUST allow the same Service Function be involved in multiple Service Function Chains.

REQ#9:

The solution MUST support multiple SFC-enabled domains be deployed within the same administrative domain.

REQ#10:

The solution MUST be able to associate the same or distinct Service Function Chains for each direction (inbound/outbound) of the traffic. In particular, unidirectional Service Function Chains MUST be supported.

REQ#11:

The solution MUST be able to dynamically enforce Service Function Chains. In particular, the solution MUST allow the update or the withdrawal of existing chains, the definition of a new chain, the addition of new Service Functions without having any impact on other existing Service Functions or other Service Function Chains.

REQ#12:

Service Function Chaining logic and related policies SHOULD NOT be exposed outside a given administrative domain.

REQ#13:

The solution SHOULD minimize fragmentation; in particular a minimal set of SFC-specific information should be conveyed in the data packet.

REQ#14:

The solution MUST NOT make any assumption on how RIBs (Routing Information Bases) and FIBs (Forwarding Information Bases) are populated. Particularly, the solution does not make any assumption on protocols and mechanisms used to build these tables.

REQ#15:

The solution MUST NOT make any assumption on the underlying transport technologies used to interconnect involved Service Functions.

1. In particular, the solution can be used whatever the switching technologies deployed in the underlying transport infrastructure.
2. Techniques such as MPLS are neither required nor excluded.

REQ#16:

The solution MUST allow for chaining logics where involved Service Functions are not within the same layer 3 subnet.

REQ#17:

The solution MUST NOT exclude Service Functions to be within the same IP subnet (this is deployment-specific). An administrative entity, grouping its Service Functions within the same IP subnet, SHOULD be able to get rid of any overhead (e.g., encapsulation).

REQ#18:

The solution MUST NOT make any assumption on how the traffic is to be bound to a given chaining policy. In other words, classification rules are deployment-specific and policy-based.

1. Service Function Chaining does not require new classification capabilities compared to current practices.
2. For instance, classification can rely on a subset of the information carried in a received packet such as 5-tuple classification.

REQ#19:

The solution MUST support classifying traffic into Service Function Chains.

1. Preferably, a single classification of packets upon their entry in the SFC domain SHOULD be supported, as this will save computation resources consumed by reclassification, and avoid the provisioning of classification rules into multiple classifiers.
2. The solution MUST NOT require every Service Function be co-located with a Classifier; this is a deployment-specific decision.

REQ#20:

A Classifier MAY be co-located with other Service Functions.

REQ#21:

A Classifier MAY be considered as a Service Function in its own.

REQ#22:

The solution MAY allow reclassification at the Service Functions (i.e., a Service Function can also be co-located with a classifier).

1. Given the risk to jeopardize the overall consistency of the Differentiated Forwarding policy enforced for a specific traffic flow or a set thereof, the administrative entity must configure coherent classification rules.
2. The configuration of classification rules in such context are the responsibility of the administrative entity managing that SFC-enabled domain.

REQ#23:

The solution MUST be able to forward the traffic between two Service Functions (involved the same Service Function Chain) without relying on the Destination Address.

REQ#24:

The solution MUST support the ability to invoke differentiated sets of policies for a Service Functions (called Profiles). A profile denotes a set of policies configured to a local Service Function (e.g., content-filter-child, content-filter-adult).

1. Few profiles should be assumed per Service Function to accommodate the need for scalable solutions.
2. Finer-grained definition of policies belonging to a Service Function should not be driven by the chaining marking.
3. Finer-grained of policies should be configured directly to each Service Function; no need to overload the design of Service Function chains with policies of low-level granularity.

REQ#25:

The solution MUST provide means to ensure the overall consistency of the procedure. For example:

1. Ensure the completion of the forwarding actions derived from the contents of the SFC Map until the border node is reached.
2. Coherent classification rules are installed to all classifiers.
3. The correlation between the classification policies and forwarding actions should be verified.

REQ#26:

The solution MUST prevent the same Service Function to be invoked multiple times in the context of the same Service Function Chain (at the risk of generating Service Function Loop).

REQ#27:

The solution MUST allow for load-balancing:

1. Load-balancing may be provided by legacy technologies or protocols (e.g., make use of load-balancers)
2. Load-balancing may be part of the Service Function itself.
3. Load-balancer may be considered as a Service Function element.
4. Because of the possible complications, load balancing SHOULD NOT be handled at the classifier. This logic should be embedded in the entity which is responsible for ensuring the overall consistency of the solution (i.e., Policy Decision Point).

REQ#28:

The solution MUST separate provisioning-related aspects from the actual handling of packets (including forwarding decisions).

REQ#29:

The solution MUST NOT exclude means to detect the liveliness of involved Service Functions; nevertheless these means are not considered as a mandatory component of the solution.

REQ#30:

Means to dynamically discover Service Functions SHOULD be supported. This feature is not required for the core chaining functionality, but its support is of high interest for operators.

REQ#31:

Service Functions may be reachable using IPv4 and/or IPv6. The administrative domain entity MUST be able to define and enforce policies with regards to the address family to be used when invoking a Service Function.

1. A Service Function Chain may be composed of IPv4 addresses, IPv6 addresses, or a mix of both IPv4 and IPv6 addresses.
2. Multiple Service Functions can be reachable using the same IP address.

REQ#32:

The solution MUST allow for gradual deployment in legacy infrastructures, and therefore coexist with legacy technologies that cannot support SFC-specific capabilities, such as SFC Map interpretation and processing. The solution MUST be able to work in a domain that may be partly composed of opaque elements, i.e., elements that do not support SFC-specific capabilities.

REQ#33:

The solution MUST be able to provide different SLAs (Service Level Agreements, [I-D.boucadair-connectivity-provisioning-profile]). In particular,

1. The solution MUST allow for different levels of service to be provided for traffic streams (e.g., configure Classes of Service (CoSes)).
2. The solution MUST be compatible with Diffserv [RFC2475].

4. IANA Considerations

Authors of this document does not require any action from IANA.

5. Security Considerations

Below are listed some security-related requirements to be taken into account when designing the Service Function Chaining solution:

SEC_REQ#1:

The solution MUST offer at least the same security protection level as the one provided using legacy service engineering and delivery practices.

SEC_REQ#2:

The solution MUST provide means to prevent leaking any information that would be used as a hint to guess internal engineering practices (e.g., network topology, service infrastructure topology, hints on the enabled mechanisms to protect internal service infrastructures, etc.).

SEC_REQ#3:

The solution MUST support means to defend against denial-of-service and theft of service (e.g., illegitimate access to the service).

SEC_REQ#4:

The solution MUST NOT interfere with IPsec [RFC4301] (in particular IPsec integrity checks).

SEC_REQ#5:

The solution MUST NOT lead to routing loops.

6. Acknowledgements

TBC.

7. References

7.1. Normative References

7.2. Informative References

Authors' Addresses