<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="info" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-mymb-sfc-nsh-allocation-timestamp-12"
     ipr="trust200902"> number="9192" ipr="trust200902" obsoletes="" updates="" submissionType="independent" category="info" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.12.0 -->
  <front>
    <title abbrev="NSH Timestamp">Network Service Header (NSH) Fixed-Length
    Context Header Allocation: Timestamp</title> Allocation</title>
    <seriesInfo name="RFC" value="9192"/>
    <author fullname="Tal Mizrahi" initials="T." surname="Mizrahi">
      <organization abbrev="">Huawei</organization>
      <address>
        <postal>
          <street/>

          <city/>

          <code/>
          <country>Israel</country>
        </postal>
        <email>tal.mizrahi.phd@gmail.com</email>
      </address>
    </author>
    <author fullname="Ilan Yerushalmi" initials="I.Y." initials="I." surname="Yerushalmi">
      <organization>Marvell</organization>
      <address>
        <postal>
          <street>6 Hamada</street>

          <!-- Reorder these if your country does things differently -->
          <city>Yokneam</city>
          <code>2066721</code>
          <country>Israel</country>
        </postal>
        <email>yilan@marvell.com</email>
      </address>
    </author>
    <author fullname="David Melman" initials="D.M." initials="D." surname="Melman">
      <organization>Marvell</organization>
      <address>
        <postal>
          <street>6 Hamada</street>

          <!-- Reorder these if your country does things differently -->
          <city>Yokneam</city>
          <code>2066721</code>
          <country>Israel</country>
        </postal>
        <email>davidme@marvell.com</email>
      </address>
    </author>
    <author fullname="Rory Browne" initials="R.B." initials="R." surname="Browne">
      <organization>Intel</organization>
      <address>
        <postal>
          <street>Dromore House</street>

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

          <city>Shannon, Co.Clare</city>
          <city>Shannon</city>
          <region>Co. Clare</region>
          <country>Ireland</country>
        </postal>
        <email>rory.browne@intel.com</email>
      </address>
    </author>
    <date year="2021"/> year="2022" month="February" />
    <area>General</area>
    <workgroup>Network Working Group</workgroup>

    <keyword>NSH, Context Header, timestamp</keyword>
    <keyword>NSH</keyword>
    <keyword>Context Header</keyword>
    <keyword>timestamp</keyword>

    <abstract>
      <t>The Network Service Header (NSH) specification defines two possible
      methods of including metadata (MD): MD Type 0x1 and MD Type 0x2. MD Type
      0x1 uses a fixed-length Context Header. The allocation of this Context
      Header, i.e., its structure and semantics, has not been standardized.
      This memo presents an allocation for defines the fixed Timestamp Context Headers of NSH, Header, which is an
      NSH fixed-length Context Header that incorporates the packet's
      timestamp, a sequence number, and a source interface identifier.</t>

      <t>Although the allocation that is definition of the Context Header presented
      in this document has not been standardized by the IETF IETF, it has been
      implemented in silicon by several manufacturers and is published
      here to allow other interoperable
      implementations and to facilitate debugging if it is seen in the
      network.</t> interoperability.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Network Service Header (NSH), defined in <xref
      target="RFC8300"/>, target="RFC8300" format="default"/>,
      is an encapsulation header that is used as the
      service encapsulation in the Service Function Chains Chaining (SFC) architecture
      <xref target="RFC7665"/>.</t> target="RFC7665" format="default"/>.</t>
      <t>In order to share metadata (MD) along a service path, the NSH
      specification <xref target="RFC8300"/> target="RFC8300" format="default"/> supports two methods: a
      fixed-length Context Header (MD Type 0x1) and a variable-length Context
      Header (MD Type 0x2). When using MD Type 0x1 0x1, the NSH includes 16 octets
      of Context Header fields.</t>
      <t>The NSH specification <xref target="RFC8300"/> target="RFC8300" format="default"/> has not defined the
      semantics of the 16-octet Context Header, nor how does it specify how the Context Header is used by
      NSH-aware service functions, SFFs Service Functions (SFs), Service Function Forwarders (SFFs), and proxies. Several context header Context Header
      formats are defined in <xref target="I-D.ietf-sfc-nsh-tlv"/>. target="NSH-TLV" format="default"/>.
      Furthermore, some allocation schemes were proposed in the past to
      acoommodate
      accommodate specific use cases, e.g., <xref
      target="I-D.ietf-sfc-nsh-dc-allocation"/>, target="NSH-DC-ALLOC"/>,
      <xref
      target="I-D.ietf-sfc-nsh-broadband-allocation"/>, target="I-D.ietf-sfc-nsh-broadband-allocation" format="default"/>,
      and <xref
      target="RFC8592"/>.</t> target="RFC8592" format="default"/>.</t>
      <t>This memo presents an allocation for the MD Type 0x1 Context Header,
      which incorporates the timestamp of the packet, a sequence number, and a
      source interface identifier. It is noted Note that other allocation schema for MD Type 0x1
      allocations
      might be specified in the future.  Although MD Type 0x1
      allocations such schema are currently not being
      standardized by the SFC working
      group, Working Group, a consistent format (allocation) (allocation schema)
      should be used in an SFC-enabled domain in order to allow interoperability.</t>
      <t>In a nutshell, packets that enter the SFC-enabled domain are
      timestamped by a Classifier classifier <xref target="RFC7665"/>. target="RFC7665" format="default"/>. Thus, the
      timestamp, sequence number number, and source interface are incorporated in the
      NSH Context Header. As defined discussed in <xref target="RFC8300"/>, target="RFC8300" format="default"/>, if
      reclassification is used, it may result in an update to the NSH
      metadata. Specifically, when the Timestamp Context Header is used, a
      reclassifier may either leave it unchanged, unchanged or update the three fields:
      timestamp, sequence number
      Timestamp, Sequence Number, and source interface.</t> Source Interface.</t>
      <t>The Timestamp Context Header includes three fields that may be used
      for various purposes. The timestamp Timestamp field may be used for logging,
      troubleshooting, delay measurement, packet marking for performance
      monitoring, and timestamp-based policies. The source interface
      identifier indicates the interface through which the packet was received
      at the classifier. This identifier may specify a physical interface or a virtual
      interface. The sequence numbers can be used by Service Functions (SFs) SFs
      to detect out-of-order delivery or duplicate transmissions. Note that
      out-of-order and duplicate packet detection is possible when packets are
      received by the same SF, SF but is not necessarily possible when there are
      multiple instances of the same SF and multiple packets are spread across
      different instances of the SF. The sequence number is maintained on a
      per-source-interface basis.</t>
      <t>This document presents the Timestamp Context Header, Header but does not
      specify the functionality of the SFs that receive the Context Header.
      Although a few possible use cases are described in the this document, the SF
      behavior and application are outside the scope of this document.</t>

      <t>KPI-stamping
      <t>Key Performance Indicator (KPI) stamping <xref target="RFC8592"/> target="RFC8592" format="default"/> defines an NSH timestamping
      mechanism that uses the MD Type 0x2 format. The current This memo defines a
      compact MD Type 0x1 Context Header that does not require the packet to
      be extended beyond the NSH header. NSH. Furthermore, the mechanisms of described in
      <xref
      target="RFC8592"/> target="RFC8592" format="default"/> and of this memo can be used in concert, as further
      discussed in <xref target="SecAnalytics"/>.</t> target="SecAnalytics" format="default"/>.</t>
      <t>Although the allocation that is definition of the Context Header presented
      in this document has not been standardized by the IETF IETF, it has been
      implemented in silicon by several manufacturers and is published
      here to allow other interoperable
      implementations and to facilitate debugging if it is seen in the
      network.</t> interoperability.</t>
    </section>
    <section title="Terminology"> numbered="true" toc="default">
      <name>Terminology</name>
      <section title="Requirements Language"> numbered="true" toc="default">
        <name>Requirements Language</name>
         <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
         "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
         "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
         "<bcp14>SHOULD NOT</bcp14>",
         "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
         "<bcp14>MAY</bcp14>", and
        "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
         are to be interpreted as described in BCP
        14 BCP&nbsp;14
         <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
         when, they appear in all capitals, as shown here.</t>
      </section>
      <section title="Abbreviations"> numbered="true" toc="default">
        <name>Abbreviations</name>
        <t>The following abbreviations are used in this document: <list
            hangIndent="14" style="hanging">
            <t hangText="KPI">Key </t>
        <dl newline="false" spacing="normal" indent="14">
          <dt>KPI</dt>
          <dd>Key Performance Indicators Indicator <xref
            target="RFC8592"/></t>

            <t hangText="NSH">Network target="RFC8592" format="default"/></dd>
          <dt>MD</dt>
          <dd>Metadata <xref target="RFC8300" format="default"/></dd>
          <dt>NSH</dt>
          <dd>Network Service Header <xref
            target="RFC8300"/></t>

            <t hangText="MD">Metadata <xref target="RFC8300"/></t>

            <t hangText="SF">Service target="RFC8300" format="default"/></dd>
          <dt>SF</dt>
          <dd>Service Function <xref target="RFC7665"/></t>

            <t hangText="SFC">Service target="RFC7665" format="default"/></dd>
          <dt>SFC</dt>
          <dd>Service Function Chaining <xref
            target="RFC7665"/></t>
          </list></t> target="RFC7665" format="default"/></dd>
          <dt>SFF</dt>
          <dd>Service Function Forwarder <xref target="RFC8300"/></dd>
        </dl>
      </section>
    </section>
    <section anchor="allocation"
             title="NSH numbered="true" toc="default">
      <name>NSH Timestamp Context Header Allocation"> Allocation</name>
      <t>This memo defines the following fixed-length Context Header
      allocation, as presented in <xref target="AllocationFormat"/>.</t> target="AllocationFormat" format="default"/>.</t>
      <figure align="center" anchor="AllocationFormat"
              title="NSH anchor="AllocationFormat">
        <name>NSH Timestamp Allocation."> Allocation</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Source Interface                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Timestamp                           |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ]]></artwork>
      </figure>

      <!-- This PI places the pagebreak correctly (before the section title) in the text output. -->

      <?rfc needLines="8" ?>

      <t>The NSH Timestamp Allocation that is allocation defined in this memo MUST <bcp14>MUST</bcp14>
      include the following fields:</t>

      <t><list style="symbols">
          <t>Sequence Number - a
      <dl spacing="normal">
        <dt>Sequence Number:</dt><dd>A 32-bit sequence number. The sequence number
          is maintained on a per-source-interface basis. Sequence numbers can
          be used by SFs to detect out-of-order delivery, delivery or duplicate
          transmissions. The Classifier classifier increments the sequence number by 1
          for each packet received through the source interface. This requires
          the classifier to maintain a per-source-interface counter. The
          sequence number is initialized to a random number on startup. After
          it reaches its maximal value (2^32-1) (2<sup>32</sup>-1), the sequence number wraps
          around back to zero.</t>

          <t>Source Interface - a zero.</dd>
        <dt>Source Interface:</dt><dd>A 32-bit source interface identifier that is
          assigned by the Classifier. classifier. The combination of the source interface
          and the classifier identity is unique within the context of an
          SFC-enabled domain. Thus, in order for an SF to be able to use the
          source interface as a unique identifier, the identity of the
          classifier needs to be known for each packet. The source interface
          is unique in the context of the given classifier.</t>

          <t>Timestamp - this classifier.</dd>
        <dt>Timestamp:</dt><dd>A 64-bit field is 64 bits long, and that specifies the time at
          which the packet was received by the Classifier. classifier. Two possible
          timestamp formats can be used for this field: the two 64-bit
          recommended formats specified in <xref target="RFC8877"/>. target="RFC8877" format="default"/>. One of
          the formats is based on the <xref target="IEEE1588"/> timestamp
          format, format defined in <xref target="IEEE1588" format="default"/>, and
          the other is based on the format defined in <xref target="RFC5905"/>
          format.</t>
        </list></t> target="RFC5905" format="default"/>.</dd>
      </dl>
      <t>The NSH specification <xref target="RFC8300"/> target="RFC8300" format="default"/> does not specify the
      possible coexistence of multiple MD Type 0x1 Context Header formats in a
      single SFC-enabled domain. It is assumed that the Timestamp Context
      Header will be deployed in an SFC-enabled domain that uniquely uses this
      Context Header format. Thus, operators SHOULD <bcp14>SHOULD</bcp14> ensure that either a
      consistent Context Header format is used in the SFC-enabled domain, domain or
      that
      there is a clear policy that allows SFs to know the Context Header
      format of each packet. Specifically, operators are expected to ensure
      the consistent use of a timestamp format across the whole SFC-enabled
      domain.</t>
      <t>The two timestamp formats that can be used in the timestamp Timestamp field
      are:</t>

      <t><list style="symbols">
          <t>IEEE 1588 Truncated
      are as follows:</t>
      <dl spacing="normal">
        <dt>Truncated Timestamp Format: this Format <xref target="IEEE1588"/>:</dt><dd>This format is specified in
          Section 4.3 of
          <xref target="RFC8877"/>. target="RFC8877" sectionFormat="of" section="4.3"/>. For the reader's
          convenience
          convenience, this format is illustrated in <xref
          target="TimestampFormat"/>.</t>
        </list></t> target="TimestampFormat" format="default"/>.</dd>
      </dl>
      <figure align="center" anchor="TimestampFormat"
              title="IEEE 1588 Truncated anchor="TimestampFormat">
        <name>Truncated Timestamp Format [IEEE1588]."> (IEEE 1588)</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Seconds                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Nanoseconds                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ]]></artwork>
      </figure>

      <t><list style="symbols">
          <t>NTP <xref target="RFC5905"/>
      <dl spacing="normal">
        <dt>NTP 64-bit Timestamp Format: this Format <xref target="RFC5905"/>:</dt><dd>This format
          is specified in Section 4.4 of <xref target="RFC8877"/>. target="RFC8877" sectionFormat="of" section="4.2.1"/>.
          For the reader's convenience convenience, this format is illustrated in
          <xref
          target="NTPFormat"/>.</t>
        </list></t> target="NTPFormat" format="default"/>.</dd>
      </dl>
      <figure align="center" anchor="NTPFormat"
              title="NTP [RFC5905] 64-bit anchor="NTPFormat">
        <name>NTP 64-Bit Timestamp Format"> Format (RFC 5905)</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Seconds                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Fraction                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ]]></artwork>
      </figure>
      <t>Synchronization aspects of the timestamp format in the context of the
      NSH timestamp Timestamp allocation are discussed in <xref target="Sync"/>.</t> target="Sync" format="default"/>.</t>
    </section>
    <section title="Timestamping numbered="true" toc="default">
      <name>Timestamping Use Cases"> Cases</name>
      <section anchor="SecAnalytics" title="Network Analytics"> numbered="true" toc="default">
        <name>Network Analytics</name>
        <t>Per-packet timestamping enables coarse-grained monitoring of the
        network delay delays along the Service Function Chain. Once a potential
        problem or bottleneck is detected, for example detected (for example, when the delay exceeds
        a certain policy, policy), a highly-granular highly granular monitoring mechanism can be
        triggered, for example
        triggered (for example, using the hop-by-hop measurement data of defined in
        <xref
        target="RFC8592"/> target="RFC8592" format="default"/> or <xref target="I-D.ietf-ippm-ioam-data"/>, target="IOAM-DATA" format="default"/>),
        allowing to analyze analysis and localize localization of the problem.</t>
        <t>Timestamping is also useful for logging, troubleshooting troubleshooting, and for
        flow analytics. It is often useful to maintain the timestamp of the
        first and last packet of the flow. Furthermore, traffic mirroring and
        sampling often requires require a timestamp to be attached to analyzed
        packets. Attaching the timestamp to the NSH provides an in-band common
        time reference that can be used for various network analytics
        applications.</t>
      </section>
      <section title="Alternate Marking"> numbered="true" toc="default">
        <name>Alternate Marking</name>
        <t>A possible approach for passive performance monitoring is to use an
        alternate marking method
        Alternate-Marking Method <xref target="RFC8321"/>. target="RFC8321" format="default"/>. This method
        requires data packets to carry a field that marks (colors) the
        traffic, and enables passive measurement of packet loss, delay, and
        delay variation. The value of this marking field is periodically
        toggled between two values.</t>
        <t>When the timestamp is incorporated in the NSH, it can natively intrinsically be
        used for alternate marking. Alternate Marking. For example, the least significant bit of
        the timestamp Seconds field can be used for this purpose, since the
        value of this bit is inherently toggled every second.</t>
      </section>
      <section title="Consistent Updates"> numbered="true" toc="default">
        <name>Consistent Updates</name>
        <t>The timestamp can be used for taking making policy decisions decisions, such as
        'Perform action A if timestamp&gt;=T_0'. This can be used for
        enforcing time-of-day policies or periodic policies in service
        functions. SFs.
        Furthermore, timestamp-based policies can be used for
        enforcing consistent network updates, as discussed in <xref
        target="DPT"/>. target="DPT" format="default"/>. It should be noted that, as in the case of Alternate
        Marking, this use case alone does not require a full 64-bit timestamp, timestamp
        but could be implemented with a significantly smaller number of
        bits.</t>
      </section>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="Sync" title="Synchronization Considerations"> numbered="true" toc="default">
      <name>Synchronization Considerations</name>
      <t>Some of the applications that make use of the timestamp require the
      Classifier
      classifier and SFs to be synchronized to a common time reference, reference -- for
      example
      example, using the Network Time Protocol <xref target="RFC5905"/> target="RFC5905" format="default"/> or the
      Precision Time Protocol <xref target="IEEE1588"/>. target="IEEE1588" format="default"/>. Although it is not a
      requirement to use a clock synchronization mechanism, it is expected
      that
      that, depending on the applications that use the timestamp, such
      synchronization mechanisms will be used in most deployments that use the
      timestamp
      Timestamp allocation.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This memo includes document has no request to IANA.</t> IANA actions.</t>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The security considerations of for the NSH in general are discussed in <xref
      target="RFC8300"/>. target="RFC8300" format="default"/>. The NSH is typically run within a confined trust domain.
      However, if a trust domain is not enough to provide the operator with
      the
      protection against the timestamp threats as described below, then the
      operator SHOULD <bcp14>SHOULD</bcp14> use transport-level protection between SFC processing
      nodes as described in <xref target="RFC8300"/>.</t> target="RFC8300" format="default"/>.</t>
      <t>The security considerations of in-band timestamping in the context of the
      NSH is are discussed in <xref target="RFC8592"/>, and the current target="RFC8592" format="default"/>; this section is
      based on that discussion.</t>

      <t>The use of in-band
      <t>In-band timestamping, as defined in this document, document and <xref target="RFC8592" format="default"/>, can be
      used as a means for network reconnaissance. By passively eavesdropping
      to
      on timestamped traffic, an attacker can gather information about network
      delays and performance bottlenecks. A man-in-the-middle An on-path attacker can
      maliciously modify timestamps in order to attack applications that use
      the timestamp values, such as performance monitoring performance-monitoring applications.</t>
      <t>Since the timestamping mechanism relies on an underlying time
      synchronization protocol, by attacking the time protocol an attack can
      potentially compromise the integrity of the NSH timestamp. Timestamp. A detailed
      discussion about the threats against time protocols and how to mitigate
      them is presented in <xref target="RFC7384"/>.</t>
    </section>

    <section anchor="Acknowledgments" title="Acknowledgments">
      <t>The authors thank Mohamed Boucadair and Greg Mirsky for their
      thorough reviews and detailed comments.</t> target="RFC7384" format="default"/>.</t>
    </section>
  </middle>

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

      &RFC2119;

      <?rfc include='reference.RFC.8174'?>

      <?rfc include='reference.RFC.8300'?>

      <?rfc include='reference.RFC.8877'?>

      <?rfc include='reference.RFC.7665'?>

