RFC 8169
Residence Time Measurement in MPLS Networks
RFC 8169: Residence Time Measurement in MPLS Networks 💖 (Part 1 of 6)
okay bestie, this one is a Standards Track document from the IETF, which means it's the official rulebook for how this stuff should work 🔥
Quick header tea ☕ The author crew is G. Mirsky (ZTE Corp.), S. Ruffini and E. Gray (Ericsson), J. Drake (Juniper Networks), S. Bryant (Huawei), and A. Vainshtein (ECI Telecom). It's dated May 2017, the ISSN is 2070-1721, and there's no Obsoletes or Updates line, so it isn't replacing or amending anything else 💅
Abstract ✨
So this doc defines a brand new Generic Associated Channel (G-ACh) for Residence Time Measurement (RTM) and explains how time sync protocols can use it inside an MPLS domain 🧚
Residence time is the variable part of the propagation delay that timing and sync messages experience. Knowing it for every single message means you can work out the delay more accurately when you apply the value in a Precision Time Protocol event message 💜
Status of This Memo 📜
This is an Internet Standards Track document 🎀
This doc is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check out Section 2 of RFC 7841 🌸
For the current status, any errata, and how to give feedback, head to http://www.rfc-editor.org/info/rfc8169 🔗
Copyright Notice ⚖️
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date of publication. Read these carefully, because they spell out your rights and restrictions for this doc. Any Code Components pulled from this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🙈
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 4
1.1.2. Requirements Language . . . . . . . . . . . . . . . . 5
2. Residence Time Measurement . . . . . . . . . . . . . . . . . 5
2.1. One-Step Clock and Two-Step Clock Modes . . . . . . . . . 6
2.1.1. RTM with Two-Step Upstream PTP Clock . . . . . . . . 7
2.1.2. Two-Step RTM with One-Step Upstream PTP Clock . . . . 8
3. G-ACh for Residence Time Measurement . . . . . . . . . . . . 8
3.1. PTP Packet Sub-TLV . . . . . . . . . . . . . . . . . . . 10
3.2. PTP Associated Value Field . . . . . . . . . . . . . . . 11
4. Control-Plane Theory of Operation . . . . . . . . . . . . . . 11
4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 11
4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 12
4.3. RTM Capability Advertisement in Routing Protocols . . . . 13
4.3.1. RTM Capability Advertisement in OSPFv2 . . . . . . . 13
4.3.2. RTM Capability Advertisement in OSPFv3 . . . . . . . 14
4.3.3. RTM Capability Advertisement in IS-IS . . . . . . . . 14
4.3.4. RTM Capability Advertisement in BGP-LS . . . . . . . 14
4.4. RSVP-TE Control-Plane Operation to Support RTM . . . . . 15
4.4.1. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . 16
5. Data-Plane Theory of Operation . . . . . . . . . . . . . . . 20
6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 22
7.2. New MPLS RTM TLV Registry . . . . . . . . . . . . . . . . 22
7.3. New MPLS RTM Sub-TLV Registry . . . . . . . . . . . . . . 23
7.4. RTM Capability Sub-TLV in OSPFv2 . . . . . . . . . . . . 23
7.5. RTM Capability Sub-TLV in IS-IS . . . . . . . . . . . . . 24
7.6. RTM Capability TLV in BGP-LS . . . . . . . . . . . . . . 24
7.7. RTM_SET Sub-object RSVP Type and Sub-TLVs . . . . . . . . 25
7.8. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 26
7.9. New Error Codes . . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Normative References . . . . . . . . . . . . . . . . . . 27
9.2. Informative References . . . . . . . . . . . . . . . . . 28
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 301. Introduction ✨
Time sync protocols like the Network Time Protocol version 4 (NTPv4) [RFC5905] and the Precision Time Protocol version 2 (PTPv2) [IEEE.1588] define timing messages that sync clocks across a network domain. The cumulative time one of these timing messages spends passing through the nodes from ingress node to egress node is called "residence time", and it's used to make clock sync more accurate ⏱️ Residence time is the sum, for each node along the path from an ingress node to an egress node, of the difference between when the message was received at an ingress interface and when it was transmitted from an egress interface. This doc defines a new Generic Associated Channel (G-ACh) value and an associated Residence Time Measurement (RTM) message, which can be used in a Multiprotocol Label Switching (MPLS) network to measure residence time over a Label Switched Path (LSP) 🦋
This doc describes RTM over an LSP signaled using RSVP-TE [RFC3209]. With RSVP-TE, the LSP's path can be either explicitly specified or determined during signaling 🛤️ It's possible to use RTM over an LSP set up with the Label Distribution Protocol [RFC5036], but that's outside the scope of this doc 🙈
Comparing this with other proposed solutions, like [TIMING-OVER-MPLS], is also outside the scope of this doc 💅
1.1. Conventions Used in This Document 📚
1.1.1. Terminology 🔤
MPLS: Multiprotocol Label Switching
ACH: Associated Channel Header
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
BC: boundary clock
LSP: Label Switched Path
OAM: Operations, Administration, and Maintenance
RRO: Record Route Object
RTM: Residence Time Measurement
IGP: Internal Gateway Protocol
BGP-LS: Border Gateway Protocol - Link State1.1.2. Requirements Language 🫶
So here's the deal with 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
2. Residence Time Measurement 🍓
Okay so "Packet Loss and Delay Measurement for MPLS Networks" [RFC6374] can measure one-way or two-way end-to-end propagation delay over an LSP or a pseudowire (PW). But those measurements aren't enough for some apps, like time sync across a network as defined in PTP 😭 In PTPv2 [IEEE.1588], residence time gets accumulated in the correctionField of the PTP event message, which is defined in [IEEE.1588] and called using a one-step clock. It can also go in the associated follow-up message (or the Delay_Resp message tied to the Delay_Req message), which is called using a two-step clock. See the detailed discussion in Section 2.1 💖
IEEE 1588 uses this residence time to correct for the transit times of nodes on an LSP, which basically makes the transit nodes transparent 🪄
This doc proposes a mechanism that can work as one type of on-path support for a clock sync protocol, or it can be used to do a one-way measurement of residence time 🦋 The mechanism adds up residence time from all nodes along a particular LSP's path that support this extension, storing it in the Scratch Pad field of an RTM message (Figure 1). The egress node can then use this value to update, for example, the correctionField of the PTP event packet carried inside the RTM message before it does its PTP processing 👑
2.1. One-Step Clock and Two-Step Clock Modes 🦋
okay so one-step mode is when an egress interface updates the correctionField right on the original event message, no cap ✨. Two-step mode is when that same update gets dropped into a follow-up message that shows up afterwards 💅.
Here's the tea 🫖: the downstream endpoint has to wait for the follow-up to arrive so it can combine the correctionField values from the original (event) message and the follow-up. Same energy for every two-step node: it has to wait for the related follow-up (if there is one) so it can update that follow-up instead of making a brand new one 🫶. So the first node that uses two-step mode MUST do two things:
- Mark the original event message so it's clear a follow-up is coming. This is needed so that:
- any later two-step node knows there's already a follow-up message 👀
- the endpoint knows to wait for a follow-up message 🧚
- Create a follow-up message and put the RTM it measured in there as the initial
correctionFieldvalue. 💖
[IEEE.1588] is where IEEE 1588v2 defines this behaviour for PTP messages 🌸.
So, for example, with the PTP protocol, the PTPType field tells you whether the message is a Sync message, a Follow_up message, a Delay_Req message, or a Delay_Resp message 📋. The 10-octet-long Port ID field holds the identity of the source port [IEEE.1588], which is the specific PTP port of the boundary clock (BC) hooked up to the MPLS network 🔌. The Sequence ID is the sequence ID of the PTP message riding in the Value field of the message 🔢.
PTP messages also have a bit that says whether a follow-up message is coming ✨. A two-step mode PTP device MAY set this bit. Once it's set, it MUST NOT be unset until an endpoint (like a BC) has combined the original and follow-up messages. 🔒
For PTP compatibility, RTM (when it's carrying PTP packets) must act in a similar way 🤝. Heads up 📝: handling Sync event messages is different from handling Delay_Req/Delay_Resp event messages when they cross a two-step RTM node. Here's how a two-step RTM node handles a PTP Sync event message. The Delay_Resp/Delay_Req details live in Section 2.1.1 💁♀️.
The quick version: a two-step RTM-capable egress interface needs to check the S bit in the Flags field of the PTP sub-TLV (for RTM messages that say they're carrying PTP) 👀. If it's clear (set to zero), the interface MUST set the S bit and create a follow-up PTP Type RTM message 🙌. If the S bit is already set, the RTM-capable node MUST wait for the RTM message whose PTP type is follow-up and whose originator and sequence number match, so it can make the matching residence time update to the Scratch Pad field. The wait period MUST be reasonably bounded. ⏳
So an RTM packet that carries residence time info about an earlier packet also carries info that identifies that earlier packet 🧠.
In practice, a two-step RTM node acts like a two-step transparent clock 🎀.
A one-step-capable RTM node MAY pick either one-step mode (updating the Scratch Pad field of the RTM message holding the PTP event message) or two-step mode (updating the Scratch Pad of a follow-up message when a follow-up is indicated), but it MUST NOT do both 🙅♀️.
There are two main subcases for an RTM node running as a two-step clock, and we'll go through them in the sub-sections below 🌈.
2.1.1. RTM with Two-Step Upstream PTP Clock
So, if any earlier RTM-capable node or the earlier PTP clock (e.g., the BC hooked up to the first node) is a two-step clock, AND the local RTM-capable node is also running two-step mode, the residence time gets added to the RTM packet that was created to carry the second PTP packet (i.e., the downstream follow-up message) 🎯. That RTM packet carries the related accumulated residence time, the right Sequence ID and Port ID (the same identifiers as the original packet), and the two-step flag set to 1 💜.
Quick note 📝: just because an upstream RTM node made a follow-up message in two-step mode doesn't mean every later RTM node has to be two-step too 🙌. That's true as long as the later node forwards the follow-up on the same LSP it forwards the matching previous message on.
A one-step-capable RTM node MAY choose to update the RTM follow-up message as if it were in two-step mode; however, it MUST NOT update both messages 💅.
A PTP Sync packet rides inside the RTM packet to tell the RTM node that RTM has to be done on that exact packet 🎯.
To handle residence time for a Delay_Req going upstream, an RTM packet must be created to carry that residence time in the matching downstream Delay_Resp message ✨.
The last RTM node in the MPLS network has a double job 👑. Besides updating the correctionField of the associated PTP packet, it must also react properly to the two-step flag on the PTP packets.
2.1.2. Two-Step RTM with One-Step Upstream PTP Clock
When the PTP network hooked up to the MPLS runs in one-step clock mode, but an RTM node runs in two-step mode, the follow-up RTM packet must be made by the RTM node itself 🙋♀️. The RTM packet carrying the PTP event packet now needs to say a follow-up message is coming.
The egress RTM-capable node of the LSP strips off the RTM encapsulation. If two-step clock mode is indicated, it generates PTP messages with the follow-up correction as appropriate (according to [IEEE.1588]) 💫. In this case, the common header of the PTP packet carrying the synchronization message would have to be tweaked by setting the twoStepFlag field, to show there's now a follow-up message attached to the current message 🦋.
3. G-ACh for Residence Time Measurement 🌸
[RFC5586] and [RFC6423] define the G-ACh, which extends the Pseudowire Associated Channel Header (ACH) [RFC5085] to LSPs 🧚. G-ACh is the way to carry OAM and other control messages over an LSP. Which transit nodes actually process these messages is controlled by the Time-to-Live (TTL) value in the MPLS header 🕰️.
Here's the RTM message format, shown 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | RTM G-ACh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Scratch Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (optional) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RTM G-ACh Message Format for Residence Time Measurement- The first four octets are a G-ACh header, per [RFC5586] 💖.
- The
Versionfield is set to0, as defined in [RFC4385] 🏷️. - The
Reservedfield MUST be set to0on transmit and ignored on receipt 🙈. - The
RTM G-AChfield (value0x000F; see Section 7.1) is what marks the packet as RTM 🏷️. - The
Scratch Padfield is 8 octets long 🍓. It's the spot where the residence time spent in each RTM-capable node transited by the packet (on its path from ingress node to egress node) gets accumulated 📈. The first RTM-capable node MUST initialize theScratch Padfield with its RTM 🔥. Its format is a 64-bit signed integer, and it holds the residence time measured in nanoseconds, multiplied by2^16✨. Heads up 📝: depending on whether the timing procedure is one-step or two-step (Section 2.1), 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
Typefield identifies the type and encapsulation of a timing packet carried in the Value field, e.g., NTP [RFC5905] or PTP [IEEE.1588] 🧁. 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 Section 7.2) 🗂️. - The
Lengthfield contains the length, in octets, of any Value field defined for the Type given in theTypefield 📏. - The TLV MUST be included in the RTM message, even if the length of the Value field is zero 💀.
3.1. PTP Packet Sub-TLV ✨
Okay bestie, so Figure 2 shows the format of a PTP sub-TLV that MUST be included in the Value field of an RTM message sent right before the carried timing packet, whenever that timing packet is PTP 🎀
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 FormatNext up is the Flags field, which has its own little layout 🦋
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-TLVHere's the breakdown of each field, and it's honestly so clean 💅
- The Type field identifies the PTP packet sub-TLV and is set to 1 according to Section 7.3.
- 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. It tells you whether the current message has been processed by a two-step node. The flag is cleared if the message has been handled exclusively by one-step nodes and there is no follow-up message. It 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 [IEEE.1588] 🧚
- 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 ✨
Okay, the key thing 👑 A tuple of PTPType, Port ID, and Sequence ID uniquely identifies the PTP timing message included in an RTM message, and it's used in two-step RTM mode. See Section 2.1.1 for the full story 🫶
3.2. PTP Associated Value Field 🌈
So 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). This is lowkey the best part: the timing message packet may be authenticated or encrypted and carried over this LSP unchanged, and it's inaccessible to intermediate RTM capable LSRs, while the residence time is accumulated in the Scratch Pad field 🔐
The LSP ingress RTM-capable LSR fills in the identifying tuple information of the PTP sub-TLV (see section 3.1) before it puts the (possibly authenticated/encrypted) PTP message packet after the PTP sub-TLV in the Value field of the RTM message. This is for an RTM message of the PTP Type (Type 1; see Section 7.3) 🎀
4. Control-Plane Theory of Operation 🧠
Here's the big idea. RTM depends on 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 💖
4.1. RTM Capability 💅
The RTM capability of a node is about a pair of interfaces, the ones 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, so that this information is available to the egress interface of the 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. From that and the arrival time information from the corresponding ingress interface, it determines the difference, which is the residence time for the packet ⏱️
An interface that can 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 ⚡
So, while both ingress and egress interfaces are required to support RTM for the pair to be RTM capable, it's the egress interface that decides whether 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 4 and 5 is a non-routing-related capability associated with the interface being advertised, based on its egress capability. Whether any pair of interfaces on a node that includes this egress interface can support any mode of RTM depends on the ingress interface of the node being able to record packet arrival time and convey it to the egress interface on that 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. They would happen, for example, if the operator decided to include or exclude a particular port from RTM processing, or to switch between RTM modes 🌸
4.2. RTM Capability Sub-TLV 🍓
[RFC4202] 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, meaning 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. You can find a detailed discussion of one-step and two-step RTM modes in Section 2.1 ✨
4.3. RTM Capability Advertisement in Routing Protocols 📡
4.3.1. RTM Capability Advertisement in OSPFv2 🌷
The format for the RTM Capability sub-TLV in OSPF is shown in Figure 4 💖
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 | Value ...
+-+-+-+-+-+-+-+-+-+- ...
Figure 4: RTM Capability Sub-TLV in OSPFv2Here are the rules, bestie 📝
- The Type value (5) has been assigned by IANA in the "OSPFv2 Extended Link TLV Sub-TLVs" registry (see Section 7.4).
- The Length value equals the number of octets of the Value field.
- The 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 [RFC7684], via the RTM Capability sub-TLV 🦋
4.3.2. RTM Capability Advertisement in OSPFv3 🌙
The capability to support RTM on a particular link (interface) can be advertised in OSPFv3 using LSA extensions, as described in [OSPFV3-EXTENDED-LSA]. The sub-TLV SHOULD use the same format as in Section 4.3.1. The type allocation and full details of the exact use of OSPFv3 LSA extensions are for further study 🔮
4.3.3. RTM Capability Advertisement in IS-IS 🛤️
The capability to support RTM on a particular link (interface) is advertised in a new sub-TLV. That sub-TLV 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 shown in Figure 5 🎀
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| Type | Length | RTM | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Figure 5: RTM Capability Sub-TLVAnd the details 🫶
- The 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 Section 7.5).
- Definitions, rules of handling, and values for the Length and Value fields are as defined in Section 4.3.1.
- RTM (capability) is a 3-bit-long bitmap field, with values defined in Section 4.3.1.
4.3.4. RTM Capability Advertisement in BGP-LS 🌐
The format for the RTM Capability TLV is shown in Figure 4 🦄
The Type value (1105) has been assigned by IANA in the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" sub-registry (see Section 7.6) 💜
Definitions, rules of handling, and values for the fields Length, Value, and RTM are as defined in Section 4.3.1 ✨
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 [RFC7752] 🌸
4.4. RSVP-TE Control-Plane Operation to Support RTM ✨
Okay bestie, so throughout this doc we call a node an RTM-capable node whenever at least one of its interfaces is RTM capable 💖. Figure 6 shows the different roles a node can play when it comes to RTM capability 🎀:
----- ----- ----- ----- ----- ----- -----
| A |-----| B |-----| C |-----| D |-----| E |-----| F |-----| G |
----- ----- ----- ----- ----- ----- -----
Figure 6: RTM-Capable Roles- 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 one 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 Section 4.3. 🔥 In the Path message that the ingress node uses to instantiate the LSP to that egress node, it places an LSP_ATTRIBUTES object [RFC5420] with an RTM_SET Attribute Flag set, as described in Section 7.8. That tells 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 [RFC5420], unless it is known that all nodes recognize the RTM attribute (but need not necessarily implement it). Why? 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 [RFC3209] and an LSP_ATTRIBUTES object where the RTM_SET Attribute Flag is set and the RTM_SET TLV (Section 4.4.1) 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 [RFC3209] 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. Lowkey a nice shortcut 🙈.
4.4.1. RTM_SET TLV
RTM-capable interfaces can be recorded via the RTM_SET TLV 🦋. The RTM_SET sub-object format is a generic TLV format, shown in Figure 7 ✨:
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 |I| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: RTM_SET TLV FormatThe Type value (5) has been assigned by IANA in the RSVP-TE "Attributes TLV Space" sub-registry (see Section 7.7) 📋.
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-TLVs. Only a single RTM_SET can be present in a given LSP_ATTRIBUTES object. The sub-TLVs are defined in Section 4.4.1.1 🌸.
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 the 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 the 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" (Section 7.9) 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" (Section 7.9) 😭.
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-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, so yikes 😬. RTM SHOULD NOT be used if it is not guaranteed that the RRO contains complete information 🚫.
4.4.1.1. RTM_SET Sub-TLVs
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 (the 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 the RTM_SET TLV 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 🥞.
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-TLV" (Section 7.9) 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 💖.
4.4.1.1.1. IPv4 Sub-TLV
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: IPv4 Sub-TLV Format- 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. 🫧
4.4.1.1.2. IPv6 Sub-TLV
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: IPv6 Sub-TLV Format- 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. 🫧
4.4.1.1.3. Unnumbered Interface Sub-TLV ✨
Okay bestie, this is the Unnumbered Interface Sub-TLV 🦋 It's how you point at a link that doesn't have its own IP address. Here's the layout:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: IPv4 Sub-TLV FormatType is 0x03, which means Unnumbered interface 🎀
Length counts the whole sub-TLV in bytes, Type and Length fields included. It's always 12, so no surprises there 💅
Node ID is interpreted as the Router ID, just like Section 2 of [RFC3477] explains 🌸
Interface ID is the identifier given to the link by whichever node the Node ID points to 🧚
Reserved gets zeroed when it's created and gets ignored when it's received. Super chill 🫶
5. Data-Plane Theory of Operation 🚀
Okay so once you've set up an LSP for a path with RSVP-TE [RFC3209] (see Section 4.4), the ingress node MAY start sending RTM packets to the first downstream RTM-capable node on that path 💜 Each RTM packet has its Scratch Pad field set up, and its TTL is set so it expires at the next downstream RTM-capable node. Every RTM-capable node on the explicit path catches an RTM packet and notes two times: when it came in on the ingress interface, and when it goes out the egress interface. Main character energy 👑
Now, these actions should be done as close to the physical layer as possible, at the same point in packet processing 🔥 The goal is to avoid making jitter show up in the propagation delay. Instead, that time gets counted as residence time. The RTM-capable node works out the difference between those two times. With one-step operation, that difference gets figured out just before or while the packet is sent, and the egress interface adds it to the value in the Scratch Pad field of the message in progress 💖 Also, for calculating residence time, a common free-running clock that syncs all the interfaces involved might be enough. For example, 4.6 ppm accuracy leads to a 4.6 nanosecond error for a residence time around 1 millisecond. That's probably fine for apps that want accuracy in the hundreds of nanoseconds range ✨ One example is wireless stuff, which is happy with 1.5 microseconds of accuracy, per [ITU-T.G.8271] 🌈
For two-step operation, the difference between packet arrival time (at an ingress interface) and the later departure time (from an egress interface) gets worked out at some point before the follow-up message is sent. That way, the value can update the correctionField in the follow-up message 🦋
Check out Section 2.1 for more on one-step versus two-step operation 🧚
The last RTM-capable node on the LSP MAY then use the value in the Scratch Pad field to do time correction, if there's no follow-up message. For example, the egress node might be a PTP boundary clock synced to a Master Clock, and it'll use the Scratch Pad value to update PTP's correctionField 🫶
6. Applicable PTP Scenarios 🌸
This approach plugs right into a PTP network that's based on the IEEE 1588 delay request-response mechanism 💅 The RTM-capable nodes act as end-to-end transparent clocks. Boundary clocks at the edges of the MPLS network usually use the Scratch Pad value to update the correctionField of the matching PTP event packet, and they do that before the usual PTP processing happens 🎀
7. IANA Considerations 📋
7.1. New RTM G-ACh 🦋
IANA has given a new G-ACh the following value 💖
+--------+----------------------------+---------------+
| Value | Description | Reference |
+--------+----------------------------+---------------+
| 0x000F | Residence Time Measurement | This document |
+--------+----------------------------+---------------+
Table 1: New Residence Time Measurement7.2. New MPLS RTM TLV Registry 🌈
IANA made a sub-registry inside the "Generic Associated Channel (G-ACh) Parameters" registry, and it's called the "MPLS RTM TLV Registry" ✨ Every codepoint from 0 through 127 in this registry shall be allocated using the "IETF Review" procedure from [RFC5226]. Codepoints from 128 through 191 shall be allocated using the "First Come First Served" procedure from [RFC5226]. This document defines these new RTM TLV types 👑
+---------+-------------------------------+---------------+
| Value | Description | Reference |
+---------+-------------------------------+---------------+
| 0 | Reserved | This document |
| 1 | No payload | This document |
| 2 | PTPv2, Ethernet encapsulation | This document |
| 3 | PTPv2, IPv4 encapsulation | This document |
| 4 | PTPv2, IPv6 encapsulation | This document |
| 5 | NTP | This document |
| 6-191 | Unassigned | |
| 192-254 | Reserved for Private Use | This document |
| 255 | Reserved | This document |
+---------+-------------------------------+---------------+
Table 2: RTM TLV Types7.3. New MPLS RTM Sub-TLV Registry 🧚
IANA made another sub-registry, this time inside the "MPLS RTM TLV Registry" (see Section 7.2). It's called the "MPLS RTM Sub-TLV Registry" 💜 Codepoints 0 through 127 shall be allocated using the "IETF Review" procedure from [RFC5226]. Codepoints 128 through 191 shall be allocated using the "First Come First Served" procedure from [RFC5226]. These are the new RTM sub-TLV types this document defines 🫶
+---------+--------------------------+---------------+
| Value | Description | Reference |
+---------+--------------------------+---------------+
| 0 | Reserved | This document |
| 1 | PTP | This document |
| 2-191 | Unassigned | |
| 192-254 | Reserved for Private Use | This document |
| 255 | Reserved | This document |
+---------+--------------------------+---------------+
Table 3: RTM Sub-TLV Type7.4. RTM Capability Sub-TLV in OSPFv2 🎀
IANA gave a new type for the RTM Capability sub-TLV in the "OSPFv2 Extended Link TLV Sub-TLVs" registry 🌸
+-------+----------------+---------------+
| Value | Description | Reference |
+-------+----------------+---------------+
| 5 | RTM Capability | This document |
+-------+----------------+---------------+
Table 4: RTM Capability Sub-TLV7.5. RTM Capability Sub-TLV in IS-IS 💅
IANA gave a new type for the RTM Capability sub-TLV from the "Sub-TLVs for TLVs 22, 23, 141, 222, and 223" registry 🦋
+------+----------------+----+----+-----+-----+-----+---------------+
| Type | Description | 22 | 23 | 141 | 222 | 223 | Reference |
+------+----------------+----+----+-----+-----+-----+---------------+
| 40 | RTM Capability | y | y | n | y | y | This document |
+------+----------------+----+----+-----+-----+-----+---------------+
Table 5: IS-IS RTM Capability Sub-TLV Registry Description7.6. RTM Capability TLV in BGP-LS 🌈
IANA gave a new codepoint for the RTM Capability TLV from the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" sub-registry, which lives in the "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry ✨
+---------------+----------------+------------------+---------------+
| TLV Code | Description | IS-IS TLV/Sub- | Reference |
| Point | | TLV | |
+---------------+----------------+------------------+---------------+
| 1105 | RTM Capability | 22/40 | This document |
+---------------+----------------+------------------+---------------+
Table 6: RTM Capability TLV in BGP-LS7.7. RTM_SET Sub-object RSVP Type and Sub-TLVs 👑
IANA gave a new type for the RTM_SET sub-object from the RSVP-TE "Attributes TLV Space" sub-registry 🫶
+------+------------+-----------+---------------+-----------+----------+
| Type | Name | Allowed | Allowed on | Allowed | Reference|
| | | on LSP_ | LSP_REQUIRED_ | on LSP | |
| | | ATTRIBUTES| ATTRIBUTES | Hop | |
| | | | | Attributes| |
+------+------------+-----------+---------------+-----------+----------+
| 5 | RTM_SET | Yes | No | No | This |
| | sub-object | | | | document |
+------+------------+-----------+---------------+-----------+----------+
Table 7: RTM_SET Sub-object TypeIANA also made a new sub-registry for sub-TLV types of the RTM_SET sub-object, called the "RTM_SET Object Sub-Object Types" registry 💖 Codepoints 0 through 127 shall be allocated using the "IETF Review" procedure from [RFC5226]. Codepoints 128 through 191 shall be allocated using the "First Come First Served" procedure from [RFC5226]. These are the new RTM_SET object sub-object values this document defines 🌸
+---------+--------------------------+---------------+
| Value | Description | Reference |
+---------+--------------------------+---------------+
| 0 | Reserved | This document |
| 1 | IPv4 address | This document |
| 2 | IPv6 address | This document |
| 3 | Unnumbered interface | This document |
| 4-191 | Unassigned | |
| 192-254 | Reserved for Private Use | This document |
| 255 | Reserved | This document |
+---------+--------------------------+---------------+
Table 8: RTM_SET Object Sub-object Types7.8. RTM_SET Attribute Flag ✨
okay so IANA has assigned a brand new flag in the RSVP-TE "Attribute Flags" registry 💖 bestie, that's an official stamp of approval 💅
+-----+---------+-----------+-----------+-----+-----+---------------+
| Bit | Name | Attribute | Attribute | RRO | ERO | Reference |
| No | | Flags | Flags | | | |
| | | Path | Resv | | | |
+-----+---------+-----------+-----------+-----+-----+---------------+
| 15 | RTM_SET | Yes | Yes | No | No | This document |
+-----+---------+-----------+-----------+-----+-----+---------------+
Table 9: RTM_SET Attribute Flag7.9. New Error Codes 🚨
IANA also added some new error codes to the RSVP "Error Codes and Globally-Defined Error Value Sub-Codes" registry. Three new ones, all pointing back to this doc 🎀
+------------+--------------------+---------------+
| Error Code | Meaning | Reference |
+------------+--------------------+---------------+
| 41 | Duplicate TLV | This document |
| 42 | Duplicate sub-TLV | This document |
| 43 | RTM_SET TLV Absent | This document |
+------------+--------------------+---------------+
Table 10: New Error Codes8. Security Considerations 🔐
okay this section is serious, so listen up bestie 🫶
Routers that support RTM are subject to the same security considerations as defined in [RFC4385] and [RFC5085].
Now the big one 😭 Especially when RTM is used with PTP, there's a presumed trust model. It depends on a trusted relationship with at least all of the PTP-aware nodes on the path that PTP messages travel. This is necessary because those nodes are expected to correctly modify specific content in PTP messages, and the protocol only works if they can do that. So in practice, those parts of the messages can't be covered by confidentiality or integrity protection. Yes, there are methods that could in theory give you either or both protections while still letting intermediate nodes make changes that can be detected but are authenticated, but they don't seem practical right now 💀 especially 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. This is still an open question 🙈
While it's possible for a supposedly compromised node to intercept and modify the G-ACh content, this is an issue that exists for nodes in general. It applies to any and all data that may be carried over an LSP, and that's the basis for an additional presumed trust model tied to existing LSPs and nodes 🧚
Security requirements of time protocols are provided in RFC 7384 [RFC7384]. Go read that one too 📚
9. References 📖
9.1. Normative References
[IEEE.1588]
IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems",
IEEE Std 1588-2008, DOI 10.1109/IEEESTD.2008.4579760.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003,
<http://www.rfc-editor.org/info/rfc3477>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <http://www.rfc-editor.org/info/rfc4385>.
[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual
Circuit Connectivity Verification (VCCV): A Control
Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085,
December 2007, <http://www.rfc-editor.org/info/rfc5085>.
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420,
February 2009, <http://www.rfc-editor.org/info/rfc5420>.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<http://www.rfc-editor.org/info/rfc5586>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>.
[RFC6423] Li, H., Martini, L., He, J., and F. Huang, "Using the
Generic Associated Channel Label for Pseudowire in the
MPLS Transport Profile (MPLS-TP)", RFC 6423,
DOI 10.17487/RFC6423, November 2011,
<http://www.rfc-editor.org/info/rfc6423>.
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
2015, <http://www.rfc-editor.org/info/rfc7684>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<http://www.rfc-editor.org/info/rfc7752>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <http://www.rfc-editor.org/info/rfc8174>.9.2. Informative References
[ITU-T.G.8271]
ITU-T, "Time and phase synchronization aspects of packet
networks", ITU-T Recomendation G.8271/Y.1366, July 2016.
[OSPFV3-EXTENDED-LSA]
Lindem, A., Roy, A., Goethals, D., Vallem, V., and F.
Baker, "OSPFv3 LSA Extendibility", Work in Progress,
draft-ietf-ospf-ospfv3-lsa-extend-14, April 2017.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
<http://www.rfc-editor.org/info/rfc4202>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[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,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374,
DOI 10.17487/RFC6374, September 2011,
<http://www.rfc-editor.org/info/rfc6374>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <http://www.rfc-editor.org/info/rfc7384>.
[TIMING-OVER-MPLS]
Davari, S., Oren, A., Bhatia, M., Roberts, P., and L.
Montini, "Transporting Timing messages over MPLS
Networks", Work in Progress, draft-ietf-tictoc-
1588overmpls-07, October 2015.Acknowledgments 🙏
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 🫶💜
Authors' Addresses 💌
Greg Mirsky
ZTE Corp.
Email: gregimirsky@gmail.com
Stefano Ruffini
Ericsson
Email: stefano.ruffini@ericsson.com
Eric Gray
Ericsson
Email: eric.gray@ericsson.com
John Drake
Juniper Networks
Email: jdrake@juniper.net
Stewart Bryant
Huawei
Email: stewart.bryant@gmail.com
Alexander Vainshtein
ECI Telecom
Email: Alexander.Vainshtein@ecitele.com
Vainshtein.alex@gmail.com📦 where this page comes from
- ietf: rfc8169 2017-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms