< draft-ietf-mpls-residence-time-12.txt | draft-ietf-mpls-residence-time-13.txt > | |||
---|---|---|---|---|
MPLS Working Group G. Mirsky | MPLS Working Group G. Mirsky | |||
Internet-Draft Independent | Internet-Draft ZTE Corp. | |||
Intended status: Standards Track S. Ruffini | Intended status: Standards Track S. Ruffini | |||
Expires: June 16, 2017 E. Gray | Expires: July 22, 2017 E. Gray | |||
Ericsson | Ericsson | |||
J. Drake | J. Drake | |||
Juniper Networks | Juniper Networks | |||
S. Bryant | S. Bryant | |||
Independent | Huawei | |||
A. Vainshtein | A. Vainshtein | |||
ECI Telecom | ECI Telecom | |||
December 13, 2016 | January 18, 2017 | |||
Residence Time Measurement in MPLS network | Residence Time Measurement in MPLS network | |||
draft-ietf-mpls-residence-time-12 | draft-ietf-mpls-residence-time-13 | |||
Abstract | Abstract | |||
This document specifies G-ACh based Residence Time Measurement and | This document specifies new Generic Associated Channel for Residence | |||
how it can be used by time synchronization protocols being | Time Measurement and how it can be used by time synchronization | |||
transported over MPLS domain. | protocols being transported over MPLS domain. | |||
Residence time is the variable part of propagation delay of timing | Residence time is the variable part of propagation delay of timing | |||
and synchronization messages and knowing what this delay is for each | and synchronization messages and knowing what this delay is for each | |||
message allows for a more accurate determination of the delay to be | message allows for a more accurate determination of the delay to be | |||
taken into account in applying the value included in a PTP event | taken into account in applying the value included in a Precision Time | |||
message. | Protocol event message. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on June 16, 2017. | This Internet-Draft will expire on July 22, 2017. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Conventions used in this document . . . . . . . . . . . . 3 | 1.1. Conventions used in this document . . . . . . . . . . . . 3 | |||
1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 | 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4 | 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4 | |||
2. Residence Time Measurement . . . . . . . . . . . . . . . . . 4 | 2. Residence Time Measurement . . . . . . . . . . . . . . . . . 4 | |||
3. G-ACh for Residence Time Measurement . . . . . . . . . . . . 5 | 2.1. One-step Clock and two-step Clock Modes . . . . . . . . . 5 | |||
3.1. PTP Packet Sub-TLV . . . . . . . . . . . . . . . . . . . 6 | 3. G-ACh for Residence Time Measurement . . . . . . . . . . . . 7 | |||
4. Control Plane Theory of Operation . . . . . . . . . . . . . . 7 | 3.1. PTP Packet Sub-TLV . . . . . . . . . . . . . . . . . . . 8 | |||
4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 7 | 4. Control Plane Theory of Operation . . . . . . . . . . . . . . 10 | |||
4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 8 | 4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 10 | |||
4.3. RTM Capability Advertisement in OSPFv2 . . . . . . . . . 9 | 4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 11 | |||
4.4. RTM Capability Advertisement in OSPFv3 . . . . . . . . . 9 | 4.3. RTM Capability Advertisement in OSPFv2 . . . . . . . . . 11 | |||
4.5. RTM Capability Advertisement in IS-IS . . . . . . . . . . 9 | 4.4. RTM Capability Advertisement in OSPFv3 . . . . . . . . . 12 | |||
4.6. RSVP-TE Control Plane Operation to Support RTM . . . . . 10 | 4.5. RTM Capability Advertisement in IS-IS . . . . . . . . . . 12 | |||
4.7. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . . . 11 | 4.6. RSVP-TE Control Plane Operation to Support RTM . . . . . 12 | |||
4.7.1. RTM_SET Sub-TLVs . . . . . . . . . . . . . . . . . . 13 | 4.7. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 16 | 4.7.1. RTM_SET Sub-TLVs . . . . . . . . . . . . . . . . . . 15 | |||
6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 16 | 5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 18 | |||
7. One-step Clock and Two-step Clock Modes . . . . . . . . . . . 17 | 6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 19 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | |||
8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 19 | 7.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 19 | |||
8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 19 | 7.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 19 | |||
8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 20 | 7.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 20 | |||
8.4. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 20 | 7.4. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 20 | |||
8.5. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 21 | 7.5. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 21 | |||
8.6. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 21 | 7.6. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 21 | |||
8.7. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 22 | 7.7. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 22 | |||
8.8. New Error Codes . . . . . . . . . . . . . . . . . . . . . 22 | 7.8. New Error Codes . . . . . . . . . . . . . . . . . . . . . 22 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 | |||
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 23 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 25 | 10.2. Informative References . . . . . . . . . . . . . . . . . 25 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
1. Introduction | 1. Introduction | |||
Time synchronization protocols, e.g., Network Time Protocol version 4 | Time synchronization protocols, e.g., Network Time Protocol version 4 | |||
(NTPv4) [RFC5905] and Precision Time Protocol (PTP) Version 2 | (NTPv4) [RFC5905] and Precision Time Protocol (PTP) Version 2 | |||
[IEEE.1588.2008] define timing messages that can be used to | [IEEE.1588.2008] 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 one of these timing messages spends transiting the | cumulative time one of these timing messages spends transiting the | |||
nodes on the path from ingress node to egress node is termed | 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 it is used to improve the accuracy of clock | |||
synchronization. (I.e., it is the sum of the difference between the | synchronization. (I.e., it is the sum of the difference between the | |||
time of receipt at an ingress interface and the time of transmission | time of receipt at an ingress interface and the time of transmission | |||
from an egress interface for each node along the path from ingress | from an egress interface for each node along the path from ingress | |||
node to egress node.) This document defines a new Generic Associated | node to egress node.) This document defines a new Generic Associated | |||
Channel (G-ACh) value and an associated residence time measurement | Channel (G-ACh) value and an associated residence time measurement | |||
(RTM) packet that can be used in a Multi-Protocol Label Switching | (RTM) message that can be used in a Multi-Protocol Label Switching | |||
(MPLS) network to measure residence time over a Label Switched Path | (MPLS) network to measure residence time over a Label Switched Path | |||
(LSP). | (LSP). | |||
Although it is possible to use RTM over an LSP instantiated using | Although it is possible to use RTM over an LSP instantiated using | |||
LDP, that is outside the scope of this document. Rather, this | LDP, that is outside the scope of this document. Rather, this | |||
document describes RTM over an LSP signaled using RSVP-TE [RFC3209] | document describes RTM over an LSP signaled using RSVP-TE [RFC3209] | |||
because the LSP's path can be either explicitly specified or | because the LSP's path can be either explicitly specified or | |||
determined during signaling. | determined during signaling. | |||
Comparison with alternative proposed solutions such as | Comparison with alternative proposed solutions such as | |||
skipping to change at page 4, line 34 | skipping to change at page 4, line 34 | |||
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 be | |||
used to measure one-way or two-way end-to-end propagation delay over | used to measure one-way or two-way end-to-end propagation delay over | |||
LSP or PW. But these measurements are insufficient for use in some | LSP or PW. But these measurements are insufficient for use in some | |||
applications, for example, time synchronization across a network as | applications, for example, time synchronization across a network as | |||
defined in the Precision Time Protocol (PTP). In PTPv2 | defined in the Precision Time Protocol (PTP). In PTPv2 | |||
[IEEE.1588.2008] residence times is accumulated in the | [IEEE.1588.2008] residence times is accumulated in the | |||
correctionField of the PTP event message, as defined in | correctionField of the PTP event message, as defined in | |||
[IEEE.1588.2008], or in the associated follow-up message (or | [IEEE.1588.2008] and referred as case of one-step clocks, or in the | |||
Delay_Resp message associated with the Delay_Req message) in case of | associated follow-up message (or Delay_Resp message associated with | |||
two-step clocks (see the detailed discussion in Section 7). | the Delay_Req message) in case of two-step clocks (see the detailed | |||
discussion in Section 2.1). | ||||
IEEE 1588 uses this residence time to correct the transit time from | IEEE 1588 uses this residence time to correct the transit time from | |||
ingress node to egress node, effectively making the transit nodes | ingress node to egress node, effectively making the transit nodes | |||
transparent. | transparent. | |||
This document proposes a mechanism that can be used as one of types | This document proposes a mechanism that can be used as one of types | |||
of on-path support for a clock synchronization protocol or to perform | of on-path support for a clock synchronization protocol or to perform | |||
one-way measurement of residence time. The proposed mechanism | one-way measurement of residence time. The proposed mechanism | |||
accumulates residence time from all nodes that support this extension | accumulates residence time from all nodes that support this extension | |||
along the path of a particular LSP in Scratch Pad field of an RTM | along the path of a particular LSP in Scratch Pad field of an RTM | |||
packet Figure 1. This value can then be used by the egress node to | message Figure 1. This value can then be used by the egress node to | |||
update, for example, the correctionField of the PTP event packet | update, for example, the correctionField of the PTP event packet | |||
carried within the RTM packet prior to performing its PTP processing. | carried within the RTM message prior to performing its PTP | |||
processing. | ||||
2.1. One-step Clock and two-step Clock Modes | ||||
One-step mode refers to the mode of operation where an egress | ||||
interface updates the correctionField value of an original event | ||||
message. two-step mode refers to the mode of operation where this | ||||
update is made in a subsequent follow-up message. | ||||
Processing of the follow-up message, if present, requires the | ||||
downstream end-point to wait for the arrival of the follow-up message | ||||
in order to combine correctionField values from both the original | ||||
(event) message and the subsequent (follow-up) message. In a similar | ||||
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 | ||||
(as opposed to creating a new one. Hence the first node that uses | ||||
two-step mode MUST do two things: | ||||
1. Mark the original event message to indicate that a follow-up | ||||
message will be forthcoming. This is necessary in order to | ||||
Let any subsequent two-step node know that there is already a | ||||
follow-up message, and | ||||
Let the end-point know to wait for a follow-up message; | ||||
2. Create a follow-up message in which to put the RTM determined as | ||||
an initial correctionField value. | ||||
IEEE 1588v2 [IEEE.1588.2008] defines this behavior for PTP messages. | ||||
Thus, for example, with reference to the PTP protocol, the PTPType | ||||
field identifies whether the message is a Sync message, Follow_up | ||||
message, Delay_Req message, or Delay_Resp message. The 10 octet long | ||||
Port ID field contains the identity of the source port | ||||
[IEEE.1588.2008], that is, the specific PTP port of the boundary | ||||
clock connected to the MPLS network. The Sequence ID is the sequence | ||||
ID of the PTP message carried in the Value field of the message. | ||||
PTP messages also include a bit that indicates whether or not a | ||||
follow-up message will be coming. This bit, once it is set by a two- | ||||
step mode device, MUST stay set accordingly until the original and | ||||
follow-up messages are combined by an end-point (such as a Boundary | ||||
Clock). | ||||
Thus, an RTM packet, containing residence time information relating | ||||
to an earlier packet, also contains information identifying that | ||||
earlier packet. | ||||
For compatibility with PTP, RTM (when used for PTP packets) must | ||||
behave in a similar fashion. To do this, a 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 they are for PTP) and | ||||
- if it is clear (set to zero), it MUST set it and create a follow-up | ||||
PTP Type RTM message. If the S bit is already set, then the RTM | ||||
capable node MUST wait for the RTM message with the PTP type of | ||||
follow-up and matching originator and sequence number to make the | ||||
corresponding residence time update to the Scratch Pad field. | ||||
In practice an RTM operating according to two-step clock behaves like | ||||
a two-steps transparent clock. | ||||
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 | ||||
containing the PTP event message), or in two-step mode (by making an | ||||
update to the Scratch Pad of a follow-up message when its presence is | ||||
indicated), but MUST NOT do both. | ||||
Two main subcases can be identified for an RTM node operating as a | ||||
two-step clock: | ||||
A) If any of the previous RTM capable node or the previous PTP clock | ||||
(e.g. the BC connected to the first node), is a two-step clock, the | ||||
residence time is added to the RTM packet that has been created to | ||||
include the associated PTP packet (i.e. follow-up message in the | ||||
downstream direction), if the local RTM-capable node is also | ||||
operating as a two-step clock. This RTM packet carries the related | ||||
accumulated residence time and the appropriate values of the Sequence | ||||
Id and Port Id (the same identifiers carried in the packet processed) | ||||
and the Two-step Flag set to 1. | ||||
Note that the fact that an upstream RTM-capable node operating in the | ||||
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 | ||||
long as that RTM-capable node forwards the follow-up message on the | ||||
same LSP on which it forwards the corresponding previous message. | ||||
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 | ||||
NOT update both messages. | ||||
A PTP event packet (sync) is carried in the RTM packet in order for | ||||
an RTM node to identify that residence time measurement must be | ||||
performed on that specific packet. | ||||
To handle the residence time of the Delay request message on the | ||||
upstream direction, an RTM packet must be created to carry the | ||||
residence time on the associated downstream Delay Resp message. | ||||
The last RTM node of the MPLS network in addition to update the | ||||
correctionField of the associated PTP packet, must also properly | ||||
handle the two-step flag of the PTP packets. | ||||
B) When the PTP network connected to the MPLS and RTM node, operates | ||||
in one-step clock mode, the associated RTM packet must be created by | ||||
the RTM node itself. The associated RTM packet including the PTP | ||||
event packet needs now to indicate that a follow up message will be | ||||
coming. | ||||
The last RTM node of the LSP, if it receives an RTM message with a | ||||
PTP payload indicating a follow-up message will be forthcoming, must | ||||
generate a follow-up message and properly set the two-step flag of | ||||
the PTP packets. | ||||
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 | RFC 5586 [RFC5586] and RFC 6423 [RFC6423] define the G-ACh to extend | |||
the applicability of the PW Associated Channel (ACH) [RFC5085] to | the applicability of the PW Associated Channel (ACH) [RFC5085] to | |||
LSPs. G-ACh provides a mechanism to transport OAM and other control | LSPs. G-ACh provides a mechanism to transport OAM and other control | |||
messages over an LSP. Processing of these messages by selected | messages over an LSP. Processing of these messages by selected | |||
transit nodes is controlled by the use of the Time-to-Live (TTL) | transit nodes is controlled by the use of the Time-to-Live (TTL) | |||
value in the MPLS header of these messages. | value in the MPLS header of these messages. | |||
The packet format for Residence Time Measurement (RTM) is presented | The message format for Residence Time Measurement (RTM) is presented | |||
in Figure 1 | 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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Value | | | Value | | |||
~ ~ | ~ ~ | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 1: RTM G-ACh packet 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 First four octets are defined as 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 RFC 4385 [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 (TBA1) to be allocated by IANA, | |||
identifies the packet as such. | identifies the 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 residence time measurement. Its format is IEEE | |||
double precision and its units are nanoseconds. Note that | double precision and its units are nanoseconds. Note that | |||
depending on whether the timing procedure is one-step or two-step | depending on whether the timing procedure is one-step or two-step | |||
operation (Section 7), the residence time is either for the timing | operation (Section 2.1), the residence time is either for the | |||
packet carried in the Value field of this RTM packet or for an | timing packet carried in the Value field of this RTM message or | |||
associated timing packet carried in the Value field of another RTM | for an associated timing packet carried in the Value field of | |||
packet. | 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]. IANA will be asked to create a sub-registry in | [IEEE.1588.2008]. This document asks IANA to create a sub- | |||
Generic Associated Channel (G-ACh) Parameters Registry called | registry in Generic Associated Channel (G-ACh) Parameters Registry | |||
"MPLS RTM TLV Registry". | called "MPLS RTM TLV Registry" Section 7.2. | |||
o The Length field contains the length, in octets , of the of the | o The Length field contains the length, in octets, of the of the | |||
timing packet carried in the Value field. | timing packet carried in the Value field. | |||
o The optional Value field MAY carry a packet of the time | o The optional Value field MAY carry a packet of the time | |||
synchronization protocol identified by Type field. It is | synchronization protocol identified by Type field. It is | |||
important to note that the packet may be authenticated or | important to note that the packet may be authenticated or | |||
encrypted and carried over LSP edge to edge unchanged while the | encrypted and carried over LSP edge to edge unchanged while the | |||
residence time is accumulated in the Scratch Pad field. | 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 format of a PTP sub-TLV that MUST be included in | Figure 2 presents format of a PTP sub-TLV that MUST be included in | |||
the Value field of an RTM packet preceding the carried timing packet | the Value field of an RTM message preceding the carried timing packet | |||
when the timing packet is PTP. | when the timing packet is PTP. | |||
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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Flags |PTPType| | | Flags |PTPType| | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Port ID | | | Port ID | | |||
skipping to change at page 7, line 4 | skipping to change at page 9, line 21 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| 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 Flags field has 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 1 | o The Type field identifies PTP packet sub-TLV and is set to 1 | |||
according to Section 8.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 field 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 2-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 1-step nodes and there is no follow-up message, and | exclusively by one-step nodes and there is no follow-up message, | |||
set if there has been at least one 2-step node and a follow-up | and set if there has been at least one two-step node and a follow- | |||
message is forthcoming. | up message is forthcoming. | |||
o The PTPType indicates the type of PTP packet carried in the TLV. | o The PTPType indicates the type of PTP packet carried in the TLV. | |||
PTPType is the messageType field of the PTPv2 packet whose values | PTPType is the messageType field of the PTPv2 packet whose values | |||
are defined in the Table 19 [IEEE.1588.2008]. | are defined in Table 19 of [IEEE.1588.2008]. | |||
o The 10 octets long Port ID field contains the identity of the | o The 10 octets 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 carried in | |||
the Value field of the message. | the Value field of the message. | |||
4. Control Plane Theory of Operation | 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 | |||
skipping to change at page 8, line 5 | skipping to change at page 10, line 21 | |||
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. | information will be available to the egress interface. | |||
The supported modes (1-step verses 2-step) of any pair of interfaces | The supported modes (one-step or two-step) of any pair of interfaces | |||
is then determined by the capability of the egress interface. For | is then determined by the capability of the egress interface. For | |||
both modes, the egress interface implementation MUST be able to | both modes, the egress interface implementation MUST be able to | |||
determine the precise departure time of the same packet and determine | determine the precise departure time of the same packet and determine | |||
from this, and the arrival time information from the corresponding | from this, and the arrival time information from the corresponding | |||
ingress interface, the difference representing the residence time for | ingress interface, the difference representing the residence time for | |||
the packet. | the 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 1-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 1-step or 2-step | interface that determines whether or not the node is one-step or two- | |||
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 is thus | The RTM capability used in the sub-TLV shown in Figure 4 is thus | |||
associated with the egress port of the node making the advertisement, | associated with the egress port of the node making the advertisement, | |||
while the ability of any pair of interfaces that includes this egress | while the ability of any pair of interfaces that includes this egress | |||
interface to support any mode of RTM depends on the ability of that | interface to support any mode of RTM depends on the ability of that | |||
interface to record packet arrival time in some way that can be | interface to record packet arrival time in some way that can be | |||
conveyed to and used by that egress interface. | conveyed to and used by that egress interface. | |||
When a node uses an IGP to carry the RTM capability sub-TLV, the sub- | When a node uses an IGP to carry the RTM capability sub-TLV, the sub- | |||
TLV MUST reflect the RTM capability (1-step or 2-step) associated | TLV MUST reflect the RTM capability (one-step or two-step) associated | |||
with egress interfaces. | with egress interfaces. | |||
4.2. RTM Capability Sub-TLV | 4.2. RTM Capability Sub-TLV | |||
The format for the RTM Capabilities sub-TLV is presented in Figure 4 | The format for the RTM Capabilities sub-TLV is presented in 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 | Reserved | | | RTM | Reserved | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 4: RTM Capability sub-TLV | Figure 4: RTM Capability sub-TLV | |||
o Type value (TBA2) will be assigned by IANA from appropriate | o Type value (TBA2) will be assigned by IANA from appropriate | |||
registry for OSPFv2. | registry for OSPFv2 Section 7.4. | |||
o Length MUST be set to 4. | o Length MUST be set to 4. | |||
o RTM (capability) - is a three-bit long bit-map field with values | o RTM (capability) - is a three-bit long bit-map field with values | |||
defined as follows: | defined as follows: | |||
* 0b001 - one-step RTM supported; | * 0b001 - one-step RTM supported; | |||
* 0b010 - two-step RTM supported; | * 0b010 - two-step RTM supported; | |||
skipping to change at page 9, line 27 | skipping to change at page 11, line 46 | |||
[RFC4202] explains that the Interface Switching Capability Descriptor | [RFC4202] explains that the Interface Switching Capability Descriptor | |||
describes switching capability of an interface. For bi-directional | describes switching capability of an interface. For bi-directional | |||
links, the switching capabilities of an interface are defined to be | links, the switching capabilities of an interface are defined to be | |||
the same in either direction. I.e., for data entering the node | the same in either direction. I.e., for data entering the node | |||
through that interface and for data leaving the node through that | through that interface and for data leaving the node through that | |||
interface. That principle SHOULD be applied when a node advertises | interface. That principle SHOULD be applied when a node advertises | |||
RTM Capability. | 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. Detailed discussion of one-step and | |||
two-step RTM modes in Section 7. | two-step RTM modes appears in Section 2.1. | |||
4.3. RTM Capability Advertisement in OSPFv2 | 4.3. RTM Capability Advertisement in OSPFv2 | |||
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 described in | |||
Section 3 [RFC7684] via the RTM Capability sub-TLV. | Section 3 [RFC7684] via the RTM Capability sub-TLV. | |||
Its Type value will be assigned by IANA from the OSPF Extended Link | Its Type value will be assigned by IANA from the OSPF Extended Link | |||
TLV Sub-TLVs registry that will be created per [RFC7684] request. | TLV Sub-TLVs registry Section 7.4, that will be created per [RFC7684] | |||
request. | ||||
4.4. RTM Capability Advertisement in OSPFv3 | 4.4. 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]. Exact use of OSPFv3 LSA | [I-D.ietf-ospf-ospfv3-lsa-extend]. Exact use of OSPFv3 LSA | |||
extensions is for further study. | extensions is for further study. | |||
4.5. RTM Capability Advertisement in IS-IS | 4.5. RTM Capability Advertisement in IS-IS | |||
skipping to change at page 10, line 16 | skipping to change at page 12, line 35 | |||
from leaking between levels. | from leaking between levels. | |||
o The D bit of the Flags field MUST be cleared as required by | o The D bit of the Flags field MUST be cleared as required by | |||
[RFC6823]. | [RFC6823]. | |||
o The I bit and the V bit MUST be set accordingly depending on | o The I bit and the V bit MUST be set accordingly depending on | |||
whether RTM capability being advertised is for an IPv4 or an IPv6 | whether RTM capability being advertised is for an IPv4 or an IPv6 | |||
interface. | interface. | |||
Application ID (TBA3) will be assigned from the Application | Application ID (TBA3) will be assigned from the Application | |||
Identifiers for TLV 251 IANA registry. The RTM Capability sub-TLV | Identifiers for TLV 251 IANA registry Section 7.5. The RTM | |||
MUST be included in GENINFO TLV in Application Specific Information. | Capability sub-TLV MUST be included in GENINFO TLV in Application | |||
Specific Information. | ||||
4.6. RSVP-TE Control Plane Operation to Support RTM | 4.6. 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 RTM capable node when | |||
at least one of its interfaces is RTM capable. Figure 5 provides an | at least one of its interfaces is RTM capable. Figure 5 provides an | |||
example of roles a node may have with respect to RTM capability: | 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 | | |||
----- ----- ----- ----- ----- ----- ----- | ----- ----- ----- ----- ----- ----- ----- | |||
skipping to change at page 10, line 43 | skipping to change at page 13, line 17 | |||
IP address is G. | 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 LER for the MPLS LSP and is the first RTM capable | |||
node. It creates RTM packets and in each it places a timing | node. It creates RTM packets and in each it places a timing | |||
packet, possibly encrypted, in the Value field and initializes the | packet, possibly encrypted, in the Value field and initializes the | |||
Scratch Pad field with its residence time measurement | Scratch Pad field with its residence time measurement | |||
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 filed | o D is RTM capable transit node. It updates the Scratch Pad field | |||
of the RTM packet without updating of the timing packet. | 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 processes | o F is the egress LER and the last RTM capable node. It processes | |||
the timing packet carried in the Value field using the value in | the timing packet carried in the Value field using the value in | |||
the Scratch Pad field. It updates the Correction field of the PTP | the Scratch Pad field. It updates the Correction field of the PTP | |||
message with the value in the Scratch Pad field of the RTM ACH, | message with the value in the Scratch Pad field of the RTM ACH, | |||
and removes the RTM ACH encapsulation. | and removes the RTM ACH encapsulation. | |||
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 verifies that the selected | through an MPLS network to an egress node verifies that the selected | |||
egress node has an interface that supports RTM via the egress node's | egress node has an interface that supports RTM via the egress node's | |||
advertisement of the RTM Capability sub-TLV. In the Path message | advertisement of the RTM Capability sub-TLV. In the Path message | |||
that the ingress node uses to instantiate the LSP to that egress node | that the ingress node uses to instantiate the LSP to that egress node | |||
it places LSP_ATTRIBUTES Object [RFC5420] with RTM_SET Attribute Flag | it places LSP_ATTRIBUTES Object [RFC5420] with RTM_SET Attribute Flag | |||
set Section 8.7 which indicates to the egress node that RTM is | set Section 7.7 which indicates to the egress node that RTM is | |||
requested for this LSP. RTM_SET Attribute Flag SHOULD NOT be set in | requested for this LSP. RTM_SET Attribute Flag SHOULD NOT be set in | |||
the LSP_REQUIRED_ATTRIBUTES object [RFC5420] , unless it is known | the LSP_REQUIRED_ATTRIBUTES object [RFC5420] , unless it is known | |||
that all nodes support RTM, because a node that does not recognize | that all nodes support RTM, because a node that does not recognize | |||
RTM_SET Attribute Flag would reject the Path message. | RTM_SET Attribute Flag would reject the Path message. | |||
If egress node receives Path message with RTM_SET Attribute Flag in | If egress node receives Path message with RTM_SET Attribute Flag in | |||
LSP_ATTRIBUTES object, it MUST include initialized RRO [RFC3209] and | LSP_ATTRIBUTES object, it MUST include initialized RRO [RFC3209] and | |||
LSP_ATTRIBUTES object where RTM_SET Attribute Flag is set and RTM_SET | LSP_ATTRIBUTES object where RTM_SET Attribute Flag is set and RTM_SET | |||
TLV Section 4.7 is initialized. When Resv message received by | TLV Section 4.7 is initialized. When Resv message received by | |||
ingress node the RTM_SET TLV will contain an ordered list, from | ingress node the RTM_SET TLV will contain an ordered list, from | |||
skipping to change at page 12, line 17 | skipping to change at page 14, line 33 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type | Length |I| Reserved | | | Type | Length |I| Reserved | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
~ Value ~ | ~ Value ~ | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 6: RTM_SET TLV format | Figure 6: RTM_SET TLV format | |||
Type value (TBA4) will be assigned by IANA from its Attributes TLV | Type value (TBA4) will be assigned by IANA from its Attributes TLV | |||
Space sub-registry. | Space sub-registry Section 7.6. | |||
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 flag indicates whether the downstream RTM capable node | |||
along the LSP is present in the RRO. | along the LSP is present in the RRO. | |||
Reserved field must be zeroed on initiation and ignored on receipt. | Reserved field must be zeroed on initiation and ignored on 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 sub- | |||
TLVs. Only a single RTM_SET can be present in the LSP_ATTRIBUTES | TLVs. Only a single RTM_SET can be present in the LSP_ATTRIBUTES | |||
object. The sub-TLVs are defined in Section 4.7.1 below. | object. The sub-TLVs are defined in Section 4.7.1 below. | |||
The following processing procedures apply to every RTM capable node | The following processing procedures apply to every RTM capable node | |||
along the LSP that in this paragraph is referred as node for sake of | along the LSP that in this paragraph is referred as node for sake of | |||
brevity. Each node MUST examine Resv message whether RTM_SET | brevity. Each node MUST examine Resv message whether RTM_SET | |||
Attribute Flag in the LSP_ATTRIBUTES object is set. If the RTM_SET | Attribute Flag in the LSP_ATTRIBUTES object is set. If the RTM_SET | |||
flag set, the node MUST inspect the LSP_ATTRIBUTES object for | flag set, the node MUST inspect the LSP_ATTRIBUTES object for | |||
presence of RTM_SET TLV. If more than one found, then the LSP setup | presence of RTM_SET TLV. If more than one found, then the LSP setup | |||
MUST fail with generation of the ResvErr message with Error Code | MUST fail with generation of the ResvErr message with Error Code | |||
Duplicate TLV Section 8.8 and Error Value that contains Type value in | Duplicate TLV Section 7.8 and Error Value that contains Type value in | |||
its 8 least significant bits. If no RTM_SET TLV has been found, then | its 8 least significant bits. If no RTM_SET TLV has been found, then | |||
the LSP setup MUST fail with generation of the ResvErr message with | the LSP setup MUST fail with generation of the ResvErr message with | |||
Error Code RTM_SET TLV Absent Section 8.8. If one RTM_SET TLV has | Error Code RTM_SET TLV Absent Section 7.8. If one RTM_SET TLV has | |||
been found the node will use the ID of the first node in the RTM_SET | been found the node will use the ID of the first node in the RTM_SET | |||
in conjunction with the RRO to compute the hop count to its | in conjunction with the RRO to compute the hop count to its | |||
downstream node with reachable RTM capable interface. If the node | downstream node with reachable RTM capable interface. If the node | |||
cannot find matching ID in RRO, then it MUST try to use ID of the | cannot find matching ID in RRO, then it MUST try to use ID of the | |||
next node in the RTM_SET until it finds the match or reaches the end | next node in the RTM_SET until it finds the match or reaches the end | |||
of RTM_SET TLV. If match has been found, the calculated value is | of RTM_SET TLV. If match has been found, the calculated value is | |||
used by the node as TTL value in outgoing label to reach the next RTM | used by the node as TTL value in outgoing label to reach the next RTM | |||
capable node on the LSP. Otherwise, the TTL value MUST be set to | capable node on the LSP. Otherwise, the TTL value MUST be set to | |||
255. The node MUST add RTM_SET sub-TLV with the same address it used | 255. The node MUST add RTM_SET sub-TLV with the same address it used | |||
in RRO sub-object at the beginning of the RTM_SET TLV in associated | in RRO sub-object at the beginning of the RTM_SET TLV in associated | |||
skipping to change at page 13, line 41 | skipping to change at page 16, line 9 | |||
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 sub- | |||
TLV is added, it is always added to the top. Only a single RTM_SET | TLV is added, it is always added to the top. Only a single RTM_SET | |||
sub-TLV with the given Value field MUST be present in the RTM_SET | sub-TLV with the given Value field MUST be present in the RTM_SET | |||
TLV. If more than one sub-TLV is found the LSP setup MUST fail with | TLV. If more than one sub-TLV is found the LSP setup MUST fail with | |||
the generation of a ResvErr message with the Error Code "Duplicate | the generation of a ResvErr message with the Error Code "Duplicate | |||
sub-TLV" Section 8.8 and Error Value contains 16-bit value composed | sub-TLV" Section 7.8 and Error Value contains 16-bit value composed | |||
of (Type of TLV, Type of sub-TLV). | 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.7.1.1. IPv4 Sub-TLV | 4.7.1.1. IPv4 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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| IPv4 address | | | IPv4 address | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 7: IPv4 sub-TLV format | Figure 7: IPv4 sub-TLV format | |||
skipping to change at page 16, line 17 | skipping to change at page 18, line 36 | |||
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.6, ingress node MAY begin sending RTM packets | described in Section 4.6, ingress node MAY begin sending RTM packets | |||
to the first downstream RTM capable node on that path. Each RTM | to the first downstream RTM capable node on that path. Each RTM | |||
packet has its Scratch Pad field initialized and its TTL set to | 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; | |||
this should be done as close to the physical layer as possible to | this should be done as close to the physical layer as possible to | |||
ensure precise accuracy in time determination. The RTM-capable node | ensure precise accuracy in time determination. The RTM-capable node | |||
determines the difference between those two times; for 1-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 4.6 nanosecond | |||
error for residence time on the order of 1 millisecond. | error for residence time on the order of 1 millisecond. | |||
For 2-step operation, the difference between packet arrival time (at | For two-step operation, the difference between packet arrival time | |||
an ingress interface) and subsequent departure time (from an egress | (at an ingress interface) and subsequent departure time (from an | |||
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 7 for further details on the difference between 1-step | See Section 2.1 for further details on the difference between one- | |||
and 2-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 follow- | |||
up message. For example, the egress node may be a PTP Boundary Clock | up message. For example, the egress node may be a PTP Boundary Clock | |||
synchronized to a Master Clock and will use the value in the Scratch | synchronized to a Master Clock and will use the value in the Scratch | |||
Pad field to update PTP's correctionField. | Pad field to update PTP's correctionField. | |||
6. Applicable PTP Scenarios | 6. Applicable PTP Scenarios | |||
The proposed approach can be directly integrated in a PTP network | The proposed approach can be directly integrated in a PTP network | |||
based on the IEEE 1588 delay request-response mechanism. The RTM | based on the IEEE 1588 delay request-response mechanism. The RTM | |||
capable node nodes act as end-to-end transparent clocks, and | capable node nodes act as end-to-end transparent clocks, and | |||
typically boundary clocks, at the edges of the MPLS network, use the | typically boundary clocks, at the edges of the MPLS network, use the | |||
value in the Scratch Pad field to update the correctionField of the | value in the Scratch Pad field to update the correctionField of the | |||
corresponding PTP event packet prior to performing the usual PTP | corresponding PTP event packet prior to performing the usual PTP | |||
processing. | processing. | |||
7. One-step Clock and Two-step Clock Modes | 7. IANA Considerations | |||
One-step mode refers to the mode of operation where an egress | ||||
interface updates the correctionField value of an original event | ||||
message. Two-step mode refers to the mode of operation where this | ||||
update is made in a subsequent follow-up message. | ||||
Processing of the follow-up message, if present, requires the | ||||
downstream end-point to wait for the arrival of the follow-up message | ||||
in order to combine correctionField values from both the original | ||||
(event) message and the subsequent (follow-up) message. In a similar | ||||
fashion, each 2-step node needs to wait for the related follow-up | ||||
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 | ||||
2-step mode MUST do two things: | ||||
1. Mark the original event message to indicate that a follow-up | ||||
message will be forthcoming (this is necessary in order to | ||||
Let any subsequent 2-step node know that there is already a | ||||
follow-up message, and | ||||
Let the end-point know to wait for a follow-up message; | ||||
2. Create a follow-up message in which to put the RTM determined as | ||||
an initial correctionField value. | ||||
IEEE 1588v2 [IEEE.1588.2008] defines this behavior for PTP messages. | ||||
Thus, for example, with reference to the PTP protocol, the PTPType | ||||
field identifies whether the message is a Sync message, Follow_up | ||||
message, Delay_Req message, or Delay_Resp message. The 10 octet long | ||||
Port ID field contains the identity of the source port, that is, the | ||||
specific PTP port of the boundary clock connected to the MPLS | ||||
network. The Sequence ID is the sequence ID of the PTP message | ||||
carried in the Value field of the message. | ||||
PTP messages also include a bit that indicates whether or not a | ||||
follow-up message will be coming. This bit, once it is set by a | ||||
2-step mode device, MUST stay set accordingly until the original and | ||||
follow-up messages are combined by an end-point (such as a Boundary | ||||
Clock). | ||||
Thus, an RTM packet, containing residence time information relating | ||||
to an earlier packet, also contains information identifying that | ||||
earlier packet. | ||||
For compatibility with PTP, RTM (when used for PTP packets) must | ||||
behave in a similar fashion. To do this, a 2-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 they are for PTP) and - | ||||
if it is clear (set to zero), it MUST set it and create a follow-up | ||||
PTP Type RTM message. If the S bit is already set, then the RTM | ||||
capable node MUST wait for the RTM message with the PTP type of | ||||
follow-up and matching originator and sequence number to make the | ||||
corresponding residence time update to the Scratch Pad field. | ||||
In practice an RTM operating according to two-step clock behaves like | ||||
a two-steps transparent clock. | ||||
A 1-step capable RTM node MAY elect to operate in either 1-step mode | ||||
(by making an update to the Scratch Pad field of the RTM message | ||||
containing the PTP even message), or in 2-step mode (by making an | ||||
update to the Scratch Pad of a follow-up message when its presence is | ||||
indicated), but MUST NOT do both. | ||||
Two main subcases can be identified for an RTM node operating as a | ||||
two-step clock: | ||||
A) If any of the previous RTM capable node or the previous PTP clock | ||||
(e.g. the BC connected to the first node), is a two-step clock, the | ||||
residence time is added to the RTM packet that has been created to | ||||
include the associated PTP packet (i.e. follow-up message in the | ||||
downstream direction), if the local RTM-capable node is also | ||||
operating as a two-step clock. This RTM packet carries the related | ||||
accumulated residence time and the appropriate values of the Sequence | ||||
Id and Port Id (the same identifiers carried in the packet processed) | ||||
and the Two-step Flag set to 1. | ||||
Note that the fact that an upstream RTM-capable node operating in the | ||||
two-step mode has created a follow-up message does not require any | ||||
subsequent RTM capable node to also operate in the 2-step mode, as | ||||
long as that RTM-capable node forwards the follow-up message on the | ||||
same LSP on which it forwards the corresponding previous message. | ||||
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 | ||||
NOT update both messages. | ||||
A PTP event packet (sync) is carried in the RTM packet in order for | ||||
an RTM node to identify that residence time measurement must be | ||||
performed on that specific packet. | ||||
To handle the residence time of the Delay request message on the | ||||
upstream direction, an RTM packet must be created to carry the | ||||
residence time on the associated downstream Delay Resp message. | ||||
The last RTM node of the MPLS network in addition to update the | ||||
correctionField of the associated PTP packet, must also properly | ||||
handle the two-step flag of the PTP packets. | ||||
B) When the PTP network connected to the MPLS and RTM node, operates | ||||
in one-step clock mode, the associated RTM packet must be created by | ||||
the RTM node itself. The associated RTM packet including the PTP | ||||
event packet needs now to indicate that a follow up message will be | ||||
coming. | ||||
The last RTM node of the LSP, if it receives an RTM message with a | ||||
PTP payload indicating a follow-up message will be forthcoming, must | ||||
generate a follow-up message and properly set the two-step flag of | ||||
the PTP packets. | ||||
8. IANA Considerations | ||||
8.1. New RTM G-ACh | 7.1. New RTM G-ACh | |||
IANA is requested to reserve a new G-ACh as follows: | IANA is requested to reserve a new G-ACh as follows: | |||
+-------+----------------------------+---------------+ | +-------+----------------------------+---------------+ | |||
| Value | Description | Reference | | | Value | Description | Reference | | |||
+-------+----------------------------+---------------+ | +-------+----------------------------+---------------+ | |||
| TBA1 | Residence Time Measurement | This document | | | TBA1 | Residence Time Measurement | This document | | |||
+-------+----------------------------+---------------+ | +-------+----------------------------+---------------+ | |||
Table 1: New Residence Time Measurement | Table 1: New Residence Time Measurement | |||
8.2. New RTM TLV Registry | 7.2. New RTM TLV Registry | |||
IANA is requested to create sub-registry in Generic Associated | IANA is requested to create sub-registry in Generic Associated | |||
Channel (G-ACh) Parameters Registry called "MPLS RTM TLV Registry". | Channel (G-ACh) Parameters Registry called "MPLS RTM TLV Registry". | |||
All code points in the range 0 through 127 in this registry shall be | All code points 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] . Code points 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 type s: | following new values RTM TLV type s: | |||
skipping to change at page 20, line 22 | skipping to change at page 20, line 22 | |||
| 4 | PTPv2, IPv6 Encapsulation | This document | | | 4 | PTPv2, IPv6 Encapsulation | This document | | |||
| 5 | NTP | This document | | | 5 | NTP | This document | | |||
| 6-127 | Unassigned | | | | 6-127 | Unassigned | | | |||
| 128 - 191 | Unassigned | | | | 128 - 191 | Unassigned | | | |||
| 192 - 254 | 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 Type | |||
8.3. New RTM Sub-TLV Registry | 7.3. New RTM Sub-TLV Registry | |||
IANA is requested to create sub-registry in MPLS RTM TLV Registry, | IANA is requested to create sub-registry in MPLS RTM TLV Registry, | |||
requested in Section 8.2, called "MPLS RTM Sub-TLV Registry". All | requested in Section 7.2, called "MPLS RTM Sub-TLV Registry". All | |||
code points in the range 0 through 127 in this registry shall be | code points 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]. Code points 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 sub-TLV types: | following new values RTM 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-127 | Unassigned | | | |||
| 128 - 191 | Unassigned | | | | 128 - 191 | Unassigned | | | |||
| 192 - 254 | 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 | |||
8.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 is requested to assign a new type for RTM Capability sub-TLV | |||
from OSPFv2 Extended Link TLV Sub-TLVs registry as follows: | from OSPFv2 Extended Link TLV Sub-TLVs registry as follows: | |||
+-------+----------------+---------------+ | +-------+----------------+---------------+ | |||
| Value | Description | Reference | | | Value | Description | Reference | | |||
+-------+----------------+---------------+ | +-------+----------------+---------------+ | |||
| TBA2 | RTM Capability | This document | | | TBA2 | RTM Capability | This document | | |||
+-------+----------------+---------------+ | +-------+----------------+---------------+ | |||
Table 4: RTM Capability sub-TLV | Table 4: RTM Capability sub-TLV | |||
8.5. IS-IS RTM Application ID | 7.5. IS-IS RTM Application ID | |||
IANA is requested to assign a new Application ID for RTM from the | IANA is requested to assign a new Application ID for RTM from the | |||
Application Identifiers for TLV 251 registry as follows: | Application Identifiers for TLV 251 registry as follows: | |||
+-------+-------------+---------------+ | +-------+-------------+---------------+ | |||
| Value | Description | Reference | | | Value | Description | Reference | | |||
+-------+-------------+---------------+ | +-------+-------------+---------------+ | |||
| TBA3 | RTM | This document | | | TBA3 | RTM | This document | | |||
+-------+-------------+---------------+ | +-------+-------------+---------------+ | |||
Table 5: IS-IS RTM Application ID | Table 5: IS-IS RTM Application ID | |||
8.6. RTM_SET Sub-object RSVP Type and sub-TLVs | 7.6. RTM_SET Sub-object RSVP Type and sub-TLVs | |||
IANA is requested to assign a new Type for RTM_SET sub-object from | IANA is requested to assign a new Type for RTM_SET sub-object from | |||
Attributes TLV Space sub-registry as follows: | Attributes TLV Space sub-registry as follows: | |||
+-----+------------+-----------+---------------+---------+----------+ | +-----+------------+-----------+---------------+---------+----------+ | |||
| Typ | Name | Allowed | Allowed on | Allowed | Referenc | | | Typ | Name | Allowed | Allowed on | Allowed | Referenc | | |||
| e | | on LSP_A | LSP_REQUIRED_ | on LSP | e | | | e | | on LSP_A | LSP_REQUIRED_ | on LSP | e | | |||
| | | TTRIBUTES | ATTRIBUTES | Hop Att | | | | | | TTRIBUTES | ATTRIBUTES | Hop Att | | | |||
| | | | | ributes | | | | | | | | ributes | | | |||
+-----+------------+-----------+---------------+---------+----------+ | +-----+------------+-----------+---------------+---------+----------+ | |||
skipping to change at page 22, line 20 | skipping to change at page 22, line 20 | |||
| 2 | IPv6 address | This document | | | 2 | IPv6 address | This document | | |||
| 3 | Unnumbered interface | This document | | | 3 | Unnumbered interface | This document | | |||
| 4-127 | Unassigned | | | | 4-127 | Unassigned | | | |||
| 128 - 191 | Unassigned | | | | 128 - 191 | Unassigned | | | |||
| 192 - 254 | Private Use | This document | | | 192 - 254 | Private Use | This document | | |||
| 255 | Reserved | This document | | | 255 | Reserved | This document | | |||
+-----------+----------------------+---------------+ | +-----------+----------------------+---------------+ | |||
Table 7: RTM_SET object sub-object types | Table 7: RTM_SET object sub-object types | |||
8.7. RTM_SET Attribute Flag | 7.7. RTM_SET Attribute Flag | |||
IANA is requested to assign new flag from Attribute Flags registry | IANA is requested to assign new flag from Attribute Flags registry | |||
+-----+--------+-----------+------------+-----+-----+---------------+ | +-----+--------+-----------+------------+-----+-----+---------------+ | |||
| Bit | Name | Attribute | Attribute | RRO | ERO | Reference | | | Bit | Name | Attribute | Attribute | RRO | ERO | Reference | | |||
| No | | Flags | Flags Resv | | | | | | No | | Flags | Flags Resv | | | | | |||
| | | Path | | | | | | | | | Path | | | | | | |||
+-----+--------+-----------+------------+-----+-----+---------------+ | +-----+--------+-----------+------------+-----+-----+---------------+ | |||
| TBA | RTM_SE | Yes | Yes | No | No | This document | | | TBA | RTM_SE | Yes | Yes | No | No | This document | | |||
| 5 | T | | | | | | | | 5 | T | | | | | | | |||
+-----+--------+-----------+------------+-----+-----+---------------+ | +-----+--------+-----------+------------+-----+-----+---------------+ | |||
Table 8: RTM_SET Attribute Flag | Table 8: RTM_SET Attribute Flag | |||
8.8. New Error Codes | 7.8. New Error Codes | |||
IANA is requested to assign new Error Codes from Error Codes and | IANA is requested to assign new Error Codes from Error Codes and | |||
Globally-Defined Error Value Sub-Codes registry | Globally-Defined Error Value Sub-Codes registry | |||
+------------+--------------------+---------------+ | +------------+--------------------+---------------+ | |||
| Error Code | Meaning | Reference | | | Error Code | Meaning | Reference | | |||
+------------+--------------------+---------------+ | +------------+--------------------+---------------+ | |||
| TBA6 | Duplicate TLV | This document | | | TBA6 | Duplicate TLV | This document | | |||
| TBA7 | Duplicate sub-TLV | This document | | | TBA7 | Duplicate sub-TLV | This document | | |||
| TBA8 | RTM_SET TLV Absent | This document | | | TBA8 | RTM_SET TLV Absent | This document | | |||
+------------+--------------------+---------------+ | +------------+--------------------+---------------+ | |||
Table 9: New Error Codes | Table 9: New Error Codes | |||
9. Security Considerations | 8. Security Considerations | |||
Routers that support Residence Time Measurement are subject to the | Routers that support Residence Time Measurement are subject to the | |||
same security considerations as defined in [RFC5586] . | same security considerations as defined in [RFC5586] . | |||
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. | proper operation of the protocol depends on this ability. | |||
As a result, the content of the PTP-related data in RTM messages that | As a result, the content of the PTP-related data in RTM messages that | |||
will be modified by intermediate nodes cannot be authenticated, and | will be modified by intermediate nodes cannot be authenticated, and | |||
the additional information that must be accessible for proper | the additional information that must be accessible for proper | |||
operation of PTP 1-step and 2-step modes MUST be accessible to | operation of PTP one-step and two-step modes MUST be accessible to | |||
intermediate nodes (i.e. - MUST NOT be encrypted in a manner that | intermediate nodes (i.e. - MUST NOT be encrypted in a manner that | |||
makes this data inaccessible). | makes this data inaccessible). | |||
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 - and | |||
is therefore the basis for an additional presumed trust model | is therefore the basis for an additional presumed trust model | |||
associated with existing LSPs and nodes. | associated with existing LSPs and nodes. | |||
The ability for potentially authenticating and/or encrypting RTM and | The ability for potentially authenticating and/or encrypting RTM and | |||
PTP data that is not needed by intermediate RTM/PTP-capable nodes is | PTP data that is not needed by intermediate RTM/PTP-capable nodes is | |||
for further study. | for further study. | |||
Security requirements of time protocols are provided in RFC 7384 | Security requirements of time protocols are provided in RFC 7384 | |||
[RFC7384]. | [RFC7384]. | |||
10. Acknowledgments | 9. Acknowledgments | |||
Authors want to thank Loa Andersson, Lou Berger and Acee Lindem for | Authors want to thank Loa Andersson, Lou Berger and Acee Lindem for | |||
their thorough reviews, thoughtful comments and, most of, patience. | their thorough reviews, thoughtful comments and, most of all, | |||
patience. | ||||
11. References | 10. References | |||
11.1. Normative References | 10.1. Normative References | |||
[IEEE.1588.2008] | [IEEE.1588.2008] | |||
"Standard for a Precision Clock Synchronization Protocol | "Standard for a Precision Clock Synchronization Protocol | |||
for Networked Measurement and Control Systems", | for Networked Measurement and Control Systems", | |||
IEEE Standard 1588, July 2008. | IEEE Standard 1588, July 2008. | |||
[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>. | |||
skipping to change at page 25, line 15 | skipping to change at page 25, line 15 | |||
[RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising | [RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising | |||
Generic Information in IS-IS", RFC 6823, | Generic Information in IS-IS", RFC 6823, | |||
DOI 10.17487/RFC6823, December 2012, | DOI 10.17487/RFC6823, December 2012, | |||
<http://www.rfc-editor.org/info/rfc6823>. | <http://www.rfc-editor.org/info/rfc6823>. | |||
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., | [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., | |||
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>. | |||
11.2. Informative References | 10.2. Informative References | |||
[I-D.ietf-ospf-ospfv3-lsa-extend] | [I-D.ietf-ospf-ospfv3-lsa-extend] | |||
Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 | Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 | |||
LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-13 | LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-13 | |||
(work in progress), October 2016. | (work in progress), October 2016. | |||
[I-D.ietf-tictoc-1588overmpls] | [I-D.ietf-tictoc-1588overmpls] | |||
Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. | Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. | |||
Montini, "Transporting Timing messages over MPLS | Montini, "Transporting Timing messages over MPLS | |||
Networks", draft-ietf-tictoc-1588overmpls-07 (work in | Networks", draft-ietf-tictoc-1588overmpls-07 (work in | |||
skipping to change at page 25, line 50 | skipping to change at page 25, line 50 | |||
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>. | |||
Authors' Addresses | Authors' Addresses | |||
Greg Mirsky | Greg Mirsky | |||
Independent | ZTE Corp. | |||
Email: gregimirsky@gmail.com | Email: gregimirsky@gmail.com | |||
Stefano Ruffini | Stefano Ruffini | |||
Ericsson | Ericsson | |||
Email: stefano.ruffini@ericsson.com | Email: stefano.ruffini@ericsson.com | |||
Eric Gray | Eric Gray | |||
Ericsson | Ericsson | |||
Email: eric.gray@ericsson.com | Email: eric.gray@ericsson.com | |||
John Drake | John Drake | |||
Juniper Networks | Juniper Networks | |||
Email: jdrake@juniper.net | Email: jdrake@juniper.net | |||
Stewart Bryant | Stewart Bryant | |||
Independent | Huawei | |||
Email: stewart.bryant@gmail.com | Email: stewart.bryant@gmail.com | |||
Alexander Vainshtein | Alexander Vainshtein | |||
ECI Telecom | ECI Telecom | |||
Email: Alexander.Vainshtein@ecitele.com | Email: Alexander.Vainshtein@ecitele.com; Vainshtein.alex@gmail.com | |||
End of changes. 65 change blocks. | ||||
220 lines changed or deleted | 227 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |