rfc9192xml2.original.xml   rfc9192.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <!DOCTYPE rfc [
ce.RFC.2119.xml"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-mymb-sfc-nsh-allo
<?rfc toc="yes"?> cation-timestamp-12" number="9192" ipr="trust200902" obsoletes="" updates="" sub
<?rfc tocdepth="4"?> missionType="independent" category="info" xml:lang="en" tocInclude="true" tocDep
<?rfc symrefs="yes"?> th="4" symRefs="true" sortRefs="true" version="3">
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?> <!-- xml2rfc v2v3 conversion 3.12.0 -->
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-mymb-sfc-nsh-allocation-timestamp-12"
ipr="trust200902">
<front> <front>
<title abbrev="NSH Timestamp">Network Service Header (NSH) Fixed-Length <title abbrev="NSH Timestamp">Network Service Header (NSH) Fixed-Length
Context Header Allocation: Timestamp</title> Context Header Allocation</title>
<seriesInfo name="RFC" value="9192"/>
<author fullname="Tal Mizrahi" initials="T." surname="Mizrahi"> <author fullname="Tal Mizrahi" initials="T." surname="Mizrahi">
<organization abbrev="">Huawei</organization> <organization abbrev="">Huawei</organization>
<address> <address>
<postal> <postal>
<street/>
<city/>
<code/>
<country>Israel</country> <country>Israel</country>
</postal> </postal>
<email>tal.mizrahi.phd@gmail.com</email> <email>tal.mizrahi.phd@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Ilan Yerushalmi" initials="I." surname="Yerushalmi">
<author fullname="Ilan Yerushalmi" initials="I.Y." surname="Yerushalmi">
<organization>Marvell</organization> <organization>Marvell</organization>
<address> <address>
<postal> <postal>
<street>6 Hamada</street> <street>6 Hamada</street>
<!-- Reorder these if your country does things differently -->
<city>Yokneam</city> <city>Yokneam</city>
<code>2066721</code> <code>2066721</code>
<country>Israel</country> <country>Israel</country>
</postal> </postal>
<email>yilan@marvell.com</email> <email>yilan@marvell.com</email>
</address> </address>
</author> </author>
<author fullname="David Melman" initials="D." surname="Melman">
<author fullname="David Melman" initials="D.M." surname="Melman">
<organization>Marvell</organization> <organization>Marvell</organization>
<address> <address>
<postal> <postal>
<street>6 Hamada</street> <street>6 Hamada</street>
<!-- Reorder these if your country does things differently -->
<city>Yokneam</city> <city>Yokneam</city>
<code>2066721</code> <code>2066721</code>
<country>Israel</country> <country>Israel</country>
</postal> </postal>
<email>davidme@marvell.com</email> <email>davidme@marvell.com</email>
</address> </address>
</author> </author>
<author fullname="Rory Browne" initials="R." surname="Browne">
<author fullname="Rory Browne" initials="R.B." surname="Browne">
<organization>Intel</organization> <organization>Intel</organization>
<address> <address>
<postal> <postal>
<street>Dromore House</street> <street>Dromore House</street>
<city>Shannon</city>
<!-- Reorder these if your country does things differently --> <region>Co. Clare</region>
<city>Shannon, Co.Clare</city>
<country>Ireland</country> <country>Ireland</country>
</postal> </postal>
<email>rory.browne@intel.com</email> <email>rory.browne@intel.com</email>
</address> </address>
</author> </author>
<date year="2022" month="February" />
<date year="2021"/>
<area>General</area> <area>General</area>
<workgroup>Network Working Group</workgroup> <workgroup>Network Working Group</workgroup>
<keyword>NSH</keyword>
<keyword>NSH, Context Header, timestamp</keyword> <keyword>Context Header</keyword>
<keyword>timestamp</keyword>
<abstract> <abstract>
<t>The Network Service Header (NSH) specification defines two possible <t>The Network Service Header (NSH) specification defines two possible
methods of including metadata (MD): MD Type 0x1 and MD Type 0x2. MD Type 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 0x1 uses a fixed-length Context Header. The allocation of this Context
Header, i.e., its structure and semantics, has not been standardized. Header, i.e., its structure and semantics, has not been standardized.
This memo presents an allocation for the fixed Context Headers of NSH, This memo defines the Timestamp Context Header, which is an
which incorporates the packet's timestamp, a sequence number, and a NSH fixed-length Context Header that incorporates the packet's
source interface identifier.</t> timestamp, a sequence number, and a source interface identifier.</t>
<t>Although the allocation that is presented in this document has not <t>Although the definition of the Context Header presented
been standardized by the IETF it has been implemented in silicon by in this document has not been standardized by the IETF, it has been
several manufacturers and is published here to allow other interoperable implemented in silicon by several manufacturers and is published
implementations and to facilitate debugging if it is seen in the here to facilitate interoperability.</t>
network.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t>The Network Service Header (NSH), defined in <xref <name>Introduction</name>
target="RFC8300"/>, is an encapsulation header that is used as the <t>The Network Service Header (NSH), defined in <xref target="RFC8300" for
service encapsulation in the Service Function Chains (SFC) architecture mat="default"/>,
<xref target="RFC7665"/>.</t> is an encapsulation header that is used as the
service encapsulation in the Service Function Chaining (SFC) architecture
<t>In order to share metadata along a service path, the NSH <xref target="RFC7665" format="default"/>.</t>
specification <xref target="RFC8300"/> supports two methods: a <t>In order to share metadata (MD) along a service path, the NSH
specification <xref target="RFC8300" format="default"/> supports two metho
ds: a
fixed-length Context Header (MD Type 0x1) and a variable-length Context fixed-length Context Header (MD Type 0x1) and a variable-length Context
Header (MD Type 0x2). When using MD Type 0x1 the NSH includes 16 octets Header (MD Type 0x2). When using MD Type 0x1, the NSH includes 16 octets
of Context Header fields.</t> of Context Header fields.</t>
<t>The NSH specification <xref target="RFC8300" format="default"/> has not
<t>The NSH specification <xref target="RFC8300"/> has not defined the defined the
semantics of the 16-octet Context Header, nor how it is used by semantics of the 16-octet Context Header, nor does it specify how the Cont
NSH-aware service functions, SFFs and proxies. Several context header ext Header is used by
formats are defined in <xref target="I-D.ietf-sfc-nsh-tlv"/>. NSH-aware Service Functions (SFs), Service Function Forwarders (SFFs), and
proxies. Several Context Header
formats are defined in <xref target="NSH-TLV" format="default"/>.
Furthermore, some allocation schemes were proposed in the past to Furthermore, some allocation schemes were proposed in the past to
acoommodate specific use cases, e.g., <xref accommodate specific use cases, e.g., <xref target="NSH-DC-ALLOC"/>,
target="I-D.ietf-sfc-nsh-dc-allocation"/>, <xref <xref target="I-D.ietf-sfc-nsh-broadband-allocation" format="default"/>,
target="I-D.ietf-sfc-nsh-broadband-allocation"/>, and <xref and <xref target="RFC8592" format="default"/>.</t>
target="RFC8592"/>.</t>
<t>This memo presents an allocation for the MD Type 0x1 Context Header, <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 which incorporates the timestamp of the packet, a sequence number, and a
source interface identifier. It is noted that other MD Type 0x1 source interface identifier. Note that other allocation schema for MD Type
allocations might be specified in the future. Although MD Type 0x1 0x1
allocations are currently not being standardized by the SFC working might be specified in the future. Although such schema are currently not
group, a consistent format (allocation) should be used in an SFC-enabled being
domain in order to allow interoperability.</t> standardized by the SFC Working Group, a consistent format (allocation sch
ema)
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 <t>In a nutshell, packets that enter the SFC-enabled domain are
timestamped by a Classifier <xref target="RFC7665"/>. Thus, the timestamped by a classifier <xref target="RFC7665" format="default"/>. Thu
timestamp, sequence number and source interface are incorporated in the s, the
NSH Context Header. As defined in <xref target="RFC8300"/>, if timestamp, sequence number, and source interface are incorporated in the
NSH Context Header. As discussed in <xref target="RFC8300" format="default
"/>, if
reclassification is used, it may result in an update to the NSH reclassification is used, it may result in an update to the NSH
metadata. Specifically, when the Timestamp Context Header is used, a metadata. Specifically, when the Timestamp Context Header is used, a
reclassifier may either leave it unchanged, or update the three fields: reclassifier may either leave it unchanged or update the three fields:
timestamp, sequence number and source interface.</t> Timestamp, Sequence Number, and Source Interface.</t>
<t>The Timestamp Context Header includes three fields that may be used <t>The Timestamp Context Header includes three fields that may be used
for various purposes. The timestamp field may be used for logging, for various purposes. The Timestamp field may be used for logging,
troubleshooting, delay measurement, packet marking for performance troubleshooting, delay measurement, packet marking for performance
monitoring, and timestamp-based policies. The source interface monitoring, and timestamp-based policies. The source interface
identifier indicates the interface through which the packet was received identifier indicates the interface through which the packet was received
at the classifier. This identifier may specify a physical or a virtual at the classifier. This identifier may specify a physical interface or a v
interface. The sequence numbers can be used by Service Functions (SFs) irtual
interface. The sequence numbers can be used by SFs
to detect out-of-order delivery or duplicate transmissions. Note that to detect out-of-order delivery or duplicate transmissions. Note that
out-of-order and duplicate packet detection is possible when packets are out-of-order and duplicate packet detection is possible when packets are
received by the same SF, but is not necessarily possible when there are received by the same SF but is not necessarily possible when there are
multiple instances of the same SF and multiple packets are spread across multiple instances of the same SF and multiple packets are spread across
different instances of the SF. The sequence number is maintained on a different instances of the SF. The sequence number is maintained on a
per-source-interface basis.</t> per-source-interface basis.</t>
<t>This document presents the Timestamp Context Header but does not
<t>This document presents the Timestamp Context Header, but does not
specify the functionality of the SFs that receive the Context Header. specify the functionality of the SFs that receive the Context Header.
Although a few possible use cases are described in the document, the SF Although a few possible use cases are described in this document, the SF
behavior and application are outside the scope of this document.</t> behavior and application are outside the scope of this document.</t>
<t>Key Performance Indicator (KPI) stamping <xref target="RFC8592" format=
<t>KPI-stamping <xref target="RFC8592"/> defines an NSH timestamping "default"/> defines an NSH timestamping
mechanism that uses the MD Type 0x2 format. The current memo defines a mechanism that uses the MD Type 0x2 format. This memo defines a
compact MD Type 0x1 Context Header that does not require the packet to compact MD Type 0x1 Context Header that does not require the packet to
be extended beyond the NSH header. Furthermore, the mechanisms of <xref be extended beyond the NSH. Furthermore, the mechanisms described in
target="RFC8592"/> and of this memo can be used in concert, as further <xref target="RFC8592" format="default"/> and this memo can be used in con
discussed in <xref target="SecAnalytics"/>.</t> cert, as further
discussed in <xref target="SecAnalytics" format="default"/>.</t>
<t>Although the allocation that is presented in this document has not <t>Although the definition of the Context Header presented
been standardized by the IETF it has been implemented in silicon by in this document has not been standardized by the IETF, it has been
several manufacturers and is published here to allow other interoperable implemented in silicon by several manufacturers and is published
implementations and to facilitate debugging if it is seen in the here to facilitate interoperability.</t>
network.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Terminology"> <name>Terminology</name>
<section title="Requirements Language"> <section numbered="true" toc="default">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <name>Requirements Language</name>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in BCP "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
when, they appear in all capitals, as shown here.</t> "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP&nbsp;14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Abbreviations"> <name>Abbreviations</name>
<t>The following abbreviations are used in this document: <list <t>The following abbreviations are used in this document: </t>
hangIndent="14" style="hanging"> <dl newline="false" spacing="normal" indent="14">
<t hangText="KPI">Key Performance Indicators <xref <dt>KPI</dt>
target="RFC8592"/></t> <dd>Key Performance Indicator <xref target="RFC8592" format="default"/
></dd>
<t hangText="NSH">Network Service Header <xref <dt>MD</dt>
target="RFC8300"/></t> <dd>Metadata <xref target="RFC8300" format="default"/></dd>
<dt>NSH</dt>
<t hangText="MD">Metadata <xref target="RFC8300"/></t> <dd>Network Service Header <xref target="RFC8300" format="default"/></
dd>
<t hangText="SF">Service Function <xref target="RFC7665"/></t> <dt>SF</dt>
<dd>Service Function <xref target="RFC7665" format="default"/></dd>
<t hangText="SFC">Service Function Chaining <xref <dt>SFC</dt>
target="RFC7665"/></t> <dd>Service Function Chaining <xref target="RFC7665" format="default"/
</list></t> ></dd>
<dt>SFF</dt>
<dd>Service Function Forwarder <xref target="RFC8300"/></dd>
</dl>
</section> </section>
</section> </section>
<section anchor="allocation" numbered="true" toc="default">
<section anchor="allocation" <name>NSH Timestamp Context Header Allocation</name>
title="NSH Timestamp Context Header Allocation">
<t>This memo defines the following fixed-length Context Header <t>This memo defines the following fixed-length Context Header
allocation, as presented in <xref target="AllocationFormat"/>.</t> allocation, as presented in <xref target="AllocationFormat" format="defaul
t"/>.</t>
<figure align="center" anchor="AllocationFormat" <figure anchor="AllocationFormat">
title="NSH Timestamp Allocation."> <name>NSH Timestamp Allocation</name>
<artwork align="left"><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Interface | | Source Interface |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<!-- This PI places the pagebreak correctly (before the section title) in <t>The NSH Timestamp allocation defined in this memo <bcp14>MUST</bcp14>
the text output. -->
<?rfc needLines="8" ?>
<t>The NSH Timestamp Allocation that is defined in this memo MUST
include the following fields:</t> include the following fields:</t>
<dl spacing="normal">
<t><list style="symbols"> <dt>Sequence Number:</dt><dd>A 32-bit sequence number. The sequence numb
<t>Sequence Number - a 32-bit sequence number. The sequence number er
is maintained on a per-source-interface basis. Sequence numbers can is maintained on a per-source-interface basis. Sequence numbers can
be used by SFs to detect out-of-order delivery, or duplicate be used by SFs to detect out-of-order delivery or duplicate
transmissions. The Classifier increments the sequence number by 1 transmissions. The classifier increments the sequence number by 1
for each packet received through the source interface. This requires for each packet received through the source interface. This requires
the classifier to maintain a per-source-interface counter. The the classifier to maintain a per-source-interface counter. The
sequence number is initialized to a random number on startup. After sequence number is initialized to a random number on startup. After
it reaches its maximal value (2^32-1) the sequence number wraps it reaches its maximal value (2<sup>32</sup>-1), the sequence number w
around back to zero.</t> raps
around back to zero.</dd>
<t>Source Interface - a 32-bit source interface identifier that is <dt>Source Interface:</dt><dd>A 32-bit source interface identifier that
assigned by the Classifier. The combination of the source interface is
assigned by the classifier. The combination of the source interface
and the classifier identity is unique within the context of an 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 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 source interface as a unique identifier, the identity of the
classifier needs to be known for each packet. The source interface classifier needs to be known for each packet. The source interface
is unique in the context of the given classifier.</t> is unique in the context of the given classifier.</dd>
<dt>Timestamp:</dt><dd>A 64-bit field that specifies the time at
<t>Timestamp - this field is 64 bits long, and specifies the time at which the packet was received by the classifier. Two possible
which the packet was received by the Classifier. Two possible
timestamp formats can be used for this field: the two 64-bit timestamp formats can be used for this field: the two 64-bit
recommended formats specified in <xref target="RFC8877"/>. One of recommended formats specified in <xref target="RFC8877" format="defaul
the formats is based on the <xref target="IEEE1588"/> timestamp t"/>. One of
format, and the other is based on the <xref target="RFC5905"/> the formats is based on the timestamp format defined in <xref target="
format.</t> IEEE1588" format="default"/>, and
</list></t> the other is based on the format defined in <xref target="RFC5905" for
mat="default"/>.</dd>
<t>The NSH specification <xref target="RFC8300"/> does not specify the </dl>
<t>The NSH specification <xref target="RFC8300" format="default"/> does no
t specify the
possible coexistence of multiple MD Type 0x1 Context Header formats in a possible coexistence of multiple MD Type 0x1 Context Header formats in a
single SFC-enabled domain. It is assumed that the Timestamp Context single SFC-enabled domain. It is assumed that the Timestamp Context
Header will be deployed in an SFC-enabled domain that uniquely uses this Header will be deployed in an SFC-enabled domain that uniquely uses this
Context Header format. Thus, operators SHOULD ensure that either a Context Header format. Thus, operators <bcp14>SHOULD</bcp14> ensure that e
consistent Context Header format is used in the SFC-enabled domain, or ither a
that there is a clear policy that allows SFs to know the Context Header consistent Context Header format is used in the SFC-enabled domain or
there is a clear policy that allows SFs to know the Context Header
format of each packet. Specifically, operators are expected to ensure format of each packet. Specifically, operators are expected to ensure
the consistent use of a timestamp format across the whole SFC-enabled the consistent use of a timestamp format across the whole SFC-enabled
domain.</t> domain.</t>
<t>The two timestamp formats that can be used in the Timestamp field
<t>The two timestamp formats that can be used in the timestamp field are as follows:</t>
are:</t> <dl spacing="normal">
<dt>Truncated Timestamp Format <xref target="IEEE1588"/>:</dt><dd>This f
<t><list style="symbols"> ormat is specified in
<t>IEEE 1588 Truncated Timestamp Format: this format is specified in <xref target="RFC8877" sectionFormat="of" section="4.3"/>. For the rea
Section 4.3 of <xref target="RFC8877"/>. For the reader's der's
convenience this format is illustrated in <xref convenience, this format is illustrated in <xref target="TimestampForm
target="TimestampFormat"/>.</t> at" format="default"/>.</dd>
</list></t> </dl>
<figure anchor="TimestampFormat">
<figure align="center" anchor="TimestampFormat" <name>Truncated Timestamp Format (IEEE 1588)</name>
title="IEEE 1588 Truncated Timestamp Format [IEEE1588]."> <artwork align="left" name="" type="" alt=""><![CDATA[
<artwork align="left"><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nanoseconds | | Nanoseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<dl spacing="normal">
<t><list style="symbols"> <dt>NTP 64-bit Timestamp Format <xref target="RFC5905"/>:</dt><dd>This f
<t>NTP <xref target="RFC5905"/> 64-bit Timestamp Format: this format ormat
is specified in Section 4.4 of <xref target="RFC8877"/>. For the is specified in <xref target="RFC8877" sectionFormat="of" section="4.2
reader's convenience this format is illustrated in <xref .1"/>.
target="NTPFormat"/>.</t> For the reader's convenience, this format is illustrated in
</list></t> <xref target="NTPFormat" format="default"/>.</dd>
</dl>
<figure align="center" anchor="NTPFormat" <figure anchor="NTPFormat">
title="NTP [RFC5905] 64-bit Timestamp Format"> <name>NTP 64-Bit Timestamp Format (RFC 5905)</name>
<artwork align="left"><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | | Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fraction | | Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Synchronization aspects of the timestamp format in the context of the <t>Synchronization aspects of the timestamp format in the context of the
NSH timestamp allocation are discussed in <xref target="Sync"/>.</t> NSH Timestamp allocation are discussed in <xref target="Sync" format="defa ult"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Timestamping Use Cases"> <name>Timestamping Use Cases</name>
<section anchor="SecAnalytics" title="Network Analytics"> <section anchor="SecAnalytics" numbered="true" toc="default">
<t>Per-packet timestamping enables coarse-grained monitoring of the <name>Network Analytics</name>
network delay along the Service Function Chain. Once a potential <t>Per-packet timestamping enables coarse-grained monitoring of
problem or bottleneck is detected, for example when the delay exceeds network delays along the Service Function Chain. Once a potential
a certain policy, a highly-granular monitoring mechanism can be problem or bottleneck is detected (for example, when the delay exceeds
triggered, for example using the hop-by-hop measurement data of <xref a certain policy), a highly granular monitoring mechanism can be
target="RFC8592"/> or <xref target="I-D.ietf-ippm-ioam-data"/>, triggered (for example, using the hop-by-hop measurement data defined in
allowing to analyze and localize the problem.</t> <xref target="RFC8592" format="default"/> or <xref target="IOAM-DATA" fo
rmat="default"/>),
<t>Timestamping is also useful for logging, troubleshooting and for allowing analysis and localization of the problem.</t>
<t>Timestamping is also useful for logging, troubleshooting, and
flow analytics. It is often useful to maintain the timestamp of the flow analytics. It is often useful to maintain the timestamp of the
first and last packet of the flow. Furthermore, traffic mirroring and first and last packet of the flow. Furthermore, traffic mirroring and
sampling often requires a timestamp to be attached to analyzed sampling often require a timestamp to be attached to analyzed
packets. Attaching the timestamp to the NSH provides an in-band common packets. Attaching the timestamp to the NSH provides an in-band common
time reference that can be used for various network analytics time reference that can be used for various network analytics
applications.</t> applications.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Alternate Marking"> <name>Alternate Marking</name>
<t>A possible approach for passive performance monitoring is to use an <t>A possible approach for passive performance monitoring is to use an
alternate marking method <xref target="RFC8321"/>. This method Alternate-Marking Method <xref target="RFC8321" format="default"/>. This method
requires data packets to carry a field that marks (colors) the requires data packets to carry a field that marks (colors) the
traffic, and enables passive measurement of packet loss, delay, and traffic, and enables passive measurement of packet loss, delay, and
delay variation. The value of this marking field is periodically delay variation. The value of this marking field is periodically
toggled between two values.</t> toggled between two values.</t>
<t>When the timestamp is incorporated in the NSH, it can intrinsically b
<t>When the timestamp is incorporated in the NSH, it can natively be e
used for alternate marking. For example, the least significant bit of used for Alternate Marking. For example, the least significant bit of
the timestamp Seconds field can be used for this purpose, since the the timestamp Seconds field can be used for this purpose, since the
value of this bit is inherently toggled every second.</t> value of this bit is inherently toggled every second.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Consistent Updates"> <name>Consistent Updates</name>
<t>The timestamp can be used for taking policy decisions such as <t>The timestamp can be used for making policy decisions, such as
'Perform action A if timestamp&gt;=T_0'. This can be used for 'Perform action A if timestamp&gt;=T_0'. This can be used for
enforcing time-of-day policies or periodic policies in service enforcing time-of-day policies or periodic policies in SFs.
functions. Furthermore, timestamp-based policies can be used for Furthermore, timestamp-based policies can be used for
enforcing consistent network updates, as discussed in <xref enforcing consistent network updates, as discussed in <xref target="DPT"
target="DPT"/>. It should be noted that, as in the case of Alternate 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, Marking, this use case alone does not require a full 64-bit timestamp
but could be implemented with a significantly smaller number of but could be implemented with a significantly smaller number of
bits.</t> bits.</t>
</section> </section>
</section> </section>
<!-- Possibly a 'Contributors' section ... --> <section anchor="Sync" numbered="true" toc="default">
<name>Synchronization Considerations</name>
<section anchor="Sync" title="Synchronization Considerations">
<t>Some of the applications that make use of the timestamp require the <t>Some of the applications that make use of the timestamp require the
Classifier and SFs to be synchronized to a common time reference, for classifier and SFs to be synchronized to a common time reference -- for
example using the Network Time Protocol <xref target="RFC5905"/> or the example, using the Network Time Protocol <xref target="RFC5905" format="de
Precision Time Protocol <xref target="IEEE1588"/>. Although it is not a fault"/> or the
Precision Time Protocol <xref target="IEEE1588" format="default"/>. Althou
gh it is not a
requirement to use a clock synchronization mechanism, it is expected requirement to use a clock synchronization mechanism, it is expected
that depending on the applications that use the timestamp, such that, depending on the applications that use the timestamp, such
synchronization mechanisms will be used in most deployments that use the synchronization mechanisms will be used in most deployments that use the
timestamp allocation.</t> Timestamp allocation.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This memo includes no request to IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>The security considerations of NSH in general are discussed in <xref <t>The security considerations for the NSH in general are discussed in <xr
target="RFC8300"/>. NSH is typically run within a confined trust domain. ef target="RFC8300" format="default"/>. The NSH is typically run within a confin
ed trust domain.
However, if a trust domain is not enough to provide the operator with However, if a trust domain is not enough to provide the operator with
the protection against the timestamp threats described below, then the protection against the timestamp threats as described below, then the
operator SHOULD use transport-level protection between SFC processing operator <bcp14>SHOULD</bcp14> use transport-level protection between SFC
nodes as described in <xref target="RFC8300"/>.</t> processing
nodes as described in <xref target="RFC8300" format="default"/>.</t>
<t>The security considerations of in-band timestamping in the context of <t>The security considerations of in-band timestamping in the context of t
NSH is discussed in <xref target="RFC8592"/>, and the current section is he
NSH are discussed in <xref target="RFC8592" format="default"/>; this secti
on is
based on that discussion.</t> based on that discussion.</t>
<t>In-band timestamping, as defined in this document and <xref target="RFC
<t>The use of in-band timestamping, as defined in this document, can be 8592" format="default"/>, can be
used as a means for network reconnaissance. By passively eavesdropping used as a means for network reconnaissance. By passively eavesdropping
to timestamped traffic, an attacker can gather information about network on timestamped traffic, an attacker can gather information about network
delays and performance bottlenecks. A man-in-the-middle attacker can delays and performance bottlenecks. An on-path attacker can
maliciously modify timestamps in order to attack applications that use maliciously modify timestamps in order to attack applications that use
the timestamp values, such as performance monitoring applications.</t> the timestamp values, such as performance-monitoring applications.</t>
<t>Since the timestamping mechanism relies on an underlying time <t>Since the timestamping mechanism relies on an underlying time
synchronization protocol, by attacking the time protocol an attack can synchronization protocol, by attacking the time protocol an attack can
potentially compromise the integrity of the NSH timestamp. A detailed potentially compromise the integrity of the NSH Timestamp. A detailed
discussion about the threats against time protocols and how to mitigate discussion about the threats against time protocols and how to mitigate
them is presented in <xref target="RFC7384"/>.</t> them is presented in <xref target="RFC7384" format="default"/>.</t>
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>The authors thank Mohamed Boucadair and Greg Mirsky for their
thorough reviews and detailed comments.</t>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <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'?>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<reference anchor="IEEE1588">
<front>
<title>IEEE 1588 Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems Version
2</title>
<author>
<organization>IEEE</organization>
</author>
<date year="2008"/>
</front>
</reference>
<reference anchor="DPT">
<front>
<title>The Case for Data Plane Timestamping in SDN</title>
<author>
<organization>Mizrahi, T., Moses, Y.</organization>
</author>
<date year="IEEE INFOCOM Workshop on Software-Driven Flexible and Agil
e Networking (SWFAN), 2016"/>
</front>
</reference>
<?rfc include='reference.RFC.7384'?> <displayreference target="I-D.ietf-sfc-nsh-broadband-allocation" to="NSH-BROADB
AND-ALLOC"/>
<?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'?> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8300.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8877.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7665.xml"/>
</references>
<?rfc include='reference.I-D.ietf-sfc-nsh-broadband-allocation'?> <references>
<name>Informative References</name>
<reference anchor="IEEE1588" target="https://standards.ieee.org/standard/1
588-2008.html">
<front>
<title>IEEE 1588-2008 - IEEE Standard for a Precision Clock Synchron
ization Protocol for Networked Measurement and Control Systems</title>
<author><organization>IEEE</organization></author>
<!-- <date year="2008"/> -->
</front>
</reference>
<reference anchor="DPT" target="https://ieeexplore.ieee.org/abstract/docume
nt/7562197">
<front>
<title>The Case for Data Plane Timestamping in SDN</title>
<author initials='T' surname='Mizrahi' fullname='Tal Mizrahi'></author>
<author initials='Y' surname='Moses' fullname='Yoram Moses'></author>
<date year="2016"/>
</front>
<refcontent>IEEE INFOCOM Workshop on Software-Driven Flexible and Agile N
etworking (SWFAN), DOI 10.1109/INFCOMW.2016.7562197</refcontent>
</reference>
<?rfc include='reference.I-D.ietf-sfc-nsh-tlv'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</references> FC.7384.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5905.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8321.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8592.xml"/>
<!-- Change Log <!-- 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>
v00 2016-08-02 TM Initial version <!-- 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>
v01 2016-08-10 TM Minor updates including: timestamp format change, added Flo <!-- draft-ietf-sfc-nsh-broadband-allocation (Expired) -->
w ID. <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 Head
ers</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> </back>
</rfc> </rfc>
 End of changes. 86 change blocks. 
335 lines changed or deleted 347 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/