Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Mohamed Boucadair , Christian Jacquenet , Yuanlong Jiang , Ron Parker , Carlos Pignataro , Kengo
Last updated 2014-02-12
Replaces draft-boucadair-chaining-requirements
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-boucadair-sfc-requirements-03
SFC                                                         M. Boucadair
Internet-Draft                                              C. Jacquenet
Intended status: Informational                            France Telecom
Expires: August 16, 2014                                        Y. Jiang
                                           Huawei Technologies Co., Ltd.
                                                               R. Parker
                                                       Affirmed Networks
                                                            C. Pignataro
                                                     Cisco Systems, Inc.
                                                                K. Naito
                                                                     NTT
                                                       February 12, 2014

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

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 16, 2014.

Boucadair, et al.        Expires August 16, 2014                [Page 1]
Internet-Draft              SFC Requirements               February 2014

Copyright Notice

   Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Detailed Requirements List  . . . . . . . . . . . . . . . . .   3
   4.  Service Function Discovery  . . . . . . . . . . . . . . . . .   8
   5.  SFC Diagnosis & Troubleshooting . . . . . . . . . . . . . . .   9
   6.  Scalability Considerations  . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   9.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  11
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     11.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 8.

   The overall problem space is described in
   [I-D.ietf-sfc-problem-statement].

Boucadair, et al.        Expires August 16, 2014                [Page 2]
Internet-Draft              SFC Requirements               February 2014

2.  Terminology

   The reader should be familiar with the terms defined in
   [I-D.boucadair-sfc-framework] and [I-D.ietf-sfc-problem-statement].

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.

Boucadair, et al.        Expires August 16, 2014                [Page 3]
Internet-Draft              SFC Requirements               February 2014

   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.

   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.

               Note, the solution must allow to involve distinct SFC
               Boundary Nodes for upstream and downstream.  Multiple SFC
               Boundary Nodes may be deployed within an administrative
               domain.

   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 SFC basis MUST be undertaken
                without relying on dedicated resources to treat
                fragments.  In particular, Out of order fragments MUST
                be forwarded on a per-SFC 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

Boucadair, et al.        Expires August 16, 2014                [Page 4]
Internet-Draft              SFC Requirements               February 2014

                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.

            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.

Boucadair, et al.        Expires August 16, 2014                [Page 5]
Internet-Draft              SFC Requirements               February 2014

   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
                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 until the SFC 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.

Boucadair, et al.        Expires August 16, 2014                [Page 6]
Internet-Draft              SFC Requirements               February 2014

            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#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,

Boucadair, et al.        Expires August 16, 2014                [Page 7]
Internet-Draft              SFC Requirements               February 2014

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

   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

Boucadair, et al.        Expires August 16, 2014                [Page 8]
Internet-Draft              SFC Requirements               February 2014

                   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.

   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.

Boucadair, et al.        Expires August 16, 2014                [Page 9]
Internet-Draft              SFC Requirements               February 2014

   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.

   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.  Scalability Considerations

   Designing the SFC solution to accommodate per-subscriber SFCs rather
   than SFCs on a per group of subscribers basis, should be conditioned
   by the outcomes of assessing the validity of use cases requiring such
   per-subscriber SFC feature.  Note, instantiating per-subscriber SFCs
   would mean that millions of SFCs would need be to handled within an
   SFC-enabled domain!

7.  IANA Considerations

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

Boucadair, et al.        Expires August 16, 2014               [Page 10]
Internet-Draft              SFC Requirements               February 2014

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

   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
                  (including direct access to some SFs), 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).

9.  Contributors

   The following individuals contributed text to the document:

Boucadair, et al.        Expires August 16, 2014               [Page 11]
Internet-Draft              SFC Requirements               February 2014

      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

10.  Acknowledgements

   Many thanks to K. Gray, N. Takaya, H. Kitada, and H. Kojima for their
   comments.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

Boucadair, et al.        Expires August 16, 2014               [Page 12]
Internet-Draft              SFC Requirements               February 2014

   [I-D.ietf-sfc-problem-statement]
              Quinn, P. and T. Nadeau, "Service Function Chaining
              Problem Statement", draft-ietf-sfc-problem-statement-00
              (work in progress), January 2014.

   [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

   Christian Jacquenet
   France Telecom
   Rennes  35000
   France

   EMail: christian.jacquenet@orange.com

Boucadair, et al.        Expires August 16, 2014               [Page 13]
Internet-Draft              SFC Requirements               February 2014

   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

   Kengo Naito
   NTT
   Midori-Cho 3-9-11
   Musashino-shi, Tokyo 180-8585
   Japan

   EMail: naito.kengo@lab.ntt.co.jp

Boucadair, et al.        Expires August 16, 2014               [Page 14]