SPRING J. Guichard, Ed.
Internet-Draft Futurewei Technologies
Intended status: Standards Track J. Tantsura, Ed.
Expires: June 16, 2022 Microsoft
December 13, 2021
Integration of Network Service Header (NSH) and Segment Routing for
Service Function Chaining (SFC)
draft-ietf-spring-nsh-sr-10
Abstract
This document describes the integration of the Network Service Header
(NSH) and Segment Routing (SR), as well as encapsulation details, to
support Service Function Chaining (SFC) in an efficient manner while
maintaining separation of the service and transport planes as
originally intended by the SFC architecture.
Combining these technologies allows SR to be used for steering
packets between Service Function Forwarders (SFF) along a given
Service Function Path (SFP) while NSH has the responsibility for
maintaining the integrity of the service plane, the SFC instance
context, and any associated metadata.
This integration demonstrates that NSH and SR can work cooperatively
and provide a network operator with the flexibility to use whichever
transport technology makes sense in specific areas of their network
infrastructure while still maintaining an end-to-end service plane
using NSH.
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 June 16, 2022.
Guichard & Tantsura Expires June 16, 2022 [Page 1]
Internet-Draft NSH-SR SFC December 2021
Copyright Notice
Copyright (c) 2021 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
1.1. SFC Overview and Rationale . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. SFC within Segment Routing Networks . . . . . . . . . . . . . 4
3. NSH-based SFC with SR-MPLS or SRv6 Transport Tunnel . . . . . 5
4. SR-based SFC with Integrated NSH Service Plane . . . . . . . 9
5. Packet Processing for SR-based SFC . . . . . . . . . . . . . 11
5.1. SR-based SFC (SR-MPLS) Packet Processing . . . . . . . . 11
5.2. SR-based SFC (SRv6) Packet Processing . . . . . . . . . . 11
6. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. NSH using SR-MPLS Transport . . . . . . . . . . . . . . . 12
6.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 14
9. Caching Considerations . . . . . . . . . . . . . . . . . . . 14
10. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11.1. Protocol Number for NSH . . . . . . . . . . . . . . . . 14
11.2. SRv6 Endpoint Behavior for NSH . . . . . . . . . . . . . 15
12. Contributing Authors . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
Guichard & Tantsura Expires June 16, 2022 [Page 2]
Internet-Draft NSH-SR SFC December 2021
1.1. SFC Overview and Rationale
The dynamic enforcement of a service-derived and adequate forwarding
policy for packets entering a network that supports advanced Service
Functions (SFs) has become a key challenge for network operators.
For instance, cascading SFs at the 3GPP (Third Generation Partnership
Project) Gi interface (N6 interface in 5G architecture) has shown
limitations such as 1) redundant classification features must be
supported by many SFs to execute their function, 2) some SFs receive
traffic that they are not supposed to process (e.g., TCP proxies
receiving UDP traffic) which inevitably affects their dimensioning
and performance, and 3) an increased design complexity related to the
properly ordered invocation of several SFs.
In order to solve those problems, and to decouple the services
topology from the underlying physical network while allowing for
simplified service delivery, Service Function Chaining (SFC)
techniques have been introduced [RFC7665].
SFC techniques are meant to rationalize the service delivery logic
and master the resulting complexity while optimizing service
activation time cycles for operators that need more agile service
delivery procedures to better accommodate ever-demanding customer
requirements. SFC allows network operators to dynamically create
service planes that can be used by specific traffic flows. Each
service plane is realized by invoking and chaining the relevant
service functions in the right sequence. [RFC7498] provides an
overview of the overall SFC problem space and [RFC7665] specifies an
SFC data plane architecture. The SFC architecture does not make
assumptions on how advanced features (e.g., load-balancing, loose or
strict service paths) could be enabled within a domain. Various
deployment options are made available to operators with the SFC
architecture and this approach is fundamental to accommodate various
and heterogeneous deployment contexts.
Many approaches can be considered for encoding the information
required for SFC purposes (e.g., communicate a service chain pointer,
encode a list of loose/explicit paths, or disseminate a service chain
identifier together with a set of context information). Likewise,
many approaches can also be considered for the channel to be used to
carry SFC-specific information (e.g., define a new header, re-use
existing packet header fields, or define an IPv6 extension header).
Among all these approaches, the IETF created a transport-independent
SFC encapsulation scheme: NSH [RFC8300]. This design is pragmatic as
it does not require replicating the same specification effort as a
function of underlying transport encapsulation. Moreover, this
design approach encourages consistent SFC-based service delivery in
Guichard & Tantsura Expires June 16, 2022 [Page 3]
Internet-Draft NSH-SR SFC December 2021
networks enabling distinct transport protocols in various network
segments or even between SFFs vs SF-SFF hops.
1.2. Requirements Language
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
[RFC2119] [RFC8174] when, and only when, they appear in all capitals,
as shown here.
2. SFC within Segment Routing Networks
As described in [