Network Working Group N.P. Bouthors Internet-Draft Qosmos Intended status: Informational September 19, 2014 Expires: March 21, 2015 Metadata transport in SFC draft-bouthors-sfc-md-00.txt Abstract This draft describes the transport of metadata in Service Function Chains. It precises how metadata MAY be shared reliably by network devices and/or network services via Metadata Messages that can be exchanged offline or inline. It proposes IPFIX as a representation mechanism for SFC Metadata and SCTP as an optional transport mechanism to enable reliable transmission of Metadata in SFC 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 March 21, 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 Bouthors Expires March 21, 2015 [Page 1] Internet-Draft Metadata transport in SFC September 2014 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 2.2. Problem Space . . . . . . . . . . . . . . . . . . . . . . 4 2.2.1. Metadata representation . . . . . . . . . . . . . . . 4 2.2.2. Metadata transport service . . . . . . . . . . . . . . 4 3. Metadata representation . . . . . . . . . . . . . . . . . . . 5 3.1. Metadata Representation Requirements . . . . . . . . . . . 6 3.1.1. Metadata Encoding requirements . . . . . . . . . . . . 6 3.1.2. Metadata Scope requirement . . . . . . . . . . . . . . 7 3.1.3. IPFIX Metadata representation . . . . . . . . . . . . 7 3.1.3.1. IPFIX Message Format . . . . . . . . . . . . . . . 8 3.1.3.2. Message Header Format . . . . . . . . . . . . . . 9 3.1.3.3. Field Specifier Format . . . . . . . . . . . . . . 9 3.1.3.4. Set and Set Header Format . . . . . . . . . . . . 10 3.1.3.5. Record Format . . . . . . . . . . . . . . . . . . 11 3.1.3.5.1. Template Record Format . . . . . . . . . . . . 11 3.1.3.5.2. Options Record Format . . . . . . . . . . . . 11 3.2. IPFIX message scoping example: . . . . . . . . . . . . . . 11 3.3. IPFIX encoding and template provisioning . . . . . . . . . 12 4. Reliable Metadata transport service . . . . . . . . . . . . . 14 4.1. Metadata transport service in SFC proposals . . . . 14 4.1.1. Metadata transport with Network Service Header . . . . 14 4.1.2. Metadata transport with Service Chain Header . . . . . 16 4.1.3. Metadata transport in NIU proposal . . . . . . . . . . 17 4.1.4. Metadata transport analysis . . . . . . . . . . . . . 17 4.2. Congruent out-of-band transport service . . . . . . . . . 18 4.3. Reliable transport service proposal 19 4.3.1. Using SCTP as a reliable Metadada transport service in SFC . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.3.2. Using SCTP as a Metadada delivery service for SF . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 8.3. External References . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 1. 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]. 2. Introduction Bouthors Expires March 21, 2015 [Page 2] Internet-Draft Metadata transport in SFC September 2014 This draft reviews the notions of metadata transport and representation in the context of Service Function Chaining. It builds upon the work done on Metadata in [RIJSMAN] and use the concepts and terminology defined in [SFC_ARCH] This document is illustrated with the example of the Network Service Header [QUINN_NSH] as well as the Service Chain Header in [ZHANG_SCH] and [NIU_SFC] as they all define implictily a metadata transport service in their corresponding proposals. As described in [SFC_ARCH] a Service Function Chain contains a set of abstract Service Functions which may be applied to a set of packets of flows. In practice, Service Functions are processing and forwarding data packets along a Rendered Service Path (RSP). As per [RIJSMAN], in the context of Service Function Chaining, metadata may be shared between Service Functions as a way to provide contextual information about the data packets which traverse the Rendered Service Path. [SFC_ARCH] states that metadata can be thought of as providing and sharing the result of classification. But we can see other sources for metadata, such as the SF or SFF along the Rendered Service Path. For [RIJSMAN] Metadata can be used for: 1. Sharing Contextual information which is not locally available, 2. Avoiding repeated execution of expensive operations , 3. Enabling support Fine-grained policies over a reduced number of chains, 4. And ensuring a single format of classification throughout the whole chain. Metadata can be exchanged directly in-band, indirectly out-of-band, or via some hybrid mode possibly with some support from the SFC header. These different models are described in in [RIJSMAN]. Section 3 will review the representation requirements for Metadata and see that they can be addressed based on existing standards. Section 4 will review the Metadata transport function of SFC from a reliability point of view. 2.1. Definition of Terms Metadata: In the context of Service Function Chaining, metadata provides contextual information about the data packets which traverse a Service Function Chain. Bouthors Expires March 21, 2015 [Page 3] Internet-Draft Metadata transport in SFC September 2014 Dataplane Metadata: These are information elements included in SFC header. They can represent values for certain contextual attributes, or keys to be used by Service Functions to access the expected contextual information via some offline collection procedures. Mandatory Dataplane Metadata: These are contextual information elements always present in SFC headers. The Service Path field in the Base Header of NSH can be considered as such. It is shared by all packets in a chain; it remains constant and acts as an identifier for the chain instance. Optional Dataplane Metadata: These are contextual information elements included in some SFC headers. Offline Metadata: Metadata transported out of band but tied to a chain, a flow in a chain or to a specific packet. Chain: For convenience in the text we will sometime refer to the Rendered Service Path as the chain. 2.2. Problem Space Two aspects of Metadata in SFC need to be addressed thoroughly because of their potential impact on target use cases. First how Metadata can be represented, Second how it can reliably transported between SFF and delivered to the target SF where needed. 2.2.1. Metadata representation Metadata can be extremely varied in term of usage and content. It can represent the result of Deep Packet Inspection (DPI) performed on the traffic for example by the Classifier Service Function at the ingress of the Rendered Service Path. It can contain information collected about the end user such as a policy identifier, a category or even represent an event related to the end-user session. Service Function and Service Forwarding Function can be as well source of Metadata This information can be used by Service Functions down the chain, as well as by monitoring entities responsible to track usage for example in the Network Function Virtualization environment to feed a VNF manager or an Orchestrator. Metadata being information shared by many network entities needs some means to be represented it in all of its dimensions. To this effect, relying the IETF IPFIX standard is proposed in Section 3 2.2.2. Metadata transport service Bouthors Expires March 21, 2015 [Page 4] Internet-Draft Metadata transport in SFC September 2014 As expected from service chain proposals, NSH, SCH and NIU proposals define some means to carry metadata between Service Functions in a Chain. They can be classified as follow: Dataplane Metadata: They are defined in the Service Function Chaining Problem Statement document. They are not considered to be part of the forwarding information of the SFC header. However they are expected to carry the result of antecedent classification, allowing Service Functions to take local policy decisions based on their values. As such, they could also be interpreted directly by Service Function Forwarder to steer traffic to various Service Functions. This is indeed confirmed by the SFC architecture document as a not in SFP forwarding function of the SFF. Offline Metadata: Beyond Dataplane Metadata, Offline Metadata can be shared between Service Functions in a chain, using out of bound, congruent or not, or hybrid models described in [RIJSMAN] The hybrid model for example, defined in [RIJSMAN], utilizes the SFC header to transport some key values for correlation purposes. These Correlation Ids can be used by the Service Functions to recover the full associated contextual information. Metadata, directly or indirectly, are transported hop by hop along a chain, in association to end-user traffic, the data payload of the SFC packets. How these metadata are transported over a chain matters. Passing metadata directly or indirectly along packets is a service that must be analyzed from a reliability point of view. Reliability requirement may vary depending on the nature of the metadata transported. Past experience for example in Mobile Network and data center with AAA Radius have shown that contextual information replication to various service function was indeed sensitive to packet loss events, and that ad hoc solutions had to be implemented to detect them. A reliable transport service for Metadata in SFC is expected. To this effect, an implementation is suggested in Section 4 3. Metadata representation Metadata definition is that it provides contextual information about the data packets which traverse a Service Function Chain. This must be understood broadly. Bouthors Expires March 21, 2015 [Page 5] Internet-Draft Metadata transport in SFC September 2014 Metadata can contain the result of traffic classification by Deep Packet Inspection (DPI). For example as an Application Id information which is tied to a traffic flow. There could be multiple flows with different application ids, in a chain. Metadata can also contain the result of DPI data extraction, such as identify requested URL in HTTP. Such information can be passed to certain SF down the chain such as a URL filtering function. Metadata can contain some punctual event information collected at the Ingress point of the chain and expected to be passed to all elements in the chain. Here this information may be triggered externally and generated only once, and be related to the tenant or the subscriber. Metadata representation involves the definition of a set of information elements types and the encoding rules for their values. Metadata representation can sometimes be performed by a single individual field with associated type and format. It is not always the case. Metadata may need multiple fields transported together to represented their values. Some addition fields may be required to describe the scope of the metadata itself. This can be any information element defining the context of the associated metadata value. For example a throughput metadata field can have a port number and a switch address as its Scope information. The following Section 3.1 explores these two axes: encoding and scope. The Section 3.1.3 proposes IPFIX as a preferred means to represent Metadata in Service Chain messages for Out-of-band, Congruent or not; Metadata sharing. 3.1. Metadata Representation Requirements Mandatory Dataplane Metadata is always part of the SFC header, it is thus reasonable to consider that its representation scheme will be implicit: based on what the SFC protocol will dictate, their position in the SFC header is sufficient for the receiving end to infer their type and encoding scheme. For example, Context Header Fields in NSH are 32 bit fields. However, it will not be the case for all metadata transported. Optional and Offline metadata, including congruent out-of-band metadata still need to be represented explicitly. This section addresses their specific case. 3.1.1. Metadata Encoding requirements Bouthors Expires March 21, 2015 [Page 6] Internet-Draft Metadata transport in SFC September 2014 These requirements are applicable to out-of-band metadata (Congruent or not). It could be applicable with SCH on optional in-line metadata fields. For interoperability purposes, metadata encoding MUST allow the receiving entity to identify the type and value of the information received as metadata Metadata encoding MUST allow for encoding techniques supporting well known types and fields as well as proprietary extensions. A receiving entity MUST be able to identify when incoming metadata type is unknown and MUST have a defined default action to handle it. A piece of information may need multiple attributes to be described. For example a tenant id and an IP address can be used to identify a server in a data center uniquely. Metadata encoding MUST support such structured fields. These groups of information have to be exchanged collectively, as part of a single logical message. In this case, a sending entity MUST specify that it is sending a set of metadata in a message. This set of transported metadata elements MUST be specified under the form of a metadata template document uniquely defined for the chain. A receiving entity MUST be able to detect if an incoming messages contains its expected set of metadata elements. 3.1.2. Metadata Scope requirement A piece of information may have to be qualified by some attributes identifying its particular scope. For example a throughput scope may have to describe where and when it was measured. Scope can apply to some individual metadata elements or to a set of metadata elements. How a scope applies to a set of transported metadata elements should be defined by a specification of the transport set under the form of a metadata template document uniquely identified for the chain. 3.1.3. IPFIX Metadata representation So far, simple Type Length Value encoding has been proposed to transport metadata. It is not clear how structured types are supported, and no distinction is done between the metadata value and the scoping value. For example, although the SCH proposal provides an optional 24-bit Organizational Unique Identifier, there is no namespace mechanism allowing to separate type definition spaces per Tenants or per chain. Bouthors Expires March 21, 2015 [Page 7] Internet-Draft Metadata transport in SFC September 2014 We suggest leveraging the work done by IETF on similar subject, driven by the requirement listed above, and which has been widely deployed. A natural candidate to leverage is IPFIX [RFC7011]: IPFIX is a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information, it provides a common representation of flow data and a standard means of communicating them. Metadata collected by Network Node and Service Node SHOULD be encoded in template following the principles described in IPFIX [RFC7011]. IPFIX SHOULD be used in the context of Congruent out of band for reliable metadata sharing. IPFIX SHOULD be used in the context of offline reliable metadata sharing. 3.1.3.1. IPFIX Message Format An IPFIX Message consisting of interleaved Template, Data, and Options Template Sets, as shown in Figure 1. Here, Template and Options Template Sets, which are optional, are shown. +--------+--------------------------------------------------------+ | | +----------+ +---------+ +-----------+ +---------+ | |Message | | Template | | Data | | Options | | Data | | | Header | | Set | | Set | ... | Template | | Set | | | | | | | | | Set | | | | | | +----------+ +---------+ +-----------+ +---------+ | +--------+--------------------------------------------------------+ Figure 1: IPFIX Message Format The Template Set describes the data transmitted in the following Data Set. It is an optional component of the message. The value of the metadata is encoded in the first Data Set. This Data Set contains a template Id field as a reference to its defining Template Set. The Options Template Set describes the data to be transmitted as scope information. It is an optional component of the message. The value of the scope information is encoded in the second Data Set element. If no scope information is present, then only the first Data Set is present in the message. The Option Template Set and following Data Set are used to describe the scope of the metadata transmitted. For example, the metadata Bouthors Expires March 21, 2015 [Page 8] Internet-Draft Metadata transport in SFC September 2014 collected is relevant to a PDP Context or a particular line card of a particular switch. 3.1.3.2. Message Header Format Refer to IPFIX Section 3.1 in [RFC7011]. An IPFIX Message consisting entirely of Template and Options Template Sets 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Export Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Observation Domain ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: IPFIX Metadata Message Header Version Version of IPFIX to which this Message conforms. The value of this field is 0x000a for the current version Observation Domain ID It is RECOMMENDED that this identifier also be unique per IPFIX Device. Collecting Processes SHOULD use the Chain path, Chain index and the Observation Domain ID field to separate different export streams originating from the same Exporter. The Observation Domain ID SHOULD be 0 when no specific Observation Domain ID is relevant for the entire Metadata IPFIX Message. The Observation Domain ID field, along with Chain path, acts as a naming space identifier. This will in particular allow for multi-tenant name space separation. 3.1.3.3. Field Specifier Format Refer to IPFIX Section 3.2 in [RFC7011]. It defines generic Information Element identifiers and allows for enterprise specific ones. See [IANA-IPFIX] for common Information Element identifiers definition. Note: Additional common attributes may be defined for the purpose of SFC use cases. (E.g. PDP context identifier) Bouthors Expires March 21, 2015 [Page 9] Internet-Draft Metadata transport in SFC September 2014 The Field Specifier format is shown in Figure 3. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Information Element ident. | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Field Specifier Format Where: E: Enterprise bit. This is the first bit of the Field Specifier. If this bit is zero, the Information Element identifier identifies an Information Element in [IANA-IPFIX], and the four-octet Enterprise Number field MUST NOT be present. If this bit is one, the Information Element identifier identifies an enterprise-specific Information Element, and the Enterprise Number field MUST be present. 3.1.3.4. Set and Set Header Format Refer to IPFIX Section 3.3 in [RFC7011], as well in Section 4 of [RFC6759] for more details on application ID field definition, (section 6 for examples). A Set has the format shown in Figure 4. The record types can be either Template Records, Options Template Records, or Data Records. The record types MUST NOT be mixed within a Set. +--------------------------------------------------+ | Set Header | +--------------------------------------------------+ | record | +--------------------------------------------------+ | record | +--------------------------------------------------+ ... +--------------------------------------------------+ | record | +--------------------------------------------------+ | Padding (opt.) | +--------------------------------------------------+ Figure 4: IPFIX Metadata Set Format Bouthors Expires March 21, 2015 [Page 10] Internet-Draft Metadata transport in SFC September 2014 The Set Header's Set ID field value 2 is reserved for Template Sets and value 3 for Options Template Sets. Data Set value are 256 and above. Data Set records MUST be used to transport the metadata values. The Template ID to which the Field Values belong is encoded in the Set Header field "Set ID", i.e., "Set ID" = "Template ID". This way the corresponding Template Set can be transported in the Metadata IPIX message, or can be made available to all SF in a chain as part of their configuration delivered by the chain Controller. 3.1.3.5. Record Format 3.1.3.5.1. Template Record Format Refer to IPFIX Section 3.4.1 in [RFC7011]. The Template Record format allows applications which don't know the format of certain fields to ignore them. This is an important feature for sharing Metadata among heterogeneous Service and Network Nodes. 3.1.3.5.2. Options Record Format Refer to IPFIX Section 3.4.2 in [RFC7011]. The Options Record format allows applications to describe the scope of the Metadata information, via a number of fields passed in the following Data Set element. Allowing scoped Metadata provides an increased level of flexibility to the Network and Service Node when applied in the context of a particular chain. 3.2. IPFIX message scoping example: The Metadata Exporting Process creates a Template Record with a few Information Elements: Bouthors Expires March 21, 2015 [Page 11] Internet-Draft Metadata transport in SFC September 2014 - sourceIPv4Address (key field) - destinationIPv4Address (key field) - protocol (key field) - destinationTransportPort (key field) - octetTotalCount (non key field) For example, a Flow Record corresponding to the above Template Record may contain: { sourceIPv4Address=192.0.2.1, destinationIPv4Address=192.0.2.2, protocol=17, destinationTransportPort=80, octetTotalCount=123456 } The Options Data Record associated with the examples above would contain the Scoping inforamtion: Scope: - servicePath, - serviceIndex, - applicationId, - applicationName - applicationDescription. For example: { scope= servicePath=0x000b, serviceIndex=0x000c, applicationId='13...10000', applicationName="webex", applicationDescription="Webex application" } Scope information may be used to carry the information of the NSH header when the information is passed offline, out of band for example via controllers. Scope information is useful when sending metadata offline, as it can contain information related to the chain and possibly the flow for which this metadata record is relevant. Here servicePath and serviceIndex are thus included in the Template. 3.3. IPFIX encoding and template provisioning IPFIX is a quite compact encoding For a template defined as followed and shared by the SF in a chain. Bouthors Expires March 21, 2015 [Page 12] Internet-Draft Metadata transport in SFC September 2014 IPFIX template record shared by SF: Note that an XML representation of IPFIX template record can be defined and used to provision Service Functions. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 28 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID 256 | Field Count = 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| sourceIPv4Address = 8 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| destinationIPv4Address = 12 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| ipNextHopIPv4Address = 15 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| packetDeltaCount = 2 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| octetDeltaCount = 1 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: IPFIX Metadata template Encoding An encoded IP fix transport message will be: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Export Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Observation Domain ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 256 | Length = 64 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.254 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5009 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5344385 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: IPFIX Metadata Encoding Bouthors Expires March 21, 2015 [Page 13] Internet-Draft Metadata transport in SFC September 2014 4. Reliable Metadata transport service We saw that various uses case support the notion that Service Functions require Metadata to be transported reliably along the Rendered Service Path they belong to. Network Orchestration for example is expected to be a significant driver for deployment of Network Services. It relies on Service Level abstractions such as Group Policies, Contracts and Services as an input for the orchestration of Service Function Chains. Specific metadata attributes such as L4-L7 fields are used as classification elements or filters to funnel packets into chains. One can expect Network Orchestration to request metadata extraction at the Classifier level, and to make it available to the Service Chaining service Current SFC proposals shows that some Metadata element may play a role in the Service Function Chain deployment to route incoming traffic to some relevant processing resources. Other Metadata can be used by SF for their internal needs, although there is no mechanism defined yet to pass these information to the SF. In both cases, Metadata can become a critical information element, required to be transported Indeed, Service Function Chain proposals such as NSH, SCH and NIU define a transport mechanism for sharing information along the Chains. It is thus important to understand there transport service in term of reliability. We review these separately in Section 4.1 Service Functions may have various needs to access SFC Metadata, for example Event Based Metadata tied to some subscriber related state changes. The complexity and length of these elements should not be constrained, neither should be their requirement for a reliable transport throughout a chain. Section 4.2 and Section 4.3 propose to take advantage of Congruent Metadata Transport. It can be used, possibly reliably, to address these needs. 4.1. Metadata transport service in SFC proposals 4.1.1. Metadata transport with Network Service Header A Network Service Header (NSH) contains metadata and service path information that is added to a packet or frame and used to create a service plane. The packets and the NSH are then encapsulated in an outer header for transport. The service header is added by a service classification function - a device or application - that determines which packets require servicing, and correspondingly which service path to follow to apply the appropriate service. Bouthors Expires March 21, 2015 [Page 14] Internet-Draft Metadata transport in SFC September 2014 A NSH is composed of a 64-bit base header, and four 32-bit context headers as shown in Figure 9 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Base Header | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Network Service Header Context headers: carry opaque metadata. NSH provides a mechanism to carry shared metadata between network devices and service functions, and between service functions. The semantics of the shared metadata is communicated via a control plane to participating nodes. Examples of metadata include classification information used for policy enforcement and network context for forwarding post service delivery. [QUINN_NSH] shows that metadata can be expected to identify information such as: 1. Network platform context: which is platform specific information shared between Network Nodes. Possibly platform centric, network related information. 2. Network shared context: metadata resulting for edge classification. 3. Service platform context: which is service specific information shared between Service Functions. Possibly platform-centric service related information. 4. Network shared context: metadata relevant to and shared between Service Functions. NSH also support inline optional variable size metadata. It contains also the notion of Critical Metadata. Critical Metadata presence is noted in the NSH Base Header so that intemediate nodes may avoid to drop such packets. Bouthors Expires March 21, 2015 [Page 15] Internet-Draft Metadata transport in SFC September 2014 This is obviously an attempt to provide some level of reliability to the service. This is still a best effort attempt as there is not guarantee that the underlay network, unaware of NSH, drops the corresponding packets. NSH does not state whether or not Metadata can be sent as congruent signaling messages: without carrying any payload. 4.1.2. Metadata transport with Service Chain Header The Service Chain Header (SCH) (see Figure 10 ) consists of a mandatory fixed length part followed by a number of optional variable length metadata as shown in Figure 10. The mandatory fields carry "SFC path" information, which is used to steer the frames or packets through an ordered set of service function instances along the service function chain. The optional variable length fields carry application/service/content related metadata information which can be used by any SFC entities. The optional fields are formatted as Type-Length-Value structures. If any field in the header is not in use, the value of that field MUST be set to zero. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver |M|R|R|R|R|Metadata Length| Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Identifier | SF Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Metadata TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Service Chain Header Optional metadata are added after the fixed part of the SCH. Each option is of variable length and has a minimum length of four octets. An optional 3-octet Organizational Unique Identifier (OUI) may be provided to differentiate multiple private number spaces for the Type field. If the OUI is not provided, the Type is assumed to be a registered globally unique type. Figure 11. shows the format of the TLV in SCH. Bouthors Expires March 21, 2015 [Page 16] Internet-Draft Metadata transport in SFC September 2014 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P|R|R|R|R|R|R|R| Type | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | OUI (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Service Chain Header TLV format Metadata transport in SCH calls for the inclusion of metadata directly in the packet. The result is that long metadata can be transported inline. Metadata is optional, so no space is taken when no metadata is sent with a packet, leading to a more compact header than NSH then. However we can see that sending 4 32 metadata fields would take more header space. The SCH may be used to carry: (1) both SFC path steering information and metadata; (2) only SFC path steering information, in which case the Metadata Length field shall be set to zero; or (3) only metadata, in which case the Path Identifier and SF Index fields shall be set to zero for transmit and ignored upon receipt. SCH thus allows Metadata to be sent as congruent signaling messages: without carrying any payload. From that point of view, two notions should be supported (reliably) 1. Point to point message. SF index may then be zero 2. "Down the chain" messages. SF index would not be nul then 4.1.3. Metadata transport in NIU proposal [NIU_SFC] also includes the notion of optional metadata. It distinguishes between FORWARDING metadata element and SERVICE metadata. FORWARDING metadata element is used to carry the SF Processing Result Metadata. Error/Success message which can be passed from a Service Function to the next one. SF Processing Result is a fixed 32 bit field. There can be only one such element in a packet. SERVICE metadata is encoded in TLV, which format is not specified in the current version as referenced below. 4.1.4. Metadata transport analysis Bouthors Expires March 21, 2015 [Page 17] Internet-Draft Metadata transport in SFC September 2014 Both NSH and SCH proposals support both inbound and out-of-band metadata transport. 1. In-band: the metadata can be included directly as a value in some of the NSH Context Header Fields. It is the preferred transport model for SCH. In such case, when a particular field is always set to the same value for all packets transported by the chain instance, then the metadata transport service is in effect reliable. Similarly, all the packet for a particular flow (defined by its 5 tupple), could receive the same metadata value. The metadata transport service is also reliable, provided that the value is understood to be attached to a flow. The general case is when the metadata varies from packet to packet in a flow. The value is then tied to a specific packet. Here the transport service is not reliable. A retransmission of a particular packet would not necessarily lead it to carry the same metadata value. 2. Out-of-band: the metadata is sent along a packet that is relevant to the metadata, to the controller. It is the preferred model for NSH, but could also be used by SCH. As for the in-band case, the metadata referred to indirectly can be transmitted reliably, when it remains the same for a chain or a flow in a chain. If however, the correlation Id passed changes over time, then the correct Metadata may not be retreived by some Service Functions. We can see that NSH and SCH do not provide a reliable transport service for metadata. Conventions can be used as particular cases when some metadata pertains to a specific chain or a flow in the chain, and when its value does not change overtime. Such conventions however are weak. They would suppose that some mechanism exists to ensure/monitor that they are followed. And some exceptions mechanism would be required to deal with error cases. The general case, metadata tied to a packet, has its own set of issues. What is a packet is lost? How to pass metadata to a legacy SF, preserving the connection between the packet and its metadata. 4.2. Congruent out-of-band transport service Congruent out-of-band metadata sharing can be required for some types of Metadata exchanges. It has the advantage of clearly tying the metadata to the chain and not to a specific packet, and to avoid payload fragmentation issues. Bouthors Expires March 21, 2015 [Page 18] Internet-Draft Metadata transport in SFC September 2014 Up to draft 2, NSH did not allow for long inline metadata transport. Four 32 bits context fields are reserved for that purpose, and seem best suited for offline Metadata sharing, or to transport predefined policy identifiers. NSH (since draf 3) as well as SCH could allow for metadata transport, either tied to a packet or possibly tied to the chain, when used without payload, as signaling messages. SCH however stipulates that in case the Path Identifier and SF Index fields shall be set to zero for transmit and ignored upon receipt, when the SCH packet will contain only metadata. So congruent out-of- band metadata, transporting Metadata hop to hop to the various Service Function in the chain, does not seem to be supported. NSH and NUI supports inline variable size metadata. They doe not mention explicitly that congruent out-of-band metadata can be used. 4.3. Reliable transport service proposal Some metadata will need a reliable transport service to be shared inline, as well as offline. A protocol SCTP provides such a service and has the interesting characteristic to be packet based, as opposed to stream based like TCP. 4.3.1. Using SCTP as a reliable Metadada transport service in SFC SCTP carries a sequence number and support retransmission and congestion control. Figure 12 illustrates how SCTP MUST used hop by hop between SFF in a chain to transport Metadata reliably. Bouthors Expires March 21, 2015 [Page 19] Internet-Draft Metadata transport in SFC September 2014 |1 ----- |n |21 ---- |2m +---+---+ +---+---+ +-+---+ +--+-----+ | SF#1 | |SF#n | |SF#i1| |SF#im | | | | | | | | | +---+---+ +---+---+ +--+--+ +--+--+--+ : : : : : : : : : : \ / \ / +-----------+ SCTP +--------+ SCTP +---------+ -- >| Chain | <---> | SFF | <---> | SFF | ----> |classifier | |Node-1 | | Node-i | +-----------+ +----+---+ +----+--+-+ \ | / \ | SFC Encapsulation / \ | / ,........................................ / \ / \ | Network | \ / \........................................./ Figure 12: SCTP for Reliable Metadata transport TLV format SCTP protocol exchanges MUST occur between SFF. The SCTP payload MUST contains the SFC header and the SFC payload. SCTP SHOULD be used in the context of Congruent out of band for reliable metadata sharing. SCTP SHOULD be used in the context of offline reliable metadata sharing. The SFF along the chain MAY route the metadata received over SCTP to the next SF in the chain. For this SCTP MUST be encapsulated in the SFC header. The SFF MUST make the received metadata available to its SF. 4.3.2. Using SCTP as a Metadada delivery service for SF SCTP could also be used as a mechanism to deliver Metadata to SF in a chain. Metadata is message based, so it fits well with the SCTP API and is reliable. Defining how an SFF could delivery metadata to a SF, would facilitate the deployment of Metadata aware SFs, allowing to distribute policies in a network for both SFC unaware application and SFC aware ones. 5. Security Considerations Bouthors Expires March 21, 2015 [Page 20] Internet-Draft Metadata transport in SFC September 2014 As with many other protocols, SFC data can be spoofed or otherwise modified. In many deployments, SFC will be used in a controlled environment, with trusted devices (e.g. a data center) thus mitigating the risk of unauthorized header manipulation. SFC is always encapsulated in a transport protocol and therefore, when required, existing security protocols that provide authenticity (e.g. [IPSec]) can be used. SCTP can be run securely when transporting metadata for the chain. Similarly if confidentiality is required, existing encryption protocols can be used in conjunction with encapsulated NSH. 6. Acknowledgments A special thank you goes to J. Tollet and U. Elzur for their guidance and feedback. 7. IANA Considerations An IEEE EtherType will be requested for NSH. 8. References 8.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", RFC 6071, February 2011. [RFC7011] Claise, B., Trammell, B. and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013. [RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, September 2013. Bouthors Expires March 21, 2015 [Page 21] Internet-Draft Metadata transport in SFC September 2014 [RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements", BCP 184, RFC 7013, September 2013. [RFC6759] Claise, B., Aitken, P. and N. Ben-Dvora, "Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX)", RFC 6759, November 2012. [RIJSMAN] Rijsman, B., "Metadata Considerations, draft-rijsman-sfc- metadata-considerations-00 ", . [SFC_ARCH] Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture draft-ietf-sfc-architecture-01 ", . [QUINN_NSH] Quinn, P., "Network Service Header, draft-quinn-sfc- nsh-02.txt ", . [ZHANG_SCH] Zang, H., "Service Chain Header draft-zhang-sfc-sch-00 ", . [NIU_SFC] Niu, L., "A Service Function Chaining Header and Forwarding Mechanism draft-niu-sfc-mechanism-01.txt ", . 8.3. External References [IANA-IPFIX] IANA , ""IP Flow Information Export (IPFIX) Entities", http://www.iana.org/assignments/ipfix/ ", . Author's Address Nicolas Bouthors Qosmos Bouthors Expires March 21, 2015 [Page 22]