Internet DRAFT - draft-hegde-spring-sfc-stitched-tunnel
draft-hegde-spring-sfc-stitched-tunnel
SPRING S. Hegde
Internet-Draft C. Barth
Intended status: Informational Juniper Networks Inc.
Expires: July 11, 2021 January 7, 2021
Service Function Chaining with Stitched Tunnels
draft-hegde-spring-sfc-stitched-tunnel-00
Abstract
The term "service function chaining" is used to describe the
definition and instantiation of an ordered list of instances of such
service functions, and the subsequent "steering" of traffic flows
through those service functions.This document describes transport
mechanisms that use stitched tunnels to achieve end-to-end service
chaining. This document specifies two different types of transport
encodings, one based on SR-MPLS and another based on IP tunnels.
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 July 11, 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
Hegde & Barth Expires July 11, 2021 [Page 1]
Internet-Draft Service Chaining with Stitched Tunnels January 2021
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Concept of Stitched Tunnel . . . . . . . . . . . . . . . . . 3
4. SR-MPLS based Tunnels . . . . . . . . . . . . . . . . . . . . 6
5. IP Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. Normative References . . . . . . . . . . . . . . . . . . 7
11.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Service function chaining requires an ordered set of service
functions to be executed on the traffic. The set of service
functions could be virtualized functions or physical appliance based
functions or in some cases a mix of both. Traffic needs to be
steered to the set of service functions in an ordered manner. Based
on the the type of traffic, the order of the service functions and
the type of service functions that need to be executed may differ.
Service functions may not be aware of the transport encodings and
hence the transport encodings may have to be removed before passing
the packet(s) to the service functions.
Section Section 3 describes basic concepts of using stitched tunnels
to steer the traffic through the service functions.
Section Section 4 describes the transport encodings using SR-MPLS
based tunnels [RFC8402]. Section Section 5 describes the transport
encodings using IP Tunnels [I-D.saad-teas-rsvpte-ip-tunnels].
This document uses terminology defined in [RFC7665].
2. Terminology
Hegde & Barth Expires July 11, 2021 [Page 2]
Internet-Draft Service Chaining with Stitched Tunnels January 2021
This document uses the following terminology
o Service Function Orchestrator (SFO): Service Function Orchestrator is
responsible for defining the Service Function Chains and the traffic
types where the particular service function chains are applicable.
SFO is also responsible for making all the required configurations to
realize the Service Chain.
Figure 1: Terminology
3. Concept of Stitched Tunnel
Consider a data center environment with virtualized service functions
as shown in (See Figure 2). DCGW1 and DCGW2 are Data center Gateway
devices that connect the data center to the WAN. SP1 and SP2 are
spine devices. TOR1, TOR2 and TOR3 are Top-Of-the-Rack switches that
connect to the servers. a1,b1, c1 etc are VLAN interfaces that
connect to the servers. A1, B1, C1 etc are the service function
instances deployed in the servers.
Hegde & Barth Expires July 11, 2021 [Page 3]
Internet-Draft Service Chaining with Stitched Tunnels January 2021
+------------------------------------------------------------+
| +------+ +------+ |
| | DCGW1| | DCGW2| |
| +------+ +------+ |
| | | |
| +-----+ +-----+ |
| | SP1 |----+ +---------| SP2 | |
| +-----+ | | +-----+ |
| | | | | | | |
| +--------+ | | | | +--------+ |
| | +--------|------|-|-----------+ | |
| | | +------|-|--------------------+ | |
| | | | | | | |
| +------+ +------+ +------+ |
| | TOR1 | | TOR2 | | TOR3 | |
| +------+ +------+ +------+ |
| / | \ / | \ / | \ |
| a1 b1 c1 a2 b2 c2 a3 b3 c3 |
| +---------+ +----------+ +----------+ |
| | A1 B1 C1| | A2 B2 C2 | | A3 B3 C3 | |
| +---------+ +----------+ +----------+ |
| |
+------------------------------------------------------------+
Figure 2: Virtualized Service Functions
Let us assume certain traffic that originates at A1 and destined to Z
(destination attached to remote WAN device not shown in the diagram),
needs to visit service functions deployed at A2 and A3. Traffic that
originates at B1 and destined to Z needs to visit service functions
B2 and B3. The stepwise procedures described below provide the basic
constructs involved in creating a stitched tunnel solution for
steering traffic through the service functions.
Building Tunnels: The traffic that originates at A1 and destined to Z
needs to visit A2 and A3. To achieve this, two transport tunnels are
built. The first tunnel Tunnel1 from TOR1 to TOR2 exiting on a2
VLAN. As the tunnels ends at the TOR2, the transport encapsulation
is removed and the original packet is passed to A2. Another tunnel
Tunnel2 is built from TOR2 to TOR3 exiting on a3 VLAN.
Similarly for the traffic originating at B1 and destined to Z, two
more tunnels are built. Tunnel3 from TOR1 to TOR2 exiting on b2 VLAN
and Tunnel4 TOR2 to TOR3 exiting from b3 interface
These separate tunnels will be stitched together using traffic
classification rules as described below
Hegde & Barth Expires July 11, 2021 [Page 4]
Internet-Draft Service Chaining with Stitched Tunnels January 2021
Traffic classification and steering: The traffic is classified at the
TOR1 based on either 5-tuple or based on other fields in in the
packet such as DSCP bits. In the above example, the traffic steering
may be based on source and destination address. Traffic from source
A1 and destination Z will be steered into Tunnel1. On TOR2, traffic
steering policies for source A1 and destination Z will steer the
traffic into Tunnel2.
Service Function Orchestrator (SFO): SFO is responsible for deploying
the service function instances. SFO builds tunnels from TOR1 to TOR2
and TOR2 to TOR3 etc as required by the service function chain. SFO
is also responsible for defining the traffic steering policies and
configuring them on appropriate traffic entry points. For
simplicity, the example in this section shows all virtualized service
functions, but the concepts equally apply to service functions
deployed on physical devices or a mix of physical and virtualized
service functions.
Bidirectionality: Certain service functions require the order of
service chaining to be preserved for the return traffic. In the
stitched tunnel based solution, the transport encodings are
completely independant and are not aware of the service functions.
The SFO should ensure the traffic steering policies on traffic entry
points to ensure correct order of service functions for the reverse
traffic. For example, the traffic with source Z and destination A1,
should be steered to TOR3 , exiting on a3 VLAN and on TOR3, same
policy should steer the traffic into a tunnel from TOR3 to TOR2
exiting from VLAN a2.
Looping service Functions: [RFC7665] describes possibility of looping
service functions that require to be applied repeatedly. In the
solution based on stitched tunnels, this needs to be orchestrated by
the SFO and traffic should be steered into the right tunnel to
redirect to the service function that needs to be applied. For
example, if the service function at A2 need to be re-applied after
servicing A3, the traffic steering policy at TOR3 should steer the
traffic through a tunnel from TOR3 to TOR2 existing out of VLAN a2.
Meta data handling: The trasnport encodings in stitched tunnel
solution is completely independent of meta data handling. There may
be SFC encapsulations as described in [RFC8300] or other kinds of
packet encapsulations. Transport encodings will see these
encapsulations as if it was original packet and hand it over to the
service functions.
Hegde & Barth Expires July 11, 2021 [Page 5]
Internet-Draft Service Chaining with Stitched Tunnels January 2021
4. SR-MPLS based Tunnels
Segment Routing (SR) [RFC8402] is an architecture based on the source
routing paradigm. SR can be used with an MPLS or an IPv6 data plane
to steer packets through an ordered list of instructions, called
segments. [I-D.ietf-spring-segment-routing-policy] describes a
mechanism to use a stack of segments to steer the traffic along the
explicit path. The Tunnel1 and Tunnel2 described in Section 3 can be
built using the segments. For example, the Tunnel1 may be built from
TOR1->SP1->TOR2->a2. The path may be represented using Node-SID or
Adj-SID as specified in [RFC8402]. At every segment end-point, the
segment will be removed and traffic will be forwarded as per the next
segment. on TOR2, the segment for a2 should be an Adj-SID. In Data
center networks that deploy IGPs, this could be an Adj-SID for the
the passive IGP interface. When the traffic hits TOR2, the passive
Adj-SID for a2 will be removed and traffic will be sent on a2 V-LAN.
As the transport encodings are completely removed from the packet
before sending to the Service Function, there is no special handling
required for SR-aware and SR-unaware service functions.
5. IP Tunnels
[I-D.saad-teas-rsvpte-ip-tunnels] is a solution that describes the
use of RSVP (Resource Reservation Protocol) to establish Point-to-
Point (P2P) Traffic Engineered IP (IP-TE) Label Switched Path (LSP)
tunnel(s) for use in native IP forwarding networks. The solution
introduces one or more reserved local IP prefixes, referred to as
Egress Address Blocks (EABs) per egress router that are dedicated for
RSVP to establish IP-TE LSP(s) tunnels. In
[I-D.saad-teas-rsvpte-ip-tunnels], EABs are managed by the egress
router. To facilitate service chaining, EAB management would be the
responsibility of the SFO along with the aforementioned flow steering
mentioned above. Further, in draft-saad-teas-rsvpte-ip-tunnels RSVP
is responsible for path establishment from ingress router to egress
router for a given IP-TE tunnel. In this solution, the SFO would not
only serve to calculate the explicit path of the IP-TE tunnel but
also to program the per node forwarding state for each IP-TE tunnel.
Extensions to the Path Computation Element Protocol (PCEP) as defined
in [I-D.ietf-teas-pce-native-ip] and
[I-D.ietf-pce-pcep-extension-native-ip]could be leveraged. The
Tunnel1 and Tunnel2 described in Section 3 can be built using per ToR
per VLAN EAB IP-TE tunnels. For example, the Tunnel1 may be built
from TOR1->SP1->TOR2->a2. The path may be represented using the EAB
associated with A2 vlan a2. At every IP-TE tunnel end-point, the IP
tunnel Encapsulation header will be removed and traffic will be
forwarded accordingly.
Hegde & Barth Expires July 11, 2021 [Page 6]
Internet-Draft Service Chaining with Stitched Tunnels January 2021
6. Backward Compatibility
TBD
7. Security Considerations
TBD
8. IANA Considerations
NA
9. Acknowledgements
TBD
10. Contributors
11. References
11.1. Normative References
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
11.2. Informative References
[I-D.ietf-pce-pcep-extension-native-ip]
Wang, A., Khasanov, B., Fang, S., Tan, R., and C. Zhu,
"PCEP Extension for Native IP Network", draft-ietf-pce-
pcep-extension-native-ip-09 (work in progress), October
2020.
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-09 (work in progress),
November 2020.
Hegde & Barth Expires July 11, 2021 [Page 7]
Internet-Draft Service Chaining with Stitched Tunnels January 2021
[I-D.ietf-teas-pce-native-ip]
Wang, A., Khasanov, B., Zhao, Q., and H. Chen, "Path
Computation Element (PCE) based Traffic Engineering (TE)
in Native IP Networks", draft-ietf-teas-pce-native-ip-15
(work in progress), December 2020.
[I-D.saad-teas-rsvpte-ip-tunnels]
Saad, T. and V. Beeram, "IP RSVP-TE: Extensions to RSVP
for P2P IP-TE LSP Tunnels", draft-saad-teas-rsvpte-ip-
tunnels-01 (work in progress), November 2019.
[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>.
[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
Shraddha Hegde
Juniper Networks Inc.
Exora Business Park
Bangalore, KA 560103
India
Email: shraddha@juniper.net
Colby Barth
Juniper Networks Inc.
Email: cbarth@juniper.net
Hegde & Barth Expires July 11, 2021 [Page 8]
