| < 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 | |
| | | | |
| skipping to change at page 2, line 40 | | skipping to change at page 2, line 40 | |
| 4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 7 | | 4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 7 | |
| 4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 8 | | 4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 8 | |
| 4.3. RTM Capability Advertisement in OSPFv2 . . . . . . . . . 9 | | 4.3. RTM Capability Advertisement in OSPFv2 . . . . . . . . . 9 | |
| 4.4. RTM Capability Advertisement in OSPFv3 . . . . . . . . . 9 | | 4.4. RTM Capability Advertisement in OSPFv3 . . . . . . . . . 9 | |
| 4.5. RTM Capability Advertisement in IS-IS . . . . . . . . . . 9 | | 4.5. RTM Capability Advertisement in IS-IS . . . . . . . . . . 9 | |
| 4.6. RSVP-TE Control Plane Operation to Support RTM . . . . . 10 | | 4.6. RSVP-TE Control Plane Operation to Support RTM . . . . . 10 | |
| 4.7. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . . . 11 | | 4.7. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . . . 11 | |
| 4.7.1. RTM_SET Sub-TLVs . . . . . . . . . . . . . . . . . . 13 | | 4.7.1. RTM_SET Sub-TLVs . . . . . . . . . . . . . . . . . . 13 | |
| 5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 16 | | 5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 16 | |
| 6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 16 | | 6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 16 | |
|
| 7. One-step Clock and Two-step Clock Modes . . . . . . . . . . . 17 | | 7. one-step Clock and two-step Clock Modes . . . . . . . . . . . 17 | |
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | |
| 8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 19 | | 8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 19 | |
| 8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 19 | | 8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 19 | |
| 8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 20 | | 8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 20 | |
| 8.4. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 20 | | 8.4. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 20 | |
| 8.5. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 21 | | 8.5. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 21 | |
| 8.6. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 21 | | 8.6. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 21 | |
| 8.7. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 22 | | 8.7. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 22 | |
| 8.8. New Error Codes . . . . . . . . . . . . . . . . . . . . . 22 | | 8.8. New Error Codes . . . . . . . . . . . . . . . . . . . . . 22 | |
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 | | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 | |
| | | | |
| skipping to change at page 3, line 22 | | skipping to change at page 3, line 22 | |
| [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 7). | |
| | | | |
| 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. | |
| | | | |
| 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 7), the residence time is either for the timing | |
|
| packet carried in the Value field of this RTM packet or for an | | packet carried in the Value field of this RTM message or for an | |
| associated timing packet carried in the Value field of another RTM | | associated timing packet carried in the Value field of another RTM | |
|
| packet. | | 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 8.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 12 | | skipping to change at page 7, line 12 | |
| | | | |
| 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 8.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 8, line 5 | |
| 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 8.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 9, line 27 | |
| [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 7. | |
| | | | |
| 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 8.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 10, line 16 | |
| 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 8.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 10, line 44 | |
| 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. | |
| | | | |
| | | | |
| skipping to change at page 12, line 17 | | skipping to change at page 12, line 17 | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | 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 8.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- | |
| | | | |
| skipping to change at page 16, line 17 | | skipping to change at page 16, line 17 | |
| 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 7 for further details on the difference between one-step | |
| and 2-step operation. | | 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. 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 end-point 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 2-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 | |
|
| 2-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 2-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 end-point 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.2008] 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, that is, the | | Port ID field contains the identity of the source port | |
| specific PTP port of the boundary clock connected to the MPLS | | [IEEE.1588.2008], that is, the specific PTP port of the boundary | |
| network. The Sequence ID is the sequence ID of the PTP message | | clock connected to the MPLS network. The Sequence ID is the sequence | |
| carried in the Value field of the message. | | 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 | | 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 | | follow-up message will be coming. This bit, once it is set by a two- | |
| 2-step mode device, MUST stay set accordingly until the original and | | step mode device, MUST stay set accordingly until the original and | |
| follow-up messages are combined by an end-point (such as a Boundary | | follow-up messages are combined by an end-point (such as a Boundary | |
| Clock). | | Clock). | |
| | | | |
| 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. | |
| | | | |
| 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. To do this, a 2-step RTM capable egress | | behave in a similar fashion. To do this, a two-step RTM capable | |
| interface will need to examine the S-bit in the Flags field of the | | egress interface will need to examine the S-bit in the Flags field of | |
| PTP sub-TLV (for RTM messages that indicate they are for PTP) and - | | 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 | | - 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 | | 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 | | capable node MUST wait for the RTM message with the PTP type of | |
| follow-up and matching originator and sequence number to make the | | follow-up and matching originator and sequence number to make the | |
| corresponding residence time update to the Scratch Pad field. | | corresponding residence time update to the Scratch Pad field. | |
| | | | |
| In practice an RTM operating according to two-step clock behaves like | | In practice an RTM operating according to two-step clock behaves like | |
| a two-steps transparent clock. | | a two-steps transparent clock. | |
| | | | |
|
| A 1-step capable RTM node MAY elect to operate in either 1-step mode | | A one-step capable RTM node MAY elect to operate in either one-step | |
| (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 even message), or in 2-step mode (by making an | | containing the PTP even message), or in two-step mode (by making an | |
| update to the Scratch Pad of a follow-up message when its presence is | | update to the Scratch Pad of a follow-up message when its presence is | |
| indicated), but MUST NOT do both. | | indicated), but MUST NOT do both. | |
| | | | |
| Two main subcases can be identified for an RTM node operating as a | | Two main subcases can be identified for an RTM node operating as a | |
| two-step clock: | | two-step clock: | |
| | | | |
| A) If any of the previous RTM capable node or the previous PTP 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 | | (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 | | 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 | | include the associated PTP packet (i.e. follow-up message in the | |
| downstream direction), if the local RTM-capable node is also | | downstream direction), if the local RTM-capable node is also | |
| operating as a two-step clock. This RTM packet carries the related | | operating as a two-step clock. This RTM packet carries the related | |
| accumulated residence time and the appropriate values of the Sequence | | accumulated residence time and the appropriate values of the Sequence | |
| Id and Port Id (the same identifiers carried in the packet processed) | | Id and Port Id (the same identifiers carried in the packet processed) | |
| 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 the | |
| 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 2-step mode, as | | 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 | | long as that RTM-capable node forwards the follow-up message on the | |
| same LSP on which it forwards the corresponding previous message. | | same 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 event packet (sync) is carried in the RTM packet in order for | | 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 | | an RTM node to identify that residence time measurement must be | |
| performed on that specific packet. | | performed on that specific packet. | |
| | | | |
| skipping to change at page 20, line 28 | | skipping to change at page 20, line 28 | |
| +-----------+-------------------------------+---------------+ | | +-----------+-------------------------------+---------------+ | |
| | | | |
| Table 2: RTM TLV Type | | Table 2: RTM TLV Type | |
| | | | |
| 8.3. New RTM Sub-TLV Registry | | 8.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 8.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 | | |
| | | | |
| skipping to change at page 23, line 20 | | skipping to change at page 23, line 20 | |
| 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 | | 10. 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 | | 11. References | |
| | | | |
| 11.1. Normative References | | 11.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. | |
| | | | |
| | | | |
| 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(_at_)gmail(_dot_)com | | Email: gregimirsky(_at_)gmail(_dot_)com | |
| Stefano Ruffini | | Stefano Ruffini | |
| Ericsson | | Ericsson | |
| | | | |
| Email: stefano(_dot_)ruffini(_at_)ericsson(_dot_)com | | Email: stefano(_dot_)ruffini(_at_)ericsson(_dot_)com | |
| | | | |
| Eric Gray | | Eric Gray | |
| Ericsson | | Ericsson | |
| | | | |
| Email: eric(_dot_)gray(_at_)ericsson(_dot_)com | | Email: eric(_dot_)gray(_at_)ericsson(_dot_)com | |
| | | | |
| John Drake | | John Drake | |
| Juniper Networks | | Juniper Networks | |
| | | | |
| Email: jdrake(_at_)juniper(_dot_)net | | Email: jdrake(_at_)juniper(_dot_)net | |
| | | | |
| Stewart Bryant | | Stewart Bryant | |
|
| Independent | | Huawei | |
| | | | |
| Email: stewart(_dot_)bryant(_at_)gmail(_dot_)com | | Email: stewart(_dot_)bryant(_at_)gmail(_dot_)com | |
| | | | |
| Alexander Vainshtein | | Alexander Vainshtein | |
| ECI Telecom | | ECI Telecom | |
| | | | |
| Email: Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com | | Email: Alexander(_dot_)Vainshtein(_at_)ecitele(_dot_)com | |
| | | | |
End of changes. 56 change blocks. |
| 80 lines changed or deleted | | 85 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/ |