SFC WG T. Ao Internet-Draft ZTE Corporation Intended status: Standards Track March 20, 2016 Expires: September 21, 2016 Interworking SFC network and Overlay network draft-ao-sfc-overlay-00.txt Abstract For SFC, it's generally transmitted over an overlay network, such as Vxlan network. This document describes how to interwork SFC network with an overlay network. Especially, when overlay network edge devide NVE is seperate with SFF, this document provide a suggestion to make sure SFC traffic can forwarded properly in the overlay 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 21, 2016. Copyright Notice Copyright (c) 2016 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 Expires September 21, 2016 [Page 1] Internet-Draft SFC overlay March 2016 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. Interworking action . . . . . . . . . . . . . . . . . . . . . 3 3.1. Classifier action . . . . . . . . . . . . . . . . . . . . 4 3.2. SFF action . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. NVE action . . . . . . . . . . . . . . . . . . . . . . . 4 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 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] . For SFC traffic, it is in overlay network to transport, which is described in SFC architecture document. [RFC7665] In an overlay network, NVE map the traffic to a tunnel according to the destination of the traffic. And we assume that the NVEs in VxLAN network already have obtained reachability information of SFs that NVEs connect, which is described in NVO3 network framework. [RFC7365] So how to coordinate SFC domain and overlay network is very important, for overlay network edge device NVE needs to know how to forward SFC traffic, especially when SFF and NVE are seperated, and NVE doesn't know which tunnel should choose for the SFC traffic. This document is going to describe a scenario that when NVE is seperate with SFF and have no idea how to transport along the path of the SFC according to SFPID. And this document is going to propose a method to solve such problem. Furthermore, we propose such actions on SFF can apply to all SFF on SFC. Ao Expires September 21, 2016 [Page 2] Internet-Draft SFC overlay March 2016 2. Terminology The terminology reuse the terminology in SFC architecture document [RFC7665] and NVO3 network framework. [RFC7365] 3. Interworking action +--------------------------------------------------------------------+ | | | VxLAN Network | | | | +---------+ +---------+ +---------+ +---------+ | +---| NVE4 |-----| NVE1 +-------+ NVE2 +-------+ NVE3 +--+ +---+-----+ +----+----+ +----+----+ +----+----+ | | | | +-----+----+ ---> +----+----+ ----> +----+----+ ---> +----+---+ |Classifier+------+ SFF1 +-------+ SFF2 +-------+ D | +----------+ +----+----+ +----+----+ +----+---+ | | +----+----+ ----> +----+----+ + SF1 +-------+ SF2 + +----+----+ +----+----+ Figure 1 Interworking of SFC domain and VxLAN As depicted in the Figure 1, all the SFC traffic is transport through a VxLAN network. The SFC path is Classifer->SF1-SF2->D. NVE1 to NVE4 are to encapsulate the SFC traffic with VxLAN header. For example, traffic from SFF1 to SFF2 should be tunnelled between NVE1 and NVE2, and traffic from SFF2 to Destination D should be tunnelled between NVE2 and NVE3. But before NVEs forward the traffic to overlay network, they have to know how to encapsulate these traffic and which tunnel should be chosen. Still take the Figure 1 as an exmaple, the NVE1 need to know 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 control plane of the VxLAN and SFC domain are irrelevant, NVE1 will tunnel the traffic to NVE3 and then NVE3 will forward the traffic to D, which is a wrong path for such SFC, ignores the process of the SF2. So there must be a way to make sure the transport path along the SFC is correct. To make sure the correctly forwarding, no matter Classifier or SFF should take action. Ao Expires September 21, 2016 [Page 3] Internet-Draft SFC overlay March 2016 3.1. Classifier action Classifier gets traffic from Source device and classifies the traffic with attaching a SFC header. When the Classifier forward the traffic to SFF1 according to SFPID in SFC header, it should get the next hop of the SFC (SF1 for example), and before it forward the traffic to NVE4, the Classifier should change the destination of the traffic to be the next hop (SF1) and store the actual destination address to SFC header as a metadata. 3.2. SFF action Once SFF gets SFC traffic from SF, before it forward the SFC traffic to NVE that the SFF connected, the SFF should find next hop with the SFPID in the SFC header of the traffic, then replace the destination address to next hop, and store the actual destination address to the metadata in SFC header. Once SFF get SFC traffic from NVE, before it forward the SFC traffic to SF according to SFPID, the SFF should restore the destination address back to the actual address which is stored in metadata of the SFC header. On the last SFF, it gets SFC traffic from SF, and find that itself is the last hop of the SFC, and next hop is the actual destination address in the metadata, so it just restore the destination address to actual destination address. 3.3. NVE action NVE gets SFC traffic from Classifier and encapsulate it with VxLAN header according to the destination address of the next hop. According to the outer address header, the traffic is transmitted to next NVE and get decapsulated so that it can be forwarded to the corresponding SF. The NVE's action is same with the description in NVO3 network framework. [RFC7365] 4. Summary As description 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 traffic can be transmitted correctly along the correspond SFC path in the overlay network. Ao Expires September 21, 2016 [Page 4] Internet-Draft SFC overlay March 2016 5. Security Considerations To be added later 6. IANA Considerations N/A 7. References 7.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, . [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015, . [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . 7.2. Informative References [I-D.ietf-sfc-nsh] Quinn, P. and U. Elzur, "Network Service Header", draft- ietf-sfc-nsh-02 (work in progress), January 2016. Author's Address Ting Ao ZTE Corporation No.889, BiBo Road Shanghai 201203 China Phone: +86 21 68897642 Email: ao.ting@zte.com.cn Ao Expires September 21, 2016 [Page 5]