idnits 2.17.00 (12 Aug 2021) /tmp/idnits16179/draft-ietf-mpls-residence-time-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1058 has weird spacing: '...Allowed on ...' -- The document date (March 7, 2017) is 1894 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.1588.2008' == Outdated reference: draft-ietf-ospf-ospfv3-lsa-extend has been published as RFC 8362 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group G. Mirsky 3 Internet-Draft ZTE Corp. 4 Intended status: Standards Track S. Ruffini 5 Expires: September 8, 2017 E. Gray 6 Ericsson 7 J. Drake 8 Juniper Networks 9 S. Bryant 10 Huawei 11 A. Vainshtein 12 ECI Telecom 13 March 7, 2017 15 Residence Time Measurement in MPLS network 16 draft-ietf-mpls-residence-time-15 18 Abstract 20 This document specifies a new Generic Associated Channel for 21 Residence Time Measurement and describes how it can be used by time 22 synchronization protocols within a MPLS domain. 24 Residence time is the variable part of the propagation delay of 25 timing and synchronization messages; knowing what this delay is for 26 each message allows for a more accurate determination of the delay to 27 be taken into account in applying the value included in a Precision 28 Time Protocol event message. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 8, 2017. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Conventions used in this document . . . . . . . . . . . . 3 66 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 67 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4 68 2. Residence Time Measurement . . . . . . . . . . . . . . . . . 4 69 2.1. One-step Clock and Two-step Clock Modes . . . . . . . . . 5 70 2.1.1. RTM with Two-step Upstream PTP Clock . . . . . . . . 6 71 2.1.2. Two-step RTM with One-step Upstream PTP Clock . . . . 7 72 3. G-ACh for Residence Time Measurement . . . . . . . . . . . . 7 73 3.1. PTP Packet Sub-TLV . . . . . . . . . . . . . . . . . . . 9 74 4. Control Plane Theory of Operation . . . . . . . . . . . . . . 10 75 4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 10 76 4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 11 77 4.3. RTM Capability Advertisement in Routing Protocols . . . . 11 78 4.3.1. RTM Capability Advertisement in OSPFv2 . . . . . . . 11 79 4.3.2. RTM Capability Advertisement in OSPFv3 . . . . . . . 13 80 4.3.3. RTM Capability Advertisement in IS-IS . . . . . . . . 13 81 4.3.4. RTM Capability Advertisement in BGP-LS . . . . . . . 13 82 4.4. RSVP-TE Control Plane Operation to Support RTM . . . . . 14 83 4.4.1. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . 15 84 5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 20 85 6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 20 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 87 7.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 21 88 7.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 21 89 7.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 22 90 7.4. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 22 91 7.5. IS-IS RTM Capability sub-TLV . . . . . . . . . . . . . . 22 92 7.6. RTM Capability TLV in BGP-LS . . . . . . . . . . . . . . 23 93 7.7. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 23 94 7.8. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 24 95 7.9. New Error Codes . . . . . . . . . . . . . . . . . . . . . 24 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 97 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 99 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 100 10.2. Informative References . . . . . . . . . . . . . . . . . 27 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 103 1. Introduction 105 Time synchronization protocols, e.g., Network Time Protocol version 4 106 (NTPv4) [RFC5905] and Precision Time Protocol (PTP) Version 2 107 [IEEE.1588.2008], define timing messages that can be used to 108 synchronize clocks across a network domain. Measurement of the 109 cumulative time that one of these timing messages spends transiting 110 the nodes on the path from ingress node to egress node is termed 111 Residence Time and it is used to improve the accuracy of clock 112 synchronization. Residence Time is the sum of the difference between 113 the time of receipt at an ingress interface and the time of 114 transmission from an egress interface for each node along the network 115 path from an ingress node to an egress node. This document defines a 116 new Generic Associated Channel (G-ACh) value and an associated 117 residence time measurement (RTM) message that can be used in a Multi- 118 Protocol Label Switching (MPLS) network to measure residence time 119 over a Label Switched Path (LSP). 121 This document describes RTM over an LSP signaled using RSVP-TE 122 [RFC3209]. Using RSVP-TE, the LSP's path can be either explicitly 123 specified or determined during signaling. Although it is possible to 124 use RTM over an LSP instantiated using Label Distribution Protocol 125 [RFC5036], that is outside the scope of this document. 127 Comparison with alternative proposed solutions such as 128 [I-D.ietf-tictoc-1588overmpls] is outside the scope of this document. 130 1.1. Conventions used in this document 132 1.1.1. Terminology 134 MPLS: Multi-Protocol Label Switching 136 ACH: Associated Channel 138 TTL: Time-to-Live 140 G-ACh: Generic Associated Channel 142 GAL: Generic Associated Channel Label 143 NTP: Network Time Protocol 145 ppm: parts per million 147 PTP: Precision Time Protocol 149 BC: Boundary Clock 151 LSP: Label Switched Path 153 OAM: Operations, Administration, and Maintenance 155 RRO: Record Route Object 157 RTM: Residence Time Measurement 159 IGP: Internal Gateway Protocol 161 BGP-LS: Border Gateway Protocol - Link State 163 1.1.2. Requirements Language 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL" in this document are to be interpreted as described in 168 [RFC2119]. 170 2. Residence Time Measurement 172 Packet Loss and Delay Measurement for MPLS Networks [RFC6374] can be 173 used to measure one-way or two-way end-to-end propagation delay over 174 LSP or PW. But these measurements are insufficient for use in some 175 applications, for example, time synchronization across a network as 176 defined in the PTP. In PTPv2 [IEEE.1588.2008], the residence time is 177 accumulated in the correctionField of the PTP event message, as 178 defined in [IEEE.1588.2008] and referred to as using a one-step 179 clock, or in the associated follow-up message (or Delay_Resp message 180 associated with the Delay_Req message), referred to as using a two- 181 step clock (see the detailed discussion in Section 2.1). 183 IEEE 1588 uses this residence time to correct for the transit times 184 of nodes on an LSP, effectively making the transit nodes transparent. 186 This document proposes a mechanism that can be used as one type of 187 on-path support for a clock synchronization protocol or to perform 188 one-way measurement of residence time. The proposed mechanism 189 accumulates residence time from all nodes that support this extension 190 along the path of a particular LSP in the Scratch Pad field of an RTM 191 message (Figure 1). This value can then be used by the egress node 192 to update, for example, the correctionField of the PTP event packet 193 carried within the RTM message prior to performing its PTP 194 processing. 196 2.1. One-step Clock and Two-step Clock Modes 198 One-step mode refers to the mode of operation where an egress 199 interface updates the correctionField value of an original event 200 message. Two-step mode refers to the mode of operation where this 201 update is made in a subsequent follow-up message. 203 Processing of the follow-up message, if present, requires the 204 downstream end-point to wait for the arrival of the follow-up message 205 in order to combine correctionField values from both the original 206 (event) message and the subsequent (follow-up) message. In a similar 207 fashion, each two-step node needs to wait for the related follow-up 208 message, if there is one, in order to update that follow-up message 209 (as opposed to creating a new one). Hence the first node that uses 210 two-step mode MUST do two things: 212 1. Mark the original event message to indicate that a follow-up 213 message will be forthcoming. This is necessary in order to 215 Let any subsequent two-step node know that there is already a 216 follow-up message, and 218 Let the end-point know to wait for a follow-up message; 220 2. Create a follow-up message in which to put the RTM determined as 221 an initial correctionField value. 223 IEEE 1588v2 [IEEE.1588.2008] defines this behavior for PTP messages. 225 Thus, for example, with reference to the PTP protocol, the PTPType 226 field identifies whether the message is a Sync message, Follow_up 227 message, Delay_Req message, or Delay_Resp message. The 10 octet long 228 Port ID field contains the identity of the source port 229 [IEEE.1588.2008], that is, the specific PTP port of the boundary 230 clock connected to the MPLS network. The Sequence ID is the sequence 231 ID of the PTP message carried in the Value field of the message. 233 PTP messages also include a bit that indicates whether or not a 234 follow-up message will be coming. This bit MAY be set by a two-step 235 mode PTP device. The value MUST NOT be unset until the original and 236 follow-up messages are combined by an end-point (such as a Boundary 237 Clock). 239 For compatibility with PTP, RTM (when used for PTP packets) must 240 behave in a similar fashion. It should be noted that the handling of 241 Sync event messages and of Delay_Req/Delay_Resp event messages that 242 cross a two-step RTM node is different. The following outlines the 243 handling of PTP Sync event message by the two-step RTM node. The 244 details of handling Delay_Resp/Delay_Req PTP event messages by the 245 two-step RTM node are discussed in Section 2.1.1. As a summary, a 246 two-step RTM capable egress interface will need to examine the S-bit 247 in the Flags field of the PTP sub-TLV (for RTM messages that indicate 248 they are for PTP) and - if it is clear (set to zero), it MUST set the 249 S bit and create a follow-up PTP Type RTM message. If the S bit is 250 already set, then the RTM capable node MUST wait for the RTM message 251 with the PTP type of follow-up and matching originator and sequence 252 number to make the corresponding residence time update to the Scratch 253 Pad field. The wait period MUST be reasonably bounded. 255 Thus, an RTM packet, containing residence time information relating 256 to an earlier packet, also contains information identifying that 257 earlier packet. 259 In practice, an RTM node operating in two-step mode behaves like a 260 two-steps transparent clock. 262 A one-step capable RTM node MAY elect to operate in either one-step 263 mode (by making an update to the Scratch Pad field of the RTM message 264 containing the PTP event message), or in two-step mode (by making an 265 update to the Scratch Pad of a follow-up message when presence of a 266 follow-up is indicated), but MUST NOT do both. 268 Two main subcases identified for an RTM node operating as a two-step 269 clock are described in the following sub-sections. 271 2.1.1. RTM with Two-step Upstream PTP Clock 273 If any of the previous RTM capable nodes or the previous PTP clock 274 (e.g., the Boundary Clock (BC) connected to the first node), is a 275 two-step clock, the residence time is added to the RTM packet that 276 has been created to include the second PTP packet (i.e., follow-up 277 message in the downstream direction), if the local RTM-capable node 278 is also operating as a two-step clock. This RTM packet carries the 279 related accumulated residence time and the appropriate values of the 280 Sequence ID and Port ID (the same identifiers carried in the original 281 packet) and the Two-step Flag set to 1. 283 Note that the fact that an upstream RTM-capable node operating in the 284 two-step mode has created a follow-up message does not require any 285 subsequent RTM capable node to also operate in the two-step mode, as 286 long as that RTM-capable node forwards the follow-up message on the 287 same LSP on which it forwards the corresponding previous message. 289 A one-step capable RTM node MAY elect to update the RTM follow-up 290 message as if it were operating in two-step mode, however, it MUST 291 NOT update both messages. 293 A PTP Sync packet is carried in the RTM packet in order to indicate 294 to the RTM node that residence time measurement must be performed on 295 that specific packet. 297 To handle the residence time of the Delay_Req message on the upstream 298 direction, an RTM packet must be created to carry the residence time 299 on the associated downstream Delay_Resp message. 301 The last RTM node of the MPLS network, in addition to updating the 302 correctionField of the associated PTP packet, must also react 303 properly to the two-step flag of the PTP packets. 305 2.1.2. Two-step RTM with One-step Upstream PTP Clock 307 When the PTP network connected to the MPLS operates in one-step clock 308 mode and an RTM node operates in two-step mode, the follow-up RTM 309 packet must be created by the RTM node itself. The RTM packet 310 carrying the PTP event packet needs now to indicate that a follow-up 311 message will be coming. 313 The egress RTM-capable node of the LSP will be removing RTM 314 encapsulation and, in case of two-step clock mode being indicated, 315 will generate PTP messages to include the follow-up correction as 316 appropriate (according to the [IEEE.1588.2008]). In this case, the 317 common header of the PTP packet carrying the synchronization message 318 would have to be modified by setting the twoStepFlag field indicating 319 that there is now a follow up message associated to the current 320 message. 322 3. G-ACh for Residence Time Measurement 324 RFC 5586 [RFC5586] and RFC 6423 [RFC6423] define the G-ACh to extend 325 the applicability of the Pseudowire Associated Channel (ACH) 326 [RFC5085] to LSPs. G-ACh provides a mechanism to transport OAM and 327 other control messages over an LSP. Processing of these messages by 328 selected transit nodes is controlled by the use of the Time-to-Live 329 (TTL) value in the MPLS header of these messages. 331 The message format for Residence Time Measurement (RTM) is presented 332 in Figure 1 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 |0 0 0 1|Version| Reserved | RTM G-ACh | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | | 339 | Scratch Pad | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Type | Length | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Sub-TLV (optional) | 344 ~ ~ 345 | | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Figure 1: RTM G-ACh message format for Residence Time Measurement 350 o First four octets are defined as G-ACh Header in [RFC5586] 352 o The Version field is set to 0, as defined in RFC 4385 [RFC4385]. 354 o The Reserved field MUST be set to 0 on transmit and ignored on 355 receipt. 357 o The RTM G-ACh field, value (TBA1) to be allocated by IANA, 358 identifies the packet as such. 360 o The Scratch Pad field is 8 octets in length. It is used to 361 accumulate the residence time spent in each RTM capable node 362 transited by the packet on its path from ingress node to egress 363 node. The first RTM-capable node MUST initialize the Scratch Pad 364 field with its residence time measurement. Its format is IEEE 365 double precision and its units are nanoseconds. Note that 366 depending on whether the timing procedure is one-step or two-step 367 operation (Section 2.1), the residence time is either for the 368 timing packet carried in the Value field of this RTM message or 369 for an associated timing packet carried in the Value field of 370 another RTM message. 372 o The Type field identifies the type and encapsulation of a timing 373 packet carried in the Value field, e.g., NTP [RFC5905] or PTP 374 [IEEE.1588.2008]. This document asks IANA to create a sub- 375 registry in Generic Associated Channel (G-ACh) Parameters Registry 376 called "MPLS RTM TLV Registry" Section 7.2. 378 o The Length field contains the length, in octets, of the of the 379 timing packet carried in the Value field. 381 o The optional Value field MAY carry a packet of the time 382 synchronization protocol identified by Type field. It is 383 important to note that the packet may be authenticated or 384 encrypted and carried over LSP edge to edge unchanged while the 385 residence time is accumulated in the Scratch Pad field. 387 o The TLV MUST be included in the RTM message, even if the length of 388 the Value field is zero. 390 3.1. PTP Packet Sub-TLV 392 Figure 2 presents the format of a PTP sub-TLV that MUST be included 393 in the Value field of an RTM message preceding the carried timing 394 packet when the timing packet is PTP. 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Type | Length | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Flags |PTPType| 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Port ID | 404 | | 405 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | | Sequence ID | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 Figure 2: PTP Sub-TLV format 411 where Flags field has format 413 0 1 2 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 |S| Reserved | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 Figure 3: Flags field format of PTP Packet Sub-TLV 421 o The Type field identifies PTP packet sub-TLV and is set to 1 422 according to Section 7.3. 424 o The Length field of the PTP sub-TLV contains the number of octets 425 of the Value field and MUST be 20. 427 o The Flags field currently defines one bit, the S-bit, that defines 428 whether the current message has been processed by a two-step node, 429 where the flag is cleared if the message has been handled 430 exclusively by one-step nodes and there is no follow-up message, 431 and is set if there has been at least one two-step node and a 432 follow-up message is forthcoming. 434 o The PTPType field indicates the type of PTP packet carried in the 435 TLV. PTPType is the messageType field of the PTPv2 packet whose 436 values are defined in Table 19 of [IEEE.1588.2008]. 438 o The 10 octet long Port ID field contains the identity of the 439 source port. 441 o The Sequence ID is the sequence ID of the PTP message carried in 442 the Value field of the message. 444 Tuple of PTPType, Port ID, and Sequence ID uniquely identifies PTP 445 control packet encapsulated in RTM message and are used in two-step 446 RTM mode Section 2.1.1. 448 4. Control Plane Theory of Operation 450 The operation of RTM depends upon TTL expiry to deliver an RTM packet 451 from one RTM capable interface to the next along the path from 452 ingress node to egress node. This means that a node with RTM capable 453 interfaces MUST be able to compute a TTL which will cause the expiry 454 of an RTM packet at the next node with RTM capable interfaces. 456 4.1. RTM Capability 458 Note that the RTM capability of a node is with respect to the pair of 459 interfaces that will be used to forward an RTM packet. In general, 460 the ingress interface of this pair must be able to capture the 461 arrival time of the packet and encode it in some way such that this 462 information will be available to the egress interface of a node. 464 The supported mode (one-step or two-step) of any pair of interfaces 465 is determined by the capability of the egress interface. For both 466 modes, the egress interface implementation MUST be able to determine 467 the precise departure time of the same packet and determine from 468 this, and the arrival time information from the corresponding ingress 469 interface, the difference representing the residence time for the 470 packet. 472 An interface with the ability to do this and update the associated 473 Scratch Pad in real-time (i.e., while the packet is being forwarded) 474 is said to be one-step capable. 476 Hence while both ingress and egress interfaces are required to 477 support RTM for the pair to be RTM-capable, it is the egress 478 interface that determines whether or not the node is one-step or two- 479 step capable with respect to the interface-pair. 481 The RTM capability used in the sub-TLV shown in Figure 4 and Figure 5 482 is thus a non-routing related capability associated with the 483 interface being advertised based on its egress capability. The 484 ability of any pair of interfaces on a node that includes this egress 485 interface to support any mode of RTM depends on the ability of the 486 ingress interface of a node to record packet arrival time and convey 487 it to the egress interface on the node. 489 When a node uses an IGP to support the RTM capability advertisement, 490 the IGP sub-TLV MUST reflect the RTM capability (one-step or two- 491 step) associated with the advertised interface. Changes of RTM 492 capability are unlikely to be frequent and would result, for example, 493 from operator's decision to include or exclude a particular port from 494 RTM processing or switch between RTM modes. 496 4.2. RTM Capability Sub-TLV 498 [RFC4202] explains that the Interface Switching Capability Descriptor 499 describes the switching capability of an interface. For bi- 500 directional links, the switching capabilities of an interface are 501 defined to be the same in either direction. I.e., for data entering 502 the node through that interface and for data leaving the node through 503 that interface. That principle SHOULD be applied when a node 504 advertises RTM Capability. 506 A node that supports RTM MUST be able to act in two-step mode and MAY 507 also support one-step RTM mode. Detailed discussion of one-step and 508 two-step RTM modes is contained in Section 2.1. 510 4.3. RTM Capability Advertisement in Routing Protocols 512 4.3.1. RTM Capability Advertisement in OSPFv2 514 The format for the RTM Capability sub-TLV in OSPF is presented in 515 Figure 4 516 0 1 2 3 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Type | Length | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | RTM | Value ... 522 +-+-+-+-+-+-+-+-+-+- ... 524 Figure 4: RTM Capability sub-TLV in OSPFv2 526 o Type value (TBA2) will be assigned by IANA from appropriate 527 registry for OSPFv2 Section 7.4. 529 o Length value equals number of octets of the Value field. 531 o Value contains variable number of bit-map fields so that overall 532 number of bits in the fields equals Length * 8. 534 o Bits are defined/sent starting with Bit 0. Additional bit-map 535 field definitions that may be defined in the future SHOULD be 536 assigned in ascending bit order so as to minimize the number of 537 bits that will need to be transmitted. 539 o Undefined bits MUST be transmitted as 0 and MUST be ignored on 540 receipt. 542 o Bits that are NOT transmitted MUST be treated as if they are set 543 to 0 on receipt. 545 o RTM (capability) - is a three-bit long bit-map field with values 546 defined as follows: 548 * 0b001 - one-step RTM supported; 550 * 0b010 - two-step RTM supported; 552 * 0b100 - reserved. 554 The capability to support RTM on a particular link (interface) is 555 advertised in the OSPFv2 Extended Link Opaque LSA described in 556 Section 3 [RFC7684] via the RTM Capability sub-TLV. 558 Its Type value will be assigned by IANA from the OSPF Extended Link 559 TLV Sub-TLVs registry Section 7.4, that will be created per [RFC7684] 560 request. 562 4.3.2. RTM Capability Advertisement in OSPFv3 564 The capability to support RTM on a particular link (interface) can be 565 advertised in OSPFv3 using LSA extensions as described in 566 [I-D.ietf-ospf-ospfv3-lsa-extend]. The sub-TLV SHOULD use the same 567 format as in Section 4.3.1. The type allocation and full details of 568 exact use of OSPFv3 LSA extensions is for further study. 570 4.3.3. RTM Capability Advertisement in IS-IS 572 The capability to support RTM on a particular link (interface) is 573 advertised in a new sub-TLV which may be included in TLVs advertising 574 Intermediate System (IS) Reachability on a specific link (TLVs 22, 575 23, 222, and 223). 577 The format for the RTM Capabilities sub-TLV is presented in Figure 5 579 0 1 2 580 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 ... 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 582 | Type | Length | RTM | Value ... 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 585 Figure 5: RTM Capability sub-TLV 587 o Type value (TBA3) will be assigned by IANA from the Sub-TLVs for 588 TLVs 22, 23, 141, 222, and 223 registry for IS-IS Section 7.5. 590 o Definitions, rules of handling, and values for fields Length and 591 Value are as defined in Section 4.3.1 593 o RTM (capability) - is a three-bit long bit-map field with values 594 defined in Section 4.3.1. 596 4.3.4. RTM Capability Advertisement in BGP-LS 598 The format for the RTM Capabilities TLV is as presented in Figure 4. 600 Type value TBA9 will be assigned by IANA from the BGP-LS Node 601 Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs 602 sub-registry Section 7.6. 604 Definitions, rules of handling, and values for fields Length, Value, 605 and RTM are as defined in Section 4.3.1. 607 The RTM Capability will be advertised in BGP-LS as a Link Attribute 608 TLV associated with the Link NLRI as described in section 3.3.2 of 609 [RFC7752]. 611 4.4. RSVP-TE Control Plane Operation to Support RTM 613 Throughout this document we refer to a node as RTM capable node when 614 at least one of its interfaces is RTM capable. Figure 6 provides an 615 example of roles a node may have with respect to RTM capability: 617 ----- ----- ----- ----- ----- ----- ----- 618 | A |-----| B |-----| C |-----| D |-----| E |-----| F |-----| G | 619 ----- ----- ----- ----- ----- ----- ----- 621 Figure 6: RTM capable roles 623 o A is a BC with its egress port in Master state. Node A transmits 624 IP encapsulated timing packets whose destination IP address is G. 626 o B is the ingress LER for the MPLS LSP and is the first RTM capable 627 node. It creates RTM packets and in each it places a timing 628 packet, possibly encrypted, in the Value field and initializes the 629 Scratch Pad field with its residence time measurement 631 o C is a transit node that is not RTM capable. It forwards RTM 632 packets without modification. 634 o D is RTM capable transit node. It updates the Scratch Pad field 635 of the RTM packet without updating the timing packet. 637 o E is a transit node that is not RTM capable. It forwards RTM 638 packets without modification. 640 o F is the egress LER and the last RTM capable node. It removes the 641 RTM ACH encapsulation and processes the timing packet carried in 642 the Value field using the value in the Scratch Pad field. In 643 particular, the value in the Scratch Pad field of the RTM ACH is 644 used in updating the Correction field of the PTP message(s). The 645 LER should also include its own residence time before creating the 646 outgoing PTP packets. The details of this process depend on 647 whether or not the node F is itself operating as one-step or two- 648 step clock. 650 o G is a Boundary Clock with its ingress port in Slave state. Node 651 G receives PTP messages. 653 An ingress node that is configured to perform RTM along a path 654 through an MPLS network to an egress node MUST verify that the 655 selected egress node has an interface that supports RTM via the 656 egress node's advertisement of the RTM Capability sub-TLV, as covered 657 in Section 4.3. In the Path message that the ingress node uses to 658 instantiate the LSP to that egress node, it places an LSP_ATTRIBUTES 659 Object [RFC5420] with RTM_SET Attribute Flag set, as described in 660 Section 7.8, which indicates to the egress node that RTM is requested 661 for this LSP. The RTM_SET Attribute Flag SHOULD NOT be set in the 662 LSP_REQUIRED_ATTRIBUTES object [RFC5420], unless it is known that all 663 nodes recognize the RTM attribute (but need not necessarily implement 664 it), because a node that does not recognize the RTM_SET Attribute 665 Flag would reject the Path message. 667 If an egress node receives a Path message with the RTM_SET Attribute 668 Flag in LSP_ATTRIBUTES object, the egress node MUST include an 669 initialized RRO [RFC3209] and LSP_ATTRIBUTES object where the RTM_SET 670 Attribute Flag is set and the RTM_SET TLV Section 4.4.1 is 671 initialized. When the Resv message is received by the ingress node, 672 the RTM_SET TLV will contain an ordered list, from egress node to 673 ingress node, of the RTM capable nodes along the LSP's path. 675 After the ingress node receives the Resv, it MAY begin sending RTM 676 packets on the LSP's path. Each RTM packet has its Scratch Pad field 677 initialized and its TTL set to expire on the closest downstream RTM 678 capable node. 680 It should be noted that RTM can also be used for LSPs instantiated 681 using [RFC3209] in an environment in which all interfaces in an IGP 682 support RTM. In this case the RTM_SET TLV and LSP_ATTRIBUTES Object 683 MAY be omitted. 685 4.4.1. RTM_SET TLV 687 RTM capable interfaces can be recorded via RTM_SET TLV. The RTM_SET 688 sub-object format is of generic Type, Length, Value (TLV), presented 689 in Figure 7 . 691 0 1 2 3 692 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 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Type | Length |I| Reserved | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 ~ Value ~ 697 | | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 Figure 7: RTM_SET TLV format 702 The type value (TBA4) will be assigned by IANA from its RSVP-TE 703 Attributes TLV Space sub-registry Section 7.7. 705 The Length contains the total length of the sub-object in bytes, 706 including the Type and Length fields. 708 The I bit flag indicates whether the downstream RTM capable node 709 along the LSP is present in the RRO. 711 The Reserved field must be zeroed on initiation and ignored on 712 receipt. 714 The content of an RTM_SET TLV is a series of variable-length sub- 715 TLVs. Only a single RTM_SET can be present in a given LSP_ATTRIBUTES 716 object. The sub-TLVs are defined in Section 4.4.1.1 below. 718 The following processing procedures apply to every RTM capable node 719 along the LSP. In this paragraph, an RTM capable node is referred to 720 as a node for sake of brevity. Each node MUST examine the Resv 721 message for whether the RTM_SET Attribute Flag in the LSP_ATTRIBUTES 722 object is set. If the RTM_SET flag is set, the node MUST inspect the 723 LSP_ATTRIBUTES object for presence of an RTM_SET TLV. If more than 724 one is found, then the LSP setup MUST fail with generation of the 725 ResvErr message with Error Code Duplicate TLV (Section 7.9) and Error 726 Value that contains Type value in its 8 least significant bits. If 727 no RTM_SET TLV is found, then the LSP setup MUST fail with generation 728 of the ResvErr message with Error Code RTM_SET TLV Absent 729 Section 7.9. If one RTM_SET TLV has been found, the node will use 730 the ID of the first node in the RTM_SET in conjunction with the RRO 731 to compute the hop count to its downstream node with reachable RTM 732 capable interface. If the node cannot find a matching ID in the RRO, 733 then it MUST try to use the ID of the next node in the RTM_SET until 734 it finds the match or reaches the end of the RTM_SET TLV. If a match 735 has been found, the calculated value is used by the node as the TTL 736 value in the outgoing label to reach the next RTM capable node on the 737 LSP. Otherwise, the TTL value MUST be set to 255. The node MUST add 738 an RTM_SET sub-TLV with the same address it used in the RRO sub- 739 object at the beginning of the RTM_SET TLV in the associated outgoing 740 Resv message before forwarding it upstream. If the calculated TTL 741 value has been set to 255, as described above, then the I flag in the 742 node's RTM_SET TLV MUST be set to 1 before the Resv message is 743 forwarded upstream. Otherwise, the I flag MUST be cleared (0). 745 The ingress node MAY inspect the I bit flag received in each RTM_SET 746 TLV contained in the LSP_ATTRIBUTES object of a received Resv 747 message. The presence of the RTM_SET TLV with the I bit field set to 748 1 indicates that some RTM nodes along the LSP could not be included 749 in the calculation of the residence time. An ingress node MAY choose 750 to resignal the LSP to include all RTM nodes or simply notify the 751 user via a management interface. 753 There are scenarios when some information is removed from an RRO due 754 to policy processing (e.g., as may happen between providers) or the 755 RRO is limited due to size constraints. Such changes affect the core 756 assumption of this method and the processing of RTM packets. RTM 757 SHOULD NOT be used if it is not guaranteed that the RRO contains 758 complete information. 760 4.4.1.1. RTM_SET Sub-TLVs 762 The RTM Set sub-object contains an ordered list, from egress node to 763 ingress node, of the RTM capable nodes along the LSP's path. 765 The contents of a RTM_SET sub-object are a series of variable-length 766 sub-TLVs. Each sub-TLV has its own Length field. The Length 767 contains the total length of the sub-TLV in bytes, including the Type 768 and Length fields. The Length MUST always be a multiple of 4, and at 769 least 8 (smallest IPv4 sub-object). 771 Sub-TLVs are organized as a last-in-first-out stack. The first-out 772 sub-TLV relative to the beginning of RTM_SET TLV is considered the 773 top. The last-out sub-TLV is considered the bottom. When a new sub- 774 TLV is added, it is always added to the top. 776 The RTM_SET TLV is intended to include the subset of the RRO sub-TLVs 777 that represents those egress interfaces on the LSP that are RTM- 778 capable. After a node chooses an egress interface to use in the RRO 779 sub-TLV, that same egress interface, if RTM-capable, SHOULD be placed 780 into the RTM_SET TLV using one of the IPv4 sub-TLV, IPv6 sub-TLV, or 781 Unnumbered Interface sub-TLV. The address family chosen SHOULD match 782 that of the RESV message and that used in the RRO; the unnumbered 783 interface sub-TLV is used when the egress interface has no assigned 784 IP address. A node MUST NOT place more sub-TLVs in the RTM_SET TLV 785 than the number of RTM-capable egress interfaces the LSP traverses 786 that are under that node's control. Only a single RTM_SET sub-TLV 787 with the given Value field MUST be present in the RTM_SET TLV. If 788 more than one sub-TLV with the same value (e.g., a duplicated 789 address) is found the LSP setup MUST fail with the generation of a 790 ResvErr message with the Error Code "Duplicate sub-TLV" Section 7.9 791 and Error Value contains 16-bit value composed of (Type of TLV, Type 792 of sub-TLV). 794 Three kinds of sub-TLVs for RTM_SET are currently defined. 796 4.4.1.1.1. IPv4 Sub-TLV 797 0 1 2 3 798 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 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | Type | Length | Reserved | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | IPv4 address | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 Figure 8: IPv4 sub-TLV format 807 Type 809 0x01 IPv4 address 811 Length 813 The Length contains the total length of the sub-TLV in bytes, 814 including the Type and Length fields. The Length is always 8. 816 IPv4 address 818 A 32-bit unicast host address. 820 Reserved 822 Zeroed on initiation and ignored on receipt. 824 4.4.1.1.2. IPv6 Sub-TLV 826 0 1 2 3 827 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 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Type | Length | Reserved | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | | 832 | IPv6 address | 833 | | 834 | | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 Figure 9: IPv6 sub-TLV format 839 Type 841 0x02 IPv6 address 843 Length 844 The Length contains the total length of the sub-TLV in bytes, 845 including the Type and Length fields. The Length is always 20. 847 IPv6 address 849 A 128-bit unicast host address. 851 Reserved 853 Zeroed on initiation and ignored on receipt. 855 4.4.1.1.3. Unnumbered Interface Sub-TLV 857 0 1 2 3 858 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 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | Type | Length | Reserved | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Node ID | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Interface ID | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 Figure 10: IPv4 sub-TLV format 869 Type 871 0x03 Unnumbered interface 873 Length 875 The Length contains the total length of the sub-TLV in bytes, 876 including the Type and Length fields. The Length is always 12. 878 Node ID 880 The Node ID interpreted as Router ID as discussed in Section 2 881 [RFC3477]. 883 Interface ID 885 The identifier assigned to the link by the node specified by the 886 Node ID. 888 Reserved 890 Zeroed on initiation and ignored on receipt. 892 5. Data Plane Theory of Operation 894 After instantiating an LSP for a path using RSVP-TE [RFC3209] as 895 described in Section 4.4, the ingress node MAY begin sending RTM 896 packets to the first downstream RTM capable node on that path. Each 897 RTM packet has its Scratch Pad field initialized and its TTL set to 898 expire on the next downstream RTM-capable node. Each RTM-capable 899 node on the explicit path receives an RTM packet and records the time 900 at which it receives that packet at its ingress interface as well as 901 the time at which it transmits that packet from its egress interface. 902 These actions should be done as close to the physical layer as 903 possible at the same point of packet processing striving to avoid 904 introducing the appearance of jitter in propagation delay whereas it 905 should be accounted as residence time. The RTM-capable node 906 determines the difference between those two times; for one-step 907 operation, this difference is determined just prior to or while 908 sending the packet, and the RTM-capable egress interface adds it to 909 the value in the Scratch Pad field of the message in progress. Note, 910 for the purpose of calculating a residence time, a common free 911 running clock synchronizing all the involved interfaces may be 912 sufficient, as, for example, 4.6 ppm accuracy leads to 4.6 nanosecond 913 error for residence time on the order of 1 millisecond. This may be 914 acceptable for applications where the target accuracy is in the order 915 of hundreds of ns. As an example, several applications being 916 considered in the area of wireless applications are satisfied with an 917 accuracy of 1.5 microseconds [ITU-T.G.8271]. 919 For two-step operation, the difference between packet arrival time 920 (at an ingress interface) and subsequent departure time (from an 921 egress interface) is determined at some later time prior to sending a 922 subsequent follow-up message, so that this value can be used to 923 update the correctionField in the follow-up message. 925 See Section 2.1 for further details on the difference between one- 926 step and two-step operation. 928 The last RTM-capable node on the LSP MAY then use the value in the 929 Scratch Pad field to perform time correction, if there is no follow- 930 up message. For example, the egress node may be a PTP Boundary Clock 931 synchronized to a Master Clock and will use the value in the Scratch 932 Pad field to update PTP's correctionField. 934 6. Applicable PTP Scenarios 936 This approach can be directly integrated in a PTP network based on 937 the IEEE 1588 delay request-response mechanism. The RTM capable 938 nodes act as end-to-end transparent clocks, and typically boundary 939 clocks, at the edges of the MPLS network, use the value in the 940 Scratch Pad field to update the correctionField of the corresponding 941 PTP event packet prior to performing the usual PTP processing. 943 7. IANA Considerations 945 7.1. New RTM G-ACh 947 IANA is requested to reserve a new G-ACh as follows: 949 +-------+----------------------------+---------------+ 950 | Value | Description | Reference | 951 +-------+----------------------------+---------------+ 952 | TBA1 | Residence Time Measurement | This document | 953 +-------+----------------------------+---------------+ 955 Table 1: New Residence Time Measurement 957 7.2. New RTM TLV Registry 959 IANA is requested to create a sub-registry in the Generic Associated 960 Channel (G-ACh) Parameters Registry called "MPLS RTM TLV Registry". 961 All code points in the range 0 through 127 in this registry shall be 962 allocated according to the "IETF Review" procedure as specified in 963 [RFC5226]. Code points in the range 128 through 191 in this registry 964 shall be allocated according to the "First Come First Served" 965 procedure as specified in [RFC5226]. This document defines the 966 following new values RTM TLV types: 968 +-----------+-------------------------------+---------------+ 969 | Value | Description | Reference | 970 +-----------+-------------------------------+---------------+ 971 | 0 | Reserved | This document | 972 | 1 | No payload | This document | 973 | 2 | PTPv2, Ethernet encapsulation | This document | 974 | 3 | PTPv2, IPv4 Encapsulation | This document | 975 | 4 | PTPv2, IPv6 Encapsulation | This document | 976 | 5 | NTP | This document | 977 | 6-127 | Unassigned | | 978 | 128 - 191 | Unassigned | | 979 | 192 - 254 | Private Use | This document | 980 | 255 | Reserved | This document | 981 +-----------+-------------------------------+---------------+ 983 Table 2: RTM TLV Type 985 7.3. New RTM Sub-TLV Registry 987 IANA is requested to create a sub-registry in the MPLS RTM TLV 988 Registry, requested in Section 7.2, called "MPLS RTM Sub-TLV 989 Registry". All code points in the range 0 through 127 in this 990 registry shall be allocated according to the "IETF Review" procedure 991 as specified in [RFC5226]. Code points in the range 128 through 191 992 in this registry shall be allocated according to the "First Come 993 First Served" procedure as specified in [RFC5226]. This document 994 defines the following new values RTM sub-TLV types: 996 +-----------+-------------+---------------+ 997 | Value | Description | Reference | 998 +-----------+-------------+---------------+ 999 | 0 | Reserved | This document | 1000 | 1 | PTP | This document | 1001 | 2-127 | Unassigned | | 1002 | 128 - 191 | Unassigned | | 1003 | 192 - 254 | Private Use | This document | 1004 | 255 | Reserved | This document | 1005 +-----------+-------------+---------------+ 1007 Table 3: RTM Sub-TLV Type 1009 7.4. RTM Capability sub-TLV in OSPFv2 1011 IANA is requested to assign a new type for RTM Capability sub-TLV 1012 from the OSPFv2 Extended Link TLV Sub-TLVs registry as follows: 1014 +-------+----------------+---------------+ 1015 | Value | Description | Reference | 1016 +-------+----------------+---------------+ 1017 | TBA2 | RTM Capability | This document | 1018 +-------+----------------+---------------+ 1020 Table 4: RTM Capability sub-TLV 1022 7.5. IS-IS RTM Capability sub-TLV 1024 IANA is requested to assign a new Type for the RTM Capability sub-TLV 1025 from the Sub-TLVs for TLVs 22, 23, 141, 222, and 223 registry as 1026 follows: 1028 +------+----------------+----+----+-----+-----+-----+---------------+ 1029 | Type | Description | 22 | 23 | 141 | 222 | 223 | Reference | 1030 +------+----------------+----+----+-----+-----+-----+---------------+ 1031 | TBA3 | RTM Capability | y | y | n | y | y | This document | 1032 +------+----------------+----+----+-----+-----+-----+---------------+ 1034 Table 5: IS-IS RTM Capability sub-TLV Registry Description 1036 7.6. RTM Capability TLV in BGP-LS 1038 IANA is requested to assign a new code point for the RTM Capability 1039 TLV from the BGP-LS Node Descriptor, Link Descriptor, Prefix 1040 Descriptor, and Attribute TLVs sub-registry in its Border Gateway 1041 Protocol - Link State (BGP-LS) Parameters registry as follows: 1043 +---------------+----------------+------------------+---------------+ 1044 | TLV Code | Description | IS-IS TLV/Sub- | Reference | 1045 | Point | | TLV | | 1046 +---------------+----------------+------------------+---------------+ 1047 | TBA9 | RTM Capability | 22/TBA3 | This document | 1048 +---------------+----------------+------------------+---------------+ 1050 Table 6: RTM Capability TLV in BGP-LS 1052 7.7. RTM_SET Sub-object RSVP Type and sub-TLVs 1054 IANA is requested to assign a new Type for the RTM_SET sub-object 1055 from the RSVP-TE Attributes TLV Space sub-registry as follows: 1057 +-----+------------+-----------+---------------+---------+----------+ 1058 | Typ | Name | Allowed | Allowed on | Allowed | Referenc | 1059 | e | | on LSP_A | LSP_REQUIRED_ | on LSP | e | 1060 | | | TTRIBUTES | ATTRIBUTES | Hop Att | | 1061 | | | | | ributes | | 1062 +-----+------------+-----------+---------------+---------+----------+ 1063 | TBA | RTM_SET | Yes | No | No | This | 1064 | 4 | sub-object | | | | document | 1065 +-----+------------+-----------+---------------+---------+----------+ 1067 Table 7: RTM_SET Sub-object Type 1069 IANA requested to create a new sub-registry for sub-TLV types of the 1070 RTM_SET sub-object. All code points in the range 0 through 127 in 1071 this registry shall be allocated according to the "IETF Review" 1072 procedure as specified in [RFC5226]. Code points in the range 128 1073 through 191 in this registry shall be allocated according to the 1074 "First Come First Served" procedure as specified in [RFC5226]. This 1075 document defines the following new values of RTM_SET object sub- 1076 object types: 1078 +-----------+----------------------+---------------+ 1079 | Value | Description | Reference | 1080 +-----------+----------------------+---------------+ 1081 | 0 | Reserved | This document | 1082 | 1 | IPv4 address | This document | 1083 | 2 | IPv6 address | This document | 1084 | 3 | Unnumbered interface | This document | 1085 | 4-127 | Unassigned | | 1086 | 128 - 191 | Unassigned | | 1087 | 192 - 254 | Private Use | This document | 1088 | 255 | Reserved | This document | 1089 +-----------+----------------------+---------------+ 1091 Table 8: RTM_SET object sub-object types 1093 7.8. RTM_SET Attribute Flag 1095 IANA is requested to assign new flag from the RSVP-TE Attribute Flags 1096 registry 1098 +-----+--------+-----------+------------+-----+-----+---------------+ 1099 | Bit | Name | Attribute | Attribute | RRO | ERO | Reference | 1100 | No | | Flags | Flags Resv | | | | 1101 | | | Path | | | | | 1102 +-----+--------+-----------+------------+-----+-----+---------------+ 1103 | TBA | RTM_SE | Yes | Yes | No | No | This document | 1104 | 5 | T | | | | | | 1105 +-----+--------+-----------+------------+-----+-----+---------------+ 1107 Table 9: RTM_SET Attribute Flag 1109 7.9. New Error Codes 1111 IANA is requested to assign new Error Codes from RSVP Error Codes and 1112 Globally-Defined Error Value Sub-Codes registry 1114 +------------+--------------------+---------------+ 1115 | Error Code | Meaning | Reference | 1116 +------------+--------------------+---------------+ 1117 | TBA6 | Duplicate TLV | This document | 1118 | TBA7 | Duplicate sub-TLV | This document | 1119 | TBA8 | RTM_SET TLV Absent | This document | 1120 +------------+--------------------+---------------+ 1122 Table 10: New Error Codes 1124 8. Security Considerations 1126 Routers that support Residence Time Measurement are subject to the 1127 same security considerations as defined in [RFC4385] and [RFC5085] . 1129 In addition - particularly as applied to use related to PTP - there 1130 is a presumed trust model that depends on the existence of a trusted 1131 relationship of at least all PTP-aware nodes on the path traversed by 1132 PTP messages. This is necessary as these nodes are expected to 1133 correctly modify specific content of the data in PTP messages and 1134 proper operation of the protocol depends on this ability. In 1135 practice, this means that those portions of messages cannot be 1136 covered by either confidentiality or integrity protection. Though 1137 there are methods that make it possible in theory to provide either 1138 or both such protections and still allow for intermediate nodes to 1139 make detectable but authenticated modifications, such methods do not 1140 seem practical at present, particularly for timing protocols that are 1141 sensitive to latency and/or jitter. 1143 The ability to potentially authenticate and/or encrypt RTM and PTP 1144 data for scenarios both with and without participation of 1145 intermediate RTM/PTP-capable nodes is left for further study. 1147 While it is possible for a supposed compromised node to intercept and 1148 modify the G-ACh content, this is an issue that exists for nodes in 1149 general - for any and all data that may be carried over an LSP - and 1150 is therefore the basis for an additional presumed trust model 1151 associated with existing LSPs and nodes. 1153 Security requirements of time protocols are provided in RFC 7384 1154 [RFC7384]. 1156 9. Acknowledgments 1158 Authors want to thank Loa Andersson, Lou Berger, Acee Lindem, Les 1159 Ginsberg, and Uma Chunduri for their thorough reviews, thoughtful 1160 comments and, most of all, patience. 1162 10. References 1164 10.1. Normative References 1166 [IEEE.1588.2008] 1167 "Standard for a Precision Clock Synchronization Protocol 1168 for Networked Measurement and Control Systems", 1169 IEEE Standard 1588, July 2008. 1171 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1172 Requirement Levels", BCP 14, RFC 2119, 1173 DOI 10.17487/RFC2119, March 1997, 1174 . 1176 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1177 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1178 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1179 . 1181 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1182 in Resource ReSerVation Protocol - Traffic Engineering 1183 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 1184 . 1186 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 1187 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 1188 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 1189 February 2006, . 1191 [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual 1192 Circuit Connectivity Verification (VCCV): A Control 1193 Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, 1194 December 2007, . 1196 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. 1197 Ayyangarps, "Encoding of Attributes for MPLS LSP 1198 Establishment Using Resource Reservation Protocol Traffic 1199 Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, 1200 February 2009, . 1202 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 1203 "MPLS Generic Associated Channel", RFC 5586, 1204 DOI 10.17487/RFC5586, June 2009, 1205 . 1207 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1208 "Network Time Protocol Version 4: Protocol and Algorithms 1209 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1210 . 1212 [RFC6423] Li, H., Martini, L., He, J., and F. Huang, "Using the 1213 Generic Associated Channel Label for Pseudowire in the 1214 MPLS Transport Profile (MPLS-TP)", RFC 6423, 1215 DOI 10.17487/RFC6423, November 2011, 1216 . 1218 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1219 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1220 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 1221 2015, . 1223 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1224 S. Ray, "North-Bound Distribution of Link-State and 1225 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1226 DOI 10.17487/RFC7752, March 2016, 1227 . 1229 10.2. Informative References 1231 [I-D.ietf-ospf-ospfv3-lsa-extend] 1232 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 1233 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-13 1234 (work in progress), October 2016. 1236 [I-D.ietf-tictoc-1588overmpls] 1237 Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. 1238 Montini, "Transporting Timing messages over MPLS 1239 Networks", draft-ietf-tictoc-1588overmpls-07 (work in 1240 progress), October 2015. 1242 [ITU-T.G.8271] 1243 "Packet over Transport aspects - Synchronization, quality 1244 and availability targets", ITU-T Recomendation 1245 G.8271/Y.1366, July 2016. 1247 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 1248 in Support of Generalized Multi-Protocol Label Switching 1249 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 1250 . 1252 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 1253 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 1254 October 2007, . 1256 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1257 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1258 DOI 10.17487/RFC5226, May 2008, 1259 . 1261 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1262 Measurement for MPLS Networks", RFC 6374, 1263 DOI 10.17487/RFC6374, September 2011, 1264 . 1266 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 1267 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 1268 October 2014, . 1270 Authors' Addresses 1272 Greg Mirsky 1273 ZTE Corp. 1275 Email: gregimirsky@gmail.com 1277 Stefano Ruffini 1278 Ericsson 1280 Email: stefano.ruffini@ericsson.com 1282 Eric Gray 1283 Ericsson 1285 Email: eric.gray@ericsson.com 1287 John Drake 1288 Juniper Networks 1290 Email: jdrake@juniper.net 1292 Stewart Bryant 1293 Huawei 1295 Email: stewart.bryant@gmail.com 1297 Alexander Vainshtein 1298 ECI Telecom 1300 Email: Alexander.Vainshtein@ecitele.com; Vainshtein.alex@gmail.com