Residence Time Measurement
in MPLS NetworksZTE Corp.gregimirsky@gmail.comEricssonstefano.ruffini@ericsson.comEricssoneric.gray@ericsson.comJuniper Networksjdrake@juniper.netHuaweistewart.bryant@gmail.comECI TelecomAlexander.Vainshtein@ecitele.com; Vainshtein.alex@gmail.com
Routing
MPLS Working GroupG-AChResident TimeMPLS
This document specifies a new Generic Associated Channel (G-ACh) for
Residence Time Measurement (RTM) and
describes how it can be used
by time synchronization protocols within an MPLS domain.
Residence time is the variable part of the propagation delay of
timing and synchronization messages;
knowing this delay for each message allows for a more
accurate determination of the
delay to be taken into account when applying the value included in a
Precision Time Protocol event message.
Time synchronization protocols, e.g., the Network Time Protocol version 4 (NTPv4) and
the Precision Time Protocol version 2 (PTPv2) , define timing messages that
can be used to synchronize clocks across a network domain. Measurement of the cumulative
time that one of these timing messages spends transiting the nodes
on the path from ingress node to egress node is termed
"residence time" and is used to improve the accuracy of clock synchronization.
Residence time is the sum of the difference between the time of receipt at an ingress interface
and the time of transmission from an egress interface for each node along the network path
from an ingress node to an egress node. This document defines a new Generic Associated Channel (G-ACh)
value and an associated Residence Time Measurement (RTM) message that can be
used in a Multiprotocol Label Switching (MPLS) network to measure residence time over a Label Switched Path (LSP).
This document describes RTM over an LSP signaled using RSVP&nbhy;TE .
Using RSVP-TE, the LSP's path can be either explicitly specified or determined during signaling.
Although it is possible to use RTM over an LSP instantiated using the Label Distribution Protocol ,
that is outside the scope of this document.
Comparison with alternative proposed solutions such as
is outside the scope of this document.
Multiprotocol Label Switching Associated Channel Header Time to Live Generic Associated Channel Generic Associated Channel Label Network Time Protocol parts per million Precision Time Protocol boundary clock Label Switched Path Operations, Administration, and Maintenance Record Route Object Residence Time Measurement Internal Gateway Protocol Border Gateway Protocol - Link State
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
.
"Packet Loss and Delay Measurement for MPLS Networks" can be used to
measure one-way or two-way end-to-end propagation delay over an LSP or a pseudowire (PW). But these measurements
are insufficient for use in some applications, for example, time synchronization across a network
as defined in the PTP. In PTPv2 , the residence time
is accumulated in the correctionField of the PTP event message, which is defined in
and referred to as using a one-step clock,
or in the associated follow-up message (or Delay_Resp message associated with
the Delay_Req message), which is referred to as using a two-step clock (see the detailed discussion in ).
IEEE 1588 uses this residence time to correct for the transit times of nodes on an LSP,
effectively making the transit nodes transparent.
This document proposes a mechanism that can be used as one type of
on-path support
for a clock synchronization protocol or can be used to perform one-way
measurement of residence time.
The proposed mechanism accumulates residence time from all nodes that support
this extension along the path of a particular LSP in the Scratch Pad
field of an RTM message ().
This value can then be used by the egress node to update, for example, the correctionField of the PTP
event packet carried within the RTM message prior to performing its 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 endpoint 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:
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 endpoint know to wait for a follow-up message.
Create a follow-up message in which to put the RTM determined as an initial correctionField value.
IEEE 1588v2 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 (BC) 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 MAY be set by a two-step mode PTP device. The value MUST NOT be unset until the original and
follow-up messages are combined by an endpoint (such as a BC).
For compatibility with PTP, RTM (when used for PTP packets) must behave in a similar fashion.
It should be noted that the handling of Sync event messages and
of Delay_Req/Delay_Resp event messages that cross a two-step RTM node is different.
The following outlines the handling of a PTP Sync event message by the two-step RTM node.
The details of handling Delay_Resp/Delay_Req PTP event messages by the two-step RTM node are discussed in .
As a summary, 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 the S bit 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.
The wait period MUST be reasonably bounded.
Thus, an RTM packet, containing residence time information relating to an earlier packet, also contains
information identifying that earlier packet.
In practice, an RTM node operating in two-step mode behaves like a two-step 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 two-step mode
(by making an update to the Scratch Pad of a follow-up message when presence of a follow-up is indicated),
but it MUST NOT do both.
Two main subcases identified for an RTM node operating as a two-step clock are described in the following sub-sections.
If any of the previous RTM-capable nodes or the previous PTP clock
(e.g., the BC connected to the first node) is a two-step clock and if the local RTM-capable node is also operating a two-tep clock, the residence time is added to the RTM
packet that has been created to include the second PTP packet (i.e., the follow-up message in the
downstream direction). This RTM packet carries
the related accumulated residence time, the appropriate values of the Sequence ID and Port ID (the
same identifiers carried in the original packet), and the two-step flag set to 1.
Note that the fact that an upstream RTM-capable node operating in two-step
mode has created a follow-up message does not require any subsequent RTM-capable
node to also operate in 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 Sync packet is carried in the RTM packet in order to indicate to the RTM node that
RTM must be performed on that specific packet.
To handle the residence time of the Delay_Req message in the upstream
direction, an RTM
packet must be created to carry the residence time in the associated
downstream Delay_Resp message.
The last RTM node of the MPLS network, in addition to updating the correctionField of the associated PTP
packet, must also react properly to the two-step flag of the PTP packets.
When the PTP network connected to the MPLS operates in one-step clock
mode and an RTM node operates in two-step mode, the
follow-up RTM packet must be created by the RTM node itself. The RTM packet
carrying the PTP event packet needs now to indicate that a follow-up message will be coming.
The egress RTM-capable node of the LSP will remove RTM encapsulation
and, in case of
two-step clock mode being indicated, will generate PTP messages to include
the follow-up correction as appropriate
(according to ).
In this case, the common header of the PTP packet carrying the synchronization message
would have to be modified by setting the twoStepFlag field indicating that there is now a
follow-up message associated to the current message.
and
define the G-ACh to extend the applicability of the Pseudowire Associated
Channel Header (ACH) to LSPs. G-ACh provides a mechanism to transport OAM
and other control messages over an LSP. Processing of these messages by selected transit nodes
is controlled by the use of the Time-to-Live (TTL) value in the MPLS header of these messages.
The message format for RTM is presented in .
The first four octets are defined as a G-ACh header in .The Version field is set to 0, as defined in . The Reserved field MUST be
set to 0 on transmit and ignored on receipt. The RTM G-ACh field (value 0x000F; see ) identifies the packet
as such. The Scratch Pad field is 8 octets in length. It is used to accumulate the residence
time spent in each RTM-capable node transited by the packet on its path from ingress node to egress node.
The first RTM-capable node MUST initialize the Scratch
Pad field with its RTM.
Its format is a 64-bit signed integer, and it indicates the value of the residence time measured in nanoseconds and multiplied by 2^16. Note that depending on whether the timing procedure is
a one-step or two-step operation (),
the residence time is either for the timing packet carried in the Value field of this RTM
message or for an associated timing packet carried in the Value field of another RTM message.
The Type field identifies the type and encapsulation of a timing packet carried in the Value field,
e.g., NTP or PTP .
Per this document, IANA has created a sub-registry called the "MPLS RTM TLV
Registry" in the "Generic
Associated Channel (G-ACh) Parameters" registry
(see ).
The Length field contains the length, in octets, of any Value field defined for the Type given in the Type field.
The TLV MUST be included in the RTM message, even if the length of the Value field is zero.
presents the format of a PTP sub-TLV that MUST be
included in the Value field of an RTM message preceding the carried timing
packet when the timing packet is PTP.
where the Flags field has the following format:
The Type field identifies the PTP packet sub-TLV and is set to 1 according to .The Length field of the PTP sub-TLV contains the number of octets of the Value part of the TLV and MUST be 20.
The Flags field currently defines one bit, the S bit, that defines whether the current message
has been processed by a two-step node, where the flag is cleared if the message has been handled
exclusively by one-step nodes and there is no follow-up message and is set if there has been at least
one two-step node and a follow-up message is forthcoming.
The PTPType field indicates the type of PTP packet to which this PTP sub-TLV applies. PTPType is the messageType
field of a PTPv2 packet with possible values defined in Table 19 of .
The 10-octet-long Port ID field contains the identity of the source port. The Sequence ID is the sequence ID of the PTP message to which this PTP sub-TLV applies.
A tuple of PTPType, Port ID, and Sequence ID uniquely identifies the PTP timing message included in an RTM message and is used in two-step RTM mode; see .
The Value field (see Figure 1) -- in addition to the PTP sub-TLV -- MAY carry a packet of the PTP
Time synchronization protocol (as was identified by the Type field). It is important to note
that the timing message packet may be authenticated or encrypted and carried over this LSP
unchanged (and inaccessible to intermediate RTM capable LSRs) while the residence time is
accumulated in the Scratch Pad field.
The LSP ingress RTM-capable LSR populates the identifying tuple information of the PTP sub-TLV
(see section 3.1) prior to including the (possibly authenticated/encrypted) PTP message packet
after the PTP sub-TLV in the Value field of the RTM message for an RTM message of the PTP Type
(Type 1; see ).
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 node to egress node. This means that a node with RTM-capable interfaces MUST be able to
compute a TTL, which will cause the expiry of an RTM packet at the next node with RTM-capable interfaces.
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, 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 of a node.
The supported mode (one-step or two-step) of any pair of interfaces is determined
by the capability of the egress interface. For both modes, 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 Scratch Pad in real time
(i.e., while the packet is being forwarded) is said to be one-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 one-step
or two-step capable with respect to the interface pair.
The RTM capability used in the sub-TLV shown in Figures
and is thus
a non-routing-related capability associated with the interface being advertised based on its egress
capability. The ability of any pair of interfaces on a node that includes
this egress interface to support any mode of RTM depends on the ability of the ingress interface
of a node to record packet arrival time and convey it to the egress interface on the node.
When a node uses an IGP to support the RTM capability advertisement, the IGP sub-TLV MUST reflect the
RTM capability (one-step or two-step) associated with the advertised interface. Changes of RTM capability
are unlikely to be frequent and would result, for example, from the operator's decision to include or
exclude a particular port from RTM processing or switch between RTM modes.
explains that the Interface Switching Capability Descriptor
describes the switching capability of an interface. For bidirectional links, the switching
capabilities of an interface are defined to be the same in either direction, that is, 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.
A detailed discussion of one-step and two-step RTM modes is contained in .
The format for the RTM Capability sub-TLV in OSPF is presented in .
Type value (5) has been assigned by IANA in the "OSPFv2 Extended Link TLV
Sub-TLVs" registry (see ).Length value equals the number of octets of the Value field.
Value contains a variable number of bitmap fields so that the overall number of bits in the fields
equals Length * 8.
Bits are defined/sent starting with Bit 0. Additional
bitmap field definitions that may be defined in the future SHOULD be assigned
in ascending bit order so as to minimize the number of bits that will
need to be transmitted.
Undefined bits MUST be transmitted as 0 and MUST be ignored on
receipt.
Bits that are NOT transmitted MUST be treated as if they are set to 0
on receipt.
RTM (capability) is a 3-bit-long bitmap field with values defined as follows:
0b001 - one-step RTM supported0b010 - two-step RTM supported0b100 - reserved
The capability to support RTM on a particular link (interface) is
advertised in the OSPFv2 Extended Link Opaque LSA as
described in Section 3 of via the RTM Capability sub-TLV.
The capability to support RTM on a particular link (interface) can be advertised in OSPFv3 using
LSA extensions as described in .
The sub-TLV SHOULD use the same format as in .
The type allocation and full details of exact use of OSPFv3 LSA extensions
is for further study.
The capability to support RTM on a particular link (interface) is
advertised in a new sub-TLV that may be included in TLVs advertising
Intermediate System (IS) Reachability on a specific link (TLVs 22, 23, 222, and 223).
The format for the RTM Capability sub-TLV is presented in .
Type value (40) has been assigned by IANA in the
"Sub-TLVs for TLVs 22, 23, 141, 222, and 223"
registry for IS-IS (see ).
Definitions, rules of handling, and values for the Length and Value fields are as defined
in .
RTM (capability) is a 3-bit-long bitmap field with values defined
in .
The format for the RTM Capability TLV is presented in .
Type value (1105) has been assigned by IANA in the "BGP-LS Node Descriptor, Link
Descriptor, Prefix Descriptor,
and Attribute TLVs" sub-registry (see ).
Definitions, rules of handling, and values for fields Length, Value, and RTM are as defined
in .
The RTM Capability will be advertised in BGP-LS as a Link Attribute TLV associated with
the Link NLRI as described in Section 3.3.2 of .
Throughout this document, we refer to a node as an
RTM-capable node when at least one of its interfaces is RTM capable.
provides an example of roles a node may have with respect to RTM capability:
A is a boundary clock with its egress port in Master state. Node A transmits
IP-encapsulated timing packets whose destination IP address is G.B is the ingress Label Edge Router (LER) for the MPLS LSP and is the first RTM-capable node.
It creates RTM packets, and in each it places
a timing packet, possibly encrypted, in the Value field and initializes the
Scratch Pad field with its RTM.C is a transit node that is not RTM capable. It forwards RTM packets without modification.D is an RTM-capable transit node. It updates the Scratch Pad field of the RTM packet without updating
the timing packet.E is a transit node that is not RTM capable. It forwards RTM packets without modification.F is the egress LER and the last RTM-capable node. It removes the RTM ACH encapsulation and
processes the timing packet carried in the Value field
using the value in the Scratch Pad field. In particular, the value in the Scratch Pad field of the
RTM ACH is used in updating the Correction field of the PTP message(s). The LER should also include
its own residence time before creating the outgoing PTP packets.
The details of this process depend on whether or not the node F is itself operating as
a one-step or two-step clock.G is a boundary clock with its ingress port in Slave state. Node G receives PTP messages.
An ingress node that is configured to perform RTM along a path through an MPLS network
to an egress node MUST verify that
the selected egress node has an interface that supports RTM via the egress node's
advertisement of the RTM
Capability sub-TLV, as covered in . In the Path
message that the ingress node uses to instantiate the LSP to that egress node,
it places an LSP_ATTRIBUTES object with an RTM_SET
Attribute Flag set, as described in ,
which indicates to the egress node that RTM is requested for this LSP.
The RTM_SET Attribute Flag SHOULD NOT be set in
the LSP_REQUIRED_ATTRIBUTES object ,
unless it is known that all nodes recognize the RTM attribute (but need not necessarily implement it),
because a node that does not recognize the RTM_SET Attribute Flag would reject the Path message.
If an egress node receives a Path message with the RTM_SET Attribute Flag in an LSP_ATTRIBUTES object,
the egress node MUST include an initialized
RRO and LSP_ATTRIBUTES object where the RTM_SET Attribute Flag is set and
the RTM_SET TLV () is initialized. When the
Resv message is received by the ingress node, the RTM_SET TLV
will contain an ordered list, from egress
node to ingress node, of the RTM-capable nodes along the LSP's path.
After the ingress node receives the Resv, it MAY begin sending RTM packets on the
LSP's path. Each RTM packet has its Scratch Pad field initialized and its TTL set to expire on the
closest downstream RTM-capable node.
It should be noted that RTM can also be used for LSPs instantiated using
in an environment in which all interfaces in an IGP support RTM. In this case, the RTM_SET TLV
and LSP_ATTRIBUTES object MAY be omitted.
RTM-capable interfaces can be recorded via the RTM_SET TLV.
The RTM_SET sub-object format is a generic TLV format,
presented in .
Type value (5) has been assigned by IANA in the RSVP-TE "Attributes TLV
Space" sub-registry (see ).
The Length contains the total length of the sub-object in bytes, including the Type and Length fields.
The I bit indicates whether the downstream RTM-capable node along the LSP is present in the RRO.
The 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&nbhy;TLVs.
Only a single RTM_SET can be present in a given LSP_ATTRIBUTES object.
The sub-TLVs are defined in .
The following processing procedures apply to every RTM-capable node along the LSP. In this paragraph,
an RTM-capable node is referred to as a node for sake of brevity. Each
node MUST examine the Resv message for whether the RTM_SET Attribute Flag in the LSP_ATTRIBUTES object is set.
If the RTM_SET flag is set, the node MUST inspect the LSP_ATTRIBUTES object for presence of an RTM_SET TLV.
If more than one is found, then the LSP setup MUST fail with generation
of the ResvErr message with Error Code "Duplicate TLV" () and Error Value
that contains the Type value in its 8 least significant bits. If no RTM_SET TLV is found,
then the LSP setup MUST fail with generation
of the ResvErr message with Error Code "RTM_SET TLV Absent" ().
If one RTM_SET TLV has 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 downstream node with a reachable RTM-capable interface.
If the node cannot find a matching ID in the RRO, then it MUST try to use
the ID of the next node in the RTM_SET until it
finds the match or reaches the end of the RTM_SET TLV. If a match has been found,
the calculated value is used by the node as the TTL
value in the outgoing label to reach the next RTM-capable node on the LSP.
Otherwise, the TTL value MUST be set to 255.
The node MUST add an RTM_SET sub-TLV with the same address it used in the RRO sub&nbhy;object
at the beginning of the RTM_SET TLV in the associated outgoing Resv message before forwarding it upstream.
If the calculated TTL value has been set to 255, as described above, then the I
flag in the node's RTM_SET TLV MUST be set to 1
before the Resv message is forwarded upstream. Otherwise,
the I flag MUST be cleared (0).
The ingress node MAY inspect the I bit received in each RTM_SET TLV
contained in the LSP_ATTRIBUTES object of a received Resv
message. The presence of the RTM_SET TLV with the I bit set to 1 indicates
that some RTM nodes along the LSP could not be included in the
calculation of the residence time. An ingress node MAY choose to resignal
the LSP to include all RTM nodes or simply notify the user via a management
interface.
There are scenarios when some information is removed from an RRO due to
policy processing (e.g., as may happen between providers)
or the RRO is limited due to size constraints.
Such changes affect the core assumption of this method and the processing of RTM packets.
RTM SHOULD NOT be used if it is not guaranteed that the RRO contains complete information.
The RTM Set sub-object contains an ordered list, from egress node to
ingress node, of the RTM-capable nodes along the LSP's path.
The contents of an RTM_SET sub-object are a series of variable-length
sub-TLVs. Each sub-TLV has its own Length
field. The Length 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 RTM_SET TLV is considered the top.
The last-out sub-TLV is considered the bottom. When a new sub&nbhy;TLV is
added, it is always added to the top.
The RTM_SET TLV is intended to include the subset of the RRO sub-TLVs that
represent those egress interfaces on the LSP that are RTM capable.
After a node chooses an egress interface to use in the RRO sub-TLV,
that same egress interface, if RTM capable, SHOULD be placed into
the RTM_SET TLV using one of the following: IPv4 sub-TLV, IPv6 sub-TLV, or Unnumbered
Interface sub-TLV. The address family chosen SHOULD match that of the RESV
message and that used in the RRO; the unnumbered interface sub-TLV is used
when the egress interface has no assigned IP address. A node MUST NOT
place more sub-TLVs in the RTM_SET TLV than the number of RTM-capable
egress interfaces the LSP traverses that are under that node's control.
Only a single RTM_SET sub-TLV with the given
Value field MUST be present in the RTM_SET TLV. If more than one sub-TLV with the same value (e.g., a duplicated address) is found,
the LSP setup MUST fail with the generation of a ResvErr message with the Error Code
"Duplicate sub&nbhy;TLV" () and the Error Value containing
a 16-bit value composed of (Type of TLV, Type of sub-TLV).
Three kinds of sub-TLVs for RTM_SET are currently defined.
Type
0x01 IPv4 address.
Length
The Length contains the total length of the sub-TLV in bytes,
including the Type and Length fields. The Length is always 8.
IPv4 address
A 32-bit unicast host address.
Reserved
Zeroed on initiation and ignored on receipt.
Type
0x02 IPv6 address.
Length
The Length contains the total length of the sub-TLV in bytes,
including the Type and Length fields. The Length is always 20.
IPv6 address
A 128-bit unicast host address.
Reserved
Zeroed on initiation and ignored on receipt.
Type
0x03 Unnumbered interface.
Length
The Length contains the total length of the sub-TLV in bytes,
including the Type and Length fields. The Length is always 12.
Node ID
The Node ID interpreted as the Router ID as discussed in Section 2 of .
Interface ID
The identifier assigned to the link by the node specified by the Node ID.
Reserved
Zeroed on initiation and ignored on receipt.
After instantiating an LSP for a path using RSVP-TE
as described in ,
the ingress node MAY begin sending RTM packets to the first downstream
RTM-capable node on that path. Each RTM packet has its Scratch Pad field initialized
and its TTL set to expire on the next downstream RTM-capable node.
Each RTM-capable 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 the time
at which it transmits that packet from its egress interface.
These actions should be done as close to the physical
layer as possible at the same point of packet processing, striving to avoid introducing
the appearance of jitter in propagation delay whereas it should be accounted as residence time.
The RTM-capable node determines the difference between those two
times; for one-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 a 4.6 nanosecond error for residence time
on the order of 1 millisecond. This may be acceptable for applications where the
target accuracy is in the order of hundreds of nanoseconds. As an example, several applications
being considered in the area of wireless applications are satisfied with an accuracy
of 1.5 microseconds .
For two-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 for further details on the difference between one-step and two-step operation.
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&nbhy;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 Pad field to update PTP's correctionField.
This approach can be directly integrated in a PTP network based
on the IEEE 1588 delay request-response mechanism. The RTM-capable nodes act
as end-to-end transparent clocks, and boundary clocks, at the edges
of the
MPLS network, typically 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.
IANA has assigned a new G-ACh as follows:
ValueDescriptionReference0x000FResidence Time MeasurementThis document
IANA has created a sub-registry in the "Generic Associated Channel (G-ACh)
Parameters" registry
called the "MPLS RTM TLV Registry". All codepoints in the range 0 through
127 in this registry shall be allocated
according to the "IETF Review" procedure as specified in . Codepoints in the range
128 through 191 in this registry shall be allocated according to the
"First Come First Served" procedure as
specified in .
This document defines the following new RTM TLV types:
ValueDescriptionReference0ReservedThis document1No payloadThis document2PTPv2, Ethernet encapsulationThis document3PTPv2, IPv4 encapsulationThis document4PTPv2, IPv6 encapsulationThis document5NTPThis document6-191Unassigned192-254Reserved for Private UseThis document255ReservedThis document
IANA has created a sub-registry in the "MPLS RTM TLV Registry" (see
)
called the "MPLS RTM Sub-TLV Registry". All codepoints in the range 0
through 127 in this registry shall be allocated
according to the "IETF Review" procedure as specified in . Codepoints in the range
128 through 191 in this registry shall be allocated according to the "First Come First Served" procedure as
specified in .
This document defines the following new RTM sub-TLV types:
ValueDescriptionReference0ReservedThis document1PTPThis document2-191Unassigned192-254Reserved for Private UseThis document255ReservedThis document
IANA has assigned a new type for the RTM Capability sub-TLV in the
"OSPFv2 Extended Link TLV
Sub-TLVs" registry as follows:
ValueDescriptionReference5RTM CapabilityThis document
IANA has assigned a new type for the RTM Capability sub-TLV
from the "Sub-TLVs for TLVs 22, 23, 141, 222, and 223" registry as follows:
TypeDescription2223141222223Reference40RTM CapabilityyynyyThis document
IANA has assigned a new codepoint for the RTM Capability TLV from the
"BGP-LS Node Descriptor,
Link Descriptor, Prefix Descriptor, and Attribute TLVs" sub-registry in
the "Border Gateway
Protocol - Link State (BGP-LS) Parameters" registry as follows:
TLV Code PointDescriptionIS-IS TLV/Sub-TLVReference1105RTM Capability22/40This document
IANA has assigned a new type for the RTM_SET sub-object from the RSVP-TE
"Attributes TLV Space" sub-registry as follows:
Type NameAllowed on LSP_ATTRIBUTES Allowed on LSP_REQUIRED_ATTRIBUTES Allowed on LSP Hop Attributes Reference 5 RTM_SET sub-objectYesNoNoThis document
IANA has created a new sub-registry for sub-TLV types of the RTM_SET
sub-object called the "RTM_SET Object Sub-Object Types" registry.
All codepoints in the range 0 through 127 in this registry shall be
allocated
according to the "IETF Review" procedure as specified in . Codepoints in the range
128 through 191 in this registry shall be allocated according to the
"First Come First Served" procedure as
specified in .
This document defines the following new values of RTM_SET object
sub&nbhy;object types:
ValueDescriptionReference0ReservedThis document1IPv4 addressThis document2IPv6 addressThis document3Unnumbered interfaceThis document4-191Unassigned192-254Reserved for Private UseThis document255ReservedThis document
IANA has assigned a new flag in the RSVP-TE "Attribute Flags" registry.
Bit NoNameAttribute Flags PathAttribute Flags ResvRROEROReference15RTM_SETYesYesNoNoThis document
IANA has assigned the following new error codes in the RSVP "Error Codes and
Globally-Defined Error Value Sub-Codes" registry.
Error CodeMeaningReference41Duplicate TLVThis document42Duplicate sub-TLVThis document43RTM_SET TLV AbsentThis document
Routers that support RTM are subject to the same security considerations as defined in
and .
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.
In practice, this means that those portions of messages cannot be covered by either confidentiality or
integrity protection. Though there are methods that make it possible in theory to provide either or both
such protections and still allow for intermediate nodes to make detectable but authenticated modifications,
such methods do not seem practical at present, particularly for timing protocols that are sensitive to latency
and/or jitter.
The ability to potentially authenticate and/or encrypt RTM and PTP data for scenarios both with and without
participation of intermediate RTM-/PTP-capable nodes is left for further study.
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 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 nodes.
Security requirements of time protocols are provided in RFC 7384 .
IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control SystemsIEEEOSPFv3 LSA ExtendibilityTransporting Timing messages over MPLS NetworksTime and phase synchronization aspects of packet networksITU-T
The authors want to thank Loa Andersson, Lou Berger, Acee Lindem, Les
Ginsberg, and Uma Chunduri for their thorough reviews, thoughtful
comments,
and, most of all, patience.