Interworking SFC network and Overlay network
draft-ao-sfc-overlay-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Ting Ao , Greg Mirsky | ||
| Last updated | 2017-03-12 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ao-sfc-overlay-01
SFC WG T. Ao
Internet-Draft ZTE Corporation
Intended status: Standards Track G. Mirsky
Expires: September 13, 2017 ZTE Corp.
March 12, 2017
Interworking SFC network and Overlay network
draft-ao-sfc-overlay-01
Abstract
For SFC, it's generally transmitted over an overlay network.A Service
Function Chain is an overlay carried over by an underlay network.This
document defines necessary interworking stand-alone Network Virtual
Edge and Service Forwarding Function entities to ensure proper
handling of SFC traffic by the underlay network.
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 http://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 13, 2017.
Copyright Notice
Copyright (c) 2017 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
(http://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
Ao & Mirsky Expires September 13, 2017 [Page 1]
Internet-Draft SFC overlay March 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
4. Interworking action . . . . . . . . . . . . . . . . . . . . . 3
4.1. Co-located NVE-SFF . . . . . . . . . . . . . . . . . . . 4
4.2. NVE-SFF split . . . . . . . . . . . . . . . . . . . . . . 4
4.2.1. Classifier action . . . . . . . . . . . . . . . . . . 4
4.2.2. SFF action . . . . . . . . . . . . . . . . . . . . . 5
4.2.3. NVE action . . . . . . . . . . . . . . . . . . . . . 5
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
Service Function Chaining (SFC) is a technique for prescribing
differentiated traffic forwarding policies within the SFC domain.
SFC is described in detail in the SFC architecture document.
[RFC7665] .
SFC traffic is transferred in overlay network, which is described in
SFC architecture document [RFC7665]. In an underlay network, Network
Virtualization Edge (NVE) maps the traffic to a tunnel according to
the inner destination address of the traffic, then encapsulates the
packet into outer. In this document, we assume that the NVEs in
overlay network have already obtained the mapping information between
NVE and Service Functions(SFs) which is described in NVO3 network
framework [RFC7365].
But the destination address of SFC traffic is the final destination
of the traffic, not the next hop of the SFC, so that NVE will not
tunnel the traffic to the next SF, but encapsulate the SFC traffic
with the NVE address connected to the destination station. So it's
important to coordinate SFC domain and corresponding underlay
network. Underlay network edge device NVE needs to know how to
forward SFC traffic, that is NVE should only encapsulate the SFC
traffic into the tunnel to the next hop of the SFC. This document
analyses how SFC domain can be coordinated with underlay network to
ensure that SFC traffic can be forwarded properly.
Ao & Mirsky Expires September 13, 2017 [Page 2]
Internet-Draft SFC overlay March 2017
2. Terminology
The terminology reuse the terminology in SFC architecture document
[RFC7665] and NVO3 network framework. [RFC7365]
NVE : Network Virtualization Edge
SFC : Service Function Chain
SFF : Service Function Forwarder
SF : Service Function
3. 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].
4. Interworking action
+--------------------------------------------------------------------+
| |
| Overlay Network |
| |
| +---------+ +---------+ +---------+ +---------+ |
+---| NVE4 |-----| NVE1 +-------+ NVE2 +-------+ NVE3 +--+
+---+-----+ +----+----+ +----+----+ +----+----+
| |/ \ | |/ \ | |/ \ | |
\ /| | \ /| | \ /| | \ /|
+-----+----+ ===> +----+----+ ====> +----+----+ ===> +----+---+
|Classifier+------+ SFF1 +-------+ SFF2 +-------+ D |
+----------+ +----+----+ +----+----+ +----+---+
| |
+----+----+ ====> +----+----+
+ SF1 +-------+ SF2 +
+----+----+ +----+----+
Figure 1 Interworking of SFC domain and Overlay Network
As depicted in the Figure 1, all the SFC traffic is transported
through an underlay network. The SFC path is Classifier->SF1-SF2->D.
NVE1 to NVE4 are to encapsulate the SFC traffic with underlay header,
such as VxLAN, GENEVE, etc. So according to the path of the SFC, SFC
traffic should be encapsulated at NVE4 and then be forwarded to NVE1
over the tunnel. NVE1 will decapsulate and forward the SFC payload
Ao & Mirsky Expires September 13, 2017 [Page 3]
Internet-Draft SFC overlay March 2017
to SF1. After being processed at the SF1, the SFC traffic should be
encapsulated by NVE1 and forwarded to the NVE2 over the tunnel. NVE2
will decapsulate and forward the SFC traffic to SF2, and so on. SFC
traffic from SFF1 to SFF2 should be tunneled between NVE1 and NVE2,
and traffic from SFF2 to node D should be tunneled between NVE2 and
NVE3. This is the behavior we expect. To differentiate these two
traffic, in Figure 1, data flow in the SFC overlay using "==>" arrows
and data flow between the overlay using "-->" arrows.
But before NVEs forward the traffic to underlay network, they have to
know how to encapsulate the traffic and which tunnel should be used,
that is the NVE need to know what's the next hop of the SFC traffic.
Still take the Figure 1 as an example, the NVE1 need to know that the
traffic should be forwarded to SF2 which is the next hop of the SFC
traffic in SFF1. As we know that the SFC traffic from Classifier has
the destination address of D. So here is a question, if the underlay
network and SFC domain are independent, NVE1 will tunnel the traffic
to NVE3 according to the destination of the SFC traffic , here is D,
and then NVE3 will forward the traffic to D, which is a wrong path
for the SFC, as it avoids the processing at the SF2. So there must
be a way to coordinate between overlay network and SFC domain, to
make sure the transport path along the SFC is correct.
4.1. Co-located NVE-SFF
In this scenario NVE and SFF are co-located. NVE and SFF can
coordinate between each other through API. Control Plane needs to
signal to NVE and SFF: SFF should notify the NVE what the next hop,
and NVE should encapsulate the traffic to the next hop NVE according
to the address of the next hop once it finds that the next protocol
is Network Service Header (NSH).
4.2. NVE-SFF split
In this scenario, NVE and SFF are physically separate. Hence the
coordination between NVE and SFF should be considered. Two possible
solutions are presented, one is from data plane aspect, and another
is from control plane aspect.
4.2.1. Classifier action
Classifier receives traffic from a Source device and classifies the
traffic, then encapsulates into NSH. When the Classifier forwards
the packet to SFF1 according to SFPID in the SFC header, it should
identify the next hop of the SFC (SF1 for example), and before it
forwards the traffic to NVE4, the Classifier should change the
destination of the packet to be the next hop (SF1) and store the
actual destination address in the SFC header as a metadata.
Ao & Mirsky Expires September 13, 2017 [Page 4]
Internet-Draft SFC overlay March 2017
4.2.2. SFF action
Once SFF gets SFC packet from SF, before it forwards the SFC traffic
to NVE that the SFF is connected to, the SFF should find the next hop
with the SFPID in the SFC header of the packet, then replace the
destination address to next hop, and store the actual destination
address in the metadata of the SFC header.
Once SFF receives SFC traffic from NVE, before it forwards the SFC
packet to SF according to SFPID, the SFF should restore the
destination address back to the actual address that is stored in the
metadata of the SFC header.
The last SFF receives the SFC packet from SF, and finds that it is
the last hop of the SFC, and the next hop is the actual destination
address in the metadata, so it just restores the destination address
to the actual destination address.
4.2.3. NVE action
NVE receives SFC packet from the Classifier and encapsulates it with
appropriate underlay network encapsulation, e.g.,VxLAN Header,
according to the destination address of the next hop. According to
the outer address header, the traffic is transmitted to the next NVE
where it is decapsulated so that it can be forwarded to the
corresponding SF. The NVE's action is the same as described inNVO3
network framework. [RFC7365].
5. Summary
As described above, we suggest before the forwarding of the SFC, the
forwarder of the SFC should get next hop of the SFC and replace the
destination address with the next hop. With this method, the SFC
packets can be transmitted correctly along the correspond SFC path in
the underlay network.
6. Security Considerations
To be added later
7. IANA Considerations
TBD
Ao & Mirsky Expires September 13, 2017 [Page 5]
Internet-Draft SFC overlay March 2017
8. References
8.1. Normative References
[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
Rekhter, "Framework for Data Center (DC) Network
Virtualization", RFC 7365, DOI 10.17487/RFC7365, October
2014, <http://www.rfc-editor.org/info/rfc7365>.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
Service Function Chaining", RFC 7498,
DOI 10.17487/RFC7498, April 2015,
<http://www.rfc-editor.org/info/rfc7498>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<http://www.rfc-editor.org/info/rfc7665>.
8.2. Informative References
[I-D.ietf-sfc-nsh]
Quinn, P. and U. Elzur, "Network Service Header", draft-
ietf-sfc-nsh-12 (work in progress), February 2017.
Authors' Addresses
Ting Ao
ZTE Corporation
No.889, BiBo Road
Shanghai 201203
China
Phone: +86 21 68897642
Email: ao.ting@zte.com.cn
Greg Mirsky
ZTE Corp.
1900 McCarthy Blvd. #205
Milpitas, CA 95035
USA
Email: gregimirsky@gmail.com
Ao & Mirsky Expires September 13, 2017 [Page 6]