SFC J. Guichard, Ed.
Internet-Draft H. Song
Intended status: Informational Huawei
Expires: September 19, 2018 J. Tantsura
Nuage Networks
J. Halpern
Ericsson
W. Henderickx
Nokia
March 18, 2018
NSH and Segment Routing Integration for Service Function Chaining
draft-guichard-sfc-nsh-sr-00
Abstract
This document describes two application scenarios where Network
Service Header (NSH) and Segment Routing (SR) can be deployed
together 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.
In the first scenario, an NSH-based SFC is created using SR as the
transport between SFFs. SR in this case is just one of many
encapsulations that could be used to maintain the transport-
independent nature of NSH-based service chains.
In the second scenario, SR is used to represent each service hop of
the NSH-based SFC as a segment within the segment-list. SR and NSH
in this case are integrated.
In both of these scenarios SR is responsible for steering packets
between SFFs of a given SFP and NSH is responsible for maintaining
the integrity of the service plane, the SFC instance context, and any
associated metadata.
These application scenarios demonstrate that NSH and SR can work
jointly and complement each other leaving the network operator with
the flexibility to use whichever transport technology makes sense in
specific areas of their network infrastructure, and still maintain an
end-to-end service plane using the NSH technology.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Guichard, et al. Expires September 19, 2018 [Page 1]
Internet-Draft NSH-SR SFC March 2018
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 September 19, 2018.
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. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. NSH-based SFC with SR-based transport tunnel . . . . . . . . 3
3. SR-based SFC with integrated NSH service plane . . . . . . . 8
4. Encapsulation Details . . . . . . . . . . . . . . . . . . . . 10
4.1. NSH using MPLS-SR Transport . . . . . . . . . . . . . . . 10
4.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. Informative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Motivation
Service Function Chaining (SFC) allows network services to be
dynamically created for specific flows by chaining the relevant
service functions in the right sequence. RFC7498 [RFC7498] provides
an overview of the SFC problem statement and RFC7665 [RFC7665]
Guichard, et al. Expires September 19, 2018 [Page 2]
Internet-Draft NSH-SR SFC March 2018
specifies the SFC architecture. NSH-based SFC [RFC8300] is the most
mature SFC solution.
As described in [I-D.ietf-spring-segment-routing], Segment Routing
(SR) leverages the source routing paradigm. A node steers a packet
through an SR Policy instantiated as an ordered list of instructions
called segments. While initially designed for policy-based source
routing, SR also finds its application in supporting SFC
[I-D.xu-clad-spring-sr-service-chaining]. The two flavors of SR,
namely MPLS-SR [I-D.ietf-spring-segment-routing-mpls] and SRv6
[I-D.ietf-6man-segment-routing-header], can both encode a Service
Function (SF) as a segment so that an SFC can be specified as a
segment list.
While each scheme (i.e., NSH-based SFC and SR-based SFC) can work
independently, we show how the two can work together in concert and
complement each other through two representative application
scenarios. Both application scenarios may be supported using either
MPLS-SR or SRv6:
o NSH-based SFC with SR-based transport tunnel: in this scenario
segment routing provides a transport tunnel between SFFs of an
NSH-based SFC.
o SR-based SFC with integrated NSH service plane: in this scenario
each service hop of the SFC is represented as a segment of the SR
segment-list. SR is responsible for steering traffic through the
necessary SFFs as part of the segment routing path and NSH is
responsible for maintaining the service plane, and holding the SFC
instance context and associated metadata.
It is of course possible to combine both of these two scenarios so as
to support specific deployment requirements and use cases.
2. NSH-based SFC with SR-based transport tunnel
Because of the transport-independent nature of NSH-based service
chains, it is expected that the technology has broad applicability
across different domains of the network. By way of illustration
perhaps the SFs for a given SFC are available in a single data
center, or perhaps spread throughout multiple data centers, or
different POPs, depending upon the preference and/or availability of
service resources. Regardless of where the service resources are
deployed it is necessary to provide traffic steering through a set of
SFFs and NSH-based service chains provide the flexibility for the
network operator to choose which particular tunnel transport to use
between said SFFs, which may be different depending upon which area
of the network the SFF/SF is currently deployed. Therefore from an
Guichard, et al. Expires September 19, 2018 [Page 3]
Internet-Draft NSH-SR SFC March 2018
SFC architecture perspective, segment routing is simply one of
multiple available transport encapsulations that can be used for
traffic steering between SFFs.
The following 3 figures provide an example of an SFC established for
flow F that has SFs located in different data centers, DC1 and DC2.
For the purpose of illustration, let the SFC's Service Path
Identifier (SPI) be 100 and the initial Service Index (SI) be 255.
Referring to Figure 1 packets of flow F in DC1 are classified into an
NSH-based SFC and encapsulated after classification as <Inner
Pkt><NSH: SPI 100, SI 255><Outer-transport> and forwarded to SFF1.
After removing the outer transport encapsulation, that may or may not
be MPLS-SR or SRv6, SFF1 uses the SPI, SI carried within the NSH
encapsulation to determine that it should forward the packet to SF1.
SF1 applies its service, decrements the SI by 1, and returns the
packet to SFF1. SFF1 therefore has <SPI 100, SI 254> when the packet
comes back from SF1. SFF1 does a lookup on <SPI 100, SI 254> which
results in <next-hop: DC-GW1> and forwards the packet to DC-GW 1.
Guichard, et al. Expires September 19, 2018 [Page 4]
Internet-Draft NSH-SR SFC March 2018
+--------------------------- DC1 ---------------------------+
| +-----+ |
| | SF1 | |
| +--+--+ |
| | |
| | |
| +------------+ | +------------+ |
| | N(100,255) | | | F:Inner Pkt| |
| +------------+ | +------------+ |
| | F:Inner Pkt| | | N(100,254) | |
| +------------+ ^ | | +------------+ |
| (2) | | | (3) |
| | | v |
| (1) | (4) |
|+------------+ ----> +--+---+ ----> +--------+ |
|| | NSH | | NSH | | |
|| Classifier +------------+ SFF1 +--------------+ DC-GW1 + |
|| | | | | | |
|+------------+ +------+ +--------+ |
| |
| +------------+ +------------+ |
| | N(100,255) | | N(100,254) | |
| +------------+ +------------+ |
| | F:Inner Pkt| | F:Inner Pkt| |
| +------------+ +------------+ |
| |
+-----------------------------------------------------------+
Figure 1: SR for inter-DC SFC - Part 1
Referring now to Figure 2 DC-GW1 performs a lookup on the NSH which
results in <next-hop: DC-GW2, encapsulation: SR>. The SR
encapsulation has the SR segment-list to forward the packet across
the Inter-DC network to DC2.
Guichard, et al. Expires September 19, 2018 [Page 5]
Internet-Draft NSH-SR SFC March 2018
+----------- Inter DC --------------+
| (5) |
+------+ ----> | +--------+ ----> +--------+ |
| | NSH | | | SR | | |
+ SFF1 +----------|-+ DC-GW1 +-------------+ DC-GW2 + |
| | | | | | | |
+------+ | +--------+ +--------+ |
| |
| +------------+ |
| | S(DC-GW2) | |
| +------------+ |
| | N(100,254) | |
| +------------+ |
| | F:Inner Pkt| |
| +------------+ |
+-----------------------------------+
Figure 2: SR for inter-DC SFC - Part 2
When the packet arrives at DC2, as shown in Figure 3, DC-GW1 performs
a lookup on the NSH which results in <next-hop: DC-GW2,
encapsulation: SR>. The SR encapsulation has the SR segment-list to
forward the packet across the Inter-DC network to DC2.
Guichard, et al. Expires September 19, 2018 [Page 6]
Internet-Draft NSH-SR SFC March 2018
+------------------------ DC2 ----------------------+
| +-----+ |
| | SF2 | |
| +--+--+ |
| | |
| | |
| +------------+ | +------------+ |
| | N(100,254) | | | F:Inner Pkt| |
| +------------+ | +------------+ |
| | F:Inner Pkt| | | N(100,253) | |
| +------------+ ^ | | +------------+ |
| (7) | | | (8) |
| | | v |
| (6) | (9) |
|+---------+ ----> +--+---+ ----> |
|| | NSH | | IP |
|| DC-GW2 +------------+ SFF2 | |
|| | | | |
|+---------+ +------+ |
| |
| +------------+ +------------+ |
| | N(100,254) | | F:Inner Pkt| |
| +------------+ +------------+ |
| | F:Inner Pkt| |
| +------------+ |
+---------------------------------------------------+
Figure 3: SR for inter-DC SFC - Part 3
The benefits of this scheme are listed as follows:
o The network operator is able to take advantage of the transport-
independent nature of the NSH encapsulation.
o The network operator is able to take advantage of the traffic
steering capability of SR where appropriate.
o Light-weight NSH is used in the data center for SFC and avoids the
complex hierarchical SFC schemes between data centers.
o Clear work division between NSH and SR.
Note that this scenario is applicable to any case where multiple
sections of an SFC are distributed into multiple domains or where a
traffic engineered path is necessary between SFFs.
Guichard, et al. Expires September 19, 2018 [Page 7]
Internet-Draft NSH-SR SFC March 2018
3. SR-based SFC with integrated NSH service plane
In this scenario we assume that the SFs are NSH-aware and therefore
it should not be necessary to implement an SFC proxy to achieve
Service Function Chaining. The operation relies upon SR to perform
SFF-SFF transport and NSH to provide the service plane between SFs
thereby maintaining SFC context and metadata.
When an SFC is established, a packet will first encapsulate an NSH
that will be used to maintain the end-to-end service plane through
use of the SFC context. The SFC context (e.g., the service plane
path referenced by the SPI) is used by an SFF to determine the SR
segment list for forwarding the packet between the SFFs. The packet
is then encapsulated with the SR header and forwarded in the SR
domain.
When a packet's service segment targets a local SF, the SFF strips
off its SR header, updates the SR information, and saves it to a
cache indexed by the NSH SPI. This saved SR information is used to
encapsulate and forward the packet(s) coming back from the SF.
When the SF receives the packet, it processes the packet as usual and
sends it back to the SFF. Once the SFF receives this packet, it
extracts the SR information using the NSH SPI as the index into the
cache. The SFF then pushes the SR header on top of the NSH header,
and forwards the packet to the next segment in the segment list.
Figure 4 illustrates an example of this scenario.
Guichard, et al. Expires September 19, 2018 [Page 8]
Internet-Draft NSH-SR SFC March 2018
+-----+ +-----+
| SF1 | | SF2 |
+--+--+ +--+--+
| |
| |
+-----------+ | +-----------+ +-----------+ | +-----------+
|N(100,255) | | |F:Inner Pkt| |N(100,254) | | |F:Inner Pkt|
+-----------+ | +-----------+ +-----------+ | +-----------+
|F:Inner Pkt| | |N(100,254) | |F:Inner Pkt| | |N(100,253) |
+-----------+ | +-----------+ +-----------+ | +-----------+
(2) ^ | (3) | (5) ^ | (6) |
| | | | | |
| | v | | v
+------------+ (1)--> +-+----+ (4)--> +---+--+ (7)-->IP
| | NSHoSR | | NSHoSR | |
| Classifier +--------+ SFF1 +---------------------+ SFF2 |
| | | | | |
+------------+ +------+ +------+
+------------+ +------------+
| S(SF1) | | S(SF2) |
+------------+ +------------+
| S(SFF2) | | N(100,254) |
+------------+ +------------+
| S(SF2) | | F:Inner Pkt|
+------------+ +------------+
| N(100,255) |
+------------+
| F:Inner Pkt|
+------------+
Figure 4: NSH over SR for SFC
The benefits of this scheme include:
o It is economically sound for SF vendors to only support one
unified solution. The SF is unaware of the SR.
o It simplifies the SFF (i.e., the SR router) by nullifying the
needs for re-classification and SR proxy.
o It provides a standard way to pass metadata to SFs. Note that
currently there is no solution for MPLS-SR to carry metadata and
there is no solution to pass metadata to SR-unaware SFs.
o SR is also used for topology routing in addition to the service
routing.
Guichard, et al. Expires September 19, 2018 [Page 9]
Internet-Draft NSH-SR SFC March 2018
o It takes advantage of SR to eliminate the NSH forwarding state in
SFFs.
o It requires no interworking as would be the case if MPLS-SR based
SFC and NSH-based SFC were deployed as independent mechanisms in
different parts of the network.
4. Encapsulation Details
4.1. NSH using MPLS-SR Transport
MPLS-SR instantiates Segment IDs (SIDs) as MPLS labels and therefore
the segment routing header is a stack of MPLS labels.
When carrying NSH within an MPLS-SR transport the full encapsulation
is as illustrated in Figure 5.
+------------------+
~ MPLS-SR Labels ~
+------------------+
| NSH Base Hdr |
+------------------+
| Service Path Hdr |
+------------------+
~ Metadata ~
+------------------+
Figure 5: NSH using MPLS-SR Transport
As described in [I-D.ietf-spring-segment-routing] the IGP signaling
extension for IGP-Prefix segment includes a flag to indicate whether
directly connected neighbors of the node on which the prefix is
attached should perform the NEXT operation or the CONTINUE operation
when processing the SID. When NSH is carried beneath MPLS-SR it is
necessary to terminate the NSH-based SFC at the tail-end node of the
MPLS-SR label stack. This is the equivalent of MPLS Ultimate Hop
Popping (UHP) and therefore the prefix-SID associated with the tail-
end of the SFC MUST be advertised with the CONTINUE operation so that
the penultimate hop node does not pop the top label of the MPLS-SR
label stack and thereby expose NSH to the wrong SFF. It is
recommended that a specific prefix-SID be allocated at each node for
use by the SFC application for this purpose.
At then end of the MPLS-SR path it is necessary to provide an
indication to the tail-end that NSH follows the MPLS-SR label stack.
Guichard, et al. Expires September 19, 2018 [Page 10]
Internet-Draft NSH-SR SFC March 2018
There are several ways to achieve this but specification is outside
the scope of this document.
4.2. NSH using SRv6 Transport
When carrying NSH within an SRv6 transport the full encapsulation is
as illustrated in Figure 6.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Entry | Flags | Tag | S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e
| | g
| Segment List[0] (128 bits IPv6 address) | m
| | e
| | n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t
| |
| | R
~ ... ~ o
| | u
| | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i
| | n
| Segment List[n] (128 bits IPv6 address) | g
| |
| | S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R
// // H
// Optional Type Length Value objects (variable) //
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N
| Service Path Identifier | Service Index | S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H
| |
~ Variable-Length Context Headers (opt.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: NSH using MPLS-SR Transport
Guichard, et al. Expires September 19, 2018 [Page 11]
Internet-Draft NSH-SR SFC March 2018
5. Security Considerations
TBD.
6. IANA Considerations
This memo includes no request to IANA.
7. Acknowledgments
TBD.
8. Informative References
[]
Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J.,
Field, B., daniel.voyer@bell.ca, d.,
daniel.bernier@bell.ca, d., Matsushima, S., Leung, I.,
Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun,
D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing
Header (SRH)", draft-ietf-6man-segment-routing-header-09
(work in progress), March 2018.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018.
[I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-12
(work in progress), February 2018.
[I-D.xu-clad-spring-sr-service-chaining]
Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
d., Decraene, B., Yadlapalli, C., Henderickx, W., Salsano,
S., and S. Ma, "Segment Routing for Service Chaining",
draft-xu-clad-spring-sr-service-chaining-00 (work in
progress), December 2017.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
Service Function Chaining", RFC 7498,
DOI 10.17487/RFC7498, April 2015,
<https://www.rfc-editor.org/info/rfc7498>.
Guichard, et al. Expires September 19, 2018 [Page 12]
Internet-Draft NSH-SR SFC March 2018
[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>.
Authors' Addresses
James N Guichard (editor)
Huawei
2330 Central Express Way
Santa Clara
USA
Email: james.n.guichard@huawei.com
Haoyu Song
Huawei
2330 Central Express Way
Santa Clara
USA
Email: haoyu.song@huawei.com
Jeff Tantsura
Nuage Networks
USA
Email: jefftant.ietf@gmail.com
Joel Halpern
Ericsson
USA
Email: joel.halpern@ericsson.com
Guichard, et al. Expires September 19, 2018 [Page 13]
Internet-Draft NSH-SR SFC March 2018
Wim Henderickx
Nokia
USA
Email: wim.henderickx@nokia.com
Guichard, et al. Expires September 19, 2018 [Page 14]