SFC B. Sarikaya
Internet-Draft
Intended status: Standards Track D. von Hugo
Expires: May 1, 2021 Deutsche Telekom
M. Boucadair
Orange
October 28, 2020
Service Function Chaining: Subscriber and Performance Policy
Identification Variable-Length Network Service Header (NSH) Context
Headers
draft-ietf-sfc-serviceid-header-11
Abstract
This document defines Subscriber and Performance Policy Identifiers
Network Service Header Variable-Length Context Headers to inform
Service Functions about subscriber- and service-related information
for the sake of policy enforcement and appropriate service function
chaining operations. The structure of each Context Header, their use
and processing by NSH-aware nodes are described.
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 May 1, 2021.
Copyright Notice
Copyright (c) 2020 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
Sarikaya, et al. Expires May 1, 2021 [Page 1]
Internet-Draft NSH Subscriber/Performance Policy TLVs October 2020
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. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Subscriber Identification NSH Variable-Length Context Header 4
4. Performance Policy Identification NSH Variable-Length Context
Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
This document discusses how to inform Service Functions (SFs)
[RFC7665] about subscriber and service policy information, when
required, for the sake of policy enforcement within a single
administrative domain. Particularly, subscriber-related information
may be required to enforce subscriber-specific SFC-based traffic
policies. However, the information carried in packets may not be
sufficient to unambiguously identify a subscriber. This document
fills this void by specifying a new Network Service Header (NSH)
[RFC8300] Context Header to convey and disseminate such information
within the boundaries of a single administrative domain (Section 3).
Also, traffic steering by means of SFC may be driven, for example, by
QoS (Quality of Service) considerations. Typically, QoS information
may serve as an input for the computation, establishment, and
selection of the Service Function Path (SFP). Furthermore, the
dynamic structuring of service function chains and their subsequent
SFPs may be conditioned by QoS requirements that will affect SF
instance(s) identification, location, and sequencing. Hence, the
need to supply a performance policy identifier to downstream SFs to
appropriately meet the service requirements arises. This information
is proposed to be included as a Context Header in the NSH
(Section 4).
Sarikaya, et al. Expires May 1, 2021 [Page 2]
Internet-Draft NSH Subscriber/Performance Policy TLVs October 2020
The context information defined in this document can be applicable in
the context of mobile networks (particularly, in the 3GPP defined
(S)Gi Interface) [I-D.ietf-sfc-use-case-mobility]. Typically,
because of the widespread use of private addressing in those
networks, if SFs to be invoked are located after a NAT function, the
identification based on the internal IP address is not possible once
the NAT has been crossed. NAT functionality can reside in a distinct
node which for 3GPP network can be the Packet Data Network (PDN)
Gateway (PGW) as specified in [TS23401] in case of 4G or the User
Plane Function (UPF) facing the external Data Network (DN) [TS23501]
in case of 5G, respectively. 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/UPF may require a subscriber identifier to
properly operate (see, for example, those listed in [RFC8371]). It
is out of the scope of this document to include a comprehensive list
of deployments which may make use of the Context Headers defined in
the document.
Since subscribers identifiers are distinct from those used to
identify a performance policy and given that multiple policies may be
associated with a single subscriber within a service function chain,
these identifiers are carried in distinct Context Headers rather than
multiplexing them in one single Context Header. This approach avoids
to require additional internal structures of the Context Headers to
decide unambiguously whether an identifier refers to a subscriber or
to a policy.
This document does not make any assumption about the structure of
subscriber or performance policy identifiers; each such identifier is
treated as an opaque value. The semantics and validation of these
identifiers are policies local to an SFC-enabled domain. This
document focuses on the data plane behaviour. Control plane
considerations are out of the scope.
The reader may refer to Section 3 of [RFC8300] for MTU
considerations. Such considerations are not reiterated here.
This document assumes the NSH is used exclusively within a single
administrative domain.
This document adheres to the SFC data plane architecture defined in
[RFC7665]. This document assumes the reader is familiar with
[RFC8300].
Sarikaya, et al. Expires May 1, 2021 [Page 3]
Internet-Draft NSH Subscriber/Performance Policy TLVs October 2020
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
The reader should be familiar with the terms defined in [RFC7665].
SFC Control Element refers to a logical entity that instructs one or
more SFC data plane functional elements on how to process packets
within an SFC-enabled domain.
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ 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 U bit: Unassigned bit (see Section 2.5.1 of [RFC8300]).
o Length: Indicates the length of the Subscriber Identifier, in
bytes (see Section 2.5.1 of [RFC8300]).
o Subscriber Identifier: Carries an opaque subscriber identifier.
The Subscriber Identifier Context Header is used to convey an
identifier assigned by the service provider to uniquely identify a
subscriber. This subscriber identifier can be used by service
functions to enforce per-subscriber policies (e.g., apply resource
quota).
Sarikaya, et al. Expires May 1, 2021 [Page 4]
Internet-Draft NSH Subscriber/Performance Policy TLVs October 2020
The classifier and NSH-aware SFs MAY inject or strip a Subscriber
Identifier Context Header as a function of a local policy. In order
to prevent interoperability issues, the type the identifiers carried
in the Subscriber Identifier Context Headers and their format to be
injected in such header should be configured to nodes authorized to
inject and consume such headers. Typically, a node can be instructed
to insert such data following a type/set scheme (e.g., node X should
inject subscriber ID type Y). Other schemes may be envisaged.
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 of the
alarm (full header, timestamp, etc.)) should be configurable.
This document adheres to the recommendations in [RFC8300] for
handling the Context Headers at both ingress and egress SFC boundary
nodes (i.e., to strip such Context Headers). Revealing any personal
and subscriber-related information to third parties is avoided by
design to prevent privacy breaches in terms of user tracking.
Intermediary NSH-aware nodes have to preserve Subscriber Identifier
Context Headers (i.e., the information can be passed to next hop NSH-
aware nodes), but local policy may require an intermediary NSH-aware
node to strip a Subscriber Identifier Context Header after processing
it.
NSH-aware SFs MUST ignore Context Headers carrying unknown subscriber
identifiers.
Local policies may require running additional validation checks on
the content of these Context Headers (e.g., accept only some lengths,
types) and the behavior to adopt at NSH-aware SFs. Such policies may
include to, e.g., ignore the Context Header or to remove it from the
packet. However, this specification does not require nor preclude
such NSH-aware SFs may be instructed to ignore the Context Header, to
remove the Context Header from the packet, etc. These validation
checks are deployment-specific. If validation checks fail on a
Subscriber Identifier Context Header, an NSH-aware SF MUST ignore
that Context Header. The event should be logged locally while a
notification alarm may be sent to a Control Element if the NSH-aware
SF is instructed to do so. For example, an SF that expects an
internal IP address as subscriber identifier will discard Subscriber
Identifier Context Headers conveying Mobile Subscriber ISDN Number
(MSISDN), International Mobile Subscriber Identity (IMSI), or
malformed IP addresses.
Sarikaya, et al. Expires May 1, 2021 [Page 5]
Internet-Draft NSH Subscriber/Performance Policy TLVs October 2020
Multiple Subscriber Identifier Context Headers MAY be present in the
NSH, each carrying a distinct opaque value but all pointing to the
same subscriber. This may be required, e.g., by policy enforcement
mechanisms in a mobile network where some SFs rely on IP addresses as
subscriber Identifiers, while others use non-IP specific identifiers
such as those listed in [RFC8371] and Section 3.3.2 of
[I-D.ietf-sfc-use-case-mobility]. When multiple subscriber
identifier Context Headers are present and an SF is instructed to
strip the Subscriber Identifier Context Header, that SF MUST remove
all Subscriber Identifier Context Headers.
4. Performance Policy Identification NSH Variable-Length Context
Headers
Dedicated service-specific performance identifiers are 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). Other policies can be considered
when instantiating a service function chain within an SFC-enabled
domain. They are conveyed in the Performance Policy Identifier
Context Header.
The Performance Policy Identifier Context Header is inserted in an
NSH packet so that downstream NSH-aware nodes can make use of the
performance information for proper distributed SFC path selection, SF
instance selection, or policy selection at SFs. Note that the use of
the Performance Policy Identifier is not helpful if the path
computation is centralized and a strict SFP is presented as local
policy to SF Forwarders (SFFs).
The Performance Policy Identifier allows for the distributed
enforcement of a per-service policy such as a service function path
to only include specific SFs instances (e.g., SFs located within the
same DC or those that are exposing the shortest delay from an SFF).
Details of this process are implementation-specific. For
illustration purposes, an SFF may retrieve the details of usable SFs
based upon the corresponding performance policy identifier. Typical
criteria for instantiating specific SFs include location,
performance, or proximity considerations. For the particular case of
UHR services, the stand-by operation of back-up capacity or the
deployment of multiple SF instances may be requested.
In an environment characterised by frequent changes of link and path
behaviour, for example due to variable load or availability caused by
propagation conditions on a wireless link, the SFP may have to be
adapted dynamically by on-the move SFC path and SF instance
selection.
Sarikaya, et al. Expires May 1, 2021 [Page 6]
Internet-Draft NSH Subscriber/Performance Policy TLVs October 2020
Performance Policy Identifier is defined as an optional variable
length Context Header. Its structure is shown in Figure 2.
Intermediary NSH-aware nodes have to preserve such Context Headers
(i.e., the information can be passed to next hop NSH-aware nodes),
but local policy may require an intermediary NSH-aware node to strip
one after processing it.
Multiple Performance Policy Identifier Context Headers MAY be present
in the NSH; each carrying an opaque value for a distinct policy that
need to be enforced for a flow. Supplying conflicting policies may
complicate the SFP computation and SF instance location.
Corresponding rules to detect conflicting policies may be provided as
a local policy to the NSH-aware nodes. When such conflict is
detected by an NSH-aware node, the default behavior of the node is to
discard the packet and send a notification alarm to a Control
Element.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Performance Policy Identifier ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Performance 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 U bit: Unassigned bit (see Section 2.5.1 of [RFC8300]).
o Length: Indicates the length of the Performance Policy Identifier,
in bytes (see Section 2.5.1 of [RFC8300]).
o Performance Policy Identifier: Represents an opaque value pointing
to specific performance policy to be enforced. The structure and
semantic of this field is deployment-specific.
Sarikaya, et al. Expires May 1, 2021 [Page 7]
Internet-Draft NSH Subscriber/Performance Policy TLVs October 2020
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.
+-------+-------------------------------+----------------+
| Value | Description | Reference |
+-------+-------------------------------+----------------+
| TBD1 | Subscriber Identifier | [ThisDocument] |
| TBD2 | Performance Policy Identifier | [ThisDocument] |
+-------+-------------------------------+----------------+
6. Security Considerations
Data plane SFC-related security considerations, including privacy,
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 are out of
scope of this document.
A misbehaving node within from the SFC-enabled domain may alter the
content of Subscriber Identifier and Performance Policy Context
Headers which may lead to service disruption. Such attack is not
unique to the Context Headers defined in this document; measures
discussed in [RFC8300] are to be followed.
Access to subscriber data usually requires specific access privilege
levels. To avoid bypassing this guard, it is not advised that an SF
maintaining logs for operational reasons to also log the content of
Subscriber and Performance Policy Context Headers received in NSH
packets if the SF does not use the content of that header for its
operation.
7. 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, Christian Esteve Rothenberg, Kyle Larose,
Donald Eastlake, Qin Wu, Shunsuke Homma, and Greg Mirsky are
thankfully acknowledged.
Sarikaya, et al. Expires May 1, 2021 [Page 8]
Internet-Draft NSH Subscriber/Performance Policy TLVs October 2020
Many thanks to Robert Sparks for the secdir review.
8. References
8.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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
8.2. Informative References
[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-09 (work in
progress), January 2019.
[RFC8371] Perkins, C. and V. Devarapalli, "Mobile Node Identifier
Types for MIPv6", RFC 8371, DOI 10.17487/RFC8371, July
2018, <https://www.rfc-editor.org/info/rfc8371>.
[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>.
[TS23401] 3GPP 23.401 16.5.0, "General Packet Radio Service (GPRS)
enhancements for Evolved Universal Terrestrial Radio
Access Network (E-UTRAN) access,", December 2019.
[TS23501] 3GPP 23.501 16.3.0, "System architecture for the 5G System
(5GS),", December 2019.
Sarikaya, et al. Expires May 1, 2021 [Page 9]
Internet-Draft NSH Subscriber/Performance Policy TLVs October 2020
Authors' Addresses
Behcet Sarikaya
Email: sarikaya@ieee.org
Dirk von Hugo
Deutsche Telekom
Deutsche-Telekom-Allee 9
D-64295 Darmstadt
Germany
Email: Dirk.von-Hugo@telekom.de
Mohamed Boucadair
Orange
Rennes 3500
France
Email: mohamed.boucadair@orange.com
Sarikaya, et al. Expires May 1, 2021 [Page 10]