<displayreference target="I-D.ietf-sfc-nsh-broadband-allocation"  to="NSH-BROADBAND-ALLOC"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8300.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8877.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"/>
      </references>

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

      <references>
        <name>Informative References</name>
      <reference anchor="IEEE1588"> anchor="IEEE1588" target="https://standards.ieee.org/standard/1588-2008.html">
          <front>
            <title>IEEE 1588 1588-2008 - IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Version
          2</title>

          <author>
            <organization>IEEE</organization>
          </author> Systems</title>
            <author><organization>IEEE</organization></author>
<!--            <date year="2008"/> -->
          </front>
        </reference>
     <reference anchor="DPT"> anchor="DPT" target="https://ieeexplore.ieee.org/abstract/document/7562197">
       <front>
         <title>The Case for Data Plane Timestamping in SDN</title>

          <author>
            <organization>Mizrahi, T., Moses, Y.</organization>
          </author>
         <author initials='T' surname='Mizrahi' fullname='Tal Mizrahi'></author>
         <author initials='Y' surname='Moses' fullname='Yoram Moses'></author>
       <date year="IEEE year="2016"/>
       </front>
       <refcontent>IEEE INFOCOM Workshop on Software-Driven Flexible and Agile Networking (SWFAN), 2016"/> DOI 10.1109/INFCOMW.2016.7562197</refcontent>
        </reference>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7384.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8321.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8592.xml"/>

