<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced.
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.martinsen-mmusic-malice SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.martinsen-mmusic-malice.xml">
<!ENTITY I-D.wing-pcp-flowdata SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wing-pcp-flowdata.xml">
<!ENTITY I-D.eckert-intarea-flow-metadata-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.eckert-intarea-flow-metadata-framework.xml">
<!ENTITY I-D.zamfir-tsvwg-flow-metadata-rsvp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zamfir-tsvwg-flow-metadata-rsvp.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<?rfc autobreaks="yes"?>
<!-- Prevent automatic page break -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-choukir-tsvwg-flow-metadata-encoding-01"
     ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN"
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
         full title is longer than 39 characters -->

    <title abbrev="Flow Metadata Encoding">Protocol Independent Encoding for
    Signaling Flow Characteristics</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor-->

    <author fullname="Toerless Eckert" initials="T." role="editor"
            surname="Eckert">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street/>

          <!-- Reorder these if your country does things differently -->

          <city>San Jose</city>

          <region/>

          <code/>

          <country>US</country>
        </postal>

        <email>eckert@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Anca Zamfir" initials="A." surname="Zamfir">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street/>

          <!-- Reorder these if your country does things differently -->

          <city>Lausanne</city>

          <region/>

          <code/>

          <country>CH</country>
        </postal>

        <email>ancaz@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Amine Choukir" initials="A." surname="Choukir">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street/>

          <!-- Reorder these if your country does things differently -->

          <city>Lausanne</city>

          <region/>

          <code/>

          <country>CH</country>
        </postal>

        <email>amchouki@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Charles Eckel" initials="C." surname="Eckel">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

          <country>US</country>
        </postal>

        <email>eckelcu@cisco.com</email>
      </address>
    </author>

    <date/>

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
         in the current day for you. If only the current year is specified, xml2rfc will fill
         in the current day and month for you. If the year is not the current one, it is
         necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
         purpose of calculating the expiry date).  With drafts it is normally sufficient to
         specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.
         If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>metadata</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>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 <xref
      target="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.</t>

      <t><xref target="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.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>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 <xref
      target="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.</t>

      <t>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 <xref
      target="I-D.zamfir-tsvwg-flow-metadata-rsvp"/>, STUN <xref
      target="I-D.martinsen-mmusic-malice"/>, and PCP <xref
      target="I-D.wing-pcp-flowdata"/>). Different network deployments call
      for different protocols or combination of protocols as described in
      <xref target="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.</t>

      <t>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 can characterize data in
      the same direction as the flow (upstream) or in the opposite direction
      (downstream). The encoding mechanism enabling signaling for either or
      both directions. The metadata 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.</t>

      <section title="Requirements Language">
        <t>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 <xref
        target="RFC2119"/>.</t>
      </section>
    </section>

    <section title="Encoding Overview">
      <section title="General Principles">
        <t>This specification assumes that the flow is specified by the
        transport protocol which carries the metadata. 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 <xref
        target="I-D.martinsen-mmusic-malice"/>). In RSVP, the same is obtained
        from the SESSION and SENDER-TEMPLATE objects (see <xref
        target="I-D.zamfir-tsvwg-flow-metadata-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<xref
        target="I-D.wing-pcp-flowdata"/>).</t>

        <t>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.</t>

        <t>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.</t>
      </section>

      <section title="Encoding Goals">
        <t>The following goals have been considered in the design of the
        encoding:<list style="symbols">
            <t>Transport independence</t>

            <t>Allow for a standard namespace as well as vendor specific
            namespaces</t>

            <t>Support multiple producers of flow characteristics</t>

            <t>Ability to encode flow characteristics for both the flow itself
            (upstream) and the flow in the reverse direction (downstream).</t>

            <t>Ability to communicate flow characteristics from an application
            to the network as well as from the network back to the
            application</t>

            <t>Extensibility while allowing for backwards compatibility</t>

            <t>Flexibility</t>

            <t>Support for integrity, authentication and authorization on a
            per producer basis</t>

            <t>Compact encoding</t>
          </list></t>

        <section title="Transport independence">
          <t>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.</t>
        </section>

        <section title="Standard and Vendor Specific Namespaces">
          <t>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.</t>
        </section>

        <section title="Multiple Producers">
          <t>Multiple producers may contribute flow characteristics to the
          Flow Metadata information associated with a given flow.</t>

          <t>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.</t>
        </section>

        <section title="Upstream and Downstream">
          <t>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
          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.</t>
        </section>

        <section title="Application to Network and Network to Application">
          <t>In accordance with <xref
          target="I-D.eckert-intarea-flow-metadata-framework"/>, flow
          characteristics may be communicated 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.</t>
        </section>

        <section title="Extensibility">
          <t>New use cases and new deployment scenarios will require the use
          of new flow characteristics. For this reason the encoding should
          support new metadata (i.e. new information elements) in a backwards
          compatible way. New information element definitions supplement but
          do not redefine existing definitions. An application or a network
          node always signals its currently supported set of information
          elements and devices leverage the subset they understand for the
          purpose of applying treatment to, or gathering information about,
          the application flows.</t>
        </section>

        <section title="Flexibility">
          <t>Distinct use cases and individual applications have a need for
          different subsets of information elements. The encoding should
          support the signaling of any subset of information elements 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.</t>
        </section>

        <section title="Per Producer Security">
          <t>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.</t>

          <t>This specification defines an optional security element
          container; however, the actual security mechanism to be used is
          outside the scope of this specification.</t>
        </section>

        <section title="Compact Encoding">
          <t>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.</t>
        </section>
      </section>
    </section>

    <section title="Encoding specification">
      <section title="Layout">
        <t>This section describes the encoding layout proposed by this
        specification. It describes the following: <list style="symbols">
            <t>How the application and network producers coexist using
            sections in <xref target="encoding_section"/></t>

            <t>Application of an optional security token to a section in <xref
            target="encoding_security_token"/></t>

            <t>The division of a section into standard and vendor specific
            sub-sections in <xref target="encoding_section_content"/></t>

            <t>The division of a sub-section into upstream and downstream
            blocks in <xref target="encoding_subsection_content"/></t>

            <t>A full example using all the encoding building blocks in <xref
            target="encoding_layout"/></t>
          </list></t>

        <section title="Sections">
          <t>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.
          <xref target="encoding_section"/> shows an example that contains an
          application section and two network sections.</t>

          <figure align="center" anchor="encoding_section"
                  title="Encoding section">
            <artwork align="left">
