draft-ietf-mpls-residence-time-15.txt   rfc8169.txt 
MPLS Working Group G. Mirsky Internet Engineering Task Force (IETF) G. Mirsky
Internet-Draft ZTE Corp. Request for Comments: 8169 ZTE Corp.
Intended status: Standards Track S. Ruffini Category: Standards Track S. Ruffini
Expires: September 8, 2017 E. Gray ISSN: 2070-1721 E. Gray
Ericsson Ericsson
J. Drake J. Drake
Juniper Networks Juniper Networks
S. Bryant S. Bryant
Huawei Huawei
A. Vainshtein A. Vainshtein
ECI Telecom ECI Telecom
March 7, 2017 May 2017
Residence Time Measurement in MPLS network Residence Time Measurement in MPLS Networks
draft-ietf-mpls-residence-time-15
Abstract Abstract
This document specifies a new Generic Associated Channel for This document specifies a new Generic Associated Channel (G-ACh) for
Residence Time Measurement and describes how it can be used by time Residence Time Measurement (RTM) and describes how it can be used by
synchronization protocols within a MPLS domain. time synchronization protocols within an MPLS domain.
Residence time is the variable part of the propagation delay of Residence time is the variable part of the propagation delay of
timing and synchronization messages; knowing what this delay is for timing and synchronization messages; knowing this delay for each
each message allows for a more accurate determination of the delay to message allows for a more accurate determination of the delay to be
be taken into account in applying the value included in a Precision taken into account when applying the value included in a Precision
Time Protocol event message. Time Protocol event message.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on September 8, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8169.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions used in this document . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 4
1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 4
1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 5
2. Residence Time Measurement . . . . . . . . . . . . . . . . . 4 2. Residence Time Measurement . . . . . . . . . . . . . . . . . 5
2.1. One-step Clock and Two-step Clock Modes . . . . . . . . . 5 2.1. One-Step Clock and Two-Step Clock Modes . . . . . . . . . 6
2.1.1. RTM with Two-step Upstream PTP Clock . . . . . . . . 6 2.1.1. RTM with Two-Step Upstream PTP Clock . . . . . . . . 7
2.1.2. Two-step RTM with One-step Upstream PTP Clock . . . . 7 2.1.2. Two-Step RTM with One-Step Upstream PTP Clock . . . . 8
3. G-ACh for Residence Time Measurement . . . . . . . . . . . . 7 3. G-ACh for Residence Time Measurement . . . . . . . . . . . . 8
3.1. PTP Packet Sub-TLV . . . . . . . . . . . . . . . . . . . 9 3.1. PTP Packet Sub-TLV . . . . . . . . . . . . . . . . . . . 10
4. Control Plane Theory of Operation . . . . . . . . . . . . . . 10 3.2. PTP Associated Value Field . . . . . . . . . . . . . . . 11
4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 10 4. Control-Plane Theory of Operation . . . . . . . . . . . . . . 11
4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 11 4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 11
4.3. RTM Capability Advertisement in Routing Protocols . . . . 11 4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 12
4.3.1. RTM Capability Advertisement in OSPFv2 . . . . . . . 11 4.3. RTM Capability Advertisement in Routing Protocols . . . . 13
4.3.2. RTM Capability Advertisement in OSPFv3 . . . . . . . 13 4.3.1. RTM Capability Advertisement in OSPFv2 . . . . . . . 13
4.3.3. RTM Capability Advertisement in IS-IS . . . . . . . . 13 4.3.2. RTM Capability Advertisement in OSPFv3 . . . . . . . 14
4.3.4. RTM Capability Advertisement in BGP-LS . . . . . . . 13 4.3.3. RTM Capability Advertisement in IS-IS . . . . . . . . 14
4.4. RSVP-TE Control Plane Operation to Support RTM . . . . . 14 4.3.4. RTM Capability Advertisement in BGP-LS . . . . . . . 14
4.4.1. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . 15 4.4. RSVP-TE Control-Plane Operation to Support RTM . . . . . 15
5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 20 4.4.1. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . 16
6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 20 5. Data-Plane Theory of Operation . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 21
7.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 21 7.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 22
7.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 22 7.2. New MPLS RTM TLV Registry . . . . . . . . . . . . . . . . 22
7.4. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 22 7.3. New MPLS RTM Sub-TLV Registry . . . . . . . . . . . . . . 23
7.5. IS-IS RTM Capability sub-TLV . . . . . . . . . . . . . . 22 7.4. RTM Capability Sub-TLV in OSPFv2 . . . . . . . . . . . . 23
7.6. RTM Capability TLV in BGP-LS . . . . . . . . . . . . . . 23 7.5. RTM Capability Sub-TLV in IS-IS . . . . . . . . . . . . . 24
7.7. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 23 7.6. RTM Capability TLV in BGP-LS . . . . . . . . . . . . . . 24
7.8. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 24 7.7. RTM_SET Sub-object RSVP Type and Sub-TLVs . . . . . . . . 25
7.9. New Error Codes . . . . . . . . . . . . . . . . . . . . . 24 7.8. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7.9. New Error Codes . . . . . . . . . . . . . . . . . . . . . 26
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . 25 9.1. Normative References . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . 27 9.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
Time synchronization protocols, e.g., Network Time Protocol version 4 Time synchronization protocols, e.g., the Network Time Protocol
(NTPv4) [RFC5905] and Precision Time Protocol (PTP) Version 2 version 4 (NTPv4) [RFC5905] and the Precision Time Protocol version 2
[IEEE.1588.2008], define timing messages that can be used to (PTPv2) [IEEE.1588], define timing messages that can be used to
synchronize clocks across a network domain. Measurement of the synchronize clocks across a network domain. Measurement of the
cumulative time that one of these timing messages spends transiting cumulative time that one of these timing messages spends transiting
the nodes on the path from ingress node to egress node is termed the nodes on the path from ingress node to egress node is termed
Residence Time and it is used to improve the accuracy of clock "residence time" and is used to improve the accuracy of clock
synchronization. Residence Time is the sum of the difference between synchronization. Residence time is the sum of the difference between
the time of receipt at an ingress interface and the time of the time of receipt at an ingress interface and the time of
transmission from an egress interface for each node along the network transmission from an egress interface for each node along the network
path from an ingress node to an egress node. This document defines a path from an ingress node to an egress node. This document defines a
new Generic Associated Channel (G-ACh) value and an associated new Generic Associated Channel (G-ACh) value and an associated
residence time measurement (RTM) message that can be used in a Multi- Residence Time Measurement (RTM) message that can be used in a
Protocol Label Switching (MPLS) network to measure residence time Multiprotocol Label Switching (MPLS) network to measure residence
over a Label Switched Path (LSP). time over a Label Switched Path (LSP).
This document describes RTM over an LSP signaled using RSVP-TE This document describes RTM over an LSP signaled using RSVP-TE
[RFC3209]. Using RSVP-TE, the LSP's path can be either explicitly [RFC3209]. Using RSVP-TE, the LSP's path can be either explicitly
specified or determined during signaling. Although it is possible to specified or determined during signaling. Although it is possible to
use RTM over an LSP instantiated using Label Distribution Protocol use RTM over an LSP instantiated using the Label Distribution
[RFC5036], that is outside the scope of this document. Protocol [RFC5036], that is outside the scope of this document.
Comparison with alternative proposed solutions such as Comparison with alternative proposed solutions such as
[I-D.ietf-tictoc-1588overmpls] is outside the scope of this document. [TIMING-OVER-MPLS] is outside the scope of this document.
1.1. Conventions used in this document 1.1. Conventions Used in This Document
1.1.1. Terminology 1.1.1. Terminology
MPLS: Multi-Protocol Label Switching MPLS: Multiprotocol Label Switching
ACH: Associated Channel ACH: Associated Channel Header
TTL: Time-to-Live TTL: Time to Live
G-ACh: Generic Associated Channel G-ACh: Generic Associated Channel
GAL: Generic Associated Channel Label GAL: Generic Associated Channel Label
NTP: Network Time Protocol
ppm: parts per million NTP: Network Time Protocol
PTP: Precision Time Protocol ppm: parts per million
BC: Boundary Clock PTP: Precision Time Protocol
LSP: Label Switched Path BC: boundary clock
LSP: Label Switched Path
OAM: Operations, Administration, and Maintenance OAM: Operations, Administration, and Maintenance
RRO: Record Route Object RRO: Record Route Object
RTM: Residence Time Measurement RTM: Residence Time Measurement
IGP: Internal Gateway Protocol IGP: Internal Gateway Protocol
BGP-LS: Border Gateway Protocol - Link State BGP-LS: Border Gateway Protocol - Link State
1.1.2. Requirements Language 1.1.2. 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 "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Residence Time Measurement 2. Residence Time Measurement
Packet Loss and Delay Measurement for MPLS Networks [RFC6374] can be "Packet Loss and Delay Measurement for MPLS Networks" [RFC6374] can
used to measure one-way or two-way end-to-end propagation delay over be used to measure one-way or two-way end-to-end propagation delay
LSP or PW. But these measurements are insufficient for use in some over an LSP or a pseudowire (PW). But these measurements are
applications, for example, time synchronization across a network as insufficient for use in some applications, for example, time
defined in the PTP. In PTPv2 [IEEE.1588.2008], the residence time is synchronization across a network as defined in the PTP. In PTPv2
accumulated in the correctionField of the PTP event message, as [IEEE.1588], the residence time is accumulated in the correctionField
defined in [IEEE.1588.2008] and referred to as using a one-step of the PTP event message, which is defined in [IEEE.1588] and
clock, or in the associated follow-up message (or Delay_Resp message referred to as using a one-step clock, or in the associated follow-up
associated with the Delay_Req message), referred to as using a two- message (or Delay_Resp message associated with the Delay_Req
step clock (see the detailed discussion in Section 2.1). message), which is referred to as using a two-step clock (see the
detailed discussion in Section 2.1).
IEEE 1588 uses this residence time to correct for the transit times IEEE 1588 uses this residence time to correct for the transit times
of nodes on an LSP, effectively making the transit nodes transparent. of nodes on an LSP, effectively making the transit nodes transparent.
This document proposes a mechanism that can be used as one type of This document proposes a mechanism that can be used as one type of
on-path support for a clock synchronization protocol or to perform on-path support for a clock synchronization protocol or can be used
one-way measurement of residence time. The proposed mechanism to perform one-way measurement of residence time. The proposed
accumulates residence time from all nodes that support this extension mechanism accumulates residence time from all nodes that support this
along the path of a particular LSP in the Scratch Pad field of an RTM extension along the path of a particular LSP in the Scratch Pad field
message (Figure 1). This value can then be used by the egress node of an RTM message (Figure 1). This value can then be used by the
to update, for example, the correctionField of the PTP event packet egress node to update, for example, the correctionField of the PTP
carried within the RTM message prior to performing its PTP event packet carried within the RTM message prior to performing its
processing. PTP processing.
2.1. One-step Clock and Two-step Clock Modes 2.1. One-Step Clock and Two-Step Clock Modes
One-step mode refers to the mode of operation where an egress One-step mode refers to the mode of operation where an egress
interface updates the correctionField value of an original event interface updates the correctionField value of an original event
message. Two-step mode refers to the mode of operation where this message. Two-step mode refers to the mode of operation where this
update is made in a subsequent follow-up message. update is made in a subsequent follow-up message.
Processing of the follow-up message, if present, requires the Processing of the follow-up message, if present, requires the
downstream end-point to wait for the arrival of the follow-up message downstream endpoint to wait for the arrival of the follow-up message
in order to combine correctionField values from both the original in order to combine correctionField values from both the original
(event) message and the subsequent (follow-up) message. In a similar (event) message and the subsequent (follow-up) message. In a similar
fashion, each two-step node needs to wait for the related follow-up fashion, each two-step node needs to wait for the related follow-up
message, if there is one, in order to update that follow-up message message, if there is one, in order to update that follow-up message
(as opposed to creating a new one). Hence the first node that uses (as opposed to creating a new one). Hence, the first node that uses
two-step mode MUST do two things: two-step mode MUST do two things:
1. Mark the original event message to indicate that a follow-up 1. Mark the original event message to indicate that a follow-up
message will be forthcoming. This is necessary in order to message will be forthcoming. This is necessary in order to
Let any subsequent two-step node know that there is already a * Let any subsequent two-step node know that there is already a
follow-up message, and follow-up message, and
Let the end-point know to wait for a follow-up message; * Let the endpoint know to wait for a follow-up message.
2. Create a follow-up message in which to put the RTM determined as 2. Create a follow-up message in which to put the RTM determined as
an initial correctionField value. an initial correctionField value.
IEEE 1588v2 [IEEE.1588.2008] defines this behavior for PTP messages. IEEE 1588v2 [IEEE.1588] defines this behavior for PTP messages.
Thus, for example, with reference to the PTP protocol, the PTPType Thus, for example, with reference to the PTP protocol, the PTPType
field identifies whether the message is a Sync message, Follow_up field identifies whether the message is a Sync message, Follow_up
message, Delay_Req message, or Delay_Resp message. The 10 octet long message, Delay_Req message, or Delay_Resp message. The 10-octet-long
Port ID field contains the identity of the source port Port ID field contains the identity of the source port [IEEE.1588],
[IEEE.1588.2008], that is, the specific PTP port of the boundary that is, the specific PTP port of the boundary clock (BC) connected
clock connected to the MPLS network. The Sequence ID is the sequence to the MPLS network. The Sequence ID is the sequence ID of the PTP
ID of the PTP message carried in the Value field of the message. message carried in the Value field of the message.
PTP messages also include a bit that indicates whether or not a PTP messages also include a bit that indicates whether or not a
follow-up message will be coming. This bit MAY be set by a two-step follow-up message will be coming. This bit MAY be set by a two-step
mode PTP device. The value MUST NOT be unset until the original and mode PTP device. The value MUST NOT be unset until the original and
follow-up messages are combined by an end-point (such as a Boundary follow-up messages are combined by an endpoint (such as a BC).
Clock).
For compatibility with PTP, RTM (when used for PTP packets) must For compatibility with PTP, RTM (when used for PTP packets) must
behave in a similar fashion. It should be noted that the handling of behave in a similar fashion. It should be noted that the handling of
Sync event messages and of Delay_Req/Delay_Resp event messages that Sync event messages and of Delay_Req/Delay_Resp event messages that
cross a two-step RTM node is different. The following outlines the cross a two-step RTM node is different. The following outlines the
handling of PTP Sync event message by the two-step RTM node. The handling of a PTP Sync event message by the two-step RTM node. The
details of handling Delay_Resp/Delay_Req PTP event messages by the details of handling Delay_Resp/Delay_Req PTP event messages by the
two-step RTM node are discussed in Section 2.1.1. As a summary, a two-step RTM node are discussed in Section 2.1.1. As a summary, a
two-step RTM capable egress interface will need to examine the S-bit two-step RTM-capable egress interface will need to examine the S bit
in the Flags field of the PTP sub-TLV (for RTM messages that indicate in the Flags field of the PTP sub-TLV (for RTM messages that indicate
they are for PTP) and - if it is clear (set to zero), it MUST set the they are for PTP), and -- if it is clear (set to zero) -- it MUST set
S bit and create a follow-up PTP Type RTM message. If the S bit is the S bit and create a follow-up PTP Type RTM message. If the S bit
already set, then the RTM capable node MUST wait for the RTM message is already set, then the RTM-capable node MUST wait for the RTM
with the PTP type of follow-up and matching originator and sequence message with the PTP type of follow-up and matching originator and
number to make the corresponding residence time update to the Scratch sequence number to make the corresponding residence time update to
Pad field. The wait period MUST be reasonably bounded. the Scratch Pad field. The wait period MUST be reasonably bounded.
Thus, an RTM packet, containing residence time information relating Thus, an RTM packet, containing residence time information relating
to an earlier packet, also contains information identifying that to an earlier packet, also contains information identifying that
earlier packet. earlier packet.
In practice, an RTM node operating in two-step mode behaves like a In practice, an RTM node operating in two-step mode behaves like a
two-steps transparent clock. two-step transparent clock.
A one-step capable RTM node MAY elect to operate in either one-step A one-step-capable RTM node MAY elect to operate in either one-step
mode (by making an update to the Scratch Pad field of the RTM message mode (by making an update to the Scratch Pad field of the RTM message
containing the PTP event message), or in two-step mode (by making an containing the PTP event message) or two-step mode (by making an
update to the Scratch Pad of a follow-up message when presence of a update to the Scratch Pad of a follow-up message when presence of a
follow-up is indicated), but MUST NOT do both. follow-up is indicated), but it MUST NOT do both.
Two main subcases identified for an RTM node operating as a two-step Two main subcases identified for an RTM node operating as a two-step
clock are described in the following sub-sections. clock are described in the following sub-sections.
2.1.1. RTM with Two-step Upstream PTP Clock 2.1.1. RTM with Two-Step Upstream PTP Clock
If any of the previous RTM capable nodes or the previous PTP clock If any of the previous RTM-capable nodes or the previous PTP clock
(e.g., the Boundary Clock (BC) connected to the first node), is a (e.g., the BC connected to the first node) is a two-step clock and if
two-step clock, the residence time is added to the RTM packet that the local RTM-capable node is also operating a two-tep clock, the
has been created to include the second PTP packet (i.e., follow-up residence time is added to the RTM packet that has been created to
message in the downstream direction), if the local RTM-capable node include the second PTP packet (i.e., the follow-up message in the
is also operating as a two-step clock. This RTM packet carries the downstream direction). This RTM packet carries the related
related accumulated residence time and the appropriate values of the accumulated residence time, the appropriate values of the Sequence ID
Sequence ID and Port ID (the same identifiers carried in the original and Port ID (the same identifiers carried in the original packet),
packet) and the Two-step Flag set to 1. and the two-step flag set to 1.
Note that the fact that an upstream RTM-capable node operating in the Note that the fact that an upstream RTM-capable node operating in
two-step mode has created a follow-up message does not require any two-step mode has created a follow-up message does not require any
subsequent RTM capable node to also operate in the two-step mode, as subsequent RTM-capable node to also operate in two-step mode, as long
long as that RTM-capable node forwards the follow-up message on the as that RTM-capable node forwards the follow-up message on the same
same LSP on which it forwards the corresponding previous message. LSP on which it forwards the corresponding previous message.
A one-step capable RTM node MAY elect to update the RTM follow-up A one-step-capable RTM node MAY elect to update the RTM follow-up
message as if it were operating in two-step mode, however, it MUST message as if it were operating in two-step mode; however, it MUST
NOT update both messages. NOT update both messages.
A PTP Sync packet is carried in the RTM packet in order to indicate A PTP Sync packet is carried in the RTM packet in order to indicate
to the RTM node that residence time measurement must be performed on to the RTM node that RTM must be performed on that specific packet.
that specific packet.
To handle the residence time of the Delay_Req message on the upstream To handle the residence time of the Delay_Req message in the upstream
direction, an RTM packet must be created to carry the residence time direction, an RTM packet must be created to carry the residence time
on the associated downstream Delay_Resp message. in the associated downstream Delay_Resp message.
The last RTM node of the MPLS network, in addition to updating the The last RTM node of the MPLS network, in addition to updating the
correctionField of the associated PTP packet, must also react correctionField of the associated PTP packet, must also react
properly to the two-step flag of the PTP packets. properly to the two-step flag of the PTP packets.
2.1.2. Two-step RTM with One-step Upstream PTP Clock 2.1.2. Two-Step RTM with One-Step Upstream PTP Clock
When the PTP network connected to the MPLS operates in one-step clock When the PTP network connected to the MPLS operates in one-step clock
mode and an RTM node operates in two-step mode, the follow-up RTM mode and an RTM node operates in two-step mode, the follow-up RTM
packet must be created by the RTM node itself. The RTM packet packet must be created by the RTM node itself. The RTM packet
carrying the PTP event packet needs now to indicate that a follow-up carrying the PTP event packet needs now to indicate that a follow-up
message will be coming. message will be coming.
The egress RTM-capable node of the LSP will be removing RTM The egress RTM-capable node of the LSP will remove RTM encapsulation
encapsulation and, in case of two-step clock mode being indicated, and, in case of two-step clock mode being indicated, will generate
will generate PTP messages to include the follow-up correction as PTP messages to include the follow-up correction as appropriate
appropriate (according to the [IEEE.1588.2008]). In this case, the (according to [IEEE.1588]). In this case, the common header of the
common header of the PTP packet carrying the synchronization message PTP packet carrying the synchronization message would have to be
would have to be modified by setting the twoStepFlag field indicating modified by setting the twoStepFlag field indicating that there is
that there is now a follow up message associated to the current now a follow-up message associated to the current message.
message.
3. G-ACh for Residence Time Measurement 3. G-ACh for Residence Time Measurement
RFC 5586 [RFC5586] and RFC 6423 [RFC6423] define the G-ACh to extend [RFC5586] and [RFC6423] define the G-ACh to extend the applicability
the applicability of the Pseudowire Associated Channel (ACH) of the Pseudowire Associated Channel Header (ACH) [RFC5085] to LSPs.
[RFC5085] to LSPs. G-ACh provides a mechanism to transport OAM and G-ACh provides a mechanism to transport OAM and other control
other control messages over an LSP. Processing of these messages by messages over an LSP. Processing of these messages by selected
selected transit nodes is controlled by the use of the Time-to-Live transit nodes is controlled by the use of the Time-to-Live (TTL)
(TTL) value in the MPLS header of these messages. value in the MPLS header of these messages.
The message format for RTM is presented in Figure 1.
The message format for Residence Time Measurement (RTM) is presented
in Figure 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | RTM G-ACh | |0 0 0 1|Version| Reserved | RTM G-ACh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Scratch Pad | | Scratch Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV (optional) | | Value (optional) |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RTM G-ACh message format for Residence Time Measurement Figure 1: RTM G-ACh Message Format for Residence Time Measurement
o First four octets are defined as G-ACh Header in [RFC5586] o The first four octets are defined as a G-ACh header in [RFC5586].
o The Version field is set to 0, as defined in RFC 4385 [RFC4385]. o The Version field is set to 0, as defined in [RFC4385].
o The Reserved field MUST be set to 0 on transmit and ignored on o The Reserved field MUST be set to 0 on transmit and ignored on
receipt. receipt.
o The RTM G-ACh field, value (TBA1) to be allocated by IANA, o The RTM G-ACh field (value 0x000F; see Section 7.1) identifies the
identifies the packet as such. packet as such.
o The Scratch Pad field is 8 octets in length. It is used to o The Scratch Pad field is 8 octets in length. It is used to
accumulate the residence time spent in each RTM capable node accumulate the residence time spent in each RTM-capable node
transited by the packet on its path from ingress node to egress transited by the packet on its path from ingress node to egress
node. The first RTM-capable node MUST initialize the Scratch Pad node. The first RTM-capable node MUST initialize the Scratch Pad
field with its residence time measurement. Its format is IEEE field with its RTM. Its format is a 64-bit signed integer, and it
double precision and its units are nanoseconds. Note that indicates the value of the residence time measured in nanoseconds
depending on whether the timing procedure is one-step or two-step and multiplied by 2^16. Note that depending on whether the timing
operation (Section 2.1), the residence time is either for the procedure is a one-step or two-step operation (Section 2.1), the
timing packet carried in the Value field of this RTM message or residence time is either for the timing packet carried in the
for an associated timing packet carried in the Value field of Value field of this RTM message or for an associated timing packet
another RTM message. carried in the Value field of another RTM message.
o The Type field identifies the type and encapsulation of a timing o The Type field identifies the type and encapsulation of a timing
packet carried in the Value field, e.g., NTP [RFC5905] or PTP packet carried in the Value field, e.g., NTP [RFC5905] or PTP
[IEEE.1588.2008]. This document asks IANA to create a sub- [IEEE.1588]. Per this document, IANA has created a sub-registry
registry in Generic Associated Channel (G-ACh) Parameters Registry called the "MPLS RTM TLV Registry" in the "Generic Associated
called "MPLS RTM TLV Registry" Section 7.2. Channel (G-ACh) Parameters" registry (see Section 7.2).
o The Length field contains the length, in octets, of the of the
timing packet carried in the Value field.
o The optional Value field MAY carry a packet of the time o The Length field contains the length, in octets, of any Value
synchronization protocol identified by Type field. It is field defined for the Type given in the Type field.
important to note that the packet may be authenticated or
encrypted and carried over LSP edge to edge unchanged while the
residence time is accumulated in the Scratch Pad field.
o The TLV MUST be included in the RTM message, even if the length of o The TLV MUST be included in the RTM message, even if the length of
the Value field is zero. the Value field is zero.
3.1. PTP Packet Sub-TLV 3.1. PTP Packet Sub-TLV
Figure 2 presents the format of a PTP sub-TLV that MUST be included Figure 2 presents the format of a PTP sub-TLV that MUST be included
in the Value field of an RTM message preceding the carried timing in the Value field of an RTM message preceding the carried timing
packet when the timing packet is PTP. packet when the timing packet is PTP.
skipping to change at page 9, line 33 skipping to change at page 10, line 27
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |PTPType| | Flags |PTPType|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID | | Port ID |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Sequence ID | | | Sequence ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PTP Sub-TLV format Figure 2: PTP Sub-TLV Format
where Flags field has format where the Flags field has the following format:
0 1 2 0 1 2
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Flags field format of PTP Packet Sub-TLV Figure 3: Flags Field Format of PTP Packet Sub-TLV
o The Type field identifies PTP packet sub-TLV and is set to 1 o The Type field identifies the PTP packet sub-TLV and is set to 1
according to Section 7.3. according to Section 7.3.
o The Length field of the PTP sub-TLV contains the number of octets o The Length field of the PTP sub-TLV contains the number of octets
of the Value field and MUST be 20. of the Value part of the TLV and MUST be 20.
o The Flags field currently defines one bit, the S-bit, that defines o The Flags field currently defines one bit, the S bit, that defines
whether the current message has been processed by a two-step node, whether the current message has been processed by a two-step node,
where the flag is cleared if the message has been handled where the flag is cleared if the message has been handled
exclusively by one-step nodes and there is no follow-up message, exclusively by one-step nodes and there is no follow-up message
and is set if there has been at least one two-step node and a and is set if there has been at least one two-step node and a
follow-up message is forthcoming. follow-up message is forthcoming.
o The PTPType field indicates the type of PTP packet carried in the o The PTPType field indicates the type of PTP packet to which this
TLV. PTPType is the messageType field of the PTPv2 packet whose PTP sub-TLV applies. PTPType is the messageType field of a PTPv2
values are defined in Table 19 of [IEEE.1588.2008]. packet with possible values defined in Table 19 of [IEEE.1588].
o The 10 octet long Port ID field contains the identity of the o The 10-octet-long Port ID field contains the identity of the
source port. source port.
o The Sequence ID is the sequence ID of the PTP message carried in o The Sequence ID is the sequence ID of the PTP message to which
the Value field of the message. this PTP sub-TLV applies.
Tuple of PTPType, Port ID, and Sequence ID uniquely identifies PTP A tuple of PTPType, Port ID, and Sequence ID uniquely identifies the
control packet encapsulated in RTM message and are used in two-step PTP timing message included in an RTM message and is used in two-step
RTM mode Section 2.1.1. RTM mode; see Section 2.1.1.
4. Control Plane Theory of Operation 3.2. PTP Associated Value Field
The Value field (see Figure 1) -- in addition to the PTP sub-TLV --
MAY carry a packet of the PTP Time synchronization protocol (as was
identified by the Type field). It is important to note that the
timing message packet may be authenticated or encrypted and carried
over this LSP unchanged (and inaccessible to intermediate RTM capable
LSRs) while the residence time is accumulated in the Scratch Pad
field.
The LSP ingress RTM-capable LSR populates the identifying tuple
information of the PTP sub-TLV (see section 3.1) prior to including
the (possibly authenticated/encrypted) PTP message packet after the
PTP sub-TLV in the Value field of the RTM message for an RTM message
of the PTP Type (Type 1; see Section 7.3).
4. Control-Plane Theory of Operation
The operation of RTM depends upon TTL expiry to deliver an RTM packet The operation of RTM depends upon TTL expiry to deliver an RTM packet
from one RTM capable interface to the next along the path from from one RTM-capable interface to the next along the path from
ingress node to egress node. This means that a node with RTM capable ingress node to egress node. This means that a node with RTM-capable
interfaces MUST be able to compute a TTL which will cause the expiry interfaces MUST be able to compute a TTL, which will cause the expiry
of an RTM packet at the next node with RTM capable interfaces. of an RTM packet at the next node with RTM-capable interfaces.
4.1. RTM Capability 4.1. RTM Capability
Note that the RTM capability of a node is with respect to the pair of Note that the RTM capability of a node is with respect to the pair of
interfaces that will be used to forward an RTM packet. In general, interfaces that will be used to forward an RTM packet. In general,
the ingress interface of this pair must be able to capture the the ingress interface of this pair must be able to capture the
arrival time of the packet and encode it in some way such that this arrival time of the packet and encode it in some way such that this
information will be available to the egress interface of a node. information will be available to the egress interface of a node.
The supported mode (one-step or two-step) of any pair of interfaces The supported mode (one-step or two-step) of any pair of interfaces
is determined by the capability of the egress interface. For both is determined by the capability of the egress interface. For both
modes, the egress interface implementation MUST be able to determine modes, the egress interface implementation MUST be able to determine
the precise departure time of the same packet and determine from the precise departure time of the same packet and determine from
this, and the arrival time information from the corresponding ingress this, and the arrival time information from the corresponding ingress
interface, the difference representing the residence time for the interface, the difference representing the residence time for the
packet. packet.
An interface with the ability to do this and update the associated An interface with the ability to do this and update the associated
Scratch Pad in real-time (i.e., while the packet is being forwarded) Scratch Pad in real time (i.e., while the packet is being forwarded)
is said to be one-step capable. is said to be one-step capable.
Hence while both ingress and egress interfaces are required to Hence, while both ingress and egress interfaces are required to
support RTM for the pair to be RTM-capable, it is the egress support RTM for the pair to be RTM capable, it is the egress
interface that determines whether or not the node is one-step or two- interface that determines whether or not the node is one-step or two-
step capable with respect to the interface-pair. step capable with respect to the interface pair.
The RTM capability used in the sub-TLV shown in Figure 4 and Figure 5 The RTM capability used in the sub-TLV shown in Figures 4 and 5 is
is thus a non-routing related capability associated with the thus a non-routing-related capability associated with the interface
interface being advertised based on its egress capability. The being advertised based on its egress capability. The ability of any
ability of any pair of interfaces on a node that includes this egress pair of interfaces on a node that includes this egress interface to
interface to support any mode of RTM depends on the ability of the support any mode of RTM depends on the ability of the ingress
ingress interface of a node to record packet arrival time and convey interface of a node to record packet arrival time and convey it to
it to the egress interface on the node. the egress interface on the node.
When a node uses an IGP to support the RTM capability advertisement, When a node uses an IGP to support the RTM capability advertisement,
the IGP sub-TLV MUST reflect the RTM capability (one-step or two- the IGP sub-TLV MUST reflect the RTM capability (one-step or two-
step) associated with the advertised interface. Changes of RTM step) associated with the advertised interface. Changes of RTM
capability are unlikely to be frequent and would result, for example, capability are unlikely to be frequent and would result, for example,
from operator's decision to include or exclude a particular port from from the operator's decision to include or exclude a particular port
RTM processing or switch between RTM modes. from RTM processing or switch between RTM modes.
4.2. RTM Capability Sub-TLV 4.2. RTM Capability Sub-TLV
[RFC4202] explains that the Interface Switching Capability Descriptor [RFC4202] explains that the Interface Switching Capability Descriptor
describes the switching capability of an interface. For bi- describes the switching capability of an interface. For
directional links, the switching capabilities of an interface are bidirectional links, the switching capabilities of an interface are
defined to be the same in either direction. I.e., for data entering defined to be the same in either direction, that is, for data
the node through that interface and for data leaving the node through entering the node through that interface and for data leaving the
that interface. That principle SHOULD be applied when a node node through that interface. That principle SHOULD be applied when a
advertises RTM Capability. node advertises RTM capability.
A node that supports RTM MUST be able to act in two-step mode and MAY A node that supports RTM MUST be able to act in two-step mode and MAY
also support one-step RTM mode. Detailed discussion of one-step and also support one-step RTM mode. A detailed discussion of one-step
two-step RTM modes is contained in Section 2.1. and two-step RTM modes is contained in Section 2.1.
4.3. RTM Capability Advertisement in Routing Protocols 4.3. RTM Capability Advertisement in Routing Protocols
4.3.1. RTM Capability Advertisement in OSPFv2 4.3.1. RTM Capability Advertisement in OSPFv2
The format for the RTM Capability sub-TLV in OSPF is presented in The format for the RTM Capability sub-TLV in OSPF is presented in
Figure 4 Figure 4.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTM | Value ... | RTM | Value ...
+-+-+-+-+-+-+-+-+-+- ... +-+-+-+-+-+-+-+-+-+- ...
Figure 4: RTM Capability sub-TLV in OSPFv2 Figure 4: RTM Capability Sub-TLV in OSPFv2
o Type value (TBA2) will be assigned by IANA from appropriate o Type value (5) has been assigned by IANA in the "OSPFv2 Extended
registry for OSPFv2 Section 7.4. Link TLV Sub-TLVs" registry (see Section 7.4).
o Length value equals number of octets of the Value field. o Length value equals the number of octets of the Value field.
o Value contains variable number of bit-map fields so that overall o Value contains a variable number of bitmap fields so that the
number of bits in the fields equals Length * 8. overall number of bits in the fields equals Length * 8.
o Bits are defined/sent starting with Bit 0. Additional bit-map o Bits are defined/sent starting with Bit 0. Additional bitmap
field definitions that may be defined in the future SHOULD be field definitions that may be defined in the future SHOULD be
assigned in ascending bit order so as to minimize the number of assigned in ascending bit order so as to minimize the number of
bits that will need to be transmitted. bits that will need to be transmitted.
o Undefined bits MUST be transmitted as 0 and MUST be ignored on o Undefined bits MUST be transmitted as 0 and MUST be ignored on
receipt. receipt.
o Bits that are NOT transmitted MUST be treated as if they are set o Bits that are NOT transmitted MUST be treated as if they are set
to 0 on receipt. to 0 on receipt.
o RTM (capability) - is a three-bit long bit-map field with values o RTM (capability) is a 3-bit-long bitmap field with values defined
defined as follows: as follows:
* 0b001 - one-step RTM supported; * 0b001 - one-step RTM supported
* 0b010 - two-step RTM supported; * 0b010 - two-step RTM supported
* 0b100 - reserved. * 0b100 - reserved
The capability to support RTM on a particular link (interface) is The capability to support RTM on a particular link (interface) is
advertised in the OSPFv2 Extended Link Opaque LSA described in advertised in the OSPFv2 Extended Link Opaque LSA as described in
Section 3 [RFC7684] via the RTM Capability sub-TLV. Section 3 of [RFC7684] via the RTM Capability sub-TLV.
Its Type value will be assigned by IANA from the OSPF Extended Link
TLV Sub-TLVs registry Section 7.4, that will be created per [RFC7684]
request.
4.3.2. RTM Capability Advertisement in OSPFv3 4.3.2. RTM Capability Advertisement in OSPFv3
The capability to support RTM on a particular link (interface) can be The capability to support RTM on a particular link (interface) can be
advertised in OSPFv3 using LSA extensions as described in advertised in OSPFv3 using LSA extensions as described in
[I-D.ietf-ospf-ospfv3-lsa-extend]. The sub-TLV SHOULD use the same [OSPFV3-EXTENDED-LSA]. The sub-TLV SHOULD use the same format as in
format as in Section 4.3.1. The type allocation and full details of Section 4.3.1. The type allocation and full details of exact use of
exact use of OSPFv3 LSA extensions is for further study. OSPFv3 LSA extensions is for further study.
4.3.3. RTM Capability Advertisement in IS-IS 4.3.3. RTM Capability Advertisement in IS-IS
The capability to support RTM on a particular link (interface) is The capability to support RTM on a particular link (interface) is
advertised in a new sub-TLV which may be included in TLVs advertising advertised in a new sub-TLV that may be included in TLVs advertising
Intermediate System (IS) Reachability on a specific link (TLVs 22, Intermediate System (IS) Reachability on a specific link (TLVs 22,
23, 222, and 223). 23, 222, and 223).
The format for the RTM Capabilities sub-TLV is presented in Figure 5 The format for the RTM Capability sub-TLV is presented in Figure 5.
0 1 2 0 1 2
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 ... 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| Type | Length | RTM | Value ... | Type | Length | RTM | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Figure 5: RTM Capability sub-TLV Figure 5: RTM Capability Sub-TLV
o Type value (TBA3) will be assigned by IANA from the Sub-TLVs for o Type value (40) has been assigned by IANA in the "Sub-TLVs for
TLVs 22, 23, 141, 222, and 223 registry for IS-IS Section 7.5. TLVs 22, 23, 141, 222, and 223" registry for IS-IS (see
Section 7.5).
o Definitions, rules of handling, and values for fields Length and o Definitions, rules of handling, and values for the Length and
Value are as defined in Section 4.3.1 Value fields are as defined in Section 4.3.1.
o RTM (capability) - is a three-bit long bit-map field with values o RTM (capability) is a 3-bit-long bitmap field with values defined
defined in Section 4.3.1. in Section 4.3.1.
4.3.4. RTM Capability Advertisement in BGP-LS 4.3.4. RTM Capability Advertisement in BGP-LS
The format for the RTM Capabilities TLV is as presented in Figure 4. The format for the RTM Capability TLV is presented in Figure 4.
Type value TBA9 will be assigned by IANA from the BGP-LS Node Type value (1105) has been assigned by IANA in the "BGP-LS Node
Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs"
sub-registry Section 7.6. sub-registry (see Section 7.6).
Definitions, rules of handling, and values for fields Length, Value, Definitions, rules of handling, and values for fields Length, Value,
and RTM are as defined in Section 4.3.1. and RTM are as defined in Section 4.3.1.
The RTM Capability will be advertised in BGP-LS as a Link Attribute The RTM capability will be advertised in BGP-LS as a Link Attribute
TLV associated with the Link NLRI as described in section 3.3.2 of TLV associated with the Link NLRI as described in Section 3.3.2 of
[RFC7752]. [RFC7752].
4.4. RSVP-TE Control Plane Operation to Support RTM 4.4. RSVP-TE Control-Plane Operation to Support RTM
Throughout this document we refer to a node as RTM capable node when Throughout this document, we refer to a node as an RTM-capable node
at least one of its interfaces is RTM capable. Figure 6 provides an when at least one of its interfaces is RTM capable. Figure 6
example of roles a node may have with respect to RTM capability: provides an example of roles a node may have with respect to RTM
capability:
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
| A |-----| B |-----| C |-----| D |-----| E |-----| F |-----| G | | A |-----| B |-----| C |-----| D |-----| E |-----| F |-----| G |
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
Figure 6: RTM capable roles Figure 6: RTM-Capable Roles
o A is a BC with its egress port in Master state. Node A transmits o A is a boundary clock with its egress port in Master state. Node
IP encapsulated timing packets whose destination IP address is G. A transmits IP-encapsulated timing packets whose destination IP
address is G.
o B is the ingress LER for the MPLS LSP and is the first RTM capable o B is the ingress Label Edge Router (LER) for the MPLS LSP and is
node. It creates RTM packets and in each it places a timing the first RTM-capable node. It creates RTM packets, and in each
packet, possibly encrypted, in the Value field and initializes the it places a timing packet, possibly encrypted, in the Value field
Scratch Pad field with its residence time measurement and initializes the Scratch Pad field with its RTM.
o C is a transit node that is not RTM capable. It forwards RTM o C is a transit node that is not RTM capable. It forwards RTM
packets without modification. packets without modification.
o D is RTM capable transit node. It updates the Scratch Pad field o D is an RTM-capable transit node. It updates the Scratch Pad
of the RTM packet without updating the timing packet. field of the RTM packet without updating the timing packet.
o E is a transit node that is not RTM capable. It forwards RTM o E is a transit node that is not RTM capable. It forwards RTM
packets without modification. packets without modification.
o F is the egress LER and the last RTM capable node. It removes the o F is the egress LER and the last RTM-capable node. It removes the
RTM ACH encapsulation and processes the timing packet carried in RTM ACH encapsulation and processes the timing packet carried in
the Value field using the value in the Scratch Pad field. In the Value field using the value in the Scratch Pad field. In
particular, the value in the Scratch Pad field of the RTM ACH is particular, the value in the Scratch Pad field of the RTM ACH is
used in updating the Correction field of the PTP message(s). The used in updating the Correction field of the PTP message(s). The
LER should also include its own residence time before creating the LER should also include its own residence time before creating the
outgoing PTP packets. The details of this process depend on outgoing PTP packets. The details of this process depend on
whether or not the node F is itself operating as one-step or two- whether or not the node F is itself operating as a one-step or
step clock. two-step clock.
o G is a Boundary Clock with its ingress port in Slave state. Node o G is a boundary clock with its ingress port in Slave state. Node
G receives PTP messages. G receives PTP messages.
An ingress node that is configured to perform RTM along a path An ingress node that is configured to perform RTM along a path
through an MPLS network to an egress node MUST verify that the through an MPLS network to an egress node MUST verify that the
selected egress node has an interface that supports RTM via the selected egress node has an interface that supports RTM via the
egress node's advertisement of the RTM Capability sub-TLV, as covered egress node's advertisement of the RTM Capability sub-TLV, as covered
in Section 4.3. In the Path message that the ingress node uses to in Section 4.3. In the Path message that the ingress node uses to
instantiate the LSP to that egress node, it places an LSP_ATTRIBUTES instantiate the LSP to that egress node, it places an LSP_ATTRIBUTES
Object [RFC5420] with RTM_SET Attribute Flag set, as described in object [RFC5420] with an RTM_SET Attribute Flag set, as described in
Section 7.8, which indicates to the egress node that RTM is requested Section 7.8, which indicates to the egress node that RTM is requested
for this LSP. The RTM_SET Attribute Flag SHOULD NOT be set in the for this LSP. The RTM_SET Attribute Flag SHOULD NOT be set in the
LSP_REQUIRED_ATTRIBUTES object [RFC5420], unless it is known that all LSP_REQUIRED_ATTRIBUTES object [RFC5420], unless it is known that all
nodes recognize the RTM attribute (but need not necessarily implement nodes recognize the RTM attribute (but need not necessarily implement
it), because a node that does not recognize the RTM_SET Attribute it), because a node that does not recognize the RTM_SET Attribute
Flag would reject the Path message. Flag would reject the Path message.
If an egress node receives a Path message with the RTM_SET Attribute If an egress node receives a Path message with the RTM_SET Attribute
Flag in LSP_ATTRIBUTES object, the egress node MUST include an Flag in an LSP_ATTRIBUTES object, the egress node MUST include an
initialized RRO [RFC3209] and LSP_ATTRIBUTES object where the RTM_SET initialized RRO [RFC3209] and LSP_ATTRIBUTES object where the RTM_SET
Attribute Flag is set and the RTM_SET TLV Section 4.4.1 is Attribute Flag is set and the RTM_SET TLV (Section 4.4.1) is
initialized. When the Resv message is received by the ingress node, initialized. When the Resv message is received by the ingress node,
the RTM_SET TLV will contain an ordered list, from egress node to the RTM_SET TLV will contain an ordered list, from egress node to
ingress node, of the RTM capable nodes along the LSP's path. ingress node, of the RTM-capable nodes along the LSP's path.
After the ingress node receives the Resv, it MAY begin sending RTM After the ingress node receives the Resv, it MAY begin sending RTM
packets on the LSP's path. Each RTM packet has its Scratch Pad field packets on the LSP's path. Each RTM packet has its Scratch Pad field
initialized and its TTL set to expire on the closest downstream RTM initialized and its TTL set to expire on the closest downstream RTM-
capable node. capable node.
It should be noted that RTM can also be used for LSPs instantiated It should be noted that RTM can also be used for LSPs instantiated
using [RFC3209] in an environment in which all interfaces in an IGP using [RFC3209] in an environment in which all interfaces in an IGP
support RTM. In this case the RTM_SET TLV and LSP_ATTRIBUTES Object support RTM. In this case, the RTM_SET TLV and LSP_ATTRIBUTES object
MAY be omitted. MAY be omitted.
4.4.1. RTM_SET TLV 4.4.1. RTM_SET TLV
RTM capable interfaces can be recorded via RTM_SET TLV. The RTM_SET RTM-capable interfaces can be recorded via the RTM_SET TLV. The
sub-object format is of generic Type, Length, Value (TLV), presented RTM_SET sub-object format is a generic TLV format, presented in
in Figure 7 . Figure 7.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |I| Reserved | | Type | Length |I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~ ~ Value ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: RTM_SET TLV format Figure 7: RTM_SET TLV Format
The type value (TBA4) will be assigned by IANA from its RSVP-TE Type value (5) has been assigned by IANA in the RSVP-TE "Attributes
Attributes TLV Space sub-registry Section 7.7. TLV Space" sub-registry (see Section 7.7).
The Length contains the total length of the sub-object in bytes, The Length contains the total length of the sub-object in bytes,
including the Type and Length fields. including the Type and Length fields.
The I bit flag indicates whether the downstream RTM capable node The I bit indicates whether the downstream RTM-capable node along the
along the LSP is present in the RRO. LSP is present in the RRO.
The Reserved field must be zeroed on initiation and ignored on The Reserved field must be zeroed on initiation and ignored on
receipt. receipt.
The content of an RTM_SET TLV is a series of variable-length sub- The content of an RTM_SET TLV is a series of variable-length
TLVs. Only a single RTM_SET can be present in a given LSP_ATTRIBUTES sub-TLVs. Only a single RTM_SET can be present in a given
object. The sub-TLVs are defined in Section 4.4.1.1 below. LSP_ATTRIBUTES object. The sub-TLVs are defined in Section 4.4.1.1.
The following processing procedures apply to every RTM capable node The following processing procedures apply to every RTM-capable node
along the LSP. In this paragraph, an RTM capable node is referred to along the LSP. In this paragraph, an RTM-capable node is referred to
as a node for sake of brevity. Each node MUST examine the Resv as a node for sake of brevity. Each node MUST examine the Resv
message for whether the RTM_SET Attribute Flag in the LSP_ATTRIBUTES message for whether the RTM_SET Attribute Flag in the LSP_ATTRIBUTES
object is set. If the RTM_SET flag is set, the node MUST inspect the object is set. If the RTM_SET flag is set, the node MUST inspect the
LSP_ATTRIBUTES object for presence of an RTM_SET TLV. If more than LSP_ATTRIBUTES object for presence of an RTM_SET TLV. If more than
one is found, then the LSP setup MUST fail with generation of the one is found, then the LSP setup MUST fail with generation of the
ResvErr message with Error Code Duplicate TLV (Section 7.9) and Error ResvErr message with Error Code "Duplicate TLV" (Section 7.9) and
Value that contains Type value in its 8 least significant bits. If Error Value that contains the Type value in its 8 least significant
no RTM_SET TLV is found, then the LSP setup MUST fail with generation bits. If no RTM_SET TLV is found, then the LSP setup MUST fail with
of the ResvErr message with Error Code RTM_SET TLV Absent generation of the ResvErr message with Error Code "RTM_SET TLV
Section 7.9. If one RTM_SET TLV has been found, the node will use Absent" (Section 7.9). If one RTM_SET TLV has been found, the node
the ID of the first node in the RTM_SET in conjunction with the RRO will use the ID of the first node in the RTM_SET in conjunction with
to compute the hop count to its downstream node with reachable RTM the RRO to compute the hop count to its downstream node with a
capable interface. If the node cannot find a matching ID in the RRO, reachable RTM-capable interface. If the node cannot find a matching
then it MUST try to use the ID of the next node in the RTM_SET until ID in the RRO, then it MUST try to use the ID of the next node in the
it finds the match or reaches the end of the RTM_SET TLV. If a match RTM_SET until it finds the match or reaches the end of the RTM_SET
has been found, the calculated value is used by the node as the TTL TLV. If a match has been found, the calculated value is used by the
value in the outgoing label to reach the next RTM capable node on the node as the TTL value in the outgoing label to reach the next RTM-
LSP. Otherwise, the TTL value MUST be set to 255. The node MUST add capable node on the LSP. Otherwise, the TTL value MUST be set to
an RTM_SET sub-TLV with the same address it used in the RRO sub- 255. The node MUST add an RTM_SET sub-TLV with the same address it
object at the beginning of the RTM_SET TLV in the associated outgoing used in the RRO sub-object at the beginning of the RTM_SET TLV in the
Resv message before forwarding it upstream. If the calculated TTL associated outgoing Resv message before forwarding it upstream. If
value has been set to 255, as described above, then the I flag in the the calculated TTL value has been set to 255, as described above,
node's RTM_SET TLV MUST be set to 1 before the Resv message is then the I flag in the node's RTM_SET TLV MUST be set to 1 before the
forwarded upstream. Otherwise, the I flag MUST be cleared (0). Resv message is forwarded upstream. Otherwise, the I flag MUST be
cleared (0).
The ingress node MAY inspect the I bit flag received in each RTM_SET The ingress node MAY inspect the I bit received in each RTM_SET TLV
TLV contained in the LSP_ATTRIBUTES object of a received Resv contained in the LSP_ATTRIBUTES object of a received Resv message.
message. The presence of the RTM_SET TLV with the I bit field set to The presence of the RTM_SET TLV with the I bit set to 1 indicates
1 indicates that some RTM nodes along the LSP could not be included that some RTM nodes along the LSP could not be included in the
in the calculation of the residence time. An ingress node MAY choose calculation of the residence time. An ingress node MAY choose to
to resignal the LSP to include all RTM nodes or simply notify the resignal the LSP to include all RTM nodes or simply notify the user
user via a management interface. via a management interface.
There are scenarios when some information is removed from an RRO due There are scenarios when some information is removed from an RRO due
to policy processing (e.g., as may happen between providers) or the to policy processing (e.g., as may happen between providers) or the
RRO is limited due to size constraints. Such changes affect the core RRO is limited due to size constraints. Such changes affect the core
assumption of this method and the processing of RTM packets. RTM assumption of this method and the processing of RTM packets. RTM
SHOULD NOT be used if it is not guaranteed that the RRO contains SHOULD NOT be used if it is not guaranteed that the RRO contains
complete information. complete information.
4.4.1.1. RTM_SET Sub-TLVs 4.4.1.1. RTM_SET Sub-TLVs
The RTM Set sub-object contains an ordered list, from egress node to The RTM Set sub-object contains an ordered list, from egress node to
ingress node, of the RTM capable nodes along the LSP's path. ingress node, of the RTM-capable nodes along the LSP's path.
The contents of a RTM_SET sub-object are a series of variable-length The contents of an RTM_SET sub-object are a series of variable-length
sub-TLVs. Each sub-TLV has its own Length field. The Length sub-TLVs. Each sub-TLV has its own Length field. The Length
contains the total length of the sub-TLV in bytes, including the Type contains the total length of the sub-TLV in bytes, including the Type
and Length fields. The Length MUST always be a multiple of 4, and at and Length fields. The Length MUST always be a multiple of 4, and at
least 8 (smallest IPv4 sub-object). least 8 (smallest IPv4 sub-object).
Sub-TLVs are organized as a last-in-first-out stack. The first-out Sub-TLVs are organized as a last-in-first-out stack. The first-out
sub-TLV relative to the beginning of RTM_SET TLV is considered the sub-TLV relative to the beginning of RTM_SET TLV is considered the
top. The last-out sub-TLV is considered the bottom. When a new sub- top. The last-out sub-TLV is considered the bottom. When a new
TLV is added, it is always added to the top. sub-TLV is added, it is always added to the top.
The RTM_SET TLV is intended to include the subset of the RRO sub-TLVs The RTM_SET TLV is intended to include the subset of the RRO sub-TLVs
that represents those egress interfaces on the LSP that are RTM- that represent those egress interfaces on the LSP that are RTM
capable. After a node chooses an egress interface to use in the RRO capable. After a node chooses an egress interface to use in the RRO
sub-TLV, that same egress interface, if RTM-capable, SHOULD be placed sub-TLV, that same egress interface, if RTM capable, SHOULD be placed
into the RTM_SET TLV using one of the IPv4 sub-TLV, IPv6 sub-TLV, or into the RTM_SET TLV using one of the following: IPv4 sub-TLV, IPv6
Unnumbered Interface sub-TLV. The address family chosen SHOULD match sub-TLV, or Unnumbered Interface sub-TLV. The address family chosen
that of the RESV message and that used in the RRO; the unnumbered SHOULD match that of the RESV message and that used in the RRO; the
interface sub-TLV is used when the egress interface has no assigned unnumbered interface sub-TLV is used when the egress interface has no
IP address. A node MUST NOT place more sub-TLVs in the RTM_SET TLV assigned IP address. A node MUST NOT place more sub-TLVs in the
than the number of RTM-capable egress interfaces the LSP traverses RTM_SET TLV than the number of RTM-capable egress interfaces the LSP
that are under that node's control. Only a single RTM_SET sub-TLV traverses that are under that node's control. Only a single RTM_SET
with the given Value field MUST be present in the RTM_SET TLV. If sub-TLV with the given Value field MUST be present in the RTM_SET
more than one sub-TLV with the same value (e.g., a duplicated TLV. If more than one sub-TLV with the same value (e.g., a
address) is found the LSP setup MUST fail with the generation of a duplicated address) is found, the LSP setup MUST fail with the
ResvErr message with the Error Code "Duplicate sub-TLV" Section 7.9 generation of a ResvErr message with the Error Code "Duplicate
and Error Value contains 16-bit value composed of (Type of TLV, Type sub-TLV" (Section 7.9) and the Error Value containing a 16-bit value
of sub-TLV). composed of (Type of TLV, Type of sub-TLV).
Three kinds of sub-TLVs for RTM_SET are currently defined. Three kinds of sub-TLVs for RTM_SET are currently defined.
4.4.1.1.1. IPv4 Sub-TLV 4.4.1.1.1. IPv4 Sub-TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: IPv4 sub-TLV format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Figure 8: IPv4 Sub-TLV Format
0x01 IPv4 address Type
0x01 IPv4 address.
Length Length
The Length contains the total length of the sub-TLV in bytes, The Length contains the total length of the sub-TLV in bytes,
including the Type and Length fields. The Length is always 8. including the Type and Length fields. The Length is always 8.
IPv4 address IPv4 address
A 32-bit unicast host address. A 32-bit unicast host address.
Reserved Reserved
Zeroed on initiation and ignored on receipt. Zeroed on initiation and ignored on receipt.
4.4.1.1.2. IPv6 Sub-TLV 4.4.1.1.2. IPv6 Sub-TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 address | | IPv6 address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: IPv6 sub-TLV format Figure 9: IPv6 Sub-TLV Format
Type Type
0x02 IPv6 address.
0x02 IPv6 address
Length Length
The Length contains the total length of the sub-TLV in bytes, The Length contains the total length of the sub-TLV in bytes,
including the Type and Length fields. The Length is always 20. including the Type and Length fields. The Length is always 20.
IPv6 address IPv6 address
A 128-bit unicast host address. A 128-bit unicast host address.
Reserved Reserved
Zeroed on initiation and ignored on receipt. Zeroed on initiation and ignored on receipt.
4.4.1.1.3. Unnumbered Interface Sub-TLV 4.4.1.1.3. Unnumbered Interface Sub-TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node ID | | Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID | | Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: IPv4 sub-TLV format Figure 10: IPv4 Sub-TLV Format
Type Type
0x03 Unnumbered interface.
0x03 Unnumbered interface
Length Length
The Length contains the total length of the sub-TLV in bytes, The Length contains the total length of the sub-TLV in bytes,
including the Type and Length fields. The Length is always 12. including the Type and Length fields. The Length is always 12.
Node ID Node ID
The Node ID interpreted as the Router ID as discussed in Section 2
The Node ID interpreted as Router ID as discussed in Section 2 of [RFC3477].
[RFC3477].
Interface ID Interface ID
The identifier assigned to the link by the node specified by the The identifier assigned to the link by the node specified by the
Node ID. Node ID.
Reserved Reserved
Zeroed on initiation and ignored on receipt. Zeroed on initiation and ignored on receipt.
5. Data Plane Theory of Operation 5. Data-Plane Theory of Operation
After instantiating an LSP for a path using RSVP-TE [RFC3209] as After instantiating an LSP for a path using RSVP-TE [RFC3209] as
described in Section 4.4, the ingress node MAY begin sending RTM described in Section 4.4, the ingress node MAY begin sending RTM
packets to the first downstream RTM capable node on that path. Each packets to the first downstream RTM-capable node on that path. Each
RTM packet has its Scratch Pad field initialized and its TTL set to RTM packet has its Scratch Pad field initialized and its TTL set to
expire on the next downstream RTM-capable node. Each RTM-capable expire on the next downstream RTM-capable node. Each RTM-capable
node on the explicit path receives an RTM packet and records the time node on the explicit path receives an RTM packet and records the time
at which it receives that packet at its ingress interface as well as at which it receives that packet at its ingress interface as well as
the time at which it transmits that packet from its egress interface. the time at which it transmits that packet from its egress interface.
These actions should be done as close to the physical layer as These actions should be done as close to the physical layer as
possible at the same point of packet processing striving to avoid possible at the same point of packet processing, striving to avoid
introducing the appearance of jitter in propagation delay whereas it introducing the appearance of jitter in propagation delay whereas it
should be accounted as residence time. The RTM-capable node should be accounted as residence time. The RTM-capable node
determines the difference between those two times; for one-step determines the difference between those two times; for one-step
operation, this difference is determined just prior to or while operation, this difference is determined just prior to or while
sending the packet, and the RTM-capable egress interface adds it to sending the packet, and the RTM-capable egress interface adds it to
the value in the Scratch Pad field of the message in progress. Note, the value in the Scratch Pad field of the message in progress. Note,
for the purpose of calculating a residence time, a common free for the purpose of calculating a residence time, a common free
running clock synchronizing all the involved interfaces may be running clock synchronizing all the involved interfaces may be
sufficient, as, for example, 4.6 ppm accuracy leads to 4.6 nanosecond sufficient, as, for example, 4.6 ppm accuracy leads to a 4.6
error for residence time on the order of 1 millisecond. This may be nanosecond error for residence time on the order of 1 millisecond.
acceptable for applications where the target accuracy is in the order This may be acceptable for applications where the target accuracy is
of hundreds of ns. As an example, several applications being in the order of hundreds of nanoseconds. As an example, several
considered in the area of wireless applications are satisfied with an applications being considered in the area of wireless applications
accuracy of 1.5 microseconds [ITU-T.G.8271]. are satisfied with an accuracy of 1.5 microseconds [ITU-T.G.8271].
For two-step operation, the difference between packet arrival time For two-step operation, the difference between packet arrival time
(at an ingress interface) and subsequent departure time (from an (at an ingress interface) and subsequent departure time (from an
egress interface) is determined at some later time prior to sending a egress interface) is determined at some later time prior to sending a
subsequent follow-up message, so that this value can be used to subsequent follow-up message, so that this value can be used to
update the correctionField in the follow-up message. update the correctionField in the follow-up message.
See Section 2.1 for further details on the difference between one- See Section 2.1 for further details on the difference between one-
step and two-step operation. step and two-step operation.
The last RTM-capable node on the LSP MAY then use the value in the The last RTM-capable node on the LSP MAY then use the value in the
Scratch Pad field to perform time correction, if there is no follow- Scratch Pad field to perform time correction, if there is no
up message. For example, the egress node may be a PTP Boundary Clock follow-up message. For example, the egress node may be a PTP
synchronized to a Master Clock and will use the value in the Scratch boundary clock synchronized to a Master Clock and will use the value
Pad field to update PTP's correctionField. in the Scratch Pad field to update PTP's correctionField.
6. Applicable PTP Scenarios 6. Applicable PTP Scenarios
This approach can be directly integrated in a PTP network based on This approach can be directly integrated in a PTP network based on
the IEEE 1588 delay request-response mechanism. The RTM capable the IEEE 1588 delay request-response mechanism. The RTM-capable
nodes act as end-to-end transparent clocks, and typically boundary nodes act as end-to-end transparent clocks, and boundary clocks, at
clocks, at the edges of the MPLS network, use the value in the the edges of the MPLS network, typically use the value in the Scratch
Scratch Pad field to update the correctionField of the corresponding Pad field to update the correctionField of the corresponding PTP
PTP event packet prior to performing the usual PTP processing. event packet prior to performing the usual PTP processing.
7. IANA Considerations 7. IANA Considerations
7.1. New RTM G-ACh 7.1. New RTM G-ACh
IANA is requested to reserve a new G-ACh as follows: IANA has assigned a new G-ACh as follows:
+-------+----------------------------+---------------+ +--------+----------------------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+----------------------------+---------------+ +--------+----------------------------+---------------+
| TBA1 | Residence Time Measurement | This document | | 0x000F | Residence Time Measurement | This document |
+-------+----------------------------+---------------+ +--------+----------------------------+---------------+
Table 1: New Residence Time Measurement Table 1: New Residence Time Measurement
7.2. New RTM TLV Registry 7.2. New MPLS RTM TLV Registry
IANA is requested to create a sub-registry in the Generic Associated IANA has created a sub-registry in the "Generic Associated Channel
Channel (G-ACh) Parameters Registry called "MPLS RTM TLV Registry". (G-ACh) Parameters" registry called the "MPLS RTM TLV Registry". All
All code points in the range 0 through 127 in this registry shall be codepoints in the range 0 through 127 in this registry shall be
allocated according to the "IETF Review" procedure as specified in allocated according to the "IETF Review" procedure as specified in
[RFC5226]. Code points in the range 128 through 191 in this registry [RFC5226]. Codepoints in the range 128 through 191 in this registry
shall be allocated according to the "First Come First Served" shall be allocated according to the "First Come First Served"
procedure as specified in [RFC5226]. This document defines the procedure as specified in [RFC5226]. This document defines the
following new values RTM TLV types: following new RTM TLV types:
+-----------+-------------------------------+---------------+ +---------+-------------------------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-----------+-------------------------------+---------------+ +---------+-------------------------------+---------------+
| 0 | Reserved | This document | | 0 | Reserved | This document |
| 1 | No payload | This document | | 1 | No payload | This document |
| 2 | PTPv2, Ethernet encapsulation | This document | | 2 | PTPv2, Ethernet encapsulation | This document |
| 3 | PTPv2, IPv4 Encapsulation | This document | | 3 | PTPv2, IPv4 encapsulation | This document |
| 4 | PTPv2, IPv6 Encapsulation | This document | | 4 | PTPv2, IPv6 encapsulation | This document |
| 5 | NTP | This document | | 5 | NTP | This document |
| 6-127 | Unassigned | | | 6-191 | Unassigned | |
| 128 - 191 | Unassigned | | | 192-254 | Reserved for Private Use | This document |
| 192 - 254 | Private Use | This document | | 255 | Reserved | This document |
| 255 | Reserved | This document | +---------+-------------------------------+---------------+
+-----------+-------------------------------+---------------+
Table 2: RTM TLV Type Table 2: RTM TLV Types
7.3. New RTM Sub-TLV Registry 7.3. New MPLS RTM Sub-TLV Registry
IANA is requested to create a sub-registry in the MPLS RTM TLV IANA has created a sub-registry in the "MPLS RTM TLV Registry" (see
Registry, requested in Section 7.2, called "MPLS RTM Sub-TLV Section 7.2) called the "MPLS RTM Sub-TLV Registry". All codepoints
Registry". All code points in the range 0 through 127 in this in the range 0 through 127 in this registry shall be allocated
registry shall be allocated according to the "IETF Review" procedure according to the "IETF Review" procedure as specified in [RFC5226].
as specified in [RFC5226]. Code points in the range 128 through 191 Codepoints in the range 128 through 191 in this registry shall be
in this registry shall be allocated according to the "First Come allocated according to the "First Come First Served" procedure as
First Served" procedure as specified in [RFC5226]. This document specified in [RFC5226]. This document defines the following new RTM
defines the following new values RTM sub-TLV types: sub-TLV types:
+-----------+-------------+---------------+ +---------+--------------------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-----------+-------------+---------------+ +---------+--------------------------+---------------+
| 0 | Reserved | This document | | 0 | Reserved | This document |
| 1 | PTP | This document | | 1 | PTP | This document |
| 2-127 | Unassigned | | | 2-191 | Unassigned | |
| 128 - 191 | Unassigned | | | 192-254 | Reserved for Private Use | This document |
| 192 - 254 | Private Use | This document | | 255 | Reserved | This document |
| 255 | Reserved | This document | +---------+--------------------------+---------------+
+-----------+-------------+---------------+
Table 3: RTM Sub-TLV Type Table 3: RTM Sub-TLV Type
7.4. RTM Capability sub-TLV in OSPFv2 7.4. RTM Capability Sub-TLV in OSPFv2
IANA is requested to assign a new type for RTM Capability sub-TLV IANA has assigned a new type for the RTM Capability sub-TLV in the
from the OSPFv2 Extended Link TLV Sub-TLVs registry as follows: "OSPFv2 Extended Link TLV Sub-TLVs" registry as follows:
+-------+----------------+---------------+ +-------+----------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+----------------+---------------+ +-------+----------------+---------------+
| TBA2 | RTM Capability | This document | | 5 | RTM Capability | This document |
+-------+----------------+---------------+ +-------+----------------+---------------+
Table 4: RTM Capability sub-TLV Table 4: RTM Capability Sub-TLV
7.5. IS-IS RTM Capability sub-TLV 7.5. RTM Capability Sub-TLV in IS-IS
IANA is requested to assign a new Type for the RTM Capability sub-TLV IANA has assigned a new type for the RTM Capability sub-TLV from the
from the Sub-TLVs for TLVs 22, 23, 141, 222, and 223 registry as "Sub-TLVs for TLVs 22, 23, 141, 222, and 223" registry as follows:
follows:
+------+----------------+----+----+-----+-----+-----+---------------+ +------+----------------+----+----+-----+-----+-----+---------------+
| Type | Description | 22 | 23 | 141 | 222 | 223 | Reference | | Type | Description | 22 | 23 | 141 | 222 | 223 | Reference |
+------+----------------+----+----+-----+-----+-----+---------------+ +------+----------------+----+----+-----+-----+-----+---------------+
| TBA3 | RTM Capability | y | y | n | y | y | This document | | 40 | RTM Capability | y | y | n | y | y | This document |
+------+----------------+----+----+-----+-----+-----+---------------+ +------+----------------+----+----+-----+-----+-----+---------------+
Table 5: IS-IS RTM Capability sub-TLV Registry Description Table 5: IS-IS RTM Capability Sub-TLV Registry Description
7.6. RTM Capability TLV in BGP-LS 7.6. RTM Capability TLV in BGP-LS
IANA is requested to assign a new code point for the RTM Capability IANA has assigned a new codepoint for the RTM Capability TLV from the
TLV from the BGP-LS Node Descriptor, Link Descriptor, Prefix "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and
Descriptor, and Attribute TLVs sub-registry in its Border Gateway Attribute TLVs" sub-registry in the "Border Gateway Protocol - Link
Protocol - Link State (BGP-LS) Parameters registry as follows: State (BGP-LS) Parameters" registry as follows:
+---------------+----------------+------------------+---------------+ +---------------+----------------+------------------+---------------+
| TLV Code | Description | IS-IS TLV/Sub- | Reference | | TLV Code | Description | IS-IS TLV/Sub- | Reference |
| Point | | TLV | | | Point | | TLV | |
+---------------+----------------+------------------+---------------+ +---------------+----------------+------------------+---------------+
| TBA9 | RTM Capability | 22/TBA3 | This document | | 1105 | RTM Capability | 22/40 | This document |
+---------------+----------------+------------------+---------------+ +---------------+----------------+------------------+---------------+
Table 6: RTM Capability TLV in BGP-LS Table 6: RTM Capability TLV in BGP-LS
7.7. RTM_SET Sub-object RSVP Type and sub-TLVs 7.7. RTM_SET Sub-object RSVP Type and Sub-TLVs
IANA is requested to assign a new Type for the RTM_SET sub-object IANA has assigned a new type for the RTM_SET sub-object from the
from the RSVP-TE Attributes TLV Space sub-registry as follows: RSVP-TE "Attributes TLV Space" sub-registry as follows:
+-----+------------+-----------+---------------+---------+----------+ +------+------------+-----------+---------------+-----------+----------+
| Typ | Name | Allowed | Allowed on | Allowed | Referenc | | Type | Name | Allowed | Allowed on | Allowed | Reference|
| e | | on LSP_A | LSP_REQUIRED_ | on LSP | e | | | | on LSP_ | LSP_REQUIRED_ | on LSP | |
| | | TTRIBUTES | ATTRIBUTES | Hop Att | | | | | ATTRIBUTES| ATTRIBUTES | Hop | |
| | | | | ributes | | | | | | | Attributes| |
+-----+------------+-----------+---------------+---------+----------+ +------+------------+-----------+---------------+-----------+----------+
| TBA | RTM_SET | Yes | No | No | This | | 5 | RTM_SET | Yes | No | No | This |
| 4 | sub-object | | | | document | | | sub-object | | | | document |
+-----+------------+-----------+---------------+---------+----------+ +------+------------+-----------+---------------+-----------+----------+
Table 7: RTM_SET Sub-object Type Table 7: RTM_SET Sub-object Type
IANA requested to create a new sub-registry for sub-TLV types of the IANA has created a new sub-registry for sub-TLV types of the RTM_SET
RTM_SET sub-object. All code points in the range 0 through 127 in sub-object called the "RTM_SET Object Sub-Object Types" registry.
this registry shall be allocated according to the "IETF Review" All codepoints in the range 0 through 127 in this registry shall be
procedure as specified in [RFC5226]. Code points in the range 128 allocated according to the "IETF Review" procedure as specified in
through 191 in this registry shall be allocated according to the [RFC5226]. Codepoints in the range 128 through 191 in this registry
"First Come First Served" procedure as specified in [RFC5226]. This shall be allocated according to the "First Come First Served"
document defines the following new values of RTM_SET object sub- procedure as specified in [RFC5226]. This document defines the
object types: following new values of RTM_SET object sub-object types:
+-----------+----------------------+---------------+ +---------+--------------------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-----------+----------------------+---------------+ +---------+--------------------------+---------------+
| 0 | Reserved | This document | | 0 | Reserved | This document |
| 1 | IPv4 address | This document | | 1 | IPv4 address | This document |
| 2 | IPv6 address | This document | | 2 | IPv6 address | This document |
| 3 | Unnumbered interface | This document | | 3 | Unnumbered interface | This document |
| 4-127 | Unassigned | | | 4-191 | Unassigned | |
| 128 - 191 | Unassigned | | | 192-254 | Reserved for Private Use | This document |
| 192 - 254 | Private Use | This document | | 255 | Reserved | This document |
| 255 | Reserved | This document | +---------+--------------------------+---------------+
+-----------+----------------------+---------------+
Table 8: RTM_SET object sub-object types Table 8: RTM_SET Object Sub-object Types
7.8. RTM_SET Attribute Flag 7.8. RTM_SET Attribute Flag
IANA is requested to assign new flag from the RSVP-TE Attribute Flags IANA has assigned a new flag in the RSVP-TE "Attribute Flags"
registry registry.
+-----+--------+-----------+------------+-----+-----+---------------+ +-----+---------+-----------+-----------+-----+-----+---------------+
| Bit | Name | Attribute | Attribute | RRO | ERO | Reference | | Bit | Name | Attribute | Attribute | RRO | ERO | Reference |
| No | | Flags | Flags Resv | | | | | No | | Flags | Flags | | | |
| | | Path | | | | | | | | Path | Resv | | | |
+-----+--------+-----------+------------+-----+-----+---------------+ +-----+---------+-----------+-----------+-----+-----+---------------+
| TBA | RTM_SE | Yes | Yes | No | No | This document | | 15 | RTM_SET | Yes | Yes | No | No | This document |
| 5 | T | | | | | | +-----+---------+-----------+-----------+-----+-----+---------------+
+-----+--------+-----------+------------+-----+-----+---------------+
Table 9: RTM_SET Attribute Flag Table 9: RTM_SET Attribute Flag
7.9. New Error Codes 7.9. New Error Codes
IANA is requested to assign new Error Codes from RSVP Error Codes and IANA has assigned the following new error codes in the RSVP "Error
Globally-Defined Error Value Sub-Codes registry Codes and Globally-Defined Error Value Sub-Codes" registry.
+------------+--------------------+---------------+ +------------+--------------------+---------------+
| Error Code | Meaning | Reference | | Error Code | Meaning | Reference |
+------------+--------------------+---------------+ +------------+--------------------+---------------+
| TBA6 | Duplicate TLV | This document | | 41 | Duplicate TLV | This document |
| TBA7 | Duplicate sub-TLV | This document | | 42 | Duplicate sub-TLV | This document |
| TBA8 | RTM_SET TLV Absent | This document | | 43 | RTM_SET TLV Absent | This document |
+------------+--------------------+---------------+ +------------+--------------------+---------------+
Table 10: New Error Codes Table 10: New Error Codes
8. Security Considerations 8. Security Considerations
Routers that support Residence Time Measurement are subject to the Routers that support RTM are subject to the same security
same security considerations as defined in [RFC4385] and [RFC5085] . considerations as defined in [RFC4385] and [RFC5085].
In addition - particularly as applied to use related to PTP - there In addition -- particularly as applied to use related to PTP -- there
is a presumed trust model that depends on the existence of a trusted is a presumed trust model that depends on the existence of a trusted
relationship of at least all PTP-aware nodes on the path traversed by relationship of at least all PTP-aware nodes on the path traversed by
PTP messages. This is necessary as these nodes are expected to PTP messages. This is necessary as these nodes are expected to
correctly modify specific content of the data in PTP messages and correctly modify specific content of the data in PTP messages, and
proper operation of the protocol depends on this ability. In proper operation of the protocol depends on this ability. In
practice, this means that those portions of messages cannot be practice, this means that those portions of messages cannot be
covered by either confidentiality or integrity protection. Though covered by either confidentiality or integrity protection. Though
there are methods that make it possible in theory to provide either there are methods that make it possible in theory to provide either
or both such protections and still allow for intermediate nodes to or both such protections and still allow for intermediate nodes to
make detectable but authenticated modifications, such methods do not make detectable but authenticated modifications, such methods do not
seem practical at present, particularly for timing protocols that are seem practical at present, particularly for timing protocols that are
sensitive to latency and/or jitter. sensitive to latency and/or jitter.
The ability to potentially authenticate and/or encrypt RTM and PTP The ability to potentially authenticate and/or encrypt RTM and PTP
data for scenarios both with and without participation of data for scenarios both with and without participation of
intermediate RTM/PTP-capable nodes is left for further study. intermediate RTM-/PTP-capable nodes is left for further study.
While it is possible for a supposed compromised node to intercept and While it is possible for a supposed compromised node to intercept and
modify the G-ACh content, this is an issue that exists for nodes in modify the G-ACh content, this is an issue that exists for nodes in
general - for any and all data that may be carried over an LSP - and general -- for any and all data that may be carried over an LSP --
is therefore the basis for an additional presumed trust model and is therefore the basis for an additional presumed trust model
associated with existing LSPs and nodes. associated with existing LSPs and nodes.
Security requirements of time protocols are provided in RFC 7384 Security requirements of time protocols are provided in RFC 7384
[RFC7384]. [RFC7384].
9. Acknowledgments 9. References
Authors want to thank Loa Andersson, Lou Berger, Acee Lindem, Les
Ginsberg, and Uma Chunduri for their thorough reviews, thoughtful
comments and, most of all, patience.
10. References
10.1. Normative References 9.1. Normative References
[IEEE.1588.2008] [IEEE.1588]
"Standard for a Precision Clock Synchronization Protocol IEEE, "IEEE Standard for a Precision Clock Synchronization
for Networked Measurement and Control Systems", Protocol for Networked Measurement and Control Systems",
IEEE Standard 1588, July 2008. IEEE Std 1588-2008, DOI 10.1109/IEEESTD.2008.4579760.
[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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>. <http://www.rfc-editor.org/info/rfc3209>.
skipping to change at page 27, line 16 skipping to change at page 28, line 38
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", RFC 7684, DOI 10.17487/RFC7684, November Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
2015, <http://www.rfc-editor.org/info/rfc7684>. 2015, <http://www.rfc-editor.org/info/rfc7684>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
<http://www.rfc-editor.org/info/rfc7752>. <http://www.rfc-editor.org/info/rfc7752>.
10.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
[I-D.ietf-ospf-ospfv3-lsa-extend] May 2017, <http://www.rfc-editor.org/info/rfc8174>.
Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3
LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-13
(work in progress), October 2016.
[I-D.ietf-tictoc-1588overmpls] 9.2. Informative References
Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.
Montini, "Transporting Timing messages over MPLS
Networks", draft-ietf-tictoc-1588overmpls-07 (work in
progress), October 2015.
[ITU-T.G.8271] [ITU-T.G.8271]
"Packet over Transport aspects - Synchronization, quality ITU-T, "Time and phase synchronization aspects of packet
and availability targets", ITU-T Recomendation networks", ITU-T Recomendation G.8271/Y.1366, July 2016.
G.8271/Y.1366, July 2016.
[OSPFV3-EXTENDED-LSA]
Lindem, A., Roy, A., Goethals, D., Vallem, V., and F.
Baker, "OSPFv3 LSA Extendibility", Work in Progress,
draft-ietf-ospf-ospfv3-lsa-extend-14, April 2017.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
in Support of Generalized Multi-Protocol Label Switching in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
<http://www.rfc-editor.org/info/rfc4202>. <http://www.rfc-editor.org/info/rfc4202>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036, "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>. October 2007, <http://www.rfc-editor.org/info/rfc5036>.
skipping to change at page 28, line 9 skipping to change at page 29, line 28
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, Measurement for MPLS Networks", RFC 6374,
DOI 10.17487/RFC6374, September 2011, DOI 10.17487/RFC6374, September 2011,
<http://www.rfc-editor.org/info/rfc6374>. <http://www.rfc-editor.org/info/rfc6374>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <http://www.rfc-editor.org/info/rfc7384>. October 2014, <http://www.rfc-editor.org/info/rfc7384>.
[TIMING-OVER-MPLS]
Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.
Montini, "Transporting Timing messages over MPLS
Networks", Work in Progress, draft-ietf-tictoc-
1588overmpls-07, October 2015.
Acknowledgments
The authors want to thank Loa Andersson, Lou Berger, Acee Lindem, Les
Ginsberg, and Uma Chunduri for their thorough reviews, thoughtful
comments, and, most of all, patience.
Authors' Addresses Authors' Addresses
Greg Mirsky Greg Mirsky
ZTE Corp. ZTE Corp.
Email: gregimirsky@gmail.com Email: gregimirsky@gmail.com
Stefano Ruffini Stefano Ruffini
Ericsson Ericsson
skipping to change at page 28, line 39 skipping to change at page 30, line 35
Email: jdrake@juniper.net Email: jdrake@juniper.net
Stewart Bryant Stewart Bryant
Huawei Huawei
Email: stewart.bryant@gmail.com Email: stewart.bryant@gmail.com
Alexander Vainshtein Alexander Vainshtein
ECI Telecom ECI Telecom
Email: Alexander.Vainshtein@ecitele.com; Vainshtein.alex@gmail.com Email: Alexander.Vainshtein@ecitele.com
Vainshtein.alex@gmail.com
 End of changes. 207 change blocks. 
563 lines changed or deleted 558 lines changed or added

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