<!-- draft-ietf-ippm-ioam-data (RFC-EDITOR)
     Have to do "long way"; all authors are editors -->
<reference anchor='IOAM-DATA'>
<front>
<title>Data Fields for In-situ OAM</title>
<author initials='F' surname='Brockners' fullname='Frank Brockners' role="editor">
<organization />
</author>
<author initials='S' surname='Bhandari' fullname='Shwetha Bhandari' role="editor">
<organization />
</author>
<author initials='T' surname='Mizrahi' fullname='Tal Mizrahi' role="editor">
<organization />
</author>
<date year='2021' month='December' day="13"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ippm-ioam-data-17"/>
</reference>

      <?rfc include='reference.RFC.7384'?>

      <?rfc include='reference.RFC.5905'?>

      <?rfc include='reference.RFC.8321'?>

      <?rfc include='reference.RFC.8592'?>

      <?rfc include='reference.I-D.ietf-ippm-ioam-data'?>

      <?rfc include='reference.I-D.ietf-sfc-nsh-dc-allocation'?>

      <?rfc include='reference.I-D.ietf-sfc-nsh-broadband-allocation'?>

      <?rfc include='reference.I-D.ietf-sfc-nsh-tlv'?>
    </references>

<!-- Change Log

v00 2016-08-02  TM   Initial version