+--------------------------------+
|      Application Section       |
+--------------------------------+
+--------------------------------+
|         Network-1 Marker       |
+--------------------------------+
+--------------------------------+
|                                |
|                                |
|         Network-1 Section      |
|                                |
+--------------------------------+
+--------------------------------+
|         Network-2 Marker       |
+--------------------------------+
+--------------------------------+
|                                |
|                                |
|         Network-2 Section      |
|                                |
|                                |
|                                |
+--------------------------------+
                    </artwork>
          </figure>
        </section>

        <section anchor="security_tokens" title="Security Tokens">
          <t>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.</t>

          <figure align="center" anchor="encoding_security_token"
                  title="Encoding security tokens">
            <artwork align="left">
+--------------------------------+
|         Security Token         |
+--------------------------------+
+--------------------------------+
|      Application Section       |
+--------------------------------+
+--------------------------------+
|         Network-1 Marker       |
+--------------------------------+
+--------------------------------+
|         Security Token N-1     |
+--------------------------------+
+--------------------------------+
|                                |
|                                |
|         Network-1 Section      |
|                                |
+--------------------------------+
+--------------------------------+
|         Network-2 Marker       |
+--------------------------------+
+--------------------------------+
|         Security Token N-2     |
+--------------------------------+
+--------------------------------+
|                                |
|                                |
|         Network-2 Section      |
|                                |
|                                |
|                                |
+--------------------------------+
                    </artwork>
          </figure>
        </section>

        <section title="Subsections">
          <t>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. <xref target="encoding_section_content"/> shows a
          sample section content.</t>

          <figure align="center" anchor="encoding_section_content"
                  title="Encoding subsections">
            <artwork align="left">
+--------------------------------+
|                                |
|                                |
|      Standard Subsection       |
|                                |
+--------------------------------+
+--------------------------------+
|         Vendor-1 Marker        |
+--------------------------------+
+--------------------------------+
|       Vendor-1 Subsection      |
|                                |
|                                |
|                                |
|                                |
|                                |
+--------------------------------+
+--------------------------------+
|         Vendor-2 Marker        |
+--------------------------------+
+--------------------------------+
|       Vendor-2 Subsection      |
|                                |
|                                |
|                                |
|                                |
|                                |
+--------------------------------+
                    </artwork>
          </figure>
        </section>

        <section title="Upstream and Downstream  Blocks">
          <t>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 representing an encoding of a specific
          information element. If the upstream and downstream blocks are both
          present, the upstream block MUST come first.</t>

          <figure align="center" anchor="encoding_subsection_content"
                  title="Encoding upstream and downstream blocks">
            <artwork align="left">
