<?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 RFC4594 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4594.xml">
<!ENTITY RFC6759 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6759.xml">
<!ENTITY I-D.choukir-tsvwg-flow-metadata-encoding SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.choukir-tsvwg-flow-metadata-encoding.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">
<!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.penno-pcp-mobile-qos SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.penno-pcp-mobile-qos.xml">
<!ENTITY I-D.ietf-mmusic-traffic-class-for-sdp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-traffic-class-for-sdp.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 -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-eckert-intarea-flow-metadata-framework-02"
     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="Framework for Signaling Flow Characteristics">A Framework
    for Signaling Flow Characteristics between Applications and the
    Network</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="Reinaldo Penno" initials="R." surname="Penno">
      <organization>Cisco Systems, Inc.</organization>

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

          <city>San Jose</city>

          <region/>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <email>repenno@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>

        <!-- uri and facsimile elements may also be added -->
      </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 framework</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 provides a framework for communicating information
      elements (a.k.a. metadata) in a consistent manner between applications
      and the network to provide better visibility of application flows,
      thereby enabling differentiated treatment of those flows. These
      information elements can be conveyed using various signaling protocols,
      including PCP, RSVP, and STUN.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This document provides a framework for communicating information
      elements (a.k.a. metadata) in a consistent manner between applications
      and the network to provide better visibility of application flows,
      thereby enabling differentiated treatment of those flows. These
      information elements can be conveyed using various signaling protocols,
      including PCP, RSVP, and STUN.</t>

      <t>The framework is built around the definition of four key
      components:<list style="numbers">
          <t>A set of application independent information elements (IEs)</t>

          <t>An encoding of these IEs that is independent of the signaling
          protocol used as transport</t>

          <t>Usages of these IEs to support various transactional
          semantics</t>

          <t>A mapping of one of more to these usages to an initial set of
          signaling protocols, including PCP, RSVP, and STUN</t>
        </list></t>

      <t>This document defines an initial set of IEs, a set of encoding rules,
      and initial usage model. The actual encoding is defined in <xref
      target="I-D.choukir-tsvwg-flow-metadata-encoding"/>. Additional
      documents define the mapping to specific signaling protocols (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"/>)</t>
    </section>

    <section title="Background">
      <t>This section provides background on the motivation for the
      framework.</t>

      <t>Identification and treatment of application flows are critical for
      the successful deployment and operation of applications based on a wide
      range of signaling protocols. Historically, this functionality has been
      accomplished to the extent possible using heuristics, which inspect and
      infer flow characteristics.</t>

      <t>Heuristics may be based on port ranges, IP subnetting, or deep packet
      inspection (DPI), e.g. application level gateway (ALG). Port based
      solutions suffer from port overloading and inconsistent port usage. IP
      subnetting solutions are error prone and result in network management
      hassle. DPI is computationally expensive and becomes a challenge with
      the wider adoption of encrypted signaling and secured traffic. An
      additional drawback of DPI is that the resulting insights are not
      available, or need to be recomputed, at network nodes further down the
      application flow path.</t>

      <t>The proposed solution allows applications to explicitly signal their
      flow characteristics to the network. It also provides network nodes with
      visibility of the application flow characteristics and enables them to
      contribute to the flow description. The resulting flow description may
      be communicated as feedback from the network to applications.</t>

      <t>The proposed solution does not enhance existing heuristic based
      mechanisms, nor does it preclude the use of such mechansims. Rather, it
      proposes a new mechanism that does not suffer the drawbacks of heuristic
      based mechanisms.</t>

      <section title="Deep packet inspection">
        <section title="Benefits">
          <t>Deep Packet Inspection (DPI) and other traffic observation
          methods (such as performance monitoring) are successfully being used
          for two type of workflows: <list counter="1" style="numbers">
              <t>Provide network operators with visibility into traffic for
              troubleshooting, capacity planning, accounting and billing and
              other off network workflows. This is done by exporting observed
              traffic analysis via protocol such as IPFIX and SNMP.</t>

              <t>Provide differentiated network services for the traffic
              according to network operator defined rule sets, including
              policing and shaping of traffic, providing admission control,
              impacting routing, permitting passage of traffic (e.g. firewall
              functions), etc.</t>
            </list>Note: For the context of this document, we consider that
          DPI starts as early into packets as using ACLs with UDP/TCP port
          numbers to classify traffic.</t>
        </section>

        <section title="Limitation">
          <t>These two workflows, visibility and differentiated network
          services, are critical in many networks. However, their reliance on
          inspection and observation limits the ability to enable these
          workflows more widely.<list style="symbols">
              <t>Simple observation based classification, especially ones
              relying on TCP/UDP, ports often result in incorrect results due
              to port overloading (i.e. ports used by applications other than
              those claiming the port with IANA).</t>

              <t>More and more traffic is encrypted, rendering deep packet
              inspection impossible or much more complex (e.g. needing to
              share encryption keys with network equipment).</t>

              <t>Observation generally requires inspecting the control and
              signaling traffic of applications. This traffic may flow through
              a different network path than the actual application data
              traffic. Impacting the traffic behavior is ineffective in those
              scenarios.</t>

              <t>Observation of control, signaling and data traffic with DPI
              will in general result in less insight into the applications
              intent than if the application was explicitly signaling its
              intent to the network.</t>

              <t>Without explicit desire by the application to signal its
              intent to the network, it will also not consider to explicitly
              provide authentication to the network. DPI mechanism have a more
              difficult job in analyzing application traffic when
              authentication mechanisms are in use (if they even can)</t>

              <t>Without explicit involvement of the application, network
              services leveraging DPI traffic classification impact the
              application behavior by impacting its traffic, but cannot
              provide explicit feedback to the application in the form of
              signaling.</t>
            </list></t>
        </section>
      </section>

      <section title="Explicit signaling methods">
        <t>There are a variety of existing and evolving signaling options that
        can provide explicit application to network signaling and serve the
        visibility and differentiated network services workflows where DPI is
        currently being used. It seems clear that there will be no single
        one-protocol-fits-all solution. Every protocol is currently defined in
        its own silo, creating duplicate or inconsistent information models.
        This results in duplicate work, more operational complexity and an
        inability to easily convert information between protocols to easily
        leverage the best protocol option for each specific use case. Examples
        of existing signaling options include the following:<list
            style="symbols">
            <t>RSVP is the original on path signaling protocol standardized by
            the IETF. It operates on path out-of-band and could support any
            transport protocol traffic (it currently supports TCP and UDP).
            Its original goal was to provide admission control. Arguably, its
            success was impacted by its reliance on router-alert because this
            often leads to RSVP packets being filtered by intervening
            networks. To date, more lightweight signaling workflows utilizing
            RSVP have not been standardized within the IETF.</t>

            <t>NSIS (next Steps in Signaling) is the next iteration of
            RSVP-like signaling defined by the IETF. Because it focused on the
            same fundamental workflow as RSVP admission control as its main
            driver, and because it did not provide significant enough use-case
            benefits over RSVP, it has seen even less adoption than RSVP.</t>

            <t>STUN is an on path, in-band signaling protocol that could
            easily be extended to provide signaling to on path network devices
            because it provides an easily inspected packet signature, at least
            for transport protocols such as UDP and SCTP. Through its
            extensions TURN and ICE, it is becoming quite popular in
            application signaling driven by the initial use-case of
            automatically opening up firewall pinholes and determining the
            best local and remote addresses for peer-to-peer connectivity
            (ICE).</t>

            <t>PCP is a protocol designed to support use cases similar to UPnP
            firewall traversal. It also can easily be extended to provide more
            generic application to network signaling for traffic flows. Unlike
            the prior protocols, it is not meant to be used on path end-to-end
            but rather independently on one "edge" of a traffic flow. It is
            therefore an attractive alternative (albeit with challenges under
            path redundancy) because it allows the introduction of application
            to network signaling without relying on the remote peer. This is
            especially useful in multi-domain communications.</t>

            <t>In addition to these, depending on the devices where it is
            performed, different degrees of DPI may be used to achieve
            explicit signaling. For example, inspection of HTTP connections is
            often viable in high-touch network devices. Such inspection may
            provide explicit signaling if the application purposely keeps or
            inserts information elements that are meant to be signaled to the
            network in the clear, or knowingly uses an encryption scheme
            shared with the network.</t>
          </list></t>

        <t>Rather than encourage independent, protocol specific solutions to
        this problem, this document provides a protocol and application
        independent framework that can be applied in a consistent fashion
        across the various protocols.</t>
      </section>
    </section>

    <section title="Proposed framework">
      <section title="Overview">
        <t>The proposed framework includes the following elements:</t>

        <section title="Common, application independent, IPFIX registered, information elements">
          <t>An application media flow may be expressed as a set of
          information elements that are defined and registered like
          observation-based IPFIX attributes. We propose leveraging IPFIX as
          the information model (not necessarily as the transport signaling)
          for the following reasons:<list style="symbols">
              <t>As outlined above, export of traffic information is one of
              the two big workflows. IPFIX is arguably the most flexible,
              extensible and best defined option for this. Leveraging the same
              information model for flow characteristics facilitates export of
              this information via IPFIX.</t>

              <t>IPFIX allows for IETF/IANA standardized information elements,
              but also for unambiguous vendor-defined attributes by including
              the so-called PEN (Private Enterprise Number) into the
              information element type. Note that IPFIX has ongoing work to
              better disseminate vendor specific registration of attributes.
              The framework defined here expects to be able to leverage the
              output of that work.</t>
            </list></t>
        </section>

        <section title="Cross-protocol information element encoding rules">
          <t>The majority of the protocols listed previously (RSVP, NSIS,
          STUN/ICE, PCP) require (or favor) compact binary encoding of
          information elements. This is natively supported by the information
          element registration of IPFIX.</t>

          <t>The IPFIX registry defines each information element's data-type,
          and there is a native binary network encoding for each of these
          types. At a minimum, every protocol leveraging common information
          elements would need to use an encoding that identifies the
          information element's PEN and IE-ID, and that leverages network
          standard binary encoding of the value including the length of the
          value. Including the length of the value into the encoding is
          required for extensibility because otherwise new information
          elements could not be introduced without first having all network
          devices know the data-type, and therefore the length, of the
          information element. Leveraging network standard binary encoding is
          equally important to permit network elements to propagate
          information elements from one protocol to another protocol without
          understanding the information elements data-type.</t>

          <t>In protocols that are not constrained to binary encoding, it is
          nevertheless highly desirable to include the equivalent information
          and therefore permit propagation between binary and non-binary
          transport of information elements without having to understand all
          information elements.</t>
        </section>

        <section title="Anticipated Usage Models">
          <t>The signaling of information elements may be from application to
          the network or from network to application. When signaled within a
          given protocol, the information elements may be interpreted
          independently of that protocol, or it may be used in combination
          with the given protocol.</t>

          <section title="Informational">
            <t>The most simplistic usage model is one in which applications
            signal information elements describing their anticipated or
            existing flows into the network along the path of those flows
            without expecting or requiring anything back from the network.
            Network elements along the flow path may or may not do something
            with this information.</t>

            <t>This "informational" usage model enables network elements along
            the path to support the workflows traditionally performed via DPI
            mechanisms, as described previously.</t>
          </section>

          <section title="Advisory">
            <t>This usage model extends the "informational" usage in that the
            application expects or requests some information back from the
            network. With this usage, the same information elements apply and
            may be communicated by the application into the network, but the
            application indicates its interest in receiving some feedback.</t>

            <t>Default values are defined for each information element to
            unambiguously support cases in which an application does not have
            a valid value to communicate with the network; rather, it wants
            the network to provide a value back to it in response. In essence,
            this allows an application to ask a question and receive an answer
            from the network. Of course, a network element may provide similar
            feedback for cases in which an application communicated a
            non-default value as well. Network elements may also provide
            unsolicited advisory feedback.</t>

            <t>In all cases, applications are not guaranteed to receive an
            answer or any specific service from the network. In the event an
            answer is provided, that answer is similarly not a guarantee of
            any specific service or treatment by the network. It is to be
            interpreted as advisory only.</t>

            <t>As mentioned previously, the same information elements are used
            in the signaling from the application to the network as well as
            from the network to the application. The underlying transport
            protocol used to carry the information elements is expected to
            provide the necessary request/response semantics or some other
            mechanism by which the communication in both directions can be
            tied together.</t>
          </section>

          <section title="Service Request">
            <t>This usage model extends the "advisory" usage to operate as an
            explicit service request. Unlike the advisory usage, information
            elements signalled by the application are interpreted by network
            elements within the context of a service request, and information
            elements signalled by the network back to the application are
            interpreted within the context of a response to that request.</t>

            <t>As with the advisory usage, the same information elements are
            used in the signaling from the application to the network as well
            as from the network to the application. The underlying transport
            protocol used to carry the information elements is expected to
            provide the necessary service request/response semantics.</t>
          </section>
        </section>

        <section title="Considerations for signaling of common information elements">
          <section title="Proxy originated information">
            <t>The goal of this framework is to enable applications to
            explicitly signal common information elements about their traffic
            flows and optionally receive common information elements from the
            network as feedback. Nevertheless, it is clear that broad adoption
            of such technology is improved by enabling the use of proxies. The
            proxies can provide or amend the flow description information in
            the absence of Flow Metadata support by the application
            itself.</t>
          </section>

          <section title="Authentication">
            <t>Common information elements should provide for cryptographic
            authentication by the sender. In general the authentication
            provides some form of identification of the sender and proves that
            the common information elements covered by the authentication were
            originated from, or approved by, that identity.</t>
          </section>

          <section title="Common encoding">
            <t>A companion document <xref
            target="I-D.choukir-tsvwg-flow-metadata-encoding"/> covers
            recommended encoding rules that take the following aspects into
            account:<list style="symbols">
                <t>Compact binary encoding rules</t>

                <t>Signaling for both sent and received traffic flows</t>

                <t>Signaling of standard and vendor specific information
                elements</t>

                <t>Minimizes protocol specific definition required to add
                informational or advisory common information elements into
                existing transactions</t>

                <t>Signaling of feedback from the network</t>

                <t>Identification of originator to support proxies and
                facilitate mitigation between common information elements from
                different originators</t>

                <t>Signaling of authenticators</t>
              </list></t>
          </section>

          <section title="Usage Model to Protocol integration">
            <t>There is a range of options for how this framework is
            integrated with a particular transport protocol. We describe two
            examples we consider useful:</t>

            <section title="Common transport informative integration">
              <t><list counter="1" style="numbers">
                  <t>A transport protocol signaling method is defined to carry
                  the common encoded information elements at least in
                  signaling from application to network.</t>

                  <t>If the transport by itself does not already have a
                  mechanism to indicate a purely informative protocol
                  transaction, then a protocol specific indication for this is
                  added.</t>
                </list></t>

              <t>In result, this integration achieves two option: <list
                  counter="1" style="numbers">
                  <t>Informative common information elements can be sent from
                  application to network by using the protocol's method to
                  indicate the purely informational protocol transaction. This
                  option effectively leverages the protocol as transport for
                  additional informative attribute based services without
                  impacting the services and transactions of the protocol
                  otherwise.</t>

                  <t>Informative common information elements can be sent
                  alongside an existing protocol transaction. In this case
                  they may either be ships in the night (triggering
                  informative attribute based services), or they may
                  additionally be used by the policy rules of the protocol
                  transaction itself which could be advisory or service
                  request. All feedback of the transaction would still rely on
                  protocol specific information element (common information
                  elements only used from host to network).</t>
                </list></t>

              <t>This integration is for example defined in <xref
              target="I-D.wing-pcp-flowdata"/>, <xref
              target="I-D.zamfir-tsvwg-flow-metadata-rsvp"/>, and <xref
              target="I-D.martinsen-mmusic-malice"/>.</t>
            </section>

            <section title="Common transport advisory integration">
              <t>In addition to the common transport informative integration,
              the transport encoding is extended to carry the common transport
              information element in feedback messages from the network to the
              host/application. The method to indicate informative only
              transaction, when sending to the network is used to indicate
              advisory only transaction when signaling from the network.</t>

              <t>This option primarily enables informative and advisory usage
              models, but it can equally interact with pre-existing
              service-request options of the transport protocol and impact
              advisory feedback or the service request itself based on that
              interaction.</t>
            </section>
          </section>
        </section>
      </section>

      <section title="Proposed common information elements">
        <t>The section defines an initial set of common information elements.
        These information elements are intended to be added to the set of IANA
        standardized information elements either by this or associated
        documents. Additional documents are expected to define additional
        attributes that can use either IANA or other vendor-PEN.</t>

        <t>All information element definition must include the following:<list
            counter="1" style="numbers">
            <t>Default value to be provided by an application when it does not
            have an informative value to provide to the network, but is
            interested in receiving an advisory value of the attribute from
            the network. If no advisory feedback is requested, and no
            informative value is known, the attribute may simply not be
            sent.</t>

            <t>Conflict resolution in the presence of different values for the
            same information element (e.g. two peers signaling information
            elements for both the upstream and downstream direction of a flow
            include different values for the information element)</t>
          </list></t>

        <section title="Bandwidth Attributes">
          <section title="Maximum Bandwidth">
            <t>This attribute is used to convey the maximum sustained
            bandwidth for the flow. It is an unsigned 64 bit value and is
            specified in bits per second.</t>

            <t>Default Value: 0</t>

            <t>Conflict Resolution: Minimum for the set of non-default
            values</t>
          </section>

          <section title="Minimum Bandwidth">
            <t>This attribute is used to convey the minimum sustained
            bandwidth for the flow. It is an unsigned 64 bit value and is
            specified in bits per second. Not sending the Minimum Bandwidth is
            equivalent to sending the same value as for Maximum Bandwidth.</t>

            <t>Default Value: 0</t>

            <t>Conflict Resolution: Minimum of the set of non-default
            values</t>
          </section>

          <section title="Bandwidth Pool">
            <t>This attribute is used to convey that the traffic dynamically
            shares bandwidth with other traffic using the same Bandwidth Pool.
            Variable length GUID (Global Unique ID) of at least 48 bits. The
            Maximum Bandwidth used by the pool is the largest Maximum
            Bandwidth indicated by any member, the Minimum Bandwidth of the
            Pool is the largest Minimum Bandwidth indicated by any member.</t>
          </section>
        </section>

        <section title="Traffic Class Attributes">
          <section title="RFC4594-DSCP">
            <t>This attribute is used to convey the DSCP value appropriate for
            the flow. It is an unsigned 8 bit value. Values signaled are
            assumed to be in compliance with <xref target="RFC4594"/> or
            backward compatible extensions thereof. Other values are
            undefined.</t>

            <t>Default Value: 0xff</t>

            <t>Conflict Resolution: tbd</t>
          </section>

          <section title="Traffic Class Label (TCL)">
            <t>The data type of this information element is a string. It
            carries the Traffic Class Label defined in <xref
            target="I-D.ietf-mmusic-traffic-class-for-sdp"/>. Depending on the
            outcome of that drafts standardization, the version carried as an
            information element may be slightly expanded over the its
            definition for SDP. The TCL is a structured string of the
            form:</t>

            <t>&lt;category&gt;.&lt;application&gt;(.adjective)(.adjective)</t>

            <t>category and application provide a base categorization of the
            traffic class that attempts to provide a simplified and
            extensible, framework for the traffic class definitions in <xref
            target="RFC4594"/>. These base classifications can be refined with
            zero or more adjectives. Examples of a TCL is
            "conversational.video.avconf".</t>

            <t>Default Value: Empty string</t>

            <t>Conflict Resolution: tbd</t>
          </section>
        </section>

        <section title="Acceptable Path Attributes">
          <t>The following set of attributes deal with tolerance to various
          path impairments. A discrete and ordered set of values is defined
          for each. This way the values are applicable on a per hop basis as
          well as end to end. The values may be mapped to relevant metrics
          within a given network, such as the mapping of delay tolerance and
          loss tolerance to QCI values as defined in <xref
          target="I-D.penno-pcp-mobile-qos"/></t>

          <section title="Delay Tolerance">
            <t>This attribute is used to convey the delay tolerance of an
            application with respect to the associated flow. When provided by
            a network element, it indicates the delay tolerance expected of
            the application with respect to the associated flow. It is a 3 bit
            field for which values are assigned as follows:</t>

            <t>0 = no information available</t>

            <t>1 = very low</t>

            <t>2 = low</t>

            <t>3 = medium</t>

            <t>4 = high</t>

            <t>5-7: reserved</t>

            <t>Default Value: 0</t>

            <t>Conflict Resolution: For application to network, the most
            strict of non-default values. For network to application, the
            least strict of the set of non-default values.</t>
          </section>

          <section title="Loss Tolerance">
            <t>This attribute is used to convey the loss tolerance of an
            application with respect to the associated flow. When provided by
            a network element, it indicates the loss tolerance expected of the
            application with respect to the associated flow. It is a 3 bit
            field for which values are assigned as follows:</t>

            <t>0 = no information available</t>

            <t>1 = very low</t>

            <t>2 = low</t>

            <t>3 = medium</t>

            <t>4 = high</t>

            <t>5-7: reserved</t>

            <t>Default Value: 0</t>

            <t>Conflict Resolution: For application to network, the most
            strict of non-default values. For network to application, the
            least strict of the set of non-default values.</t>
          </section>

          <section title="Jitter Tolerance">
            <t>This attribute is used to convey the jitter tolerance of an
            application with respect to the associated flow. When provided by
            a network element, it indicates the jitter tolerance expected of
            the application with respect to the associated flow. It is a 3 bit
            field for which values are assigned as follows:</t>

            <t>0 = no information available</t>

            <t>1 = very low</t>

            <t>2 = low</t>

            <t>3 = medium</t>

            <t>4 = high</t>

            <t>5-7: reserved</t>

            <t>Default Value: 0</t>

            <t>Conflict Resolution: For application to network, the most
            strict of non-default values. For network to application, the
            least strict of the set of non-default values.</t>
          </section>
        </section>

        <section title="Application Identification">
          <t>Application identification is clearly one of the more difficult
          classification goals. The proposals included here are as of yet not
          widely vetted:</t>

          <section title="RFC 6759 style application identification">
            <t><xref target="RFC6759"/> defines the IPFIX IE-IDs that permit
            both IANA and vendor specific application identification. Though
            defined for observation (a.k.a.: DPI), it could also be used with
            explicit signaling from applications.</t>

            <t>Applications that use one of the protocols for which there is
            an IANA port allocation could explicitly indicate this port via
            the IANA-L4 engine-id in their application to network signaling.
            This would identify the application even if the application is not
            using the IANA assigned port for it. This covers cases in which
            applications use ports other than registered, such as HTTP servers
            running on other than 80, or when ports get mapped due to PAT.</t>

            <t>To avoid collision with DPI exported IANA-L4 classification, it
            is necessary to assign a new engine-id for application-self
            assigned IANA-L4 classification (e.g. new engine-id for
            IANA-L4-SELF-ASSIGNED). If an application vendor has a PEN, the
            application can use a PANA-L7-PEN classification with the PEN of
            the originating application vendor. Likewise, if applications are
            in general made available via "market" type reseller mechanism
            (common in mobile device applications), then the application
            vendor could request an application identification from the market
            owner and leverage the market owners PEN.</t>
          </section>

          <section title="URL style application identification">
            <t>One problem with <xref target="RFC6759"/> style application
            identification especially non-IANA registered ones is the
            complexity in making all network elements learn the semantic of
            the numeric encoding of e.g. the PANA-L7-PEN information element
            in signaling protocols that only use the numeric encoding of
            information elements. The second problem may be to determine what
            PEN to use, because not every developer of an application may be a
            company that has a PEN or otherwise would intend to apply for one.
            Application identification via a URL encoded string information
            element is a way to overcome both issues. Today, almost all
            applications have some DNS domain associated with them through
            which they are being marketed or that belongs to the company
            developing the application. Therefore, one simple form of self
            assigned application identification is a new IPFIX information
            element: UrlAppId. The value of this information element is an
            abbreviated URL of the following form:</t>

            <t>&lt;fqdn&gt; / &lt;app-name&gt; /[ &lt;version&gt; |
            &lt;other-details&gt; ]</t>

            <t>The idea is that the owner of &lt;fqdn&gt; (fully qualified
            domain name) is assigning an &lt;app-name&gt;, and by signaling
            both &lt;domain-name&gt; and &lt;app-name&gt;, this information
            element provides a self-identifying, unambiguous application
            identification.</t>

            <t>Example:</t>

            <t>example.com/network-lemmings/sdn-edition</t>

            <t>A game publishing house or application market operator with the
            domain name example.com is initially allocating the UrlAppId
            example.com/network-lemmings to that application. After 35 years,
            a new variant of the game is released, the SDN edition, and the
            app-developer decides that it would best like to distinguish this
            application variant by the above UrlAppId
            example.com/network-lemmings/sdn-edition.</t>

            <t>In general, different traffic flows within a single application
            should best not be distinguished via the UrlAppId, but instead
            rely on attributes more specifically targeted for that purpose
            (such as the TrafficClassLabel). If there is no adequate better
            attribute defined, application developers may choose to use the
            other-details section of the UrlAppId to distinguish flows within
            the same application.</t>

            <t>Formally, the only requirement against the UrlAppId is that the
            fqdn part is a DNS domain owned by the assigner, and that the rest
            of the string after the first / is as self explanatory as
            possible.</t>

            <t>It should be noted that in the context of DPI, classification
            of web-based application traffic is very often performed by URL
            inspection of HTTP traffic. This proposed intent based information
            element leverages that model and makes it usable where it can not
            be currently used with just DPI: encrypted HTTP, non-HTTP
            applications, HTTP applications with non-descriptive URLs,
            etc.</t>
          </section>
        </section>
      </section>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Dan Wing, Anca Zamfir, Paul Jones,
      and Tirumaleswar Reddy for their valuable contributions to this
      document.</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="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->

      &RFC4594;

      &RFC6759;

      &I-D.choukir-tsvwg-flow-metadata-encoding;

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

      &I-D.martinsen-mmusic-malice;

      &I-D.wing-pcp-flowdata;

      &I-D.penno-pcp-mobile-qos;

      &I-D.ietf-mmusic-traffic-class-for-sdp;

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

    <!-- Change Log

v00 2006-03-15  EBD   Initial version

v01 2006-04-03  EBD   Moved PI location back to position 1 -
                      v3.1 of XMLmind is better with them at this location.
v02 2007-03-07  AH    removed extraneous nested_list attribute,
                      other minor corrections
v03 2007-03-09  EBD   Added comments on null IANA sections and fixed heading capitalization.
                      Modified comments around figure to reflect non-implementation of
                      figure indent control.  Put in reference using anchor="DOMINATION".
                      Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH     Major changes: shortened discussion of PIs,
                      added discussion of rfc include.
v05 2007-03-10 EBD    Added preamble to C program example to tell about ABNF and alternative
                      images. Removed meta-characters from comments (causes problems).  -->
  </back>
</rfc>
