Protocol Independent Encoding for Signaling Flow Characteristics
draft-choukir-tsvwg-flow-metadata-encoding-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Toerless Eckert , Anca Zamfir , Amine Choukir , Charles Eckel | ||
| Last updated | 2013-07-08 | ||
| Stream | (None) | ||
| Formats | plain text xml pdf htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-choukir-tsvwg-flow-metadata-encoding-00
Internet Engineering Task Force T. Eckert, Ed.
Internet-Draft A. Zamfir
Intended status: Standards Track A. Choukir
Expires: January 10, 2014 C. Eckel
Cisco Systems, Inc.
July 09, 2013
Protocol Independent Encoding for Signaling Flow Characteristics
draft-choukir-tsvwg-flow-metadata-encoding-00
Abstract
This document describes a protocol independent encoding for flow
characteristics (a.k.a. metadata). A flow is defined as a set of IP
packets passing through a network in a given direction. All packets
belonging to a particular flow have a set of common properties (e.g.
IP, port, transport). Flow metadata exposes key characteristics of
the flow such as the originating application, the type of media in
use (e.g. audio, video) and others as defined in
[I-D.eckert-intarea-flow-metadata-framework]. The flow
characteristics are expressed in terms of information elements.
These information elements are signaled either out of band or in band
but always along the same path of the flow associated with the
application.
[I-D.eckert-intarea-flow-metadata-framework] defines the overall
framework for flow metadata and the definition of the flow
characteristics, whereas this document captures the encoding of these
characteristics. The mapping of flow metadata encoding to different
signaling protocols is outside the scope of this document.
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 January 10, 2014.
Eckert, et al. Expires January 10, 2014 [Page 1]
Internet-Draft Flow Metadata Encoding July 2013
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Encoding Overview . . . . . . . . . . . . . . . . . . . . . . 4
2.1. General Principles . . . . . . . . . . . . . . . . . . . 4
2.2. Encoding Goals . . . . . . . . . . . . . . . . . . . . . 4
2.2.1. Transport independence . . . . . . . . . . . . . . . 5
2.2.2. Standard and Vendor Specific Namespaces . . . . . . . 5
2.2.3. Multiple Producers . . . . . . . . . . . . . . . . . 5
2.2.4. Upstream and Downstream . . . . . . . . . . . . . . . 5
2.2.5. Application to Network and Network to Application . . 6
2.2.6. Extensibility . . . . . . . . . . . . . . . . . . . . 6
2.2.7. Flexibility . . . . . . . . . . . . . . . . . . . . . 6
2.2.8. Per Producer Security . . . . . . . . . . . . . . . . 6
2.2.9. Compact Encoding . . . . . . . . . . . . . . . . . . 7
3. Encoding specification . . . . . . . . . . . . . . . . . . . 7
3.1. Layout . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Sections . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Security Tokens . . . . . . . . . . . . . . . . . . . 8
3.1.3. Subsections . . . . . . . . . . . . . . . . . . . . . 9
3.1.4. Upstream and Downstream Blocks . . . . . . . . . . . 10
3.1.5. Complete Encoding Example . . . . . . . . . . . . . . 10
3.1.6. Compact Encoding Example . . . . . . . . . . . . . . 11
3.2. Encoding Structures . . . . . . . . . . . . . . . . . . . 12
3.3. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Normative References . . . . . . . . . . . . . . . . . . 17
6.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Encoding usage examples . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Eckert, et al. Expires January 10, 2014 [Page 2]
Internet-Draft Flow Metadata Encoding July 2013
1. Introduction
This document describes a protocol independent encoding for flow
characteristics (a.k.a. metadata). A flow is defined as a set of IP
packets passing through a network in a given direction. All packets
belonging to a particular flow have a set of common properties (e.g.
IP, port, transport). Flow metadata exposes key characteristics of
the flow such as the originating application, the type of media in
use (e.g. audio, video) and others as defined in
[I-D.eckert-intarea-flow-metadata-framework]. The flow
characteristics are expressed in terms of information elements.
These information elements are signaled either out of band or in band
but always along the same path of the flow associated with the
application.
As flow characteristics across different signaling protocols are
identical, they benefit from a single definition and encoding
irrespective of the signaling protocol in use (e.g. RSVP
[ID-FMD-RSVP], STUN [I-D.martinsen-mmusic-malice], and PCP
[I-D.wing-pcp-flowdata]). Different network deployments call for
different protocols or combination of protocols as described in
[I-D.eckert-intarea-flow-metadata-framework]. The flow
characteristics can be processed by intermediate network nodes for
the purpose of applying a particular treatment to the flow or simply
for gathering insight on the nature of the traffic crossing the
network node.
Flows, and the corresponding metadata, are inherently unidirectional,
in the direction from the source to the destination (e.g. from Alice
to Bob). In some cases, there may be a related flow in the reverse
direction (e.g. from Bob to Alice), but this is treated as a separate
flow, not a bidirectional flow. The Metadata tags can characterize
data in the same direction as the flow (upstream) or in the opposite
direction (downstream). The encoding allows to signal for either
direction or both at the same time. The Metadata tags can be
signaled by the application itself and/or by network elements that
have visibility of the flow data. The encoding supports
distinguishing between attribute information originated by an
application from attribute information originated by a network
device. The encoding allows to segregates information coming from
the application from information coming from the network.
1.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].
Eckert, et al. Expires January 10, 2014 [Page 3]
Internet-Draft Flow Metadata Encoding July 2013
2. Encoding Overview
2.1. General Principles
This specification assumes that the flow is specified by the
transport protocol which carries the Metadata tags. As an example,
in STUN, flow identifiers such as IP addresses and ports are present
in layer 3 and 4 headers of STUN messages (see
[I-D.martinsen-mmusic-malice]). In RSVP, the same is obtained from
the SESSION and SENDER-TEMPLATE objects (see [ID-FMD-RSVP]). In PCP
the source IP is part of the request common header; other flow
identifiers need to be embedded in an opcode data or an option
(see[I-D.wing-pcp-flowdata]).
The Flow Metadata characteristics are to be interpreted in the
context of the flow defined by the signaling protocol. In this
specification Flow Metadata encoding does not carry any flow
identifiers but merely the flow characteristics. The specification
could be extended to carry the flow identifiers if needed.
The encoding defined herein does not relate to any specific signaling
but rather allows different signaling protocols to transport flow
characteristics. As the encoding is shared amongst several
protocols, it is versioned independently to allow, if needed, its
evolution without impacting the signaling protocol.
2.2. Encoding Goals
The following goals have been considered in the design of the
encoding:
o Transport independence
o Allow for a standard namespace as well as vendor specific
namespaces
o Support multiple producers of flow characteristics
o Ability to encode flow characteristics for both the flow itself
(upstream) and the flow in the reverse direction (downstream).
o Ability to communicate flow characteristics from an application to
the network as well as from the network back to the application
o Extensibility while allowing for backwards compatibility
o Flexibility
Eckert, et al. Expires January 10, 2014 [Page 4]
Internet-Draft Flow Metadata Encoding July 2013
o Support for integrity, authentication and authorization on a per
producer basis
o Compact encoding
2.2.1. Transport independence
One goal of this proposal is to provide an encoding that can be used
by more than one transport protocol. This should help maintain
consistency across standardization of flow metadata usage by various
signaling protocols, and it should simplify implementations that make
use of different signaling protocols when transporting flow metadata.
One example is an application that may use different signaling
protocols depending on the environment, peer protocol support, etc.
Another is a middlebox on an administrative boundary that may need to
perform protocol interworking functions.
2.2.2. Standard and Vendor Specific Namespaces
Vendors need the ability to define and use proprietary Metadata when
they are delivering a pre-standard feature or product or when the
encoded information is of commercially sensitive nature. This
specification provides support for both standard and vendor specific
defined flow characteristics.
2.2.3. Multiple Producers
Multiple producers may contribute flow characteristics to the Flow
Metadata information associated with a given flow.
Applications are one category of candidates for generating Flow
Metadata as they have precise knowledge of the flows they insert into
the network. Middleboxes constitute a second class of Metadata
producers. Deep Packet Inspection engines are deployed to recognize
the originator and nature of the flows traversing a network. Media
Termination Points (e.g. MCU, transcoders) are deployed to offer
additional services to applications. Media Termination Points have
knowledge of the transformations they apply on the flow they receive
and can therefore update the characteristics of the flow. Other
proxies and gateways exist for other applications and could produce
information in relation to the flow.
2.2.4. Upstream and Downstream
As explained in the introduction, a flow is unidirectional by
definition, but some use cases and signaling protocols require or
allow to signal both upstream and downstream flow characteristics.
For example, in the context of a home user that needs to prioritize
Eckert, et al. Expires January 10, 2014 [Page 5]
Internet-Draft Flow Metadata Encoding July 2013
its upstream and downstream flow an end-to-edge protocol can expose
flow characteristics to the edge ISP node controlling its access link
for both its upstream and downstream flow. This allows the edge node
to apply proper treatment to both directions.
2.2.5. Application to Network and Network to Application
In accordance with [I-D.eckert-intarea-flow-metadata-framework], flow
characteristics may be communication both from application to network
as well as from network to application. The encoding rules are the
same regardless of the direction of the communication. The ability
to differentiate between the two is provided by the transport
protocol. For example, when using PCP, application to network
communication is via a PCP request, and network to application
communication is via a PCP response.
2.2.6. Extensibility
New use cases and new deployment scenarios will require the use of
new flow characteristics. For this reason the encoding should
support Metadata tag additions in a backwards compatible way. New
Metadata tag addition supplement but do not redefine existing tags.
An application or a network node always signals its currently
supported tag set and devices leverage the subset they understand for
the purpose of applying treatment to, or gathering information about,
the application flows.
2.2.7. Flexibility
Distinct use cases and individual applications have a need for
different subsets of Metadata tags. The encoding should support the
signaling of any subset of Metadata tags for that purpose. For
example, a video conferencing application might need to signal
metadata for both its audio and video flows. A video surveillance
application might signal video flows only, but may need to indicate
which one has priority based on embedded analytics.
2.2.8. Per Producer Security
Treatment applied on the basis of metadata may involve the
consumption of scarce network resources and therefore contribute to
their exhaustion. Consequently, integrity, authentication, and
authorization are all important aspects of any security mechanism
used to secure the metadata.
This specification defines an optional security element container;
however, the actual security mechanism to be used is outside the
scope of this specification.
Eckert, et al. Expires January 10, 2014 [Page 6]
Internet-Draft Flow Metadata Encoding July 2013
2.2.9. Compact Encoding
One of the goals of the encoding described in this specification is
to be compact and consume minimal space in the signaling protocol
payload. Most of the protocols have limited space for Metadata
purposes and do not support semantic fragmentation. The strategy of
the encoding is to minimize the encoding structures used for the
common signaling case. The common case is foreseen to be the
application signaling standard flow characteristics.
3. Encoding specification
3.1. Layout
This section describes the encoding layout proposed by this
specification. It describes the following:
o How the application and network producers coexist using sections
in Figure 1
o Application of an optional security token to a section in Figure 2
o The division of a section into standard and vendor specific sub-
sections in Figure 3
o The division of a sub-section into upstream and downstream blocks
in Figure 4
o A full example using all the encoding building blocks in Figure 5
3.1.1. Sections
The flow characteristics are grouped in sections within the encoding.
A section pertains to an application or to a network producer. To
segregate application and network producer sections the encoding uses
a network marker. The application section does not use a network
marker and therefore must come first if present. The encoding MUST
contain at least an application or a network section. Figure 1 shows
an example that contains an application section and two network
sections.
+--------------------------------+
| Application Section |
+--------------------------------+
+--------------------------------+
| Network-1 Marker |
+--------------------------------+
+--------------------------------+
Eckert, et al. Expires January 10, 2014 [Page 7]
Internet-Draft Flow Metadata Encoding July 2013
| |
| |
| Network-1 Section |
| |
+--------------------------------+
+--------------------------------+
| Network-2 Marker |
+--------------------------------+
+--------------------------------+
| |
| |
| Network-2 Section |
| |
| |
| |
+--------------------------------+
Figure 1: Encoding section
3.1.2. Security Tokens
A section MAY include at most one security token. The security
token, if present, MUST appear at the beginning of the section. In
the following example, a separate security token is added to each
section contained in the previous example.
+--------------------------------+
| Security Token |
+--------------------------------+
+--------------------------------+
| Application Section |
+--------------------------------+
+--------------------------------+
| Network-1 Marker |
+--------------------------------+
+--------------------------------+
| Security Token N-1 |
+--------------------------------+
+--------------------------------+
| |
| |
| Network-1 Section |
| |
+--------------------------------+
+--------------------------------+
| Network-2 Marker |
+--------------------------------+
+--------------------------------+
Eckert, et al. Expires January 10, 2014 [Page 8]
Internet-Draft Flow Metadata Encoding July 2013
| Security Token N-2 |
+--------------------------------+
+--------------------------------+
| |
| |
| Network-2 Section |
| |
| |
| |
+--------------------------------+
Figure 2: Encoding security tokens
3.1.3. Subsections
A section may be divided into standard and vendor sub-sections. A
section MUST at least have one subsection. A section MUST contain at
most one standard sub-section and can contain multiple vendor
subsections for different vendors. A standard and a vendor sub-
section are segregated through a vendor marker. The standard
subsection does not use the vendor marker and therefore must come
first if present. Figure 3 shows a sample section content.
+--------------------------------+
| |
| |
| Standard Subsection |
| |
+--------------------------------+
+--------------------------------+
| Vendor-1 Marker |
+--------------------------------+
+--------------------------------+
| Vendor-1 Subsection |
| |
| |
| |
| |
| |
+--------------------------------+
+--------------------------------+
| Vendor-2 Marker |
+--------------------------------+
+--------------------------------+
| Vendor-2 Subsection |
| |
| |
| |
Eckert, et al. Expires January 10, 2014 [Page 9]
Internet-Draft Flow Metadata Encoding July 2013
| |
| |
+--------------------------------+
Figure 3: Encoding subsections
3.1.4. Upstream and Downstream Blocks
A subsection MUST contain at least one upstream or downstream block.
A subsection contains at most one upstream block and at most one
downstream block. Upstream and downstream blocks are composed of
metadata tags, with each tag specifying a flow characteristic. If
the upstream and downstream blocks are both present, the upstream
block MUST come first.
+--------------------------------+
| Upstream block |
| +------------+ +------------+ |
| | MD tag | | MD tag | |
| +------------+ +------------+ |
+--------------------------------+
+--------------------------------+
| Downstream block |
| +------------+ +------------+ |
| | MD tag | | MD tag | |
| +------------+ +------------+ |
+--------------------------------+
Figure 4: Encoding upstream and downstream blocks
3.1.5. Complete Encoding Example
Figure 5 shows a complete example combining the application and
network sections together with their standard and vendor sub-
sections. The tags appearing in a standard and in a vendor sub-
section are managed by separate registries. See
[I-D.eckert-intarea-flow-metadata-framework] for a full coverage of
the information model and how the registries are handled.
+--------------------------------+
| Security Token |
+--------------------------------+
+--------------------------------+ ^ ^
| Upstream block | | |A
| +------------+ +------------+ | | |P
| | MD tag | | MD tag | | |S |P
| +------------+ +------------+ | |T |L
+--------------------------------+ |D |I
Eckert, et al. Expires January 10, 2014 [Page 10]
Internet-Draft Flow Metadata Encoding July 2013
+--------------------------------+ | |C
| Downstream block | | |A
| +------------+ | | |T
| | MD tag | | | |I
| +------------+ | | |O
+--------------------------------+ v |N
+--------------------------------+ |
| Vendor section marker | |S
+--------------------------------+ |E
+--------------------------------+ ^ |C
| Upstream block | |V |T
| +------------+ +------------+ | |N |I
| | MD tag | | MD tag | | |D |O
| +------------+ +------------+ | | |N
+--------------------------------+ v v
+--------------------------------+ ^
| Network section marker | |
+--------------------------------+ |
+--------------------------------+ |N
| Security Token | |E
+--------------------------------+ |T
+--------------------------------+ |W
| Downstream block | |O
| +------------+ | |R
| | MD tag | | |K
| +------------+ | |
+--------------------------------+ |
+--------------------------------+ |S
| Vendor section marker | |E
+--------------------------------+ |C
+--------------------------------+ |T
| Downstream block | |I
| +------------+ | |O
| | MD tag | | |N
| +------------+ | |
+--------------------------------+ v
Figure 5: Complete encoding example
3.1.6. Compact Encoding Example
Figure 6 shows an encoding example for flow metadata standard
characteristics produced by an application for the upstream (same as
5-tuple) direction. As can be seen in the figure no network marker
is used as we are signaling for the application. In the same way
there is no vendor marker as we are signaling standard flow
characteristics. This example also assumes a use case where no
security token is needed. Further examples are given in Appendix A.
Eckert, et al. Expires January 10, 2014 [Page 11]
Internet-Draft Flow Metadata Encoding July 2013
+--------------------------------+
| Upstream block |
| +------------+ +------------+ |
| | MD tag | | MD tag | |
| +------------+ +------------+ |
+--------------------------------+
Figure 6: Compact encoding example
3.2. Encoding Structures
This section explores the encoding looking more closely at the
encoding structures.
Figure 7 shows the encoding used by an application using only
standard tags.
Figure 8 shows the encoding used by an application using only
vendor specific tags.
Figure 9 shows the encoding for network producers using only
standard tags.
The three scenarios expose all the encoding structures. These
structures may be combined in various ways to support other
scenarios.
The encoding makes use of Type Length Value (TLV) as the base
building block, plus some level of nesting to create the different
encoding structures. The type indicates which encoding structure is
in use. In case of a marker, the length gives the size of the marker
but not of the delimited section or sub-section.
As explained previously, application and network sections MUST
contain at least one standard or vendor sub-section and MAY contain a
security token. The value of the security token TLV is broken down
in two parts, a security-scheme indicating the security method used
and the security-value holding the security payload specific to the
security scheme. The definition of the different security schemes
and their payloads are left to a separate document.
The value of the upstream and downstream block TLVs are subdivided in
metadata tags. Each tag is itself a TLV specifying a flow
characteristic. A metadata tag MUST appear only once in an upstream
or a downstream block. On the one hand the security token, the
upstream and the downstream block, the vendor and network marker
types are defined within the same registry. On the other hand the
tag types are defined in a separate registry from the enclosing
Eckert, et al. Expires January 10, 2014 [Page 12]
Internet-Draft Flow Metadata Encoding July 2013
encoding structures. The separation of the registries is possible as
the tags are part of the upstream and downstream block TLV value and
therefore do not collide with the encoding structures.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+^S
| Security-type | Length ||E
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|C
| Security-scheme | :|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :|T
: Security-value :|O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+vK
| Upstream-type | Length | ^U
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+^M|P
| Tag-type | Length ||D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |B
: Tag-value :|T|L
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+v |O
: ... : |C
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ vK
| Downstream-type | Length | ^D
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N
| Tag-type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B
: Tag-value : |L
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O
: ... : |C
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ vK
Figure 7
Figure 8 adds the vendor sub-section marker which starts a vendor
section. The vendor marker is a TLV whose type is defined in the
same registry as the security token. Its value is the vendor's
Private Enterprise Number (PEN) allocated by IANA. The vendor marker
does not include the downstream and the upstream block but rather
sets the context to interpret them. Multiple vendor sub-sections
within the same application or network section are allowed as long as
they pertain to different vendors.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security-type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security-scheme | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
Eckert, et al. Expires January 10, 2014 [Page 13]
Internet-Draft Flow Metadata Encoding July 2013
: Security-value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
| PEN-type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| PEN-id | |V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E
| Upstream-type | Length | |N
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D
| Tag-type | Length | |O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R
: Tag-value : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S
: ... : |E
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C
| Downstream-type | Length | |T
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I
| Tag-type | Length | |O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N
: Tag-value : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
: ... : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
Figure 8
Figure 9 adds the network marker that starts a network section. The
network marker is a TLV whose type is defined within the same
registry as the security token. The value of the network marker is
the network precedence that indicates the administrative preference
for the network producer flow characteristics. The precedence allows
to merge information from different network producers and retain only
the preferred one.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
| Network-type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Precedence | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Security-type | Length | |P
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R
| Security-scheme | : |O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : |D
: Security-value : |U
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C
| Upstream-type | Length | |E
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R
Eckert, et al. Expires January 10, 2014 [Page 14]
Internet-Draft Flow Metadata Encoding July 2013
| Tag-type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S
: Tag-value : |E
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C
: ... : |T
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I
| Downstream-type | Length | |O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N
| Tag-type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
: Tag-value : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
: ... : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
Figure 9
All the constructs above can be combined to signal standard and
vendor specific tags for different producers and allow to secure each
producer's information independently.
3.3. ABNF
MD-block = Version (Application-block / 1*Network-block /
(Application-block 1*Network-block))
Network-blocks = Network-tlv Producer-block
Application-block = Producer-block ; For the application we do not
; require the Producer-tlv
Producer-block = [Security-tlv] (Standard-block / 1*Vendor-block /
(Standard-block 1*Vendor-block))
Vendor-blocks = PEN-tlv Flow-block
Standard-block = Flow-block; We do not require the PEN-tlv
; for the standard tags
Flow-block = Upstream-tlv / Downstream-tlv /
(Upstream-tlv Downstream-tlv)
; If both present, upstream must come first
PEN-tlv = PEN-type Length PEN-id
Network-tlv = Network-type Length Precedence
Security-tlv = Security-type Length Security-scheme Security-value
Eckert, et al. Expires January 10, 2014 [Page 15]
Internet-Draft Flow Metadata Encoding July 2013
Upstream-tlv = Upstream-type Length Upstream-value
Upstream-value = Attribute-list
Downstream-tlv = Downstream-type Length Downstream-value
Downstream-value = Attribute-list
Attribute-list = 1*(Attribute-tlv)
Attribute-tlv = Tag-type Length Attribute-value
;---------
;TERMINALS
;---------
Version = %x01 ; NEW-VER will be picked up as the first
; version of the encoding
PEN-id = 4(OCTET); Private Enterprise Number defined by IANA
Length = 2(OCTET); 16-bit length field
Precedence = 4(OCTET); Indicates the preferred source of information
; for a producer-type
Security-scheme = OCTET; Type of security used
Security-value = *(OCTET)
; length of this field must match Length of Security-tlv + 2
Tag-type = 2(OCTET) ; Value according to IANA / Vendor-specific registry
Producer-type = Zero %x01; The first foreseen producer is MD-NETWORK
; to cover for DPI engines, gateways and others
; Further values may be allocated later
Security-type = Zero %x00 ;
Upstream-type = Zero %x01 ;
Downstream-type = Zero %x02 ;
PEN-type = Zero %x03 ;
Network-type = Zero %x04
Eckert, et al. Expires January 10, 2014 [Page 16]
Internet-Draft Flow Metadata Encoding July 2013
Attribute-value = *(OCTET) ;
Zero = %x00
Figure 10
4. Security Considerations
A security token, as described in Section 3.1.2, is a mechanism
provided as part of the encoding to protect flow characteristics. A
signaling protocol used to transport the encoded metadata may provide
additional security mechanisms. The protocol specific and encoding
specific security mechanisms may be used in combination to achieve
the required level of security.
5. Acknowledgements
We would like to thank Yann Poupet and Davide Cuda for reviewing this
document and helping us proof its content. We would also like to
express our gratitude to Sergio Mena de la Cruz for contributing
ideas, proofing the text and for his work on validating the grammar.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[I-D.eckert-intarea-flow-metadata-framework]
Eckert, T., Penno, R., Choukir, A., and C. Eckel, "A
Framework for Signaling Flow Characteristics between
Applications and the Network", draft-eckert-intarea-flow-
metadata-framework-00 (work in progress), July 2013.
[I-D.martinsen-mmusic-malice]
Penno, R., Martinsen, P., Wing, D., and A. Zamfir, "Meta-
data Attribute signaLling with ICE", draft-martinsen-
mmusic-malice-00 (work in progress), July 2013.
[I-D.wing-pcp-flowdata]
Wing, D., Penno, R., and T. Reddy, "PCP Flowdata Option",
draft-wing-pcp-flowdata-00 (work in progress), July 2013.
[ID-FMD-RSVP]
Eckert, et al. Expires January 10, 2014 [Page 17]
Internet-Draft Flow Metadata Encoding July 2013
Zamfir, A., "Signaling Flow Characteristics in RSVP",
2013, <http://www.ietf.org>.
Appendix A. Encoding usage examples
TBD
Authors' Addresses
Toerless Eckert (editor)
Cisco Systems, Inc.
San Jose
US
Email: eckert@cisco.com
Anca Zamfir
Cisco Systems, Inc.
Lausanne
CH
Email: ancaz@cisco.com
Amine Choukir
Cisco Systems, Inc.
Lausanne
CH
Email: amchouki@cisco.com
Charles Eckel
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
US
Email: eckelcu@cisco.com
Eckert, et al. Expires January 10, 2014 [Page 18]