Internet DRAFT - draft-boucadair-chaining-requirements
draft-boucadair-chaining-requirements
Network Working Group M. Boucadair
Internet-Draft C. Jacquenet
Intended status: Informational France Telecom
Expires: March 09, 2014 Y. Jiang
Huawei Technologies Co., Ltd.
R. Parker
Affirmed Networks
C. Pignataro
Cisco Systems, Inc.
September 05, 2013
Requirements for Service Function Chaining
draft-boucadair-chaining-requirements-02
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 March 09, 2014.
Boucadair, et al. Expires March 09, 2014 [Page 1]
Internet-Draft SFC Requirements September 2013
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Detailed Requirements List . . . . . . . . . . . . . . . . . 2
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
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 Function Chaining
Framework is documented in
[I-D.boucadair-service-chaining-framework].
2. Terminology
The reader should be familiar with the terms defined in
[I-D.boucadair-service-chaining-framework] and
[I-D.quinn-nsc-problem-statement].
3. Detailed Requirements List
The following set of functional requirements should be considered for
the design of the Service Function Chaining solution:
Boucadair, et al. Expires March 09, 2014 [Page 2]
Internet-Draft SFC Requirements September 2013
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, horizontal scaling of Service Functions, are co-
resident on a single addressable Network Element, or any
combination thereof.
Note: Communications between Service Functions co-
resident on same Network Element are considered
implementation-specific. These considerations are 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 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, prevent
from failures (e.g., hot or cold standby protection
mechanism), 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 be
involved in multiple Service Function Chains.
REQ#9: The solution MUST support multiple SFC-enabled domains be
deployed within the same administrative domain.
Boucadair, et al. Expires March 09, 2014 [Page 3]
Internet-Draft SFC Requirements September 2013
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, 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
Service Function Chaining logic and related policies from
being exposed outside its 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 be transport independent.
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 (this is deployment-specific).
Boucadair, et al. Expires March 09, 2014 [Page 4]
Internet-Draft SFC Requirements September 2013
REQ#18: An administrative entity, grouping its Service Functions
within the same IP subnet, SHOULD be able to avoid
encapsulation overhead .
REQ#19: 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#20: The solution MUST support classifying traffic into Service
Function Chains.
REQ#21: The solution MUST NOT require every Service Function be co-
located with a SFC Classifier; this is a deployment-specific
decision.
REQ#22: The solution MAY allow reclassification at the 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 managing that SFC-enabled domain.
REQ#23: The solution MUST be able to forward the traffic between two
Service Functions (involved in the same Service Function
Chain) without relying on the original destination address
in a data packet.
REQ#24: 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
(called Profiles). A profile 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. 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.
b. [NOTE: The following items will be detailed further in
next revisions: (1) provide a generic definition of the
Boucadair, et al. Expires March 09, 2014 [Page 5]
Internet-Draft SFC Requirements September 2013
"context", (2) discuss whether the context have a
meaning for a given SFC-enabled domain or it is SF-
specific, (3) provide examples, etc.]
REQ#25: The solution MUST allow for Operations, Administration, and
Maintenance (OAM) features [RFC6291]. In particular,
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 to all SFC Classifiers.
c. Support means to correlate between the classification
policies and observed forwarding actions.
d. Support in-band liveness and functionality checking of
instantiated Service Function Chains.
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.
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.
d. Because of the possible complications, load balancing
SHOULD NOT be driven by the SFC Classifier.
REQ#28: The solution MUST separate provisioning-related aspects from
the actual handling of packets (including forwarding
decisions).
REQ#29: The solution SHOULD means to detect the liveness of involved
Service Functions.
Boucadair, et al. Expires March 09, 2014 [Page 6]
Internet-Draft SFC Requirements September 2013
REQ#30: Means to dynamically discover Service Functions SHOULD be
supported.
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.
a. A Service Function Chain 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#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,
a. The solution MUST allow for different levels of service
to be provided for traffic streams (e.g., configure
Classes of Service (CoSes)).
b. The solution MUST be compatible with Diffserv [RFC2475].
4. IANA Considerations
Authors of this document do 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 provide means to prevent leaking any
information that would be used as a hint to guess
internal engineering practices (e.g., network topology,
Boucadair, et al. Expires March 09, 2014 [Page 7]
Internet-Draft SFC Requirements September 2013
service infrastructure topology, hints on the enabled
mechanisms to protect internal service infrastructures,
etc.).
SEC_REQ#2: The solution MUST support means to defend against denial-
of-service and theft of service (e.g., illegitimate
access to the service). For example, a user should not
be granted access to connectivity services it didn't
subscribed to such as illegitimate access to network
resources.
SEC_REQ#3: The solution MUST NOT interfere with IPsec [RFC4301] (in
particular IPsec integrity checks).
6. 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
7. Acknowledgements
Many thanks to K. Gray for his review.
Boucadair, et al. Expires March 09, 2014 [Page 8]
Internet-Draft SFC Requirements September 2013
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.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-service-chaining-framework]
Boucadair, M., Jacquenet, C., Parker, R., Lopez, D.,
Guichard, J., and C. Pignataro, "Differentiated Service
Function Chaining Framework", draft-boucadair-service-
chaining-framework-00 (work in progress), August 2013.
[I-D.quinn-nsc-problem-statement]
Quinn, P., Guichard, J., Surendra, S., Agarwal, P., Manur,
R., Chauhan, A., Leymann, N., Boucadair, M., Jacquenet,
C., Smith, M., Yadav, N., Nadeau, T., Gray, K., McConnell,
B., and K. Kevin, "Network Service Chaining Problem
Statement", draft-quinn-nsc-problem-statement-03 (work in
progress), August 2013.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[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.
[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
Boucadair, et al. Expires March 09, 2014 [Page 9]
Internet-Draft SFC Requirements September 2013
Mohamed Boucadair
France Telecom
Rennes 35000
France
EMail: mohamed.boucadair@orange.com
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 March 09, 2014 [Page 10]
