draft-ietf-ntp-packet-timestamps-08.txt   draft-ietf-ntp-packet-timestamps-09.txt 
NTP Working Group T. Mizrahi NTP Working Group T. Mizrahi
Internet-Draft Huawei Smart Platforms iLab Internet-Draft Huawei Smart Platforms iLab
Intended status: Informational J. Fabini Intended status: Informational J. Fabini
Expires: August 27, 2020 TU Wien Expires: September 12, 2020 TU Wien
A. Morton A. Morton
AT&T Labs AT&T Labs
February 24, 2020 March 11, 2020
Guidelines for Defining Packet Timestamps Guidelines for Defining Packet Timestamps
draft-ietf-ntp-packet-timestamps-08 draft-ietf-ntp-packet-timestamps-09
Abstract Abstract
Various network protocols make use of binary-encoded timestamps that Various network protocols make use of binary-encoded timestamps that
are incorporated in the protocol packet format, referred to as packet are incorporated in the protocol packet format, referred to as packet
timestamps for short. This document specifies guidelines for timestamps for short. This document specifies guidelines for
defining packet timestamp formats in networking protocols at various defining packet timestamp formats in networking protocols at various
layers. It also presents three recommended timestamp formats. The layers. It also presents three recommended timestamp formats. The
target audience of this document includes network protocol designers. target audience of this document includes network protocol designers.
It is expected that a new network protocol that requires a packet It is expected that a new network protocol that requires a packet
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 27, 2020. This Internet-Draft will expire on September 12, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 2, line 37
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Terms used in this Document . . . . . . . . . . . . . . . 4 2.3. Terms used in this Document . . . . . . . . . . . . . . . 4
3. Packet Timestamp Specification Template . . . . . . . . . . . 5 3. Packet Timestamp Specification Template . . . . . . . . . . . 5
4. Recommended Timestamp Formats . . . . . . . . . . . . . . . . 6 4. Recommended Timestamp Formats . . . . . . . . . . . . . . . . 6
4.1. Using a Recommended Timestamp Format . . . . . . . . . . 7 4.1. Using a Recommended Timestamp Format . . . . . . . . . . 7
4.2. NTP Timestamp Formats . . . . . . . . . . . . . . . . . . 7 4.2. NTP Timestamp Formats . . . . . . . . . . . . . . . . . . 7
4.2.1. NTP 64-bit Timestamp Format . . . . . . . . . . . . . 7 4.2.1. NTP 64-bit Timestamp Format . . . . . . . . . . . . . 7
4.2.2. NTP 32-bit Timestamp Format . . . . . . . . . . . . . 9 4.2.2. NTP 32-bit Timestamp Format . . . . . . . . . . . . . 9
4.3. The PTP Truncated Timestamp Format . . . . . . . . . . . 10 4.3. The PTP Truncated Timestamp Format . . . . . . . . . . . 10
5. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 12 5. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 11
6. Timestamp Use Cases . . . . . . . . . . . . . . . . . . . . . 13 6. Timestamp Use Cases . . . . . . . . . . . . . . . . . . . . . 12
6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Packet Timestamp Control Field . . . . . . . . . . . . . . . 15 7. Packet Timestamp Control Field . . . . . . . . . . . . . . . 14
7.1. High-level Control Field Requirements . . . . . . . . . . 16 7.1. High-level Control Field Requirements . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
1.1. Background 1.1. Background
Timestamps are widely used in network protocols for various purposes: Timestamps are widely used in network protocols for various purposes:
timestamps are used for logging or reporting the time of an event, timestamps are used for logging or reporting the time of an event,
delay measurement and clock synchronization protocols both make use delay measurement and clock synchronization protocols both make use
of timestamped messages, and in security protocols a timestamp is of timestamped messages, and in security protocols a timestamp is
often used as a value that is unlikely to repeat (nonce). often used as part of a value that is unlikely to repeat (nonce).
Timestamps are represented in the RFC series in one of two forms: Timestamps are represented in the RFC series in one of two forms:
text-based timestamps, and packet timestamps. Text-based timestamps text-based timestamps, and packet timestamps. Text-based timestamps
[RFC3339] are represented as user-friendly strings, and are widely [RFC3339] are represented as user-friendly strings, and are widely
used in the RFC series, for example in information objects and data used in the RFC series, for example in information objects and data
models, e.g., [RFC5646], [RFC6991], and [RFC7493]. Packet models, e.g., [RFC5646], [RFC6991], and [RFC7493]. Packet
timestamps, on the other hand, are represented by a compact binary timestamps, on the other hand, are represented by a compact binary
field that has a fixed size, and are not intended to have a human- field that has a fixed size, and are not intended to have a human-
friendly format. Packet timestamps are also very common in the RFC friendly format. Packet timestamps are also very common in the RFC
series, and are used for example for measuring delay and for series, and are used for example for measuring delay and for
skipping to change at page 4, line 17 skipping to change at page 4, line 17
functionality, then a new timestamp format should be defined using functionality, then a new timestamp format should be defined using
the template of Section 3. the template of Section 3.
2. Terminology 2. Terminology
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 14 [RFC2119] [RFC8174] when, and only when, they appear in all
appear in all capitals, as shown here. capitals, as shown here.
2.2. Abbreviations 2.2. Abbreviations
NTP Network Time Protocol [RFC5905] NTP Network Time Protocol [RFC5905]
PTP Precision Time Protocol [IEEE1588] PTP Precision Time Protocol [IEEE1588]
TAI International Atomic Time TAI International Atomic Time
UTC Coordinated Universal Time UTC Coordinated Universal Time
skipping to change at page 5, line 32 skipping to change at page 5, line 32
timestamp specification. timestamp specification.
This section defines a template for specifying packet timestamps. A This section defines a template for specifying packet timestamps. A
timestamp format specification MUST include at least the following timestamp format specification MUST include at least the following
aspects: aspects:
Timestamp syntax: Timestamp syntax:
- Size: The number of bits (or octets) used to represent the - Size: The number of bits (or octets) used to represent the
packet timestamp field. If the timestamp is comprised of more packet timestamp field. If the timestamp is comprised of more
than one field, the size of each field is specified. than one field, the size of each field is specified. Network
order (big endian) is assumed by default; if this is not the case
then this section explicitly specifies the endianity.
Timestamp semantics: Timestamp semantics:
- Units: The units used to represent the timestamp. If the - Units: The units used to represent the timestamp. If the
timestamp is comprised of more than one field, the units of each timestamp is comprised of more than one field, the units of each
field are specified. field are specified. If a field is limited to a specific range of
values, this section specifies the permitted range of values.
- Resolution: The timestamp resolution; the resolution is equal to - Resolution: The timestamp resolution; the resolution is equal to
the timestamp field unit. If the timestamp consists of two or the timestamp field unit. If the timestamp consists of two or
more fields using different time units, then the resolution is the more fields using different time units, then the resolution is the
smallest time unit. smallest time unit.
- Wraparound: The wraparound period of the timestamp; any further - Wraparound: The wraparound period of the timestamp; any further
wraparound-related considerations should be described here. wraparound-related considerations should be described here.
- Epoch: The origin of the timescale used for the timestamp; the - Epoch: The origin of the timescale used for the timestamp; the
moment in time used as a reference for the timestamp value. For moment in time used as a reference for the timestamp value. For
example, the epoch may be based on a standard time scale, such as example, the epoch may be based on a standard time scale, such as
UTC. Another example is a relative timestamp, in which the epoch UTC. Another example is a relative timestamp, in which the epoch
is the time at which the device using the timestamp was powered could be the time at which the device using the timestamp was
up, and is not affected by leap seconds (see the next attribute). powered up, and is not affected by leap seconds (see the next
attribute).
- Leap seconds: This subsection specifies whether the timestamp is - Leap seconds: This subsection specifies whether the timestamp is
affected by leap seconds. If the timestamp is affected by leap affected by leap seconds. If the timestamp is affected by leap
seconds, then it represents the time elapsed since the epoch minus seconds, then it represents the time elapsed since the epoch minus
the number of leap seconds that have occurred since the epoch. the number of leap seconds that have occurred since the epoch.
Synchronization aspects: Synchronization aspects:
The specification of a network protocol that makes use of a packet The specification of a network protocol that makes use of a packet
timestamp is expected to include the synchronization aspects of timestamp is expected to include the synchronization aspects of
skipping to change at page 6, line 30 skipping to change at page 6, line 33
synchronization, e.g., a timestamp that indicates the number of synchronization, e.g., a timestamp that indicates the number of
seconds since power up. In such cases the Synchronization Aspects seconds since power up. In such cases the Synchronization Aspects
section will specify that the timestamp does not correspond to a section will specify that the timestamp does not correspond to a
synchronized time reference, and may discuss how this affects the synchronized time reference, and may discuss how this affects the
usage of the timestamp. Further details about synchronization usage of the timestamp. Further details about synchronization
aspects are discussed in Section 5. aspects are discussed in Section 5.
4. Recommended Timestamp Formats 4. Recommended Timestamp Formats
This document defines a set of recommended timestamp formats. This document defines a set of recommended timestamp formats.
Defining a relatively small set of recommended formats enables
significant reuse; for example, a network protocol may reuse the NTP
or PTP timestamp format, allowing a straightforward integration with
an NTP or a PTP-based timer. Moreover, since accurate timestamping
mechanisms are often implemented in hardware, a new network protocol
that reuses an existing timestamp format can be quickly deployed
using existing hardware timestamping capabilities. This document
recommends to use one of the timestamp formats specified below.
Clearly, different network protocols may have different requirements Clearly, different network protocols may have different requirements
and constraints, and consequently may use different timestamp and constraints, and consequently may use different timestamp
formats. The choice of the specific timestamp format for a given formats. The choice of the specific timestamp format for a given
protocol may depend on a various factors. A few examples of factors protocol may depend on a various factors. A few examples of factors
that may affect the choice of the timestamp format: that may affect the choice of the timestamp format:
o Timestamp size: while some network protocols use a large timestamp o Timestamp size: while some network protocols use a large timestamp
field, in some cases there may be constraints with respect to the field, in some cases there may be constraints with respect to the
timestamp size, affecting the choice of the timestamp format. timestamp size, affecting the choice of the timestamp format.
skipping to change at page 7, line 18 skipping to change at page 7, line 14
o Wraparound period: the length of the time interval in which the o Wraparound period: the length of the time interval in which the
timestamp is unique may also be an important factor in choosing timestamp is unique may also be an important factor in choosing
the timestamp format. Along with the timestamp resolution, these the timestamp format. Along with the timestamp resolution, these
two factors determine the required number of bits in the two factors determine the required number of bits in the
timestamp. timestamp.
o Common format for multiple protocols: if there are two or more o Common format for multiple protocols: if there are two or more
network protocols that use timestamps and are often used together network protocols that use timestamps and are often used together
in typical systems, using a common timestamp format should be in typical systems, using a common timestamp format should be
preferred if possible. Specifically, if the network protocol that preferred if possible. For example, if the network protocol that
is being defined typically runs on a PC, then an NTP-based is being defined typically runs on a PC, then an NTP-based
timestamp format may allow easier integration with an NTP- timestamp format may allow easier integration with an NTP-
synchronized timer. In contrast, a protocol that is typically synchronized timer. In contrast, a protocol that is typically
deployed on a hardware-based platform, may make better use of a deployed on a hardware-based platform, may make better use of a
PTP-based timestamp, allowing more efficient integration with a PTP-based timestamp, allowing more efficient integration with a
PTP-synchronized timer. PTP-synchronized timer.
4.1. Using a Recommended Timestamp Format 4.1. Using a Recommended Timestamp Format
A specification that uses one of the recommended timestamp formats A specification that uses one of the recommended timestamp formats
skipping to change at page 8, line 47 skipping to change at page 8, line 37
exist prior to 1 January 1972, but it is convenient to assume it exist prior to 1 January 1972, but it is convenient to assume it
has existed for all eternity. The current epoch implies that the has existed for all eternity. The current epoch implies that the
timestamp specifies the number of seconds since 1 January 1972 at timestamp specifies the number of seconds since 1 January 1972 at
00:00 UTC plus 2272060800 (which is the number of seconds between 00:00 UTC plus 2272060800 (which is the number of seconds between
1 January 1900 and 1 January 1972). 1 January 1900 and 1 January 1972).
Leap seconds: Leap seconds:
This timestamp format is affected by leap seconds. The timestamp This timestamp format is affected by leap seconds. The timestamp
represents the number of seconds elapsed since the epoch minus the represents the number of seconds elapsed since the epoch minus the
number of leap seconds. Thus, during and possibly after the number of leap seconds. Thus, during and possibly before and/or
occurrence of a leap second, the value of the timestamp may after the occurrence of a leap second, the value of the timestamp
temporarily be ambiguous, as further discussed in Section 5. may temporarily be ambiguous, as further discussed in Section 5.
Resolution: Resolution:
The resolution is 2^(-32) seconds. The resolution is 2^(-32) seconds.
Wraparound: Wraparound:
This time format wraps around every 2^32 seconds, which is roughly This time format wraps around every 2^32 seconds, which is roughly
136 years. The next wraparound will occur in the year 2036. 136 years. The next wraparound will occur in the year 2036.
skipping to change at page 15, line 45 skipping to change at page 14, line 45
In some cases it is desirable to have a control field that describes In some cases it is desirable to have a control field that describes
structure, format, content, and properties of timestamps. Control structure, format, content, and properties of timestamps. Control
information about the timestamp format can be conveyed in some information about the timestamp format can be conveyed in some
protocols using a dedicated control plane protocol, or may be made protocols using a dedicated control plane protocol, or may be made
available at the management plane, for example using a YANG data available at the management plane, for example using a YANG data
model. An optional control field allows some of the control model. An optional control field allows some of the control
information to be attached to the timestamp. information to be attached to the timestamp.
An example of a packet timestamp control field is the Error Estimate An example of a packet timestamp control field is the Error Estimate
field, defined by Section 4.1.2 in [RFC4656], which is used in OWAMP field, defined by Section 4.1.2 in [RFC4656], which is used in OWAMP
[RFC4656] and TWAMP [RFC5357]. [RFC4656] and TWAMP [RFC5357]. The Root Dispersion and Root Delay
fields in the NTP header [RFC5905] are two examples of fields that
provide information about the timestamp precision. Another example
of an auxiliary field is the Correction Field in the PTP header
[IEEE1588]; its value is used as a correction to the timestamp, and
may be assigned by the sender of the PTP message and updated by
transit nodes (Transparent Clocks) in order to account for the delay
along the path.
This section defines high-level guidelines for defining packet This section defines high-level guidelines for defining packet
timestamp control fields in network protocols that can benefit from timestamp control fields in network protocols that can benefit from
such timestamp-related control information. The word 'requirements' such timestamp-related control information. The word 'requirements'
is used in its informal context in this section. is used in its informal context in this section.
7.1. High-level Control Field Requirements 7.1. High-level Control Field Requirements
A control field for packet timestamps must offer an adequate feature A control field for packet timestamps must offer an adequate feature
set and fulfill a series of requirements to be usable and accepted. set and fulfill a series of requirements to be usable and accepted.
skipping to change at page 17, line 22 skipping to change at page 16, line 25
security considerations that result from using the timestamp. This security considerations that result from using the timestamp. This
section provides an overview of some of the common security section provides an overview of some of the common security
considerations of using timestamps. considerations of using timestamps.
Any metadata that is attached to control or data packets, and Any metadata that is attached to control or data packets, and
specifically packet timestamps, can facilitate network specifically packet timestamps, can facilitate network
reconnaissance; by passively eavesdropping to timestamped packets an reconnaissance; by passively eavesdropping to timestamped packets an
attacker can gather information about the network performance, and attacker can gather information about the network performance, and
about the level of synchronization between nodes. about the level of synchronization between nodes.
Timestamps can be spoofed or modified by on-path attackers, thus In some cases timestamps could be spoofed or modified by on-path
attacking the application that uses the timestamps. For example, if attackers, thus attacking the application that uses the timestamps.
timestamps are used in a delay measurement protocol, an attacker can For example, if timestamps are used in a delay measurement protocol,
modify en route timestamps in a way that manipulates the measurement an attacker can modify en route timestamps in a way that manipulates
results. Integrity protection mechanisms, such as Message the measurement results. Integrity protection mechanisms, such as
Authentication Codes (MAC), can mitigate such attacks. The Message Authentication Codes (MAC), can mitigate such attacks. The
specification of an integrity protection mechanism is outside the specification of an integrity protection mechanism is outside the
scope of this document, as typically integrity protection will be scope of this document, as typically integrity protection will be
defined on a per-network-protocol basis, and not specifically for the defined on a per-network-protocol basis, and not specifically for the
timestamp field. timestamp field.
Another potential threat that can have a similar impact is delay Another potential threat that can have a similar impact is delay
attacks. An attacker can maliciously delay some or all of the en attacks. An attacker can maliciously delay some or all of the en
route messages, with the same harmful implications as described in route messages, with the same harmful implications as described in
the previous paragraph. Mitigating delay attacks is a significant the previous paragraph. Mitigating delay attacks is a significant
challenge; in contrast to spoofing and modification attacks, the challenge; in contrast to spoofing and modification attacks, the
skipping to change at page 18, line 9 skipping to change at page 17, line 9
In many cases timestamping relies on an underlying synchronization In many cases timestamping relies on an underlying synchronization
mechanism. Thus, any attack that compromises the synchronization mechanism. Thus, any attack that compromises the synchronization
mechanism can also compromise protocols that use timestamping. mechanism can also compromise protocols that use timestamping.
Attacks on time protocols are discussed in detail in [RFC7384]. Attacks on time protocols are discussed in detail in [RFC7384].
10. Acknowledgments 10. Acknowledgments
The authors thank Russ Housley, Yaakov Stein, Greg Mirsky, Warner The authors thank Russ Housley, Yaakov Stein, Greg Mirsky, Warner
Losh, Rodney Cummings, Miroslav Lichvar, Denis Reilly, Daniel Franke, Losh, Rodney Cummings, Miroslav Lichvar, Denis Reilly, Daniel Franke,
Watson Ladd, and other members of the NTP working group for many Eric Vyncke, Ben Kaduk, Ian Swett, Francesca Palombini, Watson Ladd,
helpful comments. The authors gratefully acknowledge Harlan Stenn and other members of the NTP working group for many helpful comments.
and the people from the Network Time Foundation for sharing their The authors gratefully acknowledge Harlan Stenn and the people from
thoughts and ideas. the Network Time Foundation for sharing their thoughts and ideas.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-ippm-initial-registry] [I-D.ietf-ippm-initial-registry]
Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza, Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza,
"Initial Performance Metrics Registry Entries", draft- "Initial Performance Metrics Registry Entries", draft-
ietf-ippm-initial-registry-15 (work in progress), December ietf-ippm-initial-registry-16 (work in progress), March
2019. 2020.
[I-D.ietf-ntp-packet-timestamps] [I-D.ietf-ntp-packet-timestamps]
Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
Defining Packet Timestamps", draft-ietf-ntp-packet- Defining Packet Timestamps", draft-ietf-ntp-packet-
timestamps-07 (work in progress), August 2019. timestamps-08 (work in progress), February 2020.
[I-D.ietf-sfc-nsh-dc-allocation] [I-D.ietf-sfc-nsh-dc-allocation]
Guichard, J., Smith, M., Kumar, S., Majee, S., and T. Guichard, J., Smith, M., Kumar, S., Majee, S., and T.
Mizrahi, "Network Service Header (NSH) MD Type 1: Context Mizrahi, "Network Service Header (NSH) MD Type 1: Context
Header Allocation (Data Center)", draft-ietf-sfc-nsh-dc- Header Allocation (Data Center)", draft-ietf-sfc-nsh-dc-
allocation-02 (work in progress), September 2018. allocation-02 (work in progress), September 2018.
[IEEE1588] [IEEE1588]
IEEE, "IEEE 1588 Standard for a Precision Clock IEEE, "IEEE 1588 Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
 End of changes. 18 change blocks. 
51 lines changed or deleted 53 lines changed or added

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