Service Function Chaining: Subscriber and Policy Identification Variable-Length NSH Context Headers
draft-sfc-serviceid-header-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Authors Behcet Sarikaya  , Mohamed Boucadair  , Dirk Hugo 
Last updated 2018-10-15
Replaced by RFC 8979, RFC 8979
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                                                          B. Sarikaya
Internet-Draft                                       Denpel Informatique
Intended status: Standards Track                            M. Boucadair
Expires: April 18, 2019                                           Orange
                                                             D. von Hugo
                                                        Deutsche Telekom
                                                        October 15, 2018

    Service Function Chaining: Subscriber and Policy Identification
                  Variable-Length NSH Context Headers
                     draft-sfc-serviceid-header-00

Abstract

   This document discusses how to inform Service Functions (SFs) about
   subscriber- and service-related information for the sake of policy
   enforcement and appropriate SFC-inferred forwarding.

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 https://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 18, 2019.

Copyright Notice

   Copyright (c) 2018 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
   (https://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

Sarikaya, et al.         Expires April 18, 2019                 [Page 1]
Internet-Draft    Service, Subscriber and Hostid in SFC     October 2018

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   4
   3.  Subscriber Identification NSH Variable-Length Context Header    4
   4.  Policy Identification NSH Variable-Length Context Headers . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   8
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   This document discusses how to inform Service Functions about
   subscriber- and service-related information when required for the
   sake of policy enforcement.  Indeed, subscriber-related information
   may be required to enforce subscriber-specific, SFC-based traffic
   forwarding policies, since the information carried in packets may not
   be sufficient.

   The enforcement of SFC-based differentiated traffic forwarding
   policies may also be inferred by QoS considerations.  QoS information
   may serve as an input to classification of the Service Function Path
   (SFP) for path computation and establishment.

   The dynamic structuring of service function chains and their
   subsequent enforcement may be conditioned by QoS requirements that
   will affect SF instance identification, location, and sequencing.

   Since network and path conditions may change dynamically based on
   e.g. traffic load and radio path variations the path decision and
   configuration mechanisms have to reflect the potentially changing
   context and consider corresponding information network.

   SFs and SF Forwarders (SFFs) involved in an SFC have to contribute to
   the respective QoS requirements characterized by low transmission
   delay between each other, by exposing a high availability of
   resources to process function tasks, or by redundancy provided by
   stand-by machines for seamless execution continuation in case of
   failures.  These requirements may be satisfied by means of control
   protocols, but in some contexts, (e.g., in networks where resources

Sarikaya, et al.         Expires April 18, 2019                 [Page 2]
Internet-Draft    Service, Subscriber and Hostid in SFC     October 2018

   are very much constrained), carrying QoS-related information directly
   in packets may improve the overall SFC operation instead of relying
   upon the potential complexity or adding overhead introduced by some
   SFC control plane features.  This information is e.g. included as
   metadata in the Network Service Header (NSH) [RFC8300] as the SFC
   encapsulation to provide the SFP identification.

   This document adheres to the architecture defined in [RFC7665].  This
   document assumes the reader is familiar with [RFC7665], [RFC8459] and
   [RFC8300].

   Metadata defined in this document may be required to implement
   services such as, but not limited to, traffic policy control,
   parental control, traffic offload.  Such features are often provided
   by operators as part of their service portfolio.

   Another example is the applicability of service chaining in the
   context of mobile networks (typically, in the 3GPP defined (S)Gi
   Interface) [I-D.ietf-sfc-use-case-mobility].  Because of the
   widespread use of private addressing in those networks, if advanced
   SFs to be invoked are located after a NAT device (that can reside in
   the Packet Data Network (PDN) Gateway (PGW) or in a distinct
   operator-specific node), the identification based on the internal IP
   address is not anymore possible once the NAT has been crossed.  As
   such, means to allow passing the internal information may optimise
   packet traversal within an SFC-enabled mobile network domain.
   Furthermore, some SFs that are not enabled on the PGW may require a
   subscriber identifier to properly operate.  Other use cases that
   suffer from identification problems further are discussed in
   [RFC7620].

   This document does not make any assumption about the structure of
   policy identifiers; each such service-related information is treated
   as an opaque value by the SFC operations and protocols.  The
   semantics and validation of these identifiers are up to the control
   plane used for SFC.  Expectations to SFC control plane protocols are
   laid down, e.g., in [RFC8459], but specifications of SFC control
   plane functionalities are also discussed in
   [I-D.ietf-bess-nsh-bgp-control-plane],
   [I-D.wu-pce-traffic-steering-sfc], or [I-D.maglione-sfc-nsh-radius].

   The use cases considered in this document assume the NSH is used
   exclusively within a single administrative domain.

Sarikaya, et al.         Expires April 18, 2019                 [Page 3]
Internet-Draft    Service, Subscriber and Hostid in SFC     October 2018

2.  Conventions and Terminology

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

   The reader should be familiar with the terms defined in [RFC7665].

3.  Subscriber Identification NSH Variable-Length Context Header

   Subscriber Identifier is defined as an optional variable-length NSH
   context header.  Its structure is shown in Figure 1.

   The subscriber identifier is used to convey an identifier already
   assigned by the service provider to uniquely identify a subscriber.
   This header may convey an opaque subscriber Identifier, a domain-
   local encoding of the subscriber identity that can be used by the
   service functions to find appropriate policy, state, or similar
   information.

   Revealing any personal and subscriber-related information to third
   parties must be avoided to prevent privacy breaches in terms of user
   tracking etc.

   The classifier and SFC-aware Service Functions MAY be instructed via
   a control interface to inject or strip a subscriber identifier
   context header.  Also, the data to be injected in such header SHOULD
   be configured to nodes authorized to inject such headers.  Failures
   to inject such headers SHOULD be logged locally while a notification
   alarm MAY be sent to a Control Element.  The details of sending
   notification alarms (i.e., the parameters affecting the transmission
   of the notification alarms depend on the information in the context
   header such as frequency, thresholds, and content in the alarm: full
   header, header ID, timestamp etc.)  SHOULD be configurable by the
   control plane.

   This document adheres to the recommendations in [RFC8300] for
   handling the context headers at both ingress and egress SFC boundary
   nodes.  That is, to strip such context headers.

   SFC-aware SFs and proxies MAY be instructed to strip a subscriber
   identifier from the packet or to pass the data to the next SF in the
   chain after processing the content of the headers.  If no instruction
   is provided, the default behavior is to maintain such context headers
   so that the information can be passed to next SFC-aware hops.

   SFC-aware functions MAY be instructed via the control plane about the
   validation checks to run on the content of these context headers

Sarikaya, et al.         Expires April 18, 2019                 [Page 4]
Internet-Draft    Service, Subscriber and Hostid in SFC     October 2018

   (e.g., accept only some lengths, accept some subtypes) and the
   behavior to adopt.  For example, SFC-aware nodes may be instructed to
   ignore the context header, to remove the context header from the
   packet, etc.  Nevertheless, this specification does not require nor
   preclude such additional validation checks.  These validation checks
   are deployment-specific.  If validation checks fail on a context
   header, an SFC-aware node ignores that context header.  The event
   SHOULD be logged locally while a notification alarm MAY be sent to a
   control element if the SFC-aware node is instructed to do so.

   Multiple subscriber Identifier context TLVs MAY be present in the NSH
   each carrying a distinct sub-type.

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Metadata Class       |      Type     |U|    Length   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   SubT        |                                               |
      +-+-+-+-+-+-+-+-+
      ~                      Subscriber Identifier                    ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 1: Subscriber Identifier Variable-Length Context Header

   The description of the fields is as follows:

   o  Metadata Class: MUST be set to 0x0 [RFC8300].

   o  Type: TBD1 (See Section 5)

   o  SubT field of 8 bits indicates the sub-type of the information
      conveyed in the "Subscriber Identifier" field.  The following
      values are defined:

      *  0x00: Opaque value

      *  0x02: Subscriber ID.  The structure of this ID is deployment-
         specific.

   o  Subscriber Identifier: Carries an opaque subscriber identifier or
      an identifier that corresponds to the sub-type.

   An agreement on standardized NSH elements as proposed above and in
   the next section would allow for cross-vendor inter-operability
   within an SFC domain, which according to [RFC7665] is limited to a
   single network administrative domain.  Thus with the proposed Context

Sarikaya, et al.         Expires April 18, 2019                 [Page 5]
Internet-Draft    Service, Subscriber and Hostid in SFC     October 2018

   Headers size a large amount of subscribers, and services should be
   supported and the approach would scale.

4.  Policy Identification NSH Variable-Length Context Headers

   Dedicated service-specific performance identifier is defined to
   differentiate between services requiring specific treatment to
   exhibit a performance characterized by, e.g., ultra-low latency (ULL)
   or ultra-high reliability (UHR).  These parameters are related to
   policy identifier, among others.  They are contained in the Policy
   Identifier.  The policy Identifier thus allows for the enforcement of
   a per service policy such as a service classification function to
   only consider specific Service Function instances during service
   function path establishment.  Details of this process are
   implementation- specific.  For illustration purposes, the classifier
   may retrieve the details of usable service functions based upon the
   corresponding service ID.  Typical criteria for instantiating
   specific service functions include location, performance or proximity
   considerations.  For UHR services, the stand-by operation of back-up
   capacity or the deployment of multiple service function instances may
   be requested.

   In other words, the classifier uses this kind of information to
   decide about the set of SFFs to invoke to honor the latency or
   reliability requirement (e.g., compute an Rendered Service Path, RSP,
   or insert a pointer to be shared with involved SFFs).

   Policy Identifier is defined as optional variable length context
   header.  Its structure is shown in Figure 2.

   Policy Identifier context header MAY convey a user or service
   provider defined unique identity which can be described by an opaque
   value.

   The service requirements in terms of, e.g., maximum latency or
   minimum outage probability are specified by service providers and are
   out of the scope of this document.

   Multiple Policy Identifier context headers MAY be present in the NSH;
   each carrying a distinct sub-type.

Sarikaya, et al.         Expires April 18, 2019                 [Page 6]
Internet-Draft    Service, Subscriber and Hostid in SFC     October 2018

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Metadata Class       |      Type     |U|    Length   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   SubT        |                                               |
      +-+-+-+-+-+-+-+-+
      ~                      Policy Identifier                       ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 2: Policy Identifier Variable-Length Context Header

   The description of the fields is as follows:

   o  Metadata Class: MUST be set to 0x0 [RFC8300].

   o  Type: TBD2 (See Section 5)

   o  SubT: 8-bit field that carries the sub-type of the information
      conveyed in the "Policy Identifier" field.  The following values
      are defined:

      *  0x00: Opaque value

      *  0x03: Policy Identifier.  The structure of this ID is service
         deployment-specific.

      *  0x04 - 0x08: reserved

   o  Policy Identifier: Represents a specific service performance
      characteristic reflected in the SubT field, but also denotes a
      default basic (best effort) service without specifically defined
      requirements.  It MAY also be an opaque value which semantic is
      defined by the operator.

5.  IANA Considerations

   This document requests IANA to assign the following types from the
   "NSH IETF- Assigned Optional Variable-Length Metadata Types" (0x0000
   IETF Base NSH MD Class) registry available at:
   https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable-
   length-metadata-types.

Sarikaya, et al.         Expires April 18, 2019                 [Page 7]
Internet-Draft    Service, Subscriber and Hostid in SFC     October 2018

             +------+-----------------------+----------------+
             | C1   | C2                    |                |
             +------+-----------------------+----------------+
             | TBD1 | Subscriber Identifier | [ThisDocument] |
             | TBD2 | Policy Identifier     | [ThisDocument] |
             +------+-----------------------+----------------+

6.  Security Considerations

   Data plane SFC-related security considerations are discussed in
   [RFC7665] and [RFC8300].

   Nodes that are involved in an SFC-enabled domain are assumed to be
   trusted ([RFC8300]).  Means to check that only authorized nodes are
   solicited when a packet is crossing an SFC-enabled domain.

7.  Privacy Considerations

   The metadata defined in this document does not include any privacy
   related information.

8.  Acknowledgements

   Comments from Joel Halpern on a previous version and by Carlos
   Bernardos are appreciated.  Contributions and review by Christian
   Jacquenet, Danny Lachos, Debashish Purkayastha, and Christian Esteve
   Rothenberg are thankfully acknowledged.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <https://www.rfc-editor.org/info/rfc7665>.

   [RFC8300]  Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
              "Network Service Header (NSH)", RFC 8300,
              DOI 10.17487/RFC8300, January 2018,
              <https://www.rfc-editor.org/info/rfc8300>.

Sarikaya, et al.         Expires April 18, 2019                 [Page 8]
Internet-Draft    Service, Subscriber and Hostid in SFC     October 2018

9.2.  Informative References

   [I-D.ietf-bess-nsh-bgp-control-plane]
              Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L.
              Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess-
              nsh-bgp-control-plane-04 (work in progress), July 2018.

   [I-D.ietf-sfc-use-case-mobility]
              Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and
              J. Uttaro, "Service Function Chaining Use Cases in Mobile
              Networks", draft-ietf-sfc-use-case-mobility-08 (work in
              progress), May 2018.

   [I-D.maglione-sfc-nsh-radius]
              Maglione, R., Trueba, G., and C. Pignataro, "RADIUS
              Attributes for NSH", draft-maglione-sfc-nsh-radius-01
              (work in progress), October 2016.

   [I-D.wu-pce-traffic-steering-sfc]
              Wu, Q., Dhody, D., Boucadair, M., Jacquenet, C., and J.
              Tantsura, "PCEP Extensions for Service Function Chaining
              (SFC)", draft-wu-pce-traffic-steering-sfc-12 (work in
              progress), June 2017.

   [RFC7620]  Boucadair, M., Ed., Chatras, B., Reddy, T., Williams, B.,
              and B. Sarikaya, "Scenarios with Host Identification
              Complications", RFC 7620, DOI 10.17487/RFC7620, August
              2015, <https://www.rfc-editor.org/info/rfc7620>.

   [RFC8459]  Dolson, D., Homma, S., Lopez, D., and M. Boucadair,
              "Hierarchical Service Function Chaining (hSFC)", RFC 8459,
              DOI 10.17487/RFC8459, September 2018,
              <https://www.rfc-editor.org/info/rfc8459>.

Authors' Addresses

   Behcet Sarikaya
   Denpel Informatique

   Email: sarikaya@ieee.org

   Mohamed Boucadair
   Orange
   Rennes 3500, France

   Email: mohamed.boucadair@orange.com

Sarikaya, et al.         Expires April 18, 2019                 [Page 9]
Internet-Draft    Service, Subscriber and Hostid in SFC     October 2018

   Dirk von Hugo
   Deutsche Telekom
   Deutsche-Telekom-Allee 7
   D-64295 Darmstadt
   Germany

   Email: Dirk.von-Hugo@telekom.de

Sarikaya, et al.         Expires April 18, 2019                [Page 10]