Service Function Chaining Guanwen Li Internet Draft Guanglei Li Intended status: Standards Track Taixin Li Expires: December 12, 2016 Qi Xu Bohao Feng Huachun Zhou Beijing Jiaotong University June 11, 2016 Multi-domain Service Forwarding For NSH draft-li-sfc-nsh-multi-domain-00 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 12, 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 Li Expires December 12, 2016 [Page 1] Internet-Draft Multi-domain For NSH June 10, 2016 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. Abstract This document describes the mechanism to achieve multi-domain service forwarding for NSH. The purposed mechanism adopts a horizontal deployment structure, which divides a multi-domain SFC into several segmental SFCs in the control plane and each domain creates its own SFP independently in data plane. A label is purposed to identify different cross-domain flows at the classifier by extending the metadata of the NSH encapsulation. Table of Contents 1. Introduction ................................................ 2 1.1. Requirement Language.................................... 3 2. Definition Of Terms ......................................... 3 3. Multi-domain Service Forwarding Mechanism ................... 4 3.1. Service Function Chaining Segmentation ................. 4 3.2. Inter-domain Service Forwarding ........................ 5 3.3. Classification and Intra-domain Service Forwarding ..... 5 4. Multi-domain Service Forwarding Encapsulation ............... 5 5. Multi-domain Service Forwarding Example ..................... 6 6. Security Considerations...................................... 7 7. IANA Considerations ......................................... 8 8. Conclusions ................................................. 8 9. References .................................................. 8 9.1. Normative References.................................... 8 9.2. Informative References.................................. 9 10. Acknowledgments ............................................ 9 1. Introduction Service Function Chaining (SFC) [RFC7665] is an architecture purposed to decouple traditional network service functions with corresponding physical resources. It is flexible and convenience for a network operator to deploy on-demand service functions and steer the traffic through them in sequence. Network Service Header (NSH) [I-D.ietf-sfc-nsh] is defined as a data plane protocol to create a dynamic service function chaining. According to the NSH encapsulation, the flow can pass along its service function path and exchange metadata among the Service Li Expires December 12, 2016 [Page 2] Internet-Draft Multi-domain For NSH June 10, 2016 Classifier, the Service Function and the Service Function Forwarder for information sharing. Network service forwarding in SFC is based on the combination of Service Path Identifier (SPI) and Service index (SI), which is described in [I-D.ietf-sfc-nsh]. [I-D.kumar-sfc-nsh-forwarding] analyzes the NSH forwarding shortcomings and further discusses the separation of the service forwarding and the service delivery. However, it focuses on infrastructure service forwarding for NSH in single domain. [I-D.dolson-sfc-hierarchical] purpose a hierarchical way to achieves multi-domain SFC, which can be regarded as a vertical approach. Contrast to the vertical approach, a horizontal one is easy to scale in and out. Besides, the horizontal approach can decrease the overhead of the control plane, because it maintains more service traffic in the data plane. Therefore, this document purposes a horizontal approach to achieve multi-domain service forwarding for NSH. The main idea is to divide a multi-domain SFC into several segmental SFCs according to domain partitions in the control plane and create corresponding SFP in each domain by its classifier independently. A label is purposed to identify different cross-domain flows, which is encapsulated in the metadata. 1.1. Requirement Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Definition Of Terms This document uses some terms defined in SFC architecture [RFC7665] and NSH [I-D.ietf-sfc-nsh] drafts for ease of understanding and the reader is advised to refer to those documents for up to date and additional information. Segmental SFC: The cross-domain SFC is divided into several segmental SFCs according to the domain partitions. Each segmental SFC is assigned to its corresponding domain. Service Label: A label used to identify different flows can help the classifier create the SFP by its corresponding segmental SFC, which is issued from SFC control plane. Cross-domain Forwarding Table: There are three columns in the table: Service Label, Next Classifier and Segmental SFC. The table matches a Li Expires December 12, 2016 [Page 3] Internet-Draft Multi-domain For NSH June 10, 2016 specific flow with its Service Label. The cross-domain forwarding of a flow is depended on the address of Next Classifier. The Cross- domain Forwarding Table is maintained by SFC control plane and issued to corresponding classifier according to the Segmental SFC. 3. Multi-domain Service Forwarding Mechanism +---------------------------------------------------+ | | | Control Plane | | | +-----+----------------+----------------------+-----+ | | | |Segmental |Segmental |Segmental |SFC-1 |SFC-2 |SFC-N | | | +-----v-----+ +-----v-----+ +-----v-----+ | | | | | | ----> Domain1 +----> Domain2 +->......--> DomainN +---> | | | | | | +-----------+ +-----------+ +-----------+ Figure 1 Multi-domain SFC Divide As shown in Figure 1, SFC control plane divides the whole SFC and issues cross-domain forwarding tables to corresponding classifiers initially. Multi-domain service forwarding includes two aspects: the inter-domain service forwarding and the intra-domain forwarding. The former is based on a unique label for each flow, and the latter is performed by the classifier. To achieve a unify service forwarding mechanism in multi-domain, this mechanism uses metadata in NSH encapsulation to carry the necessary forwarding information among different forwarding elements, such as the Service Classifier and the Service Function Forwarder. 3.1. Service Function Chaining Segmentation At first, the orchestrator in SFC control plane creates a SFC with a unique Service Label for the flow. Then, the SFC is divided into several segmental SFCs according to physical resource constraints. It is important to note that the control plane MUST NOT specific the SFP directly. The control plane is only responsible to indicate what service functions are required in each domain, and the corresponding SFP MUST be specified by the service classifier. Li Expires December 12, 2016 [Page 4] Internet-Draft Multi-domain For NSH June 10, 2016 3.2. Inter-domain Service Forwarding The Service Label is purposed to identify different flows when packets need to be cross-domain forwarded. When the service classifier receives a packet with the NSH encapsulation, it firstly checks the Service Label of the packet to look up the address of the next classifier in its cross-domain forwarding table. The table is issued by SFC control plane. Then the information of next classifier is written into the metadata and will be used by the last SFF in the domain. Once the last SFF receives the packet from last SF in the domain, which changes the SI to zero, it forwards the packet to next classifier directly without any modification of the NSH encapsulation. 3.3. Classification and Intra-domain Service Forwarding The service classifier creates SFP for each flow according to the segmental SFC in its cross-domain forwarding table. After the control plane assigns segmental SFCs for different domains, the corresponding table is issued to the classifier in each domain. When the packet with an NSH encapsulation arrives at the classifier, its Service Label is used to find out the corresponding segmental SFC. Then, the classifier creates a SFP for the flow according to its segmental SFC. 4. Multi-domain Service Forwarding Encapsulation In order to reduce overhead of metadata, the context header with MD Type = 0x2 is chosen to support multi-domain service forwarding, Figure 2 shows the allocation of the metadata. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x2 | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Path Identifier (SPI) | Service Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class=0x20 |C| Type=0x1 |R|R|R| Len=0x4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D|R|R|R| Service Label | Next Classifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Multi-domain Service Forwarding Encapsulation Context Header Allocation Descriptions: Metadata Class: It MUST be set to 0x20 as requested in Section 7. C bit: It SHOULD be set indicating critical metadata exists. Li Expires December 12, 2016 [Page 5] Internet-Draft Multi-domain For NSH June 10, 2016 Type: It MUST be set to 0x1 for multi-domain service forwarding. Len: Because the length of the context header is constant, it MUST be set to 0x4. D bit: The default value is zero, which means the metadata SHOULD be ignored. When set to 0x1 indicates that this packet need to be forwarded in multiple domains. Service Label: Identifies different flows with different labels. The service classifier decides the service forwarding path of the packet according to its domain label with a forwarding table issued by control plane. Next Classifier: Indicates the address of the classifier in next domain. Because of the SFC segmentation, each classifier only works in the SFC domain it belongs to. When a packet leaves current domain, it will notice the last SFF where is the next classifier. All other flag fields are reserved for future use. Reserved bits MUST be set to zero and MUST be ignored upon receipt. 5. Multi-domain Service Forwarding Example +----------+ +----------+ +----------+ | | | | | | Domain1 | SF-a | | SF-b | Domain2 | SF-c | | | | | | | +---^--+---+ +---^--+---+ +---^--+---+ | | | | | | +-------+ +---+--v---+ +---+--v---+ +-------+ +---+--v---+ | | | | | | | | | | ---> CF1 +-> SFF1-1 +-> SFF1-2 +----> CF2 +-> SFF2-1 +---> | | | | | | | | | | +-------+ +----------+ +----------+ +-------+ +----------+ Figure 3 Multi-domain Service Forwarding Example This section describes the scenario shown in Figure 3, a packet flow pass through tree service functions deployed in two domains. The domain1 is consist of CF1, SFF1-1, SFF1-2, SF-a and SF-b; the domain2 is consist of CF2, SFF2-1 and SF-c. The workflow is as follow: 1.SFC control plane creates the SFC with a Service Label for the specific flow and divides the whole SFC into several segmental SFCs 2.The cross-domain forwarding table is issued to its corresponding classifier with Service Label, Next Classifier and Segmental SFC Li Expires December 12, 2016 [Page 6] Internet-Draft Multi-domain For NSH June 10, 2016 3.CF1(the classifier in domain1) creates the SFP and the NSH encapsulation for the flow packet according to its segmental SFC in domain1. It sets 'D' flag to 1 and fills in the Service Label and Next Classifier. 4.CF1 forwards the packet to SFF1-1 5.SFF1-1 determines SF-a as the next hop and forwards the packet. 6.After SF-a processes the packet, the packet is forwarded back to SFF with decremented SI 7.SFF1-1 forwards the received packet to SFF1-2 8.SFF1-2 determines SF-a as the next hop and forwards the packet. 9.Similar to SF-a, SF-b forwards the packet to SFF1-2 and decrements SI to zero 10.When SFF1-2 receives the packet, it finds out that the SFP is terminate in this domain because of the SI, and then SFF1-2 forwards the packet to next classifier without modification of the NSH encapsulation 11.CF2(the classifier in domain2) receives the packet with an NSH encapsulation, checks its Service Label. 12.Accroding to the Service Label, CF2 looks up segmental SFC in the cross-domain forwarding table and creates the corresponding SFP and the NSH encapsulation 13.CF2 sets the 'D' flag to zero and forwards the packet to SFF2-1 13.SFF2-1 determines SF-c as the next hop and forwards the packet 14.SFc processes the packet and forwards it back to SFF2-1 with decremented SI 15.SFF2-1 finds out that the SFP is terminate and forwards the packet to the final Receiver 6. Security Considerations As with many other protocols, metadata of the NSH encapsulation can be spoofed or otherwise modified. It is important to protect the cross-domain packet from malicious modification, because the metadata contains sensitive information about the user and environment. Li Expires December 12, 2016 [Page 7] Internet-Draft Multi-domain For NSH June 10, 2016 Therefore, it is significate to ensure the integrity of the metadata and provide the protection of the user privacy. 7. IANA Considerations IANA is requested to allocate a new class from the TLV Class defined in [I-D.ietf-sfc-nsh]. 0x20 Multi-domain Forwarding Type IANA is requested to set up a registry of "NSH Multi-domain Service Forwarding TLV Types". These are 7-bit values. Registry entries are assigned by using the "IETF Review" policy defined in [RFC5226]. IANA is requested to allocate two new types as follows: o Type = 0x00 Reserved o Type = 0x01 Multi-domain Service Forwarding 8. Conclusions This document purposes a mechanism for multi-domain service forwarding based on a unique label. In order to relieve the pressure of the control plane, the multi-domain SFC is divided into segmental SFC according to the domain partitions, and the SFP in each domain is created independently. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC7665] J. Halpern, Ed. and C. Pignataro, Ed. "Service Function Chaining (SFC) Architecture", October 2015. [I-D.ietf-sfc-nsh] Quinn, P. and U. Elzur, "Network Service Header", draft- ietf-sfc-nsh-05 (work in progress), May 2016. Li Expires December 12, 2016 [Page 8] Internet-Draft Multi-domain For NSH June 10, 2016 9.2. Informative References [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [I-D.kumar-sfc-nsh-forwarding] S. Kumar, K. Leung, P. Bosch, et al. "Infrastructure Service Forwarding For NSH", draft-kumar-sfc-nsh- forwarding-00 (work in progress), February 2016. [I-D.dolson-sfc-hierarchical] D. Dolson, S. Homma, D. Lopez, et al. "Hierarchical Service Function Chaining", draft-dolson-sfc-hierarchical-05 (work in progress), March 2016. 10. Acknowledgments This work in this document was supported by National High Technology of China ("863 program") under Grant No.2015AA015702. Li Expires December 12, 2016 [Page 9] Internet-Draft Multi-domain For NSH June 10, 2016 Authors' Addresses Guanwen Li Beijing Jiaotong University Beijing 100044, P.R. China Email: 14120079@bjtu.edu.cn Guanglei Li Beijing Jiaotong University Beijing 100044, P.R. China Email: 15111035@bjtu.edu.cn Taixin Li Beijing Jiaotong University Beijing 100044, P.R. China Email: 14111040@bjtu.edu.cn Qi Xu Beijing Jiaotong University Beijing 100044, P.R. China Email: 15111046@bjtu.edu.cn Bohao Feng Beijing Jiaotong University Beijing 100044, P.R. China Email: 11111021@bjtu.edu.cn Huachun Zhou Beijing Jiaotong University Beijing 100044, P.R. China Email: hchzhou@bjtu.edu.cn Li Expires December 12, 2016 [Page 10]