MPLS Working Group | G. Mirsky |
Internet-Draft | S. Ruffini |
Intended status: Standards Track | E. Gray |
Expires: August 15, 2016 | Ericsson |
J. Drake | |
Juniper Networks | |
S. Bryant | |
Cisco Systems | |
A. Vainshtein | |
ECI Telecom | |
February 12, 2016 |
Residence Time Measurement in MPLS network
draft-ietf-mpls-residence-time-03
This document specifies G-ACh based Residence Time Measurement and how it can be used by time synchronization protocols being transported over MPLS domain.
Residence time is the variable part of propagation delay of timing and synchronization messages and knowing what this delay is for each message allows for a more accurate determination of the delay to be taken into account in applying the value included in a PTP event message.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 15, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Time synchronization protocols, Network Time Protocol version 4 (NTPv4) [RFC5905] and Precision Time Protocol (PTP) Version 2 [IEEE.1588.2008] can be used to synchronize clocks across network domain. Measurement of the time a PTP event message spends traversing a node (using precise times of receipt at an ingress interface and transmission at an egress interface), called Residence Time, is one of on-path support types defined in [IEEE.1588.2008] and can be used to improve the accuracy of clock synchronization. This document defines new Generalized Associated Channel (G-ACh) that can be used in Multi-Protocol Label Switching (MPLS) network to measure Residence Time over Label Switched Path (LSP). Mechanisms for transport of time synchronization protocol packets over MPLS are out of scope in this document.
Though it is possible to use RTM over LSPs instantiated using LDP such scenarios are outside the scope of this document. The scope of this document is on Traffic Engineered LSPs because the LSP's path can be either explicitly specified or, at the minimum, can be determined when signaling. Such LSP can be instantiated either by using RSVP-TE [RFC3209] or Path Computation Element [RFC4655]. The PCE-based scenario is for further study and is outside the scope of this document.
[I-D.ietf-tictoc-1588overmpls] describes alternative method of on-path support for timing distribution protocols. Comparison of proposed solutions is outside the scope of this document.
MPLS: Multi-Protocol Label Switching
ACH: Associated Channel
TTL: Time-to-Live
G-ACh: Generic Associated Channel
GAL: Generic Associated Channel Label
NTP: Network Time Protocol
ppm: parts per million
PTP: Precision Time Protocol
LSP: Label Switched Path
LSR: Label Switching Router
OAM: Operations, Administration, and Maintenance
RRO: Record Route Object
RSSO: RTM Set Sub-object
RTM: Residence Time Measurement
IGP: Internal Gateway Protocol
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
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 LSP or PW. But these metrics are insufficient for use in some applications, for example, time synchronization across a network as defined in the Precision Time Protocol (PTP). PTPv2 [IEEE.1588.2008] uses "residence time", the time it takes for a PTPv2 event packet to transit a node. Residence times are accumulated in the correctionField of the PTP event messages, as defined in [IEEE.1588.2008], or of the associated follow-up messages (or Delay_Resp message associated with the Delay_Req message) in case of two-step clocks (detailed discussion in Section 7). The residence time values are specific to each output PTP port and message.
IEEE 1588 uses this residence time to correct the propagated time, effectively making these nodes transparent.
This document proposes mechanism to accumulate packet residence time from all LSRs that support the mechanism across a particular LSP. The values accumulated in scratchpad fields of MPLS RTM messages can be used by the last RTM-capable LSR on an LSP to update the correctionField of the corresponding PTP event packet prior to performing the usual PTP processing.
RFC 5586 [RFC5586] and RFC 6423 [RFC6423] extended applicability of PW Associated Channel (ACH) [RFC5085] to LSPs. G-ACh provides a mechanism to transport OAM and other control messages. Processing by arbitrary transit LSRs can be triggered through controlled use of the Time-to-Live (TTL) value. In a way that is analogous to PTP operations, the packet residence time can be handled by the RTM capable node either as "one-step clock" or as a "two-step clock".
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 0 0 1|Version| Reserved | RTM Channel | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Scratch Pad | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RTM G-ACh packet format for Residence Time Measurement
The packet format for Residence Time Measurement (RTM) is presented in Figure 1
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags |PTPType| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port ID | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Sequence ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PTP Sub-TLV format
Figure 2 presents format of a PTP sub-TLV that MUST be precede every PTP packet carried in RTM TLV.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Flags field format of PTP Packet Sub-TLV
where Flags field has format
The operation of RTM depends upon TTL expiry to deliver an RTM packet from one RTM capable interface to the next along the path from ingress LSR to egress LSR. This means that an LSR with RTM capable interfaces MUST be able to compute a TTL which will cause the expiry of an RTM packet at the next LSR with RTM capable interfaces.
Note that RTM capability of a node is with respect to the pair of interfaces that will be used to forward an RTM packet. In general, 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 information will be available to the egress interface.
The supported modes (1-step verses 2-step) of any pair of interfaces is then determined by the capability of the egress interface. In both cases, the egress interface implementation MUST be able to determine the precise departure time of the same packet and determine from this, and the arrival time information from the corresponding ingress interface, the difference representing the residence time for the packet.
An interface with the ability to do this and update the associated ScratchPad in real-time (i.e. while the packet is being forwarded) is said to be 1-step capable.
Hence while both ingress and egress interfaces are required to 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 capable with respect to the interface-pair.
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, 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 record packet arrival time in some way that can be conveyed to and used by that egress interface.
When an LSR uses an IGP to carry the RTM capability sub-TLV, the sub-TLV MUST reflect the RTM capability (1-step or 2-step) associated with egress interfaces and MUST NOT propagate this sub-TLV in IGP LSAs sent from a router which describe a particular interface that does not support the same capability for RTM messages it receives.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTM | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: RTM Capability sub-TLV
The format for the RTM Capabilities sub-TLV is presented in Figure 4
[RFC4202] explains that the Interface Switching Capability Descriptor describes switching capability of an interface. For bi-directional links, the switching capabilities of an interface are defined to be the same in either direction. I.e., for data entering the node through that interface and for data leaving the node through that interface". That principle SHOULD be applied when a node advertises RTM Capability.
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 two-step RTM modes in Section 7.
The capability to support RTM on a particular link advertised in the OSPFv2 Extended Link Opaque LSA described in Section 3 [RFC7684] as RTM Capability sub-TLV, presented in Figure 4, of the OSPFv2 Extended Link TLV.
Type value will be assigned by IANA from the OSPF Extended Link TLV Sub-TLVs registry that will be created per [RFC7684] request.
The capability to support RTM on a particular link in OSPFv3 can be advertised by including an RTM Capability sub-TLV defined in Section 4.3 in the following TLVs defined in [I-D.ietf-ospf-ospfv3-lsa-extend] Intra-Area-Prefix TLV, IPv6 Link-Local Address TLV, or IPv4 Link-Local Address TLV when these are included in E-Link-LSA.
The RTM capability logically belongs to a group of parameters characterized as "generic information not directly related to the operation of the IS-IS protocol" [RFC6823]. Hence the capability to process RTM messages can be advertised by including RTM Capability sub-TLV in GENINFO TLV [RFC6823].
With respect to the Flags field of the GENINFO TLV:
Application ID (TBA4) will be assigned from the Application Identifiers for TLV 251 IANA registry. The RTM Capability sub-TLV, presented in Figure 4, MUST be included in GENINFO TLV in Application Specific Information.
Throughout this document we refer to an LSR as RTM capable LSR when at least one of its interfaces is RTM capable. Figure 5 provides an example of relationship between roles a network element may have in PTP over MPLS scenario and RTM capability:
----- ----- ----- ----- ----- ----- ----- | A |-----| B |-----| C |-----| D |-----| E |-----| F |-----| G | ----- ----- ----- ----- ----- ----- -----
Figure 5: RTM capable roles
An ingress LSR that is configured to perform RTM along a path through an MPLS network to an egress LSR verifies that the selected egress LSR has an interface that supports RTM via the egress LSR's advertisement of the RTM Capability sub-TLV. In the Path message that the ingress LSR uses to instantiate the LSP to that egress LSR it places initialized Record Route Object (RRO) [RFC3209] and LSP_ATTRIBUTES Object [RFC5420] with RTM Set Sub-object (RSSO) [Section 4.7], which indicates to the egress LSR that RTM is requested for this LSP. RSSO SHOULD NOT be included into the LSP_REQUIRED_ATTRIBUTES object [RFC5420] , unless it is known that all LSRs support RSSO, because then LSR that does not recognize RSSO would reject the Path message.
In the Resv message that the egress LSR sends in response to the received Path message, it includes initialized RRO and RSSO. The RSSO contains an ordered list, from egress LSR to ingress LSR, of the RTM capable LSRs along the LSP's path. Each such LSR will use the ID of the first LSR in the RSSO in conjunction with the RRO to compute the hop count to its downstream LSR with reachable RTM capable interface. It will also insert its ID at the beginning of the RSSO before forwarding the Resv message upstream.
After the ingress LSR receives the Resv, it MAY begin sending RTM packets to the first RTM capable LSR on the LSP's path. Each RTM packet has its Scratch Pad field initialized and its TTL set to expire on that first subsequent RTM capable LSR.
It should be noted that RTM can also be used for LSPs instantiated using [RFC3209] in an environment in which all interfaces in an IGP support RTM. In this case the RSSO and LSP_ATTRIBUTES Object MAY be omitted.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: RTM Set Sub-object format
RTM capable interfaces can be recorded via RTM_SET sub-object (RSSO). The RTM_SET sub-object format is of generic Type, Length, Value (TLV), presented in Figure 6
Type value (TBA5) will be assigned by IANA from its Attributes TLV Space sub-registry.
The Length contains the total length of the sub-object in bytes, including the Type and Length fields.
Reserved field must be zeroed on transmit and ignored on receipt.
The content of an RSSO is a series of variable-length sub-TLVs. The sub-TLVs are defined in Section 4.7.1 below.
The RSSO can be present in both RSVP Path and Resv messages. If a Path message contains multiple RSSOs, only the first RSSO is meaningful. Subsequent RSSOs SHOULD be ignored and SHOULD NOT be propagated. Similarly, if in a Resv message multiple RSSOs are encountered following a FILTER_SPEC before another FILTER_SPEC is encountered, only the first RSSO is meaningful. Subsequent RSSOs SHOULD be ignored and SHOULD NOT be propagated.
The RTM Set sub-object contains an ordered list, from egress LSR to ingress LSR, of the RTM capable LSRs along the LSP's path.
The contents of a RTM_SET sub-object are a series of variable-length sub-TLVs. Each sub-TLV has its own Length field. The Length contains the total length of the sub-TLV in bytes, including the Type and Length fields. The Length MUST always be a multiple of 4, and at least 8 (smallest IPv4 sub-object).
Sub-TLVs are organized as a last-in-first-out stack. The first -out sub-TLV relative to the beginning of RSSO is considered the top. The last-out sub-TLV is considered the bottom. When a new sub-TLV is added, it is always added to the top.
Three kinds of sub-TLVs for RSSO are currently defined.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: IPv4 sub-TLV format
Type
Length
IPv4 address
Flags
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: IPv6 sub-TLV format
Type
Length
IPv6 address
Flags
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: IPv4 sub-TLV format
Type
Length
Router ID
Interface ID
Flags
After instantiating an LSP for a path using RSVP-TE [RFC3209] as described in Section 4.6 or as described in the second paragraph of Section 4 and in Section 4.6, ingress LSR MAY begin sending RTM packets to the first downstream RTM capable LSR on that path. Each RTM packet has its Scratch Pad field initialized and its TTL set to expire on the next downstream RTM-capable LSR. Each RTM-capable LSR 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 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 ensure precise accuracy in time determination. The RTM-capable LSR determines the difference between those two times; for 1-step operation, this difference is determined just prior to or while 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, for the purpose of calculating a residence time, a common free running clock synchronizing all the involved interfaces may be sufficient, as, for example, 4.6 ppm accuracy leads to 4.6 nanosecond error for residence time on the order of 1 millisecond.
For 2-step operation, the difference between packet arrival time (at an ingress interface) and subsequent departure time (from an egress interface) is determined at some later time prior to sending a subsequent follow-up message, so that this value can be used to update the correctionField in the follow-up message.
See Section 7 for further details on the difference between 1-step and 2-step operation.
The last RTM-capable LSR on the LSP MAY then use the value in the Scratch Pad field to perform time correction, if there is no follow-up message. For example, the egress LSR may be a PTP Boundary Clock synchronized to a Master Clock and will use the value in the Scratch Pad field to update PTP's correctionField.
The proposed approach can be directly integrated in a PTP network based on the IEEE 1588 delay reqest-response mechanism. The RTM capable LSR nodes act as end-to-end transparent clocks, and typically boundary clocks, at the edges of the MPLS network, use the value in the Scratch Pad field to update the correctionField of the corresponding PTP event packet prior to performing the usual PTP processing.
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:
IEEE 1588v2 [IEEE.1588.2008] defines this behaviour 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 LSR), 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 LSR 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 LSR to also operate in the 2-step mode, as long as that RTM-capable LSR 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, modeif 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.
IANA is requested to reserve a new G-ACh as follows:
Value | Description | Reference |
---|---|---|
TBA1 | Residence Time Measurement | This document |
IANA is requested to create sub-registry in Generic Associated Channel (G-ACh) Parameters Registry called "MPLS RTM TLV Registry". All code points in the range 0 through 127 in this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC5226] . Remaining code points are allocated according to the table below. This document defines the following new values RTM TLV type s:
Value | Description | Reference |
---|---|---|
0 | Reserved | This document |
1 | No payload | This document |
2 | PTPv2 | This document |
3 | NTP | This document |
4-127 | Reserved | IETF Consensus |
128 - 191 | Reserved | First Come First Served |
192 - 255 | Reserved | Private Use |
IANA is requested to create sub-registry in MPLS RTM TLV Registry, 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 allocated according to the "IETF Review" procedure as specified in [RFC5226] . Remaining code points are allocated according to the table below. This document defines the following new values RTM sub-TLV types:
Value | Description | Reference |
---|---|---|
0 | Reserved | This document |
1 | PTP 2-step | This document |
2-127 | Reserved | IETF Consensus |
128 - 191 | Reserved | First Come First Served |
192 - 255 | Reserved | Private Use |
IANA is requested to assign a new type for RTM Capability sub-TLV from OSPFv2 Extended Link TLV Sub-TLVs registry as follows:
Value | Description | Reference |
---|---|---|
TBA2 | RTM Capability | This document |
IANA is requested to assign a new type for RTM Capability sub-TLV from future OSPFv3 Extended-LSA Sub-TLVs registry that would be part of OSPFv3 IANA registry as follows:
Value | Description | Reference |
---|---|---|
TBA3 | RTM Capability | This document |
IANA is requested to assign a new Application ID for RTM from the Application Identifiers for TLV 251 registry as follows:
Value | Description | Reference |
---|---|---|
TBA4 | RTM | This document |
IANA is requested to assign a new Type for RTM_SET sub-object from Attributes TLV Space sub-registry as follows:
Type | Name | Allowed on LSP_ATTRIBUTES | Allowed on LSP_REQUIRED_ATTRIBUTES | Allowed on LSP Hop Attributes | Reference |
---|---|---|---|---|---|
TBA5 | RTM_SET sub-object | Yes | No | No | This document |
IANA requested to create new sub-registry for sub-TLV types of RTM_SET sub-object as follows:
Value | Description | Reference |
---|---|---|
0 | Reserved | |
1 | IPv4 address | This document |
2 | IPv6 address | This document |
3 | Unnumbered interface | This document |
4-127 | Reserved | IETF Consensus |
128 - 191 | Reserved | First Come First Served |
192 - 255 | Reserved | Private Use |
Routers that support Residence Time Measurement are subject to the same security considerations as defined in [RFC5586] .
In addition - particularly as applied to use related to PTP - there 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 PTP messages. This is necessary as these nodes are expected to correctly modify specific content of the data in PTP messages and proper operation of the protocol depends on this ability.
As a result, the content of the PTP-related data in RTM messages that will be modified by intermediate nodes cannot be authenticated, and the additional information that must be accessible for proper operation of PTP 1-step and 2-step modes MUST be accessible to intermediate nodes (i.e. - MUST NOT be encrypted in a manner that makes this data inaccessible).
While it is possible for a supposed compromised LSR to intercept and modify the G-ACh content, this is an issue that exists for LSRs in general - for any and all data that may be carried over an LSP - and is therefore the basis for an additional presumed trust model associated with existing LSPs and LSRs.
The ability for potentially authenticating and/or encrypting RTM and PTP data that is not needed by intermediate RTM/PTP-capable nodes is for further study.
Security requirements of time protocols are provided in RFC 7384 [RFC7384].
Authors want to thank Loa Andersson for his thorough review and thoghtful comments.
[I-D.ietf-tictoc-1588overmpls] | Davari, S., Oren, A., Bhatia, M., Roberts, P. and L. Montini, "Transporting Timing messages over MPLS Networks", Internet-Draft draft-ietf-tictoc-1588overmpls-07, October 2015. |
[RFC4202] | Kompella, K. and Y. Rekhter, "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005. |
[RFC4655] | Farrel, A., Vasseur, J. and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006. |
[RFC5226] | Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008. |
[RFC6374] | Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011. |
[RFC7384] | Mizrahi, T., "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, October 2014. |