SFC working group S. Vallamkonda Internet Draft F5 Neworks Intended status: Standard Track L. Dunbar Expires: November 8, 2017 Huawei D. Dolson Sandvine July 5, 2016 A Framework for SFC Metadata draft-vallamkonda-sfc-metadata-model-01 Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. 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 November 8, 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 Ghanwani et al. Expires November 2017 [Page 1] Internet-Draft A framework for Metadata on SFC February 2016 (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. Abstract Various types of metadata are applicable to Service Function Chaining (SFC). Metadata can be used for many purposes, such as conveying processing information, resource usage, and flow specific information, from prior nodes along the Service Function Path. It can also be vendor specific to leverage vendor capabilities and hint to downstream Service functions dynamically for improved performance. In contrast, metadata carried out of band introduces latency and overhead with inefficiency and non-synchronous to real- time traffic. A Service Function (SF) that needs to process the information carried by the metadata may need detailed information of the metadata structure carried by the packets and can have local policies based on metadata. The purpose of this document is to specify a framework and information model on how to provision information about metadata among classifiers and service functions on a service function chain. Table of Contents 1. Introduction...................................................3 2. Terminology....................................................3 3. Use Cases of Metadata exchanged by SFs (by multiple vendors)...4 4. Standardized Encoding of Metadata attached to packets..........5 5. Framework of encoding metadata.................................5 6. Classes of Metadata............................................6 6.1. Metadata passed between controller and SFs................6 6.1.1. IP Endpoint Property.................................7 6.2. Metadata carried by payload packets.......................7 6.2.1. Routing Domain.......................................7 6.2.2. Traffic Policy Indication............................8 6.2.3. Flow Classification..................................8 7. Metadata Information and Data Model............................8 7.1. Objects over the Vendor registration interface............8 7.2. Objects over the Control Plane to SF interface............8 Vallamkonda et al. Expires November 2017 [Page 2] Internet-Draft A framework for Metadata on SFC February 2016 7.3. Objects encoded in the NSH carried by data packets over SF path...........................................................9 8. Dictionary for Metadata........................................9 8.1. Metadata wire format.....................................10 9. Security Considerations.......................................11 10. IANA Considerations..........................................11 11. References...................................................11 11.1. Normative References....................................11 11.2. Informative References..................................11 11.3. Acknowledgments.........................................11 1. Introduction Service Function Chaining (SFC) is a technology for directing network traffic via a set of functions in a specific order. The SFC architecture document [RFC7665] has in-depth description of SFC, which will not be repeated here. The metadata specified by [sfc-nsh] provides a mechanism for additional information exchanged between nodes along the service function path. Even though many metadata exchanged among the service functions on a path are proprietary, there are some metadata that are expected to convey information from upstream service functions to downstream service functions by different vendors, such as time stamp and others. It is important that this information is not hardcoded and static but provisioned to a Service Node. This document will first describe the use cases (or the examples) of such metadata that are expected to be passed among service functions. It will then describe a framework on how to identify metadata, and specifies the information model and corresponding data model for those metadata. 2. 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 RFC 2119 [RFC2119]. Metadata: Information about a packet that is attached to a packet, specifically within the NSH header. SF: Service Function Vallamkonda et al. Expires November 2017 [Page 3] Internet-Draft A framework for Metadata on SFC February 2016 3. Use Cases of Metadata exchanged by SFs (by multiple vendors) The SFC architecture calls for metadata to be included in packets sent between elements of a service chain. Several types of Service Functions inject packets into data streams. Examples include routers creating ICMP messages, or firewalls creating TCP reset packets. The question that naturally arises is what metadata should be attached to payload packets. This question cannot be answered without knowing what each type of metadata means. Further, without this there is ambiguity on limitations and restrictions for services offered by the service functions on the service function path. +----+ +----+ +----+ ---->|SFF1|----->|SFF2|------->|SFF | <----| |<-----| |<-------| | +----+ +----+ +----+ | | | | +-------+ | | | | +------+ +----+ +----+ +----+ | SF4 |-> |SF1 | | SF2| |SF3 | +------+ +----+ +----+ +----+ Figure 1: Metadata passed between SFs Figure 1 shows a SFC with two service functions: L3-L7 ACL with firewall (SF1) and second with DPI (SF2). The path can be symmetric or asymmetric on per pathID/flow basis. SF1 and SF2 are different NFVs providing different services to flow. Here are some examples that SF2 needs packets to carry the processing information done by SF1: SF1 may at real-time attach DoS information for the next SF in downstream. SF1 provides the hint and it is up to the downstream SFs to process it or ignore it. However if a downstream SF chooses to processes, it needs standardized metadata data model to understand the hint encoded by SF1 in packets. Vallamkonda et al. Expires November 2017 [Page 4] Internet-Draft A framework for Metadata on SFC February 2016 SF1 may send protocol flood (DNS/HTTP/SYN) indicators in metadata. This may be attached to packet based on local policy that can be time orevent based. The downstream SF2 would need to be aware of a standardized format (the proposal) to interpret the data. Then it may process the packet per local policy. Without standard method and framework, service functions can't pass meaningful metadata to other SFs on a service function chain to achieve sophisticated service functions. 4. Standardized Encoding of Metadata attached to packets Metadata could be self-describing or there could be control-plane descriptions of metadata encoding in the form of a metadata dictionary (or a combination thereof). In either case, there needs to be a language for describing the meaning of metadata context vocabulary. This document provides the analysis of various types metadata, the framework to carry metadata across SFs or SFF on a SFC path, and the corresponding information and data model for some well-known metadata that can be useful for services functions. Note: this document does not document all potential metadata used by SFs, because there are many types of proprietary metadata exchanged among SFs. 5. Framework of encoding metadata To minimize the extra bytes added to packets in NSH, it is necessary to have compact encoding of the metadata carried by data packets. Achieving this goal will need control plane to inform the encoding mechanisms to SFs via out of band control channels. In addition, it is necessary for vendors to register the metadata that their corresponding SFs can send and receive, as depicted in the following diagram: Vallamkonda et al. Expires November 2017 [Page 5] Internet-Draft A framework for Metadata on SFC February 2016 +----------------------------------------------+ | | | SFC Control Plane +-------+ +-------| | | | | | |C5 C1 +------^-----------^-------------^-------------+ | +---------------------|C3---------|-------------|-------------+ | | | +----+ | | | v | | | SF | |C2 |C2 | +------------+ | | +----+ | | | | SF metadata| | +----V--- --+ | | | | |registration| | | SFC | +----+ +-|--+ +----+ | +------------+ | |Classifier |---->|SFF |----->|SFF |------->|SFF | | | | Node |<----| |<-----| |<-------| | | | +-----------+ +----+ +----+ +----+ | | | | | | | |C2 ------- | | | | | | +-----------+ C4 | | V +----+ +----+ | SFC Proxy |--> | | | SF | |SF | +-----------+ | | +----+ +----+ | | |C3 |C3 | | SFC Data Plane Components V V | +-------------------------------------------------------------+ Figure 2: SFC Architecture Extension for Metadata SF Registration Interface (C5) is for vendors of the SFs to inform the controller on the metadata their SFs supported. The information over this interface should include: SF vendor name ABC metadata objects Objects passed over the Controller - SF interface (C3) Objects carried by data packets, i.e. encoded in the packets'NSH Actions that can be performed on the SFs 6. Classes of Metadata 6.1. Metadata passed between controller and SFs This section describes the metadata not carried by payload packets, but instead communicated between controller and SFs, i.e. over the C3 interface of the Figure 2 above. Vallamkonda et al. Expires November 2017 [Page 6] Internet-Draft A framework for Metadata on SFC February 2016 The metadata over the C3 interface should carry the policies associated with each metadata encoding carried by the packets through the SFs (in NSH header). 6.1.1. IP Endpoint Property A metadata type indicates a property of an IP endpoint of either the source or the destination IP address in the encapsulated conversation. As examples, the metadata could indicate a user's class of service, that the endpoint is flagged as the subject of an attack or may indicate the account number to charge the user's traffic. Injected packets may clone this type of metadata from other packets having the same IP endpoint, for packets in the same direction. 6.2. Metadata carried by payload packets The metadata carried by payload packets need to be encoded in the NSH header. However, the interpretation of the encoding has to be exchanged between controller and the SFs. 6.2.1. Routing Domain A Routing Domain metadata type indicates the specific private network for the packet. A policy could be "Neither traffic nor information may cross between domains". Service functions must use the domain to discriminate between overlapping private IPv4. When a packet exits SFC (has the NSH header removed), a Routing Domain metadata can indicate which routing table should be used to forward the packet. E.g., Routing Domain metadata allows support of multiple private networks within the same SFC cluster. Metadata of this type is generally attached by the classifier. In general, this type of metadata must not be removed or modified by SFs (except in the case when the intention is to route traffic between domains). Injected packets must include this type of metadata, to indicate the routing domain the packet is being injected into. Vallamkonda et al. Expires November 2017 [Page 7] Internet-Draft A framework for Metadata on SFC February 2016 6.2.2. Traffic Policy Indication This metadata type indicates a class of treatment for customer traffic, which may be attached by the classifier or another SF in the chain. Class values are assigned and administered by the operator. This type of metadata is not required on every packet. If missing, a default policy can be applied. The most recent value can be cached for the customer IP address; injected packets can use the cached value. 6.2.3. Flow Classification This metadata type indicates a flow classification. As examples, the metadata could indicate a DPI classification result or whether the flow has been selected for differentiated service. This type may be attached by the classifier or another SF in the chain. It may also be overwritten by SFs along the chain. This type of metadata is a property of the session 5-tuple. Injected packets may clone this property from other packets of the flow, for packets in the same direction. 7. Metadata Information and Data Model 7.1. Objects over the Vendor registration interface 7.2. Objects over the Control Plane to SF interface The purpose of the control plane interface to SF is to describe to the classifier and service functions both the encoding and semantics of each type of metadata. The model of each instance of metadata should include: - Keyword name Vallamkonda et al. Expires November 2017 [Page 8] Internet-Draft A framework for Metadata on SFC February 2016 - Long description - Data type (integer, string, enumeration of type X, timestamp, indirect handle to Y, etc.) - The class of metadata is it (see section 6)? - how is it transported? - in a MD-Type1 slot number 1, , 4 - in a MD-Type2 TLV, with code number N and vendor type V. "Indirect handle" indicates that the value is a key into a table transferred out of band. E.g., it could be a handle for a subscriber identity or it could be a handle for a mobile cell sector. TODO: model in YANG. 7.3. Objects encoded in the NSH carried by data packets over SF path In the data packets, metadata items are identified by either (a) Position within the fixed MD-Type 1 header (b) Vendor/Code within the variable-length MD-Type 2 header. The position or vendor/code is to be conveyed in the control plane ahead of arrival of the information in the data packets. 8. Dictionary for Metadata The metadata can be defined by vendor in common published format in ASCII file. This file could be used by other vendors of Service Nodes (SF/SFFs) to recognize the metadata and its content dynamically. The metadata can be used by local policies on Service Node if needed. This common format encourages rapid deployment and supports interoperability on real-time traffic without restrictions of hardcoding or worry about dynamically changing capabilities of Service nodes in SFC. VENDOR-DEF vendor_name vendor_id VENDOR-ATTRIBUTE attribute-name attribute_ID syntax_type (DEFAULT, LENGTH, etc) flags ATTRIBUTE-VALUE attribute-name value_name value_number_associated Vallamkonda et al. Expires November 2017 [Page 9] Internet-Draft A framework for Metadata on SFC February 2016 Example: VENDOR-DEF ABC 100 VENDOR-ATTRIBUTE dns-attack 10 DEFAULT ATTRIBUTE-VALUE dns-attack attack_state 1 (suspect), 2 (found). 8.1. Metadata wire format The above dictionary format of metadata specification could be translated in a common wire format for interoperability. Some data will be passed over the C5 (Registration) interface and others will be passed over the C3 interface in the Figure 2 above. Editor's note: details will be added after the framework is accepted. Thus the salient benefits of this metadata framework are: o It is independent of capabilities discovery of SF by Controller which is configuration and provision. It is different from Metadata which is real time on per flow and per packet. o The metadata dictionary can be uploaded to Controller which is the central entity which can download to SFs during provision of SFs as OOB initially and later as needed along with its local policy for flows and metadata. o Metadata flags can specify additional information to downstream Service Nodes in chain such as donot-delete, append-only, etc. o The proposal does not limit the semantics or content context of Metadata at any node. The content can be local resource such as CPU, Storage indicators affected by the flow and/or flow specific service information. o It eliminates hardcoding, static prototyping and type guessing by products and versions. o It is independent of any specific hardware. o The framework is portable across SFC technologies and SFC protocols. o The framework can be used to enhance definitions by extending to subtypes within both generic and vendor global categories. Vallamkonda et al. Expires November 2017 [Page 10] Internet-Draft A framework for Metadata on SFC February 2016 o Scale: It supports growth of vendors, their product types and capabilities with versions and ease of adding attribute and types. o The highlevel class classification would be generic and vendor where generic would be applicable for all NFVs/Services of same category (minimum subset support across all products to be compatible), and vendor specific are enhanced based particularly on a vendor and their product. Both of these can be specific as any data format as JSON, yang, etc. 9. Security Considerations This draft does not introduce any new security considerations beyond what may be present in proposed solutions. 10. IANA Considerations This document requires no IANA actions. RFC Editor: Please remove this section before publication. 11. References 11.1. Normative References [RFC7365] Lasserre, M. et al., "Framework for data center (DC) network virtualization", October 2014. 11.2. Informative References [RFC7348] Mahalingam, M. et al., " Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", August 2014. 11.3. Acknowledgments Thanks are to. This document was prepared using 2-Word-v2.0.template.dot. Vallamkonda et al. Expires November 2017 [Page 11] Internet-Draft A framework for Metadata on SFC February 2016 Authors' Addresses Sunil Vallamkonda F5 Networks 3545 N. 1st Street San Jose, CA 95134 USA Phone: +1 408 274 4820 Email: sunilvk@f5.com Linda Dunbar Huawei Technologies 5340 Legacy Drive, Suite 1750 Plano, TX 75024, USA Phone: (469) 277 5840 Email: ldunbar@huawei.com David Dolson Sandvine 408 Albert Street Waterloo, ON N2L 3V3 Canada Phone: +1 519 880 2400 Email: ddolson@sandvine.com Vallamkonda et al. Expires November 2017 [Page 12]