SFC WG C. Wang Internet-Draft W. Meng Intended status: Standards Track ZTE Corporation Expires: April 27, 2017 October 24, 2016 Metadata Type Issues draft-wang-sfc-md-type-issues-02 Abstract Service function chain is the definition of an ordered set of service functions. After instantiated, the service function path is created and the classified traffic is steered through the corresponding service function path and then forwarded to the final destination. Metadata (MD) is conveyed in SFC data plane which provides the ability to exchange context information between classifiers and SFs, among SFs, and between external systems and SFs. This document is motivated to state an issue when MD Type = 0x1. 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 April 27, 2017. 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 Wang & Meng Expires April 27, 2017 [Page 1] Internet-Draft Metadata Type Issues October 2016 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Convention and Terminology . . . . . . . . . . . . . . . . . 3 3. An issue in MD-Type = 0x1 . . . . . . . . . . . . . . . . . . 4 4. An analysis on how to solve above issue . . . . . . . . . . . 6 4.1. Method 1 . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Method 2 . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Service function chain is the definition of an ordered set of service functions. After instantiated, the service function path is created and the classified traffic is steered through the corresponding service function path and then forwarded to the final destination. Metadata is conveyed in the Context Headers in SFC data plane which provides the ability to exchange context information between classifiers and SFs, among SFs, and between external systems and SFs. In [I-D.ietf-sfc-nsh], it defines two mandate parts including Base Header and Service Path Header in NSH header. Besides these two parts, there are Contexts Headers immediately following the Service Path Header as well. As for what kinds of Contexts Headers is according to the MD Type specified in the Base Header. In fact, it defines two MD types: When the Base Header specifies MD Type = 0x1, four Mandatory Context Headers must be added immediately following the Service Path Header, as per Figure 1. Wang & Meng Expires April 27, 2017 [Page 2] Internet-Draft Metadata Type Issues October 2016 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=0x1 | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Path ID | Service Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: NSH Format when MD Type = 0x1 When the Base Header specifies MD Type = 0x2, zero or more Variable Length Context Headers MAY be added immediately following the Service Path Header, as per Figure 2. 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 ID | Service Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Variable Length Context Headers (opt.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: NSH Format when MD Type = 0x2 From the perspective in [I-D.ietf-sfc-nsh] and its companion drafts, it seems to be apt to support MD Type = 0x1 to be mandate. This document is motivated to state an issue when MD Type = 0x1 is mandate and discuss which Metadata Type in more appropriate in what circumstances in SFC data plane. 2. Convention and Terminology 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 [RFC2119]. Wang & Meng Expires April 27, 2017 [Page 3] Internet-Draft Metadata Type Issues October 2016 The terms are all defined in [RFC7665] and [I-D.ietf-sfc-nsh]. 3. An issue in MD-Type = 0x1 In [I-D.guichard-sfc-nsh-dc-allocation], it provides the allocation scheme when Network Service Header (NSH) is used under data center scenario and defines a recommended default allocation for the Mandatory Context Headers while MD-Type = 0x1 (See Figure 3 below). 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=0x1 | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Path ID | Service Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D|F|Res| Source Node ID | Source Interface ID | Context Header 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Tenant ID | Context Header 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Class / Reserved | Source Class | Context Header 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ServiceTag / Opaque Service Class | Context Header 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: NSH DC Context Allocation What's more, in [I-D.napper-sfc-nsh-mobility-allocation] , it provides the allocation scheme when Network Service Header (NSH) is used under mobility scenario and defines a recommended default allocation for the Mandatory Context Headers while MD-Type = 0x1 (See Figure 4 below). Wang & Meng Expires April 27, 2017 [Page 4] Internet-Draft Metadata Type Issues October 2016 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=0x1 | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Path ID | Service Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow Cookie | Context Header 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserv |TenTy| Tenant ID | Context Header 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub/App ID ~ Context Header 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Sub/App ID (cont.) | Context Header 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: NSH Mobility Context Header There is no issue while the data center scenario and mobility scenario are deployed separately. For example, SFs in data centers can identify the exactly meaning in the Mandatory Context Headers according to the definition in [I-D.guichard-sfc-nsh-dc-allocation], while SFs in mobility service provider can understand the exactly meaning in the Mandatory Context Headers according to the definition in [I-D.napper-sfc-nsh-mobility-allocation]. But it is possible that there is a mixed need, such as Data Centers providing both wireless and classic DC services. Under this mixed scenario, there seems to be some difficulty when SFs tries to analyze the Mandatory Context Headers while MD Type = 0x1. For example, in Figure 5, it illustrates the mixed scenario where a data center provides both wireless and classic DC services. And in this data center, a service function (such as SF3) serves both wireless and classic DC services. Wang & Meng Expires April 27, 2017 [Page 5] Internet-Draft Metadata Type Issues October 2016 .--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--. ( DC serving both wireless and classic DC services ) ( ) Claasic DC incoming traffic( +-----+ +-----+ +-----+ ) ------->-------------> ---(---> | SF1 |----->| SF2 |------>\ /--->-- | SF4 |----->----)-----> ( +-----+ +-----+ \ / +-----+ ) ( +--|--+ ) ( | SF3 | ) ( +--|--+ ) Wireless incoming traffic( +-----+ +-----+ / \ +-----+ ) -------> ------------> ---(---->| SF5 |----->| SF6 |------>/ \--->-- | SF7 |----->----)-----> ( +-----+ +-----+ +-----+ ) ( ) .--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--.--. Figure 5: DC serving both wireless and classic DC services When traffic is steered to SF3, how SF3 to correctly analyze the Mandatory Context Headers in NSH within the arriving traffic? In other words, how SF3 in this mixed environments to know the receiving Mandatory Context Headers in the NSH are used for wireless service or classic DC services? 4. An analysis on how to solve above issue There may be several methods to address the above issue. Here just tries to list two feasible methods. 4.1. Method 1 Still using the recommended definition in draft-dc and draft-mobility while MD Type = 0x1, but tries to add some bits in NSH to identify what type of Mandatory Context Headers is conveyed within NSH. For example, as per Figure 6, here occupies the lowest two bits in MD Type field to identify the exact type of Mandatory Context Headers. Wang & Meng Expires April 27, 2017 [Page 6] Internet-Draft Metadata Type Issues October 2016 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=0x1| T | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Path ID | Service Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Two bits in MD Type field In fact, this issue only exists while MD Type = 0x1. While MD Type = 0x2, there is no such issue. So these added two bits have no meaning while MD Type = 0x2. When traffic is steered to SF3, SF3 finds the MD Type = 0x1 and then analyze these added two bits to know what kind of Mandatory Context Headers is contained. After that, correctly analyze the following Mandatory Context Headers according to the type. 4.2. Method 2 It also may be a feasible method to use MD Type = 0x2 to identify the Context Headers. According to MD Type = 0x2, the exact format for Variable Length Context Headers is illustrated in Figure 7, which states the TLV Class field or Type field already. Then, no matter in separated scenarios or mixed scenarios, there is no confusion when traffic arrives at SFs. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Variable Length Context Headers when MD Type = 0x2 Wang & Meng Expires April 27, 2017 [Page 7] Internet-Draft Metadata Type Issues October 2016 5. Gap analysis This document tries to raise one issue when using MD Type = 0x1 as mandatory type. As for which MD Type need to be mandatory there still need much more attentions and discussions. 6. Security Considerations TBD 7. IANA Considerations TBD 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . 8.2. Informative References [I-D.guichard-sfc-nsh-dc-allocation] Guichard, J., Smith, M., Surendra, S., Majee, S., Agarwal, P., Glavin, K., and Y. Laribi, "Network Service Header (NSH) Context Header Allocation (Data Center)", draft- guichard-sfc-nsh-dc-allocation-05 (work in progress), August 2016. [I-D.ietf-sfc-nsh] Quinn, P. and U. Elzur, "Network Service Header", draft- ietf-sfc-nsh-10 (work in progress), September 2016. [I-D.napper-sfc-nsh-mobility-allocation] Napper, J., Surendra, S., Muley, P., and W. Henderickx, "NSH Context Header Allocation -- Mobility", draft-napper- sfc-nsh-mobility-allocation-02 (work in progress), November 2015. Wang & Meng Expires April 27, 2017 [Page 8] Internet-Draft Metadata Type Issues October 2016 Authors' Addresses Cui Wang ZTE Corporation No.50 Software Avenue, Yuhuatai District Nanjing China Email: wang.cui1@zte.com.cn Wei Meng ZTE Corporation No.50 Software Avenue, Yuhuatai District Nanjing China Email: meng.wei2@zte.com.cn,vally.meng@gmail.com Wang & Meng Expires April 27, 2017 [Page 9]