v01 2016-08-10  TM   Minor updates including: timestamp format change, added Flow ID. draft-ietf-sfc-nsh-dc-allocation (Expired)
     Have to do "long way"; one author is editor -->
<reference anchor="NSH-DC-ALLOC">
   <front>
      <title>Network Service Header (NSH) MD Type 1: Context Header Allocation (Data Center)</title>
      <author fullname="Jim Guichard" role="editor"></author>
      <author fullname="Michael Smith"></author>
      <author fullname="Surendra Kumar"></author>
      <author fullname="Sumandra Majee"></author>
      <author fullname="Tal Mizrahi"></author>
      <date month="September" day="25" year="2018" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-sfc-nsh-dc-allocation-02" />
</reference>

<!-- draft-ietf-sfc-nsh-broadband-allocation (Expired) -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-sfc-nsh-broadband-allocation.xml"/>

<!-- draft-ietf-sfc-nsh-tlv (IESG Evaluation::AD Followup)
     Have to do "long way"; one author is editor -->
 <reference anchor="NSH-TLV">
   <front>
      <title>Network Service Header Metadata Type 2 Variable-Length Context Headers</title>
      <author fullname="Yuehua Wei" role="editor"></author>
      <author fullname="Uri Elzur"></author>
      <author fullname="Sumandra Majee"></author>
      <author fullname="Carlos Pignataro"></author>
      <author fullname="Donald Eastlake"></author>
      <date month="January" day="26" year="2022" />
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-sfc-nsh-tlv-13"/>
 </reference>
</references>
</references>
    <section anchor="Acknowledgments" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors thank <contact fullname="Mohamed Boucadair"/> and <contact fullname="Greg Mirsky"/> for their thorough reviews and detailed comments.</t>
    </section>
  </back>
</rfc>