Requirements for Service Function Chaining
draft-boucadair-sfc-requirements-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Authors Mohamed Boucadair  , Christian Jacquenet  , Yuanlong Jiang  , Ron Parker  , Carlos Pignataro 
Last updated 2013-10-02
Replaces draft-boucadair-chaining-requirements
Stream (None)
Formats pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
SFC                                                         M. Boucadair
Internet-Draft                                              C. Jacquenet
Intended status: Informational                            France Telecom
Expires: April 06, 2014                                         Y. Jiang
                                           Huawei Technologies Co., Ltd.
                                                               R. Parker
                                                       Affirmed Networks
                                                            C. Pignataro
                                                     Cisco Systems, Inc.
                                                        October 03, 2013

               Requirements for Service Function Chaining
                  draft-boucadair-sfc-requirements-00

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 April 06, 2014.

Boucadair, et al.        Expires April 06, 2014                 [Page 1]
Internet-Draft              SFC Requirements                October 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 . . . . . . . . . . . . . . . . . . .   8
   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   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 April 06, 2014                 [Page 2]
Internet-Draft              SFC Requirements                October 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 April 06, 2014                 [Page 3]
Internet-Draft              SFC Requirements                October 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.

            a.  The per-SF Map forwarding 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 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.

            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.

Boucadair, et al.        Expires April 06, 2014                 [Page 4]
Internet-Draft              SFC Requirements                October 2013

            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).

   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).

Boucadair, et al.        Expires April 06, 2014                 [Page 5]
Internet-Draft              SFC Requirements                October 2013

                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.

   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).

Boucadair, et al.        Expires April 06, 2014                 [Page 6]
Internet-Draft              SFC Requirements                October 2013

   REQ#29:  The solution SHOULD means to detect the liveness of involved
            Service Functions.

   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 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#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].

            c.  The solution SHOULD support the two modes defined in
                [RFC2983].

   REQ#34:  ECN re-marking, when required, MUST be performed according
            to [RFC6040].

4.  IANA Considerations

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

Boucadair, et al.        Expires April 06, 2014                 [Page 7]
Internet-Draft              SFC Requirements                October 2013

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,
               service infrastructure topology, hints on the enabled
               mechanisms to protect internal service infrastructures,
               etc.).

                  In particular, topology hiding means MUST supported to
                  avoid exposing the topology of an SFC-enabled domain
                  (including the set of involved Service Functions).

   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

Boucadair, et al.        Expires April 06, 2014                 [Page 8]
Internet-Draft              SFC Requirements                October 2013

      Email: paulq@cisco.com

7.  Acknowledgements

   Many thanks to K. Gray for his review.

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.

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

Boucadair, et al.        Expires April 06, 2014                 [Page 9]
Internet-Draft              SFC Requirements                October 2013

   [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

   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

Boucadair, et al.        Expires April 06, 2014                [Page 10]
Internet-Draft              SFC Requirements                October 2013

   Carlos Pignataro
   Cisco Systems, Inc.
   USA

   EMail: cpignata@cisco.com

Boucadair, et al.        Expires April 06, 2014                [Page 11]