One document matched: draft-mirsky-mpls-residence-time-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5905 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5905.xml">
<!ENTITY RFC6374 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6374.xml">
<!ENTITY RFC5586 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5586.xml">
<!ENTITY RFC6423 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6423.xml">
<!ENTITY RFC5085 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5085.xml">
<!ENTITY RFC3209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml">
<!ENTITY RFC4385 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4385.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC6823 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6823.xml">
<!ENTITY RFC3477 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3477.xml">
<!ENTITY RFC4202 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4202.xml">
<!ENTITY RFC7384 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7384.xml">
<!ENTITY I-D.ietf-ospf-prefix-link-attr SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ospf-prefix-link-attr-04.xml">
<!ENTITY I-D.ietf-ospf-ospfv3-lsa-extend SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ospf-ospfv3-lsa-extend-06.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" ipr="trust200902" docName="draft-mirsky-mpls-residence-time-06">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<front>
<title abbrev='Residence Time Measurement'>Residence Time Measurement in MPLS network</title>
<author initials='G.' surname="Mirsky" fullname='Greg Mirsky'>
<organization>Ericsson</organization>
<address>
<email>gregory.mirsky@ericsson.com</email>
</address>
</author>
<author initials='S.' surname="Ruffini" fullname='Stefano Ruffini'>
<organization>Ericsson</organization>
<address>
<email>stefano.ruffini@ericsson.com</email>
</address>
</author>
<author initials='E.' surname="Gray" fullname='Eric Gray'>
<organization>Ericsson</organization>
<address>
<email>eric.gray@ericsson.com</email>
</address>
</author>
<author initials='J.' surname="Drake" fullname='John Drake'>
<organization>Juniper Networks</organization>
<address>
<email>jdrake@juniper.net</email>
</address>
</author>
<author initials='S.' surname="Bryant" fullname='Stewart Bryant'>
<organization>Cisco Systems</organization>
<address>
<email>stbryant@cisco.com</email>
</address>
</author>
<author initials='A.' surname="Vainshtein" fullname='Alexander Vainshtein'>
<organization>ECI Telecom</organization>
<address>
<email>Alexander.Vainshtein@ecitele.com</email>
</address>
</author>
<date day="2" month="May" year="2015" />
<area>Routing</area>
<workgroup>MPLS Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>G-ACh</keyword>
<keyword>Resident Time</keyword>
<keyword>MPLS</keyword>
<abstract>
<t>
This document specifies G-ACh based Residence Time Measurement and how it can be used
by time synchronization protocols being transported over MPLS domain.
</t>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
Time synchronization protocols, Network Time Protocol version 4 (NTPv4) <xref target="RFC5905"/> and
Precision Time Protocol (PTP) Version 2 <xref target="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, 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.
</t>
<section title="Conventions used in this document">
<section title="Terminology">
<t>MPLS: Multi-Protocol Label Switching</t>
<t>ACH: Associated Channel</t>
<t>TTL: Time-to-Live</t>
<t>G-ACh: Generic Associated Channel</t>
<t>GAL: Generic Associated Channel Label</t>
<t>NTP: Network Time Protocol</t>
<t>ppm: parts per million
</t>
<t>PTP: Precision Time Protocol</t>
<t>LSP: Label Switched Path</t>
<t>LSR: Label Switching Router</t>
<t>OAM: Operations, Administration, and Maintenance</t>
<t>RRO: Record Route Object </t>
<t>RSO: RTM Set Object </t>
<t>RTM: Residence Time Measurement</t>
<t>IGP: Internal Gateway Protocol</t>
</section>
<section title="Requirements Language">
<t>
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
<xref target="RFC2119"></xref>.
</t>
</section>
</section>
</section>
<section anchor="residence-time" title="Residence Time Measurement">
<t>
Packet Loss and Delay Measurement for MPLS Networks <xref target="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 <xref target="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 <xref target="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 <xref target="one-two-step-modes"/>).
The residence time values are specific to each output PTP
port and message.
</t>
<!--
<t>
Note the delay of propagation over a link connected to a port receiving the PTP event message is handled by
IEEE 1588 <xref target="IEEE.1588.2008"/> by means of specific messages, Pdelay_Req and Pdelay_Resp,or
Delay_Req and Delay_Resp depending on the applicable delay mechanism, peer-to-peer or delay request-response
mechanism respectively.
</t>
-->
<t>
IEEE 1588 uses this residence time to correct the propagated time, effectively making these nodes transparent.
</t>
<t>
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.
</t>
</section>
<section anchor="associated-channel" title="G-ACh for Residence Time Measurement">
<t>
RFC 5586 <xref target="RFC5586"/> and RFC 6423 <xref target="RFC6423"/> extended applicability of PW Associated
Channel (ACH) <xref target="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".
</t>
<t>
The packet format for Residence Time Measurement (RTM) is presented in <xref target="residence-time-format"/>
<figure align="left" anchor="residence-time-format"
title="RTM G-ACh packet format for Residence Time Measurement">
<artwork><![CDATA[
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 |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>
<list style="symbols">
<t>First four octets are defined as G-ACh Header in <xref target="RFC5586"/></t>
<t>The Version field is set to 0, as defined in RFC 4385 <xref target="RFC4385"/>. </t>
<t>The Reserved field MUST be
set to 0 on transmit and ignored on receipt. </t>
<t>The RTM G-ACh field, value to be allocated by IANA, identifies the packet
as such. </t>
<t>The Scratch Pad field is 8 octets in length. The first RTM-capable LSR MUST initialize the Scratch
Pad field, it SHOULD set it to zero value. The Scratch Pad is used to accumulate the residence
time spent in each RTM capable LSR
transited by the packet on its path from ingress LSR to egress LSR. Its format is IEEE double precision and its
units are nanoseconds. Note: depending on one-step or two-step operation (<xref target="one-two-step-modes"/>),
the residence time might be
related to the same packet carried in the Value field or to a packet carried in a
different RTM
packet.</t>
<t>
The Type field identifies the type of Value that the TLV carries. IANA will be asked to create a
sub-registry in Generic
Associated Channel (G-ACh) Parameters Registry called "MPLS RTM TLV Registry".</t>
<t>The Length field contains the number of octets
of the Value field.</t>
<t>The optional Value field may be used to
carry a packet of a given time
synchronization protocol.
If packet data is carried in the
RTM message, then this is identified by Type accordingly. The data MAY be
NTP <xref target="RFC5905"/> or
PTP <xref target="IEEE.1588.2008"/>. It is important to note that the
packet may be authenticated or encrypted
and carried over MPLS LSP edge to edge unchanged while
residence time being accumulated in the Scratch Pad field.
Sub-TLVs MAY be included in the Value field.</t>
<t>The TLV MUST be included in the RTM message, even if the length of the Value field is zero.
</t>
</list>
</t>
<section anchor="ptp-sub-tlv" title="PTP Packet Sub-TLV">
<t>
<xref target="ptp-sub-tlv-fig"/> presents format of a PTP sub-TLV that MUST be
precede every PTP packet carried in RTM TLV.
<figure align="left" anchor="ptp-sub-tlv-fig" title="PTP Sub-TLV format">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>
where Flags field has format
<figure align="left" anchor="flags-filed-format"
title="Flags field format of PTP Packet Sub-TLV">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>
<list style="symbols">
<t>The Type field identifies PTP sub-TLV defined in the Table 19 Values of messageType field
in <xref target="IEEE.1588.2008"/>.</t>
<t>The Length field of the PTP sub-TLV contains the number of octets of the Value field and MUST be 20.</t>
<!--
<t>The Flags field has one bit, S, which acts as a step flag, set to 0 if the boundary clocks are operating in
one-step mode, and set to 1 if they are operating in two-step mode.</t>
-->
<t>
The Flags field currently defines one bit, the S-bit, that defines whether or not the current message
has been processed by a 2-step node, where the flag is cleared if the message has been handled
exclusively by 1-step nodes and there is no follow-up message, and set if there has been at least
one 2-step node and a follow-up message is forthcoming.
</t>
<t>
The PTPType indicates the type of PTP packet carried in the TLV. PTPType is the messageType
field of the PTPv2 packet whose values are defined in the Table 19 <xref target="IEEE.1588.2008"/>.
</t>
<t>The 10 octets long Port ID field contains the identity of the source port. </t>
<t>The Sequence ID is the sequence
ID of the PTP message carried in the Value field of the message. </t>
</list>
</t>
</section>
</section>
<section anchor="cp-operation-theory" title="Control Plane Theory of Operation">
<t>
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.
</t>
<t>
However, because of Equal Cost Multipath, labels distributed by LDP do not necessarily
instantiate a single path between a given ingress/egress
LSR pair but rather MAY create a graph in which different flows will take different
paths through this network. This means one doesn't necessarily know
the path that RTM packets will take or even if they all take the same path.
In an environment in which not all interfaces in
an IGP domain support RTM, it is effectively impossible to use TTL
expiry to deliver RTM packets. Hence RTM cannot be
used for LSPs instantiated using LDP, if multi-pathing is in use and not all LSRs are RTM-capable.
In the special but important case of environment in which all interfaces in an IGP
domain support RTM, setting the TTL to
1 will always cause the expiry of an RTM packet on the next RTM capable
downstream LSR and hence in such an environment,
RTM can be used for LSPs instantiated using LDP.
</t>
<t>Also, if it is possible and desirable, multi-path forwarding may be
disabled,at least for LSPs used for RTM.
</t>
<t>
Generally speaking, RTM is more useful for an LSP instantiated using RSVP-TE <xref target="RFC3209"/> because the LSP's path
can be determined.
</t>
<section anchor="rtm-capability" title="RTM Capability">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
The RTM capability used in the sub-TLV shown in <xref target="rtm-capab-sub-tlv"/> 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.
</t>
<t>
<!--
When an IGP is used to carry the above defined RTM capability sub-TLV, the implementation
MUST associate the advertisement with the interface that has the ability used to determine its
supported RTM capabilities, and MUST NOT propagate this sub-TLV via any interface that does
not have the associated ingress ability described in this section.
-->
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 an interface that does not support the same
capability for RTM messages it receives.
</t>
</section>
<section anchor="rtm-capability-sub-tlv" title="RTM Capability Sub-TLV">
<t>
The format for the RTM Capabilities sub-TLV is presented in <xref target="rtm-capab-sub-tlv"/>
<figure align="left" anchor="rtm-capab-sub-tlv"
title="RTM Capability sub-TLV">
<artwork><![CDATA[
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(TBA5) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTM | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>
<list style="symbols">
<t>Type value will be assigned by IANA from appropriate registries.</t>
<t>Length MUST be set to 4.</t>
<t>RTM (capability) - is a three-bit long bit-map field with values defined as follows:
<list style="symbols">
<t>0b001 - one-step RTM supported;</t>
<t>0b010 - two-step RTM supported;</t>
<t>0b100 - reserved.</t>
</list>
</t>
<t>Reserved field must be set to all zeroes on transmit and ignored on receipt.</t>
</list>
</t>
<t>
<xref target="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.
</t>
<t>
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 <xref target="one-two-step-modes"/>.
</t>
</section>
<section anchor="rtm-capability-ospfv2" title="RTM Capability Advertisement in OSPFv2">
<t>
The capability to support RTM on a particular link advertised in the OSPFv2 Extended Link Opaque LSA <xref target="I-D.ietf-ospf-prefix-link-attr"/> as
RTM Capability sub-TLV, presented in <xref target="rtm-capab-sub-tlv"/>, of the OSPFv2 Extended Link TLV.
</t>
<t>
Type value will be assigned by IANA from the OSPF Extended Link TLV Sub-TLVs registry that will be created per
<xref target="I-D.ietf-ospf-prefix-link-attr"/> request.
</t>
</section>
<section anchor="rtm-capability-ospfv3" title="RTM Capability Advertisement in OSPFv3">
<t>
The capability to support RTM on a particular link in OSPFv3 can be advertised by including
an RTM Capability sub-TLV defined in <xref target="rtm-capability-ospfv2"/> in
the following TLVs defined in <xref target="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.
</t>
</section>
<section anchor="isis-rtm-ext" title="RTM Capability Advertisement in IS-IS">
<t>
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" <xref target="RFC6823"/>. Hence the capability to process
RTM messages can be advertised by including RTM Capability sub-TLV in GENINFO TLV <xref target="RFC6823"/>.
</t>
<t>
With respect to the Flags field of the GENINFO TLV:
<list style="symbols">
<t>The S bit MUST be cleared to prevent the RTM Capability sub-TLV from leaking between levels.</t>
<t>The D bit of the Flags field MUST be cleared as required by <xref target="RFC6823"/>.</t>
<t> The I bit and the V bit MUST be set accordingly depending on whether RTM capability being
advertised for IPv4 or IPv6 interface of the node.</t>
</list>
</t>
<t>
Application
ID (TBA6) will be assigned from the Application Identifiers for TLV 251
IANA registry. The RTM Capability
sub-TLV, presented in <xref target="rtm-capab-sub-tlv"/>,
MUST be included in GENINFO TLV in Application
Specific Information.
</t>
</section>
<section anchor="rsvp-operation-RTM" title="RSVP-TE Control Plane Operation to Support RTM">
<t>
Though RTM capability is per interface throughout this document we will refer to an LSR as RTM capable LSR when:
</t>
<t>
<list style="symbols">
<t>ingress LSR's LSP interface is RTM capable;</t>
<t>transit LSR's ingress and egress interfaces for the given LSP are RTM capable;</t>
<t>egress LSR's egress interface is RTM capable.</t>
</list>
</t>
<t>
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) <xref target="RFC3209"/>
and RTM Set Object (RSO) [<xref target="rtm-set-object"/>], which tell the egress LSR that RTM is
requested for this LSP.
</t>
<t>
In the Resv message that the egress LSR sends in response to the received Path message, it includes initialized
RRO and RSO. The RSO 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 RSO 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 RTM
Set Object before forwarding the Resv upstream.
</t>
<t>
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.
</t>
<t>
It should be noted that RTM can also be used for LSPs instantiated using <xref target="RFC3209"/>
in an environment in which all interfaces in an IGP support RTM. In this case the RSO
MAY be omitted.
</t>
</section>
<section anchor="rtm-set-object" title="RTM_SET Object">
<t>
RTM capable interfaces can be recorded via RTM_SET object (RSO). The RTM Set Class is TBA7.
This document defines one C_Type, Type TBA8 RTM Set. The RTM_SET object format presented in <xref target="rso-figure"/>
<figure align="left" anchor="rso-figure"
title="RTM Set object format">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Sub-objects ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>
The contents of a RTM_SET object are a series of
variable-length data items called sub-objects. The sub-objects
are defined in <xref target="rso-sub-objects"/> below.
</t>
<t>
The RSO can be present in both RSVP Path and Resv messages. If a
Path message contains multiple RSOs, only the first RSO is
meaningful. Subsequent RSOs SHOULD be ignored and SHOULD NOT be
propagated. Similarly, if in a Resv message multiple RSOs are
encountered following a FILTER_SPEC before another FILTER_SPEC is
encountered, only the first RSO is meaningful. Subsequent RSOs
SHOULD be ignored and SHOULD NOT be propagated.
</t>
<section anchor="rso-sub-objects" title="RSO Sub-objects">
<t>
The RTM Set object contains an ordered list, from egress LSR to
ingress LSR, of the RTM capable LSRs along the LSP's path.
</t>
<t>
The contents of a RTM_SET object are a series of variable-length
data items called sub-objects. Each sub-object has its own Length
field. The length contains the total length of the sub-object 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).
</t>
<t>
Sub-objects are organized as a last-in-first-out stack. The first
-out
sub-object relative to the beginning of RSO is considered the top.
The last-out sub-object is considered the bottom. When a new sub-object is
added, it is always added to the top.
</t>
<t>
Three kinds of sub-objects for RSO are currently defined.
</t>
<section anchor="ipv4-sub-object" title="IPv4 Sub-object">
<t>
<figure align="left" anchor="ipv4-sub-figure"
title="IPv4 sub-object format">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>
Type
</t>
<t><list><t>
0x01 IPv4 address
</t></list></t>
<t>
Length
</t>
<t><list><t>
The Length contains the total length of the sub-object in bytes,
including the Type and Length fields. The Length is always 8.
</t></list></t>
<t>
IPv4 address
</t>
<t><list><t>
A 32-bit unicast host address.
</t></list></t>
<t>
Flags
</t>
<t><list><t>
TBD
</t></list></t>
<t>
</t>
</section>
<section anchor="ipv6-sub-object" title="IPv6 Sub-object">
<t>
<figure align="left" anchor="ipv6-sub-figure"
title="IPv6 sub-object format">
<artwork><![CDATA[
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 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>
Type
</t>
<t><list><t>
0x02 IPv6 address
</t></list></t>
<t>
Length
</t>
<t><list><t>
The Length contains the total length of the sub-object in bytes,
including the Type and Length fields. The Length is always 20.
</t></list></t>
<t>
IPv6 address
</t>
<t><list><t>
A 128-bit unicast host address.
</t></list></t>
<t>
Flags
</t>
<t><list><t>
TBD
</t></list></t>
</section>
<section anchor="unnum-sub-object" title="Unnumbered Interface Sub-object">
<t>
<figure align="left" anchor="unnum-sub-figure"
title="IPv4 sub-object format">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>
Type
</t>
<t><list><t>
0x03 Unnumbered interface
</t></list></t>
<t>
Length
</t>
<t><list><t>
The Length contains the total length of the sub-object in bytes,
including the Type and Length fields. The Length is always 12.
</t></list></t>
<t>
Router ID
</t>
<t><list><t>
The Router ID interpreted as discussed in the Section 2 of RFC 3447 <xref target="RFC3477"/>.
</t></list></t>
<t>
Interface ID
</t>
<t><list><t>
The identifier assigned to the link by the LSR specified by the Router ID.
</t></list></t>
<t>
Flags
</t>
<t><list><t>
TBD
</t></list></t>
</section>
</section>
</section>
</section>
<section anchor="dp-operation-theory" title="Data Plane Theory of Operation">
<t>
After instantiating an LSP for a path using RSVP-TE <xref target="RFC3209"/> as described in <xref target="rsvp-operation-RTM"/>
or as described in the second paragraph of <xref target="cp-operation-theory"/> and in <xref target="rsvp-operation-RTM"/>,
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.
</t>
<t>
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.
</t>
<t>
See <xref target="one-two-step-modes"/> for further details on the difference between 1-step and 2-step operation.
</t>
<!-- <t>
The RTM capable LSR also sets the RTM packet's TTL to expire on the
next downstream RTM capable LSR. </t>
<t>-->
<t>
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.
</t>
<!--
<t>
The above description is directly applicable to the case of one-step clock modes. In case of two-step clock modes
there are some differences, see <xref target="one-two-step-modes"/>).
</t>
-->
</section>
<section anchor="PTP-scenarios" title="Applicable PTP Scenarios">
<t>
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.
</t>
<!--
<t>
Under certain assumptions the proposed solution in a network where peer delay mechanism is used is also possible.
The solution in this case requires the definition of a specific protocol to be used to calculate the link delays according to
a peer delay link measurement approach. This is not described in this version of the draft.
</t>
-->
</section>
<section anchor="one-two-step-modes" title="One-step Clock and Two-step Clock Modes">
<!--
<t>
One-step mode refers to no "follow_up" type message containing the residence time of an earlier event message.
Two-step mode indicates there is a further message containing the residence time of an earlier event message.
</t>
-->
<t>
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.
</t>
<t>
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:
<list style="numbers">
<t>
Mark the original event message to indicate that a follow-up message will be forthcoming (this is necessary in order to
<list style="latin">
<t>
Let any subsequent 2-step node know that there is already a follow-up message, and
</t>
<t>
Let the end-point know to wait for a follow-up message;
</t>
</list>
</t>
<t>
Create a follow-up message in which to put the RTM determined as an initial correctionField value.
</t>
</list>
</t>
<t>
IEEE 1588v2 <xref target="IEEE.1588.2008"/> defines this behaviour for PTP messages.
</t>
<t>
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.
</t>
<t>
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).
</t>
<t>
Thus, an RTM packet, containing residence time information relating to an earlier packet, also contains
information identifying that earlier packet.
</t>
<t>
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.
</t>
<t>
In practice an RTM operating according to two-step clock behaves like a two-steps transparent clock.
</t>
<t>
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.
</t>
<!--
<t>
In particular, with reference to PTP protocol, in case of a two-step RTM node, the PTP (event) packets are
still carried by RTM but without updating the Scratch Pad with the residence time of that packet. The related
residence time information is accumulated and carried in a subsequent RTM packet.
</t>
<t>
The use of two-step clock mode is communicated between RTM nodes via the Two-step clock flag and by
the message type (e.g. in case of sync messages, indicating the associated follow up message).
</t>
-->
<t>
Two main subcases can be identified for an RTM node operating as a two-step clock:
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor="iana-consider" title="IANA Considerations">
<section anchor="rtm-gach" title="New RTM G-ACh">
<t>
IANA is requested to reserve a new G-ACh as follows:
</t>
<texttable anchor="residence-time-table" title="New Residence Time Measurement">
<ttcol align='left'>Value</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>TBA1</c>
<c>Residence Time Measurement</c>
<c>This document</c>
</texttable>
</section>
<section anchor="rtm-tlv-registry" title="New RTM TLV Registry">
<t>
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 <xref target="RFC5226"/>
.
Remaining code points are allocated according to the table below.
This document defines the following new values RTM TLV type
s:
</t>
<texttable anchor="rtm-tlv-table" title="RTM TLV Type">
<ttcol align='left'>Value</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>0</c>
<c>Reserved</c>
<c>This document</c>
<c>1</c>
<c>No payload</c>
<c>This document</c>
<c>2</c>
<c>PTPv2</c>
<c>This document</c>
<c>3</c>
<c>NTP</c>
<c>This document</c>
<c>4-127</c>
<c>Reserved</c>
<c>IETF Consensus</c>
<c>128 - 191</c>
<c>Reserved</c>
<c>First Come First Served</c>
<c>192 - 255</c>
<c>Reserved</c>
<c>Private Use</c>
</texttable>
</section>
<section anchor="rtm-su-tlv-registry" title="New RTM Sub-TLV Registry">
<t>
IANA is requested to create sub-registry in MPLS RTM TLV Registry, requested in <xref target="rtm-tlv-registry"/>,
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 <xref target="RFC5226"/>
.
Remaining code points are allocated according to the table below.
This document defines the following new values RTM sub-TLV types:
</t>
<texttable anchor="rtm-sub-tlv-table" title="RTM Sub-TLV Type">
<ttcol align='left'>Value</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>0</c>
<c>Reserved</c>
<c>This document</c>
<c>1</c>
<c>PTP 2-step</c>
<c>This document</c>
<c>2-127</c>
<c>Reserved</c>
<c>IETF Consensus</c>
<c>128 - 191</c>
<c>Reserved</c>
<c>First Come First Served</c>
<c>192 - 255</c>
<c>Reserved</c>
<c>Private Use</c>
</texttable>
</section>
<section anchor="iana-rtm-capability-sub-tlv" title="RTM Capability sub-TLV">
<t>
IANA is requested to assign a new type for RTM Capability sub-TLV from future OSPF Extended Link TLV
Sub-TLVs registry as follows:
</t>
<texttable anchor="iana-rtm-cap-sub-tlv" title="RTM Capability sub-TLV">
<ttcol align='left'>Value</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>TBA2</c>
<c>RTM Capability</c>
<c>This document</c>
</texttable>
</section>
<section anchor="iana-isis-rtm-application-id" title="IS-IS RTM Application ID">
<t>
IANA is requested to assign a new Application ID for RTM from the Application Identifiers for TLV 251 registry as follows:
</t>
<texttable anchor="iana-rtm-app-id" title="IS-IS RTM Application ID">
<ttcol align='left'>Value</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>TBA3</c>
<c>RTM</c>
<c>This document</c>
</texttable>
</section>
<section anchor="iana-rtm-set-class" title="RTM_SET Object RSVP Class Number, Class Type and Sub-object Types">
<t>
IANA is requested to assign a new Class Number for RTM_SET object as follows:
</t>
<texttable anchor="iana-rtm-set-class-tl" title="RTM_SET object Class">
<ttcol align='left'>Value</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>TBA4</c>
<c>RTM_SET object</c>
<c>This document</c>
</texttable>
<t>
IANA is requested to assign a new Class Type for RTM_SET object as follows:
</t>
<texttable anchor="iana-rtm-set-class-type-tbl" title="RTM_SET object Class Type">
<ttcol align='left'>Value</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>TBA5</c>
<c>RTM Set</c>
<c>This document</c>
</texttable>
<t>
IANA requested to create new sub-registry for sub-object types of RTM_SET object as follows:
</t>
<texttable anchor="iana-rtm-set-sub-type-tbl" title="RTM_SET object sub-object types">
<ttcol align='left'>Value</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>0</c>
<c>Reserved</c>
<c></c>
<c>1</c>
<c>IPv4 address</c>
<c>This document</c>
<c>2</c>
<c>IPv6 address</c>
<c>This document</c>
<c>3</c>
<c>Unnumbered interface</c>
<c>This document</c>
<c>4-127</c>
<c>Reserved</c>
<c>IETF Consensus</c>
<c>128 - 191</c>
<c>Reserved</c>
<c>First Come First Served</c>
<c>192 - 255</c>
<c>Reserved</c>
<c>Private Use</c>
</texttable>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>
Routers that support Residence Time Measurement are subject to the same security considerations as defined in
<xref target="RFC5586"/> <!-- and <xref target="RFC6423"/> -->.
</t>
<t>
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.
</t>
<t>
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).
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
Security requirements of time protocols are provided in RFC 7384 <xref target="RFC7384"/>.
</t>
</section>
<section title="Acknowledgements">
<t>
Authors want to thank Loa Andersson for his thorough review and thoghtful comments.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC5905;
&RFC5586;
&RFC5085;
&RFC4385;
&RFC6423;
&RFC3209;
&RFC6823;
&RFC3477;
&I-D.ietf-ospf-prefix-link-attr;
&I-D.ietf-ospf-ospfv3-lsa-extend;
<reference anchor="IEEE.1588.2008">
<front>
<title>Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems</title>
<author>
<organization/>
</author>
<date month="March" year="2008"/>
</front>
<seriesInfo name="IEEE" value="Standard 1588"/>
</reference>
</references>
<references title="Informative References">
&RFC6374;
&RFC5226;
&RFC4202;
&RFC7384;
<!--?rfc.include='reference.IANA'?-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:30:28 |