+--------------------------------+
|          Upstream block        |
| +------------+  +------------+ |
| |  MD tag    |  |  MD tag    | |
| +------------+  +------------+ |
+--------------------------------+
+--------------------------------+
|        Downstream block        |
| +------------+  +------------+ |
| |  MD tag    |  |  MD tag    | |
| +------------+  +------------+ |
+--------------------------------+
                    </artwork>
          </figure>

          <t/>
        </section>

        <section title="Complete Encoding Example">
          <t><xref target="encoding_layout"/> shows a complete example
          combining the application and network sections together with their
          standard and vendor sub-sections. The metadata tags appearing in a
          standard and in a vendor sub-section are managed by separate
          registries. See <xref
          target="I-D.eckert-intarea-flow-metadata-framework"/> for a full
          coverage of the information model and how the registries are
          handled.</t>

          <figure align="center" anchor="encoding_layout"
                  title="Complete encoding example">
            <artwork align="left">
+--------------------------------+
|         Security Token         |
+--------------------------------+
+--------------------------------+ ^  ^
|          Upstream block        | |  |A
| +------------+  +------------+ | |  |P
| |  MD tag    |  |  MD tag    | | |S |P
| +------------+  +------------+ | |T |L
+--------------------------------+ |D |I
+--------------------------------+ |  |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
                        </artwork>
          </figure>
        </section>

        <section title="Compact Encoding Example">
          <t><xref target="encoding_layout_compact"/> 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 <xref target="examples"/>.</t>

          <figure align="center" anchor="encoding_layout_compact"
                  title="Compact encoding example">
            <artwork align="left">
+--------------------------------+
|          Upstream block        |
| +------------+  +------------+ |
| |  MD tag    |  |  MD tag    | |
| +------------+  +------------+ |
+--------------------------------+
                        </artwork>
          </figure>
        </section>
      </section>

      <section title="Encoding Structures">
        <t>This section explores the encoding looking more closely at the
        encoding structures. <list>
            <t><xref target="encoding_ep_std_struct"/> shows the encoding used
            by an application using only standard metadata tags.</t>

            <t><xref target="encoding_ep_vnd_struct"/> shows the encoding used
            by an application using only vendor specific metadata tags.</t>

            <t><xref target="encoding_nt_std_struct"/> shows the encoding for
            network producers using only standard metadata tags.</t>
          </list>The three scenarios expose all the encoding structures. These
        structures may be combined in various ways to support other
        scenarios.</t>

        <t>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.</t>

        <t>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.</t>

        <t>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 encoding structures.
        The separation of the registries is possible as the metadata tags are
        part of the upstream and downstream block TLV value and therefore do
        not collide with the encoding structures.</t>

        <figure align="center" anchor="encoding_ep_std_struct">
          <artwork align="left">
 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
                        </artwork>
        </figure>

        <t><xref target="encoding_ep_vnd_struct"/> 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.</t>

        <figure align="center" anchor="encoding_ep_vnd_struct">
          <artwork align="left">
 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         |                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               :
:                       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
                        </artwork>
        </figure>

        <t><xref target="encoding_nt_std_struct"/> 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.</t>

        <figure align="center" anchor="encoding_nt_std_struct">
          <artwork align="left">
 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
|           Tag-type            |             Length            | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S
:                           Tag-value                           : |E
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C
:                            ...                                : |T
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I
|        Downstream-type        |             Length            | |O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N
|           Tag-type            |             Length            | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
:                           Tag-value                           : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
:                            ...                                : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
                        </artwork>
        </figure>

        <t>All the constructs above can be combined to signal standard and
        vendor specific metadata tags for different producers and allow to
        secure each producer's information independently.</t>
      </section>

      <section title="ABNF">
        <figure align="left" anchor="abnf">
          <artwork align="left">
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 metadata 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

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

Attribute-value = *(OCTET) ;

Zero = %x00
                        </artwork>
        </figure>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>A security token, as described in <xref target="security_tokens"/>,
      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.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>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.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->

      &RFC2119;
    </references>

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->

      &I-D.eckert-intarea-flow-metadata-framework;

      &I-D.martinsen-mmusic-malice;

      &I-D.wing-pcp-flowdata;

      &I-D.zamfir-tsvwg-flow-metadata-rsvp;

      <!-- A reference written by by an organization not a person. -->
    </references>

    <section anchor="examples" title="Encoding usage examples">
      <t>TBD</t>
    </section>
  </back>
</rfc>
