| Network Working Group | N. Bouthors |
| Internet-Draft | Qosmos |
| Intended status: Informational | September 19, 2014 |
| Expires: March 23, 2015 |
Metadata transport in SFC
draft-bouthors-sfc-md-00.txt
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
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 23, 2015.
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.
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].
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:
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.
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.
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
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:
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
Metadata definition is that it provides contextual information about the data packets which traverse a Service Function Chain. This must be understood broadly.
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.
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.
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.
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.
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.
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.
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.
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
Figure 1: IPFIX Metadata Message
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 collected is relevant to a PDP Context or a particular line card of a particular switch.
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
Figure 2: IPFIX Metadata Message Header
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)
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
Figure 3: IPFIX Field Specifier Format
Where:
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
Figure 4: IPFIX Metadata Set Format
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.
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.
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.
The Metadata Exporting Process creates a Template Record with a few Information Elements:
- 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.
IPFIX is a quite compact encoding
For a template defined as followed and shared by the SF in a chain.
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 5: IPFIX Metadata template Encoding
Figure 5: IPFIX Metadata Set Format
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 6: IPFIX Metadata Encoding
Figure 6: IPFIX Metadata Set Format
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.
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.
A NSH is composed of a 64-bit base header, and four 32-bit context headers as shown in Figure 7 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 7: Network Service Header
Figure 7: 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:
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.
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.
The Service Chain Header (SCH) (see Figure 8 ) consists of a mandatory fixed length part followed by a number of optional variable length metadata as shown in Figure 8. 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 8: Service Chain Header
Figure 8: 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 9. shows the format of the TLV in SCH.
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 9: Service Chain Header TLV format
Figure 9: 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)
[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.
Both NSH and SCH proposals support both inbound and out-of-band metadata transport.
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.
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.
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.
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.
SCTP carries a sequence number and support retransmission and congestion control.
Figure 10 illustrates how SCTP MUST used hop by hop between SFF in a chain to transport Metadata reliably.
|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 10: SCTP for Reliable Metadata transport TLV format
Figure 10: SCTP for metadata
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.
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.
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.
A special thank you goes to J. Tollet and U. Elzur for their guidance and feedback.
An IEEE EtherType will be requested for NSH.
| [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. |
| [IANA-IPFIX] | IANA, ""IP Flow Information Export (IPFIX) Entities", http://www.iana.org/assignments/ipfix/", . |