Service Function Chaining J. Napper Internet-Draft S. Kumar Intended status: Informational Cisco Systems, Inc. Expires: May 17, 2015 November 13, 2014 NSH Context Header Allocation -- Mobility draft-napper-sfc-nsh-mobility-allocation-00 Abstract This document provides a recommended allocation of the mandatory fixed context headers for a Network Service Header (NSH) within the mobility service provider network context. NSH is described in detail in [quinn-sfc-nsh]. This allocation is intended to support uses cases as defined in [ietf-sfc-use-case-mobility]. Requirements 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 [RFC2119]. 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 May 17, 2015. Copyright Notice Copyright (c) 2014 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction 2. Definition Of Terms 3. Network Service Header (NSH) Context Headers 4. Recommended Mobility Context Allocation 5. Mobility Allocation Specifics 6. Context Allocation and Control Plane Considerations 7. Security Considerations 8. IANA Considerations 9. Acknowledgments 10. References 10.1. Normative References 10.2. Informative References Authors' Addresses 1. Introduction Service function chaining provides a mechanism for network traffic to be forced through multiple service functions in a sequence. Metadata can be useful to service functions. Network Service Headers (NSH) provides support for carrying shared metadata between service functions (and devices) using 4 fixed-length 32-bit context headers and optional TLV headers as defined in [quinn-sfc-nsh]. NSH is then encapsulated within an outer header for transport. This document provides a recommended default allocation scheme for the fixed-length context headers in the context of service chaining within mobile service provider networks. Supporting use cases describing the need for a metadata header in this context are described in [ietf-sfc-use-case-mobility]. This draft does not define any TLV headers within this context and does not address control plane mechanisms. 2. Definition Of Terms This document uses the terms as defined in [ietf-sfc-problem-statement], and [ietf-sfc-arch]. 3. Network Service Header (NSH) Context Headers In Service Function Chaining, the Network Service Header is composed of a 4-byte base header (BH1), a 4-byte service path header (SH1) and four mandatory 4-byte context headers (CH1-CH4) as described in [quinn-sfc-nsh]. An optional TLV can be signalled using the Length field. 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 = 0x01| Next Protocol | BH1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Path ID | Service Index | SH1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header 1 | CH1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header 2 | CH2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header 3 | CH3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header 4 | CH4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | TLV ~ Optional Variable Length Context Headers ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Network Service Header - MD Type 0x01 4. Recommended Mobility Context Allocation The following context header allocation provides information to support service function chaining in a mobile service provider network as described in [ietf-sfc-use-case-mobility]. The set of context headers can be delivered to service functions that can use the metadata within to enforce policy, communicate between service functions, provide subscriber information and other functionality. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow Cookie | CH1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserv |TenTy| Tenant ID | CH2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub/App ID ~ CH3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Sub/App ID (cont.) | CH4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: NSH Mobility Context Allocation 5. Mobility Allocation Specifics The intended use for each of the context header allocations is as follows: Flow Cookie - unique value with respect to the Subscriber/ Application Identifier field that can be used to identify a packet or flow even if the encapsulated packet changes (e.g., when a flow is terminated at a proxy). Reserv Reserved TenTy Tenant Type - represents type of Tenant Identifier field (e.g., vlan, vxlan, vrf, mpls, etc.). Tenant ID - value encoded according to Tenant Type field corresponding to encapsulated packet (e.g., ingress VRF id). The Tenant ID field allows the Base Header (BH1) and Service Headers (SH) to be tenant independent. Sub/App ID - 64-bit length Subscriber/Application identifier (e.g., IMSI [itu-e-164], MSISDN (8-15 digit) [itu-e-164], or implementation-specific Application ID) of the corresponding subscriber/application for the flow. 6. Context Allocation and Control Plane Considerations This document describes an allocation scheme for the mandatory context headers in the context of mobile service providers. This suggested allocation of context headers should be considered as a guideline and may vary depending on the use case. The control plane aspects of specifying and distributing the allocation scheme among different service functions within the Service Function Chaining environment to guarantee consistent semantics for the metadata is beyond the scope of this document. 7. Security Considerations The context header allocation recommended by this document includes numbers that must be distributed consistently across a Service Function Chaining environment. Protocols for distributing these numbers securely are required in the control plane, but are out of scope of this document. Furthermore, some of the metadata carried in the context headers require secure methods to prevent spoofing or modification by service function elements that may themselves be exposed to subscriber traffic and thus might be compromised. This document does not address such security concerns. 8. IANA Considerations This document has no actions for IANA. 9. Acknowledgments The authors would like to thank Jim Guichard for his assistance structuring the document. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [guichard-sfc-nsh-dc-allocation] , , and , "Network Service Header (NSH) Context Header Allocation (Data Center)", I-D draft-guichard-sfc-nsh-dc- allocation-00 (work in progress), August 2014. [ietf-sfc-arch] and , "Service Function Chaining (SFC) Architecture", I-D draft-ietf-sfc-architecture-02 (work in progress), September 2014. [ietf-sfc-problem-statement] and , "Service Function Chaining Problem Statement", I-D draft-ietf-sfc-problem-statement-09 (work in progress), August 2014. [ietf-sfc-use-case-mobility] , , , , and , "Service Function Chaining Use Cases in Mobile Networks", I-D draft-ietf-sfc-use-case-mobility-02 (work in progress), July 2014. [itu-e-164] "The international public telecommunication numbering plan", ITU-T E.164, November 2010. [quinn-sfc-nsh] , , , , , , , , , , , , and , "Network Service Header", I-D draft-quinn-sfc-nsh-03 (work in progress), July 2014. Authors' Addresses Jeffrey Napper Cisco Systems, Inc. Email: jenapper@cisco.com Surendra Kumar Cisco Systems, Inc. Email: smkumar@cisco.com