SFC M. Boucadair
Internet-Draft C. Jacquenet
Intended status: Informational France Telecom
Expires: August 2, 2014 Y. Jiang
Huawei Technologies Co., Ltd.
R. Parker
Affirmed Networks
C. Pignataro
Cisco Systems, Inc.
January 29, 2014
Requirements for Service Function Chaining
draft-boucadair-sfc-requirements-01
Abstract
This document identifies the requirements for the Service Function
Chaining (SFC).
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 August 2, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Boucadair, et al. Expires August 2, 2014 [Page 1]
Internet-Draft SFC Requirements January 2014
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Detailed Requirements List . . . . . . . . . . . . . . . . . 3
4. Service Function Discovery . . . . . . . . . . . . . . . . . 8
5. SFC Diagnosis & Troubleshooting . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12
1. Introduction
This document identifies the requirements for the Service Function
Chaining (SFC). In particular:
1. Generic requirements are listed in Section 3.
2. Service Function Discovery requirements are discussed in
Section 4.
3. SFC diagnostic requirements are discussed in Section 5.
4. Security-specific requirements are listed in Section 7.
The overall problem space is described in
[I-D.quinn-sfc-problem-statement].
2. Terminology
The reader should be familiar with the terms defined in
[I-D.boucadair-sfc-framework] and [I-D.quinn-sfc-problem-statement].
Boucadair, et al. Expires August 2, 2014 [Page 2]
Internet-Draft SFC Requirements January 2014
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, or as a horizontal scaling of Service Functions, or
are co-resident in a single addressable Network Element, or
any combination thereof.
Note: Communications between co-located Service Functions
are considered implementation-specific. These
considerations are therefore out of scope of the SFC
specification effort.
REQ#3: The solution MUST NOT require any IANA registry for Service
Functions.
REQ#4: The solution MUST NOT assume any predefined order of 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 multiple instances of a given
Service Function ( i.e., a Service Function can be embedded
in multiple Network Elements).
A. This is used for load-balancing, load-sharing, to
minimize the impact of failures (e.g., by means of a hot
or cold standby protection design), to accommodate
planned maintenance operations, etc.
B. 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 to belong
to multiple Service Function Chains.
Boucadair, et al. Expires August 2, 2014 [Page 3]
Internet-Draft SFC Requirements January 2014
REQ#9: The solution MUST support the ability to deploy multiple
SFC-enabled domains 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 pertaining to a specific service.
In particular, unidirectional Service Function Chains, bi-
directional Service Function Chains, or any combination
thereof 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 Service Function
Chains, the definition of a new Service Function Chain, the
addition of new Service Functions without having any impact
on other existing Service Functions or other Service
Function Chains.
REQ#12: The solution MUST provide means to control the SF-inferred
information to be leaked outside an SFC-enabled domain. In
particular, an administrative entity MUST be able to prevent
the exposure of the Service Function Chaining logic and its
related policies outside the 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.
A. Traffic forwarding on a SF Map basis MUST be undertaken
without relying on dedicated resources to treat
fragments. In particular, Out of order fragments MUST
be forwarded on a per-SF Map basis without relying on
any state.
B. Of course, some SFs (e.g., NAT) may require dedicated
resources (e.g., resources to store fragmented packets)
or they may adopt a specific behavior (e.g, limit the
time interval to accept fragments). The solution MUST
NOT interfere with such practices.
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 be transport independent.
Boucadair, et al. Expires August 2, 2014 [Page 4]
Internet-Draft SFC Requirements January 2014
A. The Service Function Chaining should operate regardless
of the network transport used by the administrative
entity. In particular, the solution can be used
whatever the switching technologies deployed in the
underlying transport infrastructure.
B. 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 (because this is deployment-specific).
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. 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 traffic classification
capabilities according to the Service Function Chains
supported within the SFC domain.
REQ#20: The solution MUST NOT require every Service Function to be
co-located with a SFC Classifier; this is a deployment-
specific decision.
REQ#21: The solution MAY allow traffic re-classification at the
level of Service Functions (i.e., a Service Function can
also be co-located with a classifier). The configuration of
classification rules in such context are the responsibility
of the administrative entity that operates the SFC-enabled
domain.
REQ#22: The solution MUST be able to forward traffic between two
Service Functions (involved in the same Service Function
Chain) without relying upon the destination address field of
the a data packet.
REQ#23: The solution MUST allow for the association of a context
with the data packets. In particular:
A. The solution MUST support the ability to invoke
differentiated sets of policies for a Service Function
(such sets of policies are called Profiles). A profile
Boucadair, et al. Expires August 2, 2014 [Page 5]
Internet-Draft SFC Requirements January 2014
denotes a set of policies configured to a local Service
Function (e.g., content-filter-child, content-filter-
adult).
a. Few profiles should be assumed per Service Function
to accommodate the need for scalable solutions.
b. A finer granularity of profiles may be configured
directly to each Service Function; there is indeed
no need to overload the design of Service Function
Chains with policies of low-level granularity.
REQ#24: The solution MUST allow for Operations, Administration, and
Maintenance (OAM) features [RFC6291]. In particular, the
solution MUST:
A. Support means to verify the completion of the forwarding
actions derived from the contents of the SF Map until
the Border Node is reached (see Section 3.4.1 of
[RFC5706]).
B. Support means to ensure coherent classification rules
are installed in and enforced by all the Classifiers of
the SFC domain.
C. Support means to correlate classification policies with
observed forwarding actions.
D. Support in-band liveliness and functionality checking
mechanisms for the instantiated Service Function Chains
and the Service Functions that belong to these chains.
REQ#25: The solution MUST prevent the same Service Function to be
invoked multiple times within the context of the same
Service Function Chain (at the risk of generating Service
Function Loop).
REQ#26: The solution MUST allow for load-balancing.
A. Load-balancing may be provided by legacy technologies or
protocols (e.g., make use of load-balancers)
B. Load-balancing may be part of the Service Function
itself.
C. Load-balancer may be considered as a Service Function
element.
Boucadair, et al. Expires August 2, 2014 [Page 6]
Internet-Draft SFC Requirements January 2014
D. Because of the possible complications, load balancing
SHOULD NOT be driven by the SFC Classifier.
REQ#27: The solution MUST separate SF-specific policy provisioning-
related aspects from the actual handling of packets
(including forwarding decisions).
REQ#28: The solution SHOULD support means to detect the liveliness
of involved Service Functions.
REQ#29: Means to dynamically discover Service Functions SHOULD be
supported.
REQ#30: 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.
A. A SF Map may be composed of IPv4 addresses, IPv6
addresses, or a mix of both IPv4 and IPv6 addresses.
B. Multiple Service Functions can be reachable using the
same IP address. Each of these Service Functions is
unambiguously identified with a Service Function
Identifier.
REQ#31: 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#32: The solution MUST be able to provide different SLAs (Service
Level Agreements,
[I-D.boucadair-connectivity-provisioning-profile]). In
particular,
A. The solution MUST allow for different levels of service
to be provided for different traffic streams (e.g.,
configure Classes of Service (CoSes)).
B. The solution MUST be able to work properly within a
Diffserv domain [RFC2475].
C. The solution SHOULD support the two modes defined in
[RFC2983].
Boucadair, et al. Expires August 2, 2014 [Page 7]
Internet-Draft SFC Requirements January 2014
REQ#33: ECN re-marking, when required, MUST be performed according
to [RFC6040].
4. Service Function Discovery
This section lists the set of requirements for the Service Function
Discovery procedure (denoted hereafter as "the solution").
DISC_REQ#1: The solution MUST use the Service Function Identifier as
a unique identifier that unambiguously distinguishes a
Service Function among the set of Service Functions
enabled in a given SFC domain.
DISC_REQ#2: The solution MUST NOT make any assumption on how a
Service Function Identifier is configured and associated
to a given Service Function.
DISC_REQ#3: The solution MUST allow for the dynamic discovery of all
locations where a given Service Function may reside and
be invoked for a given SF chain. Particularly, the
solution MUST allow for the dynamic discovery of both
IPv4 and IPv6 locators of a Service Function instance.
DISC_REQ#4: The solution SHOULD allow the dynamic discovery of
additional information characterizing a Service
Function, including:
* The capabilities of the Service Function.
* The capacity of the Service Function. For example,
this information can refer to the maximum number of
binding entries that can be supported by a NAT
function, the maximum number of IP-in-IP tunnels that
can be established, the maximum link capacity, etc.
* The current load of the Service Function. This
information may be used for load-balancing purposes
for instance. This parameter may reflect the amount
of active NAT entries, the number of active IP-in-IP
tunnel, the link capacity usage, etc.
DISC_REQ#5: The solution MUST support means to protect the SFC
domain as a whole against attacks that would lead to the
discovery of an illegitimate Service Function. For
example, a Service Function that cannot be invoked for a
specific SF chain.
Boucadair, et al. Expires August 2, 2014 [Page 8]
Internet-Draft SFC Requirements January 2014
DISC_REQ#6: The solution MUST support means to dynamically detect
that a Service Function instance is out of service and
notify the relevant elements accordingly (PDP and
classifiers, for one).
DISC_REQ#7: The solution MUST allow a Service Function instance to
dynamically announce scheduled periods of unavailability
(for maintenance purposes, for example). The support of
this capability is useful for instance to migrate
traffic to another instance of the same Service Function
so as to minimize service disruption. Note also that
operational teams proceed to regular reboots of
operational devices (for major software upgrades, for
example). Dynamically advertising such events to inform
the PDP that a Service Function instance will not be
available during the reboot of the device, would be
useful. Means to indicate whether the Service Function
will be available immediately after the reboot or not
are RECOMMENDED. Indeed, such information will be used
as an input to the decision-making process of the PDP to
avoid any subsequent traffic forwarding policy changes
at the risk of service disruption.
DISC_REQ#8: The solution MAY allow for a Service Function to
dynamically discover its PDP.
5. SFC Diagnosis & Troubleshooting
This section lists the set of requirements for the SFC Diagnosis &
Troubleshooting procedure (denoted hereafter as "the solution").
DIAG_REQ#1: The solution MUST allow to assess the status of the
serviceability of a Service Function (i.e., the
Service Function that provides the service(s) it is
configured for).
DIAG_REQ#2: The solution MUST NOT rely only on IP reachability to
assess whether a Service Function is up and running.
DIAG_REQ#3: The solution MUST allow to diagnose the availability of
a Service Function Chain.
DIAG_REQ#4: The solution MUST support the correlation between a
Service Function Chain and the actual forwarding path
followed by a packet matching that SFC.
Boucadair, et al. Expires August 2, 2014 [Page 9]
Internet-Draft SFC Requirements January 2014
DIAG_REQ#5: The solution MUST allow to diagnose the availability of
a segment of a Service Function Chain, i.e., a subset
of service functions that belong to the said chain.
DIAG_REQ#6: The solution MUST be able to analyze the outcomes of
the processing of a test packet when presented to a
given Service Function for diagnosis purposes.
DIAG_REQ#7: The solution MUST support the unsolicited notification
of signals as a means to notify the PDPs whenever some
events occur (for example, a malfunctioning service
function instance).
DIAG_REQ#8: The solution MUST allow for local diagnostic procedures
specific to each Service Function.
DIAG_REQ#9: The solution MUST allow to make use of local diagnostic
procedures (e.g., regular checks using built-in
diagnostic procedures).
DIAG_REQ#10: The solution MUST allow for customized service
diagnostic. For example, the solution should be able
to generate a test packet as per a customer's request
who may have observed some service degradation.
6. IANA Considerations
Authors of this document do not require any action from IANA.
7. 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 provide means to prevent any
information leaking 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.).
In particular, topology hiding means MUST be supported
to avoid the exposure of the SFC-enabled domain
topology (including the set of the service function
chains supported within the domain and the
corresponding Service Functions that belong to these
chains).
Boucadair, et al. Expires August 2, 2014 [Page 10]
Internet-Draft SFC Requirements January 2014
SEC_REQ#2: The solution MUST support means to protect the SFC-
enabled domain against any kind of denial-of-service and
theft of service (e.g., illegitimate access to the
service) attack.
For example, a user should not be granted access to
connectivity services he/she didn't subscribe to, at
the risk of providing illegitimate access to network
resources.
SEC_REQ#3: The solution MUST NOT interfere with IPsec [RFC4301] (in
particular IPsec integrity checks).
8. Contributors
The following individuals contributed text to the document:
Hongyu Li
Huawei Technologies Co., Ltd.
Bantian, Longgang district
Shenzhen 518129,
China
EMail: hongyu.lihongyu@huawei.com
Jim Guichard
Cisco Systems, Inc.
USA
EMail: jguichar@cisco.com
Paul Quinn
Cisco Systems, Inc.
USA
Email: paulq@cisco.com
9. Acknowledgements
Many thanks to K. Gray for his review.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Boucadair, et al. Expires August 2, 2014 [Page 11]
Internet-Draft SFC Requirements January 2014
10.2. Informative References
[I-D.boucadair-connectivity-provisioning-profile]
Boucadair, M., Jacquenet, C., and N. Wang, "IP/MPLS
Connectivity Provisioning Profile", draft-boucadair-
connectivity-provisioning-profile-02 (work in progress),
September 2012.
[I-D.boucadair-sfc-framework]
Boucadair, M., Jacquenet, C., Parker, R., Lopez, D.,
Guichard, J., and C. Pignataro, "Service Function
Chaining: Framework & Architecture", draft-boucadair-sfc-
framework-00 (work in progress), October 2013.
[I-D.quinn-sfc-problem-statement]
Quinn, P., "Service Function Chaining Problem Statement",
draft-quinn-sfc-problem-statement-02 (work in progress),
December 2013.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
2983, October 2000.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions", RFC
5706, November 2009.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, November 2010.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291, June 2011.
Authors' Addresses
Mohamed Boucadair
France Telecom
Rennes 35000
France
EMail: mohamed.boucadair@orange.com
Boucadair, et al. Expires August 2, 2014 [Page 12]
Internet-Draft SFC Requirements January 2014
Christian Jacquenet
France Telecom
Rennes 35000
France
EMail: christian.jacquenet@orange.com
Yuanlong Jiang
Huawei Technologies Co., Ltd.
Bantian, Longgang district
Shenzhen 518129,
China
EMail: jiangyuanlong@huawei.com
Ron Parker
Affirmed Networks
Acton, MA
USA
EMail: Ron_Parker@affirmednetworks.com
Carlos Pignataro
Cisco Systems, Inc.
USA
EMail: cpignata@cisco.com
Boucadair, et al. Expires August 2, 2014 [Page 13]