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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

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

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

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.

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 (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:

• Metadata Class: MUST be set to 0x0 [RFC8300].
• Type: TBD1 (See Section 5)
• 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.
• 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 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.

    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:

• Metadata Class: MUST be set to 0x0 [RFC8300].
• Type: TBD2 (See Section 5)
• 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
• 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.

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

9.2. Informative References

Authors' Addresses