idnits 2.17.1 draft-ietf-mpls-residence-time-14.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 1037 has weird spacing: '...Allowed on ...' -- The document date (February 22, 2017) is 2619 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' ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-lsa-extend-13 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 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: August 26, 2017 E. Gray 6 Ericsson 7 J. Drake 8 Juniper Networks 9 S. Bryant 10 Huawei 11 A. Vainshtein 12 ECI Telecom 13 February 22, 2017 15 Residence Time Measurement in MPLS network 16 draft-ietf-mpls-residence-time-14 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 propagation delay of timing 25 and synchronization messages and knowing what this delay is for each 26 message allows for a more accurate determination of the delay to be 27 taken into account in applying the value included in a Precision Time 28 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 August 26, 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. 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 OSPFv2 . . . . . . . . . 11 78 4.4. RTM Capability Advertisement in OSPFv3 . . . . . . . . . 12 79 4.5. RTM Capability Advertisement in IS-IS . . . . . . . . . . 12 80 4.6. RTM Capability Advertisement in BGP-LS . . . . . . . . . 13 81 4.7. RSVP-TE Control Plane Operation to Support RTM . . . . . 13 82 4.8. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . . . 15 83 4.8.1. RTM_SET Sub-TLVs . . . . . . . . . . . . . . . . . . 16 84 5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 19 85 6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 20 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 87 7.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 20 88 7.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 20 89 7.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 21 90 7.4. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 21 91 7.5. IS-IS RTM Capability sub-TLV . . . . . . . . . . . . . . 22 92 7.6. RTM Capability TLV in BGP-LS . . . . . . . . . . . . . . 22 93 7.7. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 22 94 7.8. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 23 95 7.9. New Error Codes . . . . . . . . . . . . . . . . . . . . . 24 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 97 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 99 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 100 10.2. Informative References . . . . . . . . . . . . . . . . . 26 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 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 116 a 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 LDP, that is outside the scope 125 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 Precision Time Protocol (PTP). In PTPv2 177 [IEEE.1588.2008], residence time is accumulated in the 178 correctionField of the PTP event message, as defined in 179 [IEEE.1588.2008] and referred to as using a one-step clock, or in the 180 associated follow-up message (or Delay_Resp message associated with 181 the Delay_Req message), referred to as using a two-step clock (see 182 the detailed discussion in Section 2.1). 184 IEEE 1588 uses this residence time to correct for the transit times 185 of nodes on an LSP, effectively making the transit nodes transparent. 187 This document proposes a mechanism that can be used as one type of 188 on-path support for a clock synchronization protocol or to perform 189 one-way measurement of residence time. The proposed mechanism 190 accumulates residence time from all nodes that support this extension 191 along the path of a particular LSP in the Scratch Pad field of an RTM 192 message (Figure 1). This value can then be used by the egress node 193 to update, for example, the correctionField of the PTP event packet 194 carried within the RTM message prior to performing its PTP 195 processing. 197 2.1. One-step Clock and Two-step Clock Modes 199 One-step mode refers to the mode of operation where an egress 200 interface updates the correctionField value of an original event 201 message. Two-step mode refers to the mode of operation where this 202 update is made in a subsequent follow-up message. 204 Processing of the follow-up message, if present, requires the 205 downstream end-point to wait for the arrival of the follow-up message 206 in order to combine correctionField values from both the original 207 (event) message and the subsequent (follow-up) message. In a similar 208 fashion, each two-step node needs to wait for the related follow-up 209 message, if there is one, in order to update that follow-up message 210 (as opposed to creating a new one. Hence the first node that uses 211 two-step mode MUST do two things: 213 1. Mark the original event message to indicate that a follow-up 214 message will be forthcoming. This is necessary in order to 216 Let any subsequent two-step node know that there is already a 217 follow-up message, and 219 Let the end-point know to wait for a follow-up message; 221 2. Create a follow-up message in which to put the RTM determined as 222 an initial correctionField value. 224 IEEE 1588v2 [IEEE.1588.2008] defines this behavior for PTP messages. 226 Thus, for example, with reference to the PTP protocol, the PTPType 227 field identifies whether the message is a Sync message, Follow_up 228 message, Delay_Req message, or Delay_Resp message. The 10 octet long 229 Port ID field contains the identity of the source port 230 [IEEE.1588.2008], that is, the specific PTP port of the boundary 231 clock connected to the MPLS network. The Sequence ID is the sequence 232 ID of the PTP message carried in the Value field of the message. 234 PTP messages also include a bit that indicates whether or not a 235 follow-up message will be coming. This bit, once it is set by a two- 236 step mode device, MUST stay set accordingly until the original and 237 follow-up messages are combined by an end-point (such as a Boundary 238 Clock). 240 Thus, an RTM packet, containing residence time information relating 241 to an earlier packet, also contains information identifying that 242 earlier packet. 244 For compatibility with PTP, RTM (when used for PTP packets) must 245 behave in a similar fashion. Without loss of generality should note 246 that handling of Sync event messages and handling of Delay_Req/ 247 Delay_Resp event messages that cross a two-step RTM node is 248 different. Following outlines handling of PTP Sync event message by 249 the two-step RTM node. Details of handling Delay_Resp/Delay_Req PTP 250 event messages by the two-step RTM node are in Section 2.1.1. To do 251 this, a two-step RTM capable egress interface will need to examine 252 the S-bit in the Flags field of the PTP sub-TLV (for RTM messages 253 that indicate they are for PTP) and - if it is clear (set to zero), 254 it MUST set it and create a follow-up PTP Type RTM message. If the S 255 bit is already set, then the RTM capable node MUST wait for the RTM 256 message with the PTP type of follow-up and matching originator and 257 sequence number to make the corresponding residence time update to 258 the Scratch Pad field. The wait period MUST be reasonably bound. 260 In practice an RTM operating according to two-step clock behaves like 261 a two-steps transparent clock. 263 A one-step capable RTM node MAY elect to operate in either one-step 264 mode (by making an update to the Scratch Pad field of the RTM message 265 containing the PTP event message), or in two-step mode (by making an 266 update to the Scratch Pad of a follow-up message when its presence is 267 indicated), but MUST NOT do both. 269 Two main subcases identified for an RTM node operating as a two-step 270 clock described in the following sub-sections. 272 2.1.1. RTM with Two-step Upstream PTP Clock 274 If any of the previous RTM capable nodes or the previous PTP clock 275 (e.g. the BC connected to the first node), is a two-step clock, the 276 residence time is added to the RTM packet that has been created to 277 include the associated PTP packet (i.e. follow-up message in the 278 downstream direction), if the local RTM-capable node is also 279 operating as a two-step clock. This RTM packet carries the related 280 accumulated residence time and the appropriate values of the Sequence 281 Id and Port Id (the same identifiers carried in the packet processed) 282 and the Two-step Flag set to 1. 284 Note that the fact that an upstream RTM-capable node operating in the 285 two-step mode has created a follow-up message does not require any 286 subsequent RTM capable node to also operate in the two-step mode, as 287 long as that RTM-capable node forwards the follow-up message on the 288 same LSP on which it forwards the corresponding previous message. 290 A one-step capable RTM node MAY elect to update the RTM follow-up 291 message as if it were operating in two-step mode, however, it MUST 292 NOT update both messages. 294 A PTP event packet (sync) is carried in the RTM packet in order for 295 an RTM node to identify that residence time measurement must be 296 performed on that specific packet. 298 To handle the residence time of the Delay_Req message on the upstream 299 direction, an RTM packet must be created to carry the residence time 300 on the associated downstream Delay_Resp message. 302 The last RTM node of the MPLS network, in addition to updating the 303 correctionField of the associated PTP packet, must also properly 304 handle the two-step flag of the PTP packets. 306 2.1.2. RTM with One-step Upstream PTP Clock 308 When the PTP network connected to the MPLS and RTM node, operates in 309 one-step clock mode, the associated RTM packet must be created by the 310 RTM node itself. The associated RTM packet including the PTP event 311 packet needs now to indicate that a follow up 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 as appropriate (according to the 316 [IEEE.1588.2008]). In this case, the common header of the PTP packet 317 carrying the synchronization message would have to be modified in the 318 twoStepFlag field indicating that there is now a follow up message 319 associated to that. 321 3. G-ACh for Residence Time Measurement 323 RFC 5586 [RFC5586] and RFC 6423 [RFC6423] define the G-ACh to extend 324 the applicability of the PW Associated Channel (ACH) [RFC5085] to 325 LSPs. G-ACh provides a mechanism to transport OAM and other control 326 messages over an LSP. Processing of these messages by selected 327 transit nodes is controlled by the use of the Time-to-Live (TTL) 328 value in the MPLS header of these messages. 330 The message format for Residence Time Measurement (RTM) is presented 331 in Figure 1 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 |0 0 0 1|Version| Reserved | RTM G-ACh | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | | 338 | Scratch Pad | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Type | Length | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Value | 343 ~ ~ 344 | | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Figure 1: RTM G-ACh message format for Residence Time Measurement 349 o First four octets are defined as G-ACh Header in [RFC5586] 351 o The Version field is set to 0, as defined in RFC 4385 [RFC4385]. 353 o The Reserved field MUST be set to 0 on transmit and ignored on 354 receipt. 356 o The RTM G-ACh field, value (TBA1) to be allocated by IANA, 357 identifies the packet as such. 359 o The Scratch Pad field is 8 octets in length. It is used to 360 accumulate the residence time spent in each RTM capable node 361 transited by the packet on its path from ingress node to egress 362 node. The first RTM-capable node MUST initialize the Scratch Pad 363 field with its residence time measurement. Its format is IEEE 364 double precision and its units are nanoseconds. Note that 365 depending on whether the timing procedure is one-step or two-step 366 operation (Section 2.1), the residence time is either for the 367 timing packet carried in the Value field of this RTM message or 368 for an associated timing packet carried in the Value field of 369 another RTM message. 371 o The Type field identifies the type and encapsulation of a timing 372 packet carried in the Value field, e.g., NTP [RFC5905] or PTP 373 [IEEE.1588.2008]. This document asks IANA to create a sub- 374 registry in Generic Associated Channel (G-ACh) Parameters Registry 375 called "MPLS RTM TLV Registry" Section 7.2. 377 o The Length field contains the length, in octets, of the of the 378 timing packet carried in the Value field. 380 o The optional Value field MAY carry a packet of the time 381 synchronization protocol identified by Type field. It is 382 important to note that the packet may be authenticated or 383 encrypted and carried over LSP edge to edge unchanged while the 384 residence time is accumulated in the Scratch Pad field. 386 o The TLV MUST be included in the RTM message, even if the length of 387 the Value field is zero. 389 3.1. PTP Packet Sub-TLV 391 Figure 2 presents format of a PTP sub-TLV that MUST be included in 392 the Value field of an RTM message preceding the carried timing packet 393 when the timing packet is PTP. 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Type | Length | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Flags |PTPType| 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Port ID | 403 | | 404 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | | Sequence ID | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 Figure 2: PTP Sub-TLV format 410 where Flags field has format 412 0 1 2 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 |S| Reserved | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Figure 3: Flags field format of PTP Packet Sub-TLV 420 o The Type field identifies PTP packet sub-TLV and is set to 1 421 according to Section 7.3. 423 o The Length field of the PTP sub-TLV contains the number of octets 424 of the Value field and MUST be 20. 426 o The Flags field currently defines one bit, the S-bit, that defines 427 whether the current message has been processed by a two-step node, 428 where the flag is cleared if the message has been handled 429 exclusively by one-step nodes and there is no follow-up message, 430 and set if there has been at least one two-step node and a follow- 431 up message is forthcoming. 433 o The PTPType indicates the type of PTP packet carried in the TLV. 434 PTPType is the messageType field of the PTPv2 packet whose values 435 are defined in Table 19 of [IEEE.1588.2008]. 437 o The 10 octets long Port ID field contains the identity of the 438 source port. 440 o The Sequence ID is the sequence ID of the PTP message carried in 441 the Value field of the message. 443 4. Control Plane Theory of Operation 445 The operation of RTM depends upon TTL expiry to deliver an RTM packet 446 from one RTM capable interface to the next along the path from 447 ingress node to egress node. This means that a node with RTM capable 448 interfaces MUST be able to compute a TTL which will cause the expiry 449 of an RTM packet at the next node with RTM capable interfaces. 451 4.1. RTM Capability 453 Note that the RTM capability of a node is with respect to the pair of 454 interfaces that will be used to forward an RTM packet. In general, 455 the ingress interface of this pair must be able to capture the 456 arrival time of the packet and encode it in some way such that this 457 information will be available to the egress interface of a node. 459 The supported mode (one-step or two-step) of any pair of interfaces 460 is determined by the capability of the egress interface. For both 461 modes, the egress interface implementation MUST be able to determine 462 the precise departure time of the same packet and determine from 463 this, and the arrival time information from the corresponding ingress 464 interface, the difference representing the residence time for the 465 packet. 467 An interface with the ability to do this and update the associated 468 Scratch Pad in real-time (i.e. while the packet is being forwarded) 469 is said to be one-step capable. 471 Hence while both ingress and egress interfaces are required to 472 support RTM for the pair to be RTM-capable, it is the egress 473 interface that determines whether or not the node is one-step or two- 474 step capable with respect to the interface-pair. 476 The RTM capability used in the sub-TLV shown in Figure 4 and Figure 5 477 is thus a non-routing related capability associated with the 478 interface being advertised based on its egress capability. The 479 ability of any pair of interfaces on a node that includes this egress 480 interface to support any mode of RTM depends on the ability of the 481 ingress interface of a node to record packet arrival time and convey 482 it to the egress interface on the node. 484 When a node uses an IGP to support the RTM capability advertisement, 485 the IGP the sub-TLV MUST reflect the RTM capability (one-step or two- 486 step) associated with the advertised interface. Changes of RTM 487 capability are unlikely to be frequent and would result, for example, 488 from operator's decision to include or exclude a particular port from 489 RTM processing or switch between RTM modes. 491 4.2. RTM Capability Sub-TLV 493 [RFC4202] explains that the Interface Switching Capability Descriptor 494 describes the switching capability of an interface. For bi- 495 directional links, the switching capabilities of an interface are 496 defined to be the same in either direction. I.e., for data entering 497 the node through that interface and for data leaving the node through 498 that interface. That principle SHOULD be applied when a node 499 advertises RTM Capability. 501 A node that supports RTM MUST be able to act in two-step mode and MAY 502 also support one-step RTM mode. Detailed discussion of one-step and 503 two-step RTM modes is contained in Section 2.1. 505 4.3. RTM Capability Advertisement in OSPFv2 507 The format for the RTM Capability sub-TLV in OSPF is presented in 508 Figure 4 510 0 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Type | Length | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | RTM | ... 516 +-+-+-+-+-+-+-+-+-+- ... 518 Figure 4: RTM Capability sub-TLV in OSPFv2 520 o Type value (TBA2) will be assigned by IANA from appropriate 521 registry for OSPFv2 Section 7.4. 523 o Length value equals number of octets of the Value field. 525 o Value contains variable number of bit-map fields so that overall 526 number of bits in the fields equals Length * 8. 528 o Bits are defined/sent starting with Bit 0. Additional bit-map 529 field definitions that may be defined in the future SHOULD be 530 assigned in ascending bit order so as to minimize the number of 531 bits that will need to be transmitted. 533 o Undefined bits MUST be transmitted as 0 and MUST be ignored on 534 receipt. 536 o Bits that are NOT transmitted MUST be treated as if they are set 537 to 0 on receipt. 539 o RTM (capability) - is a three-bit long bit-map field with values 540 defined as follows: 542 * 0b001 - one-step RTM supported; 544 * 0b010 - two-step RTM supported; 546 * 0b100 - reserved. 548 The capability to support RTM on a particular link (interface) is 549 advertised in the OSPFv2 Extended Link Opaque LSA described in 550 Section 3 [RFC7684] via the RTM Capability sub-TLV. 552 Its Type value will be assigned by IANA from the OSPF Extended Link 553 TLV Sub-TLVs registry Section 7.4, that will be created per [RFC7684] 554 request. 556 4.4. RTM Capability Advertisement in OSPFv3 558 The capability to support RTM on a particular link (interface) can be 559 advertised in OSPFv3 using LSA extensions as described in 560 [I-D.ietf-ospf-ospfv3-lsa-extend]. Exact use of OSPFv3 LSA 561 extensions is for further study. 563 4.5. RTM Capability Advertisement in IS-IS 565 The capability to support RTM on a particular link (interface) is 566 advertised in a new sub-TLV which may be included in TLVs advertising 567 Intermediate System (IS) Reachability on a specific link (TLVs 22, 568 23, 222, and 223). 570 The format for the RTM Capabilities sub-TLV is presented in Figure 5 571 0 1 2 572 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 ... 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 574 | Type | Length | RTM | ... 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 577 Figure 5: RTM Capability sub-TLV 579 o Type value (TBA3) will be assigned by IANA from the Sub-TLVs for 580 TLVs 22, 23, 141, 222, and 223 registry for IS-IS Section 7.5. 582 o Definitions, rules of handling, and values for fields Length and 583 Value are as defined in Section 4.3 585 o RTM (capability) - is a three-bit long bit-map field with values 586 defined in Section 4.3. 588 4.6. RTM Capability Advertisement in BGP-LS 590 The format for the RTM Capabilities TLV is as presented in Figure 4. 592 Type value TBA9 will be assigned by IANA from the BGP-LS Node 593 Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs 594 sub-registry Section 7.6. 596 Definitions, rules of handling, and values for fields Length, Value, 597 and RTM are as defined in Section 4.3. 599 The RTM Capability will be advertised in BGP-LS as a Link Attribute 600 TLV associated with the Link NLRI as described in section 3.3.2 of 601 [RFC7752]. 603 4.7. RSVP-TE Control Plane Operation to Support RTM 605 Throughout this document we refer to a node as RTM capable node when 606 at least one of its interfaces is RTM capable. Figure 6 provides an 607 example of roles a node may have with respect to RTM capability: 609 ----- ----- ----- ----- ----- ----- ----- 610 | A |-----| B |-----| C |-----| D |-----| E |-----| F |-----| G | 611 ----- ----- ----- ----- ----- ----- ----- 613 Figure 6: RTM capable roles 615 o A is a Boundary Clock (BC) with its egress port in Master state. 616 Node A transmits IP encapsulated timing packets whose destination 617 IP address is G. 619 o B is the ingress LER for the MPLS LSP and is the first RTM capable 620 node. It creates RTM packets and in each it places a timing 621 packet, possibly encrypted, in the Value field and initializes the 622 Scratch Pad field with its residence time measurement 624 o C is a transit node that is not RTM capable. It forwards RTM 625 packets without modification. 627 o D is RTM capable transit node. It updates the Scratch Pad field 628 of the RTM packet without updating the timing packet. 630 o E is a transit node that is not RTM capable. It forwards RTM 631 packets without modification. 633 o F is the egress LER and the last RTM capable node. It removes the 634 RTM ACH encapsulation and processes the timing packet carried in 635 the Value field using the value in the Scratch Pad field. In 636 particular, the value in the Scratch Pad field of the RTM ACH is 637 used in updating the Correction field of the PTP message(s). The 638 LER should also include its own residence time before creating the 639 outgoing PTP packets. The details of this process depend on 640 whether or not the node F is itself operating as one-step or two- 641 step clock. 643 o G is a Boundary Clock with its ingress port in Slave state. Node 644 G receives PTP messages. 646 An ingress node that is configured to perform RTM along a path 647 through an MPLS network to an egress node MUST verify that the 648 selected egress node has an interface that supports RTM via the 649 egress node's advertisement of the RTM Capability sub-TLV. In the 650 Path message that the ingress node uses to instantiate the LSP to 651 that egress node it places the LSP_ATTRIBUTES Object [RFC5420] with 652 RTM_SET Attribute Flag set, as described in Section 7.8, which 653 indicates to the egress node that RTM is requested for this LSP. 654 RTM_SET Attribute Flag SHOULD NOT be set in the 655 LSP_REQUIRED_ATTRIBUTES object [RFC5420], unless it is known that all 656 nodes support RTM, because a node that does not recognize RTM_SET 657 Attribute Flag would reject the Path message. 659 If an egress node receives a Path message with RTM_SET Attribute Flag 660 in LSP_ATTRIBUTES object, it MUST include initialized RRO [RFC3209] 661 and LSP_ATTRIBUTES object where RTM_SET Attribute Flag is set and 662 RTM_SET TLV Section 4.8 is initialized. When the Resv message is 663 received by the ingress node the RTM_SET TLV will contain an ordered 664 list, from egress node to ingress node, of the RTM capable nodes 665 along the LSP's path. 667 After the ingress node receives the Resv, it MAY begin sending RTM 668 packets on the LSP's path. Each RTM packet has its Scratch Pad field 669 initialized and its TTL set to expire on the closest downstream RTM 670 capable node. 672 It should be noted that RTM can also be used for LSPs instantiated 673 using [RFC3209] in an environment in which all interfaces in an IGP 674 support RTM. In this case the RTM_SET TLV and LSP_ATTRIBUTES Object 675 MAY be omitted. 677 4.8. RTM_SET TLV 679 RTM capable interfaces can be recorded via RTM_SET TLV. The RTM_SET 680 sub-object format is of generic Type, Length, Value (TLV), presented 681 in Figure 7 . 683 0 1 2 3 684 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 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | Type | Length |I| Reserved | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 ~ Value ~ 689 | | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 Figure 7: RTM_SET TLV format 694 Type value (TBA4) will be assigned by IANA from its Attributes TLV 695 Space sub-registry Section 7.7. 697 The Length contains the total length of the sub-object in bytes, 698 including the Type and Length fields. 700 The I bit flag indicates whether the downstream RTM capable node 701 along the LSP is present in the RRO. 703 Reserved field must be zeroed on initiation and ignored on receipt. 705 The content of an RTM_SET TLV is a series of variable-length sub- 706 TLVs. Only a single RTM_SET can be present in the LSP_ATTRIBUTES 707 object. The sub-TLVs are defined in Section 4.8.1 below. 709 The following processing procedures apply to every RTM capable node 710 along the LSP. In this paragraph, an RTM capable node is referred to 711 as a node for sake of brevity. Each node MUST examine Resv message 712 for whether the RTM_SET Attribute Flag in the LSP_ATTRIBUTES object 713 is set. If the RTM_SET flag is set, the node MUST inspect the 714 LSP_ATTRIBUTES object for presence of RTM_SET TLV. If more than one 715 is found, then the LSP setup MUST fail with generation of the ResvErr 716 message with Error Code Duplicate TLV (Section 7.9) and Error Value 717 that contains Type value in its 8 least significant bits. If no 718 RTM_SET TLV has been found, then the LSP setup MUST fail with 719 generation of the ResvErr message with Error Code RTM_SET TLV Absent 720 Section 7.9. If one RTM_SET TLV has been found the node will use the 721 ID of the first node in the RTM_SET in conjunction with the RRO to 722 compute the hop count to its downstream node with reachable RTM 723 capable interface. If the node cannot find a matching ID in RRO, 724 then it MUST try to use the ID of the next node in the RTM_SET until 725 it finds the match or reaches the end of the RTM_SET TLV. If a match 726 has been found, the calculated value is used by the node as the TTL 727 value in the outgoing label to reach the next RTM capable node on the 728 LSP. Otherwise, the TTL value MUST be set to 255. The node MUST add 729 RTM_SET sub-TLV with the same address it used in RRO sub-object at 730 the beginning of the RTM_SET TLV in the associated outgoing Resv 731 message before forwarding it upstream. If the calculated TTL value 732 been set to 255, as described above, then the I flag in node RTM_SET 733 TLV MUST be set to 1 before Resv message forwarded upstream. 734 Otherwise, the I flag MUST be cleared (0). 736 The ingress node MAY inspect the I bit flag received in each RTM_SET 737 TLV contained in the LSP_ATTRIBUTES object of a received Resv 738 message. Presence of the RTM_SET TLV with I bit field set to 1 739 indicates that some RTM nodes along the LSP could be included in the 740 calculation of the residence time. An ingress node MAY choose to 741 resignal the LSP to include all RTM nodes or simply notify the user 742 via a management interface. 744 There are scenarios when some information is removed from an RRO due 745 to policy processing (e.g., as may happen between providers) or RRO 746 is limited due to size constraints . Such changes affect the core 747 assumption of this method and processing of RTM packets. RTM SHOULD 748 NOT be used if it is not guaranteed that the RRO contains complete 749 information. 751 4.8.1. RTM_SET Sub-TLVs 753 The RTM Set sub-object contains an ordered list, from egress node to 754 ingress node, of the RTM capable nodes along the LSP's path. 756 The contents of a RTM_SET sub-object are a series of variable-length 757 sub-TLVs. Each sub-TLV has its own Length field. The Length 758 contains the total length of the sub-TLV in bytes, including the Type 759 and Length fields. The Length MUST always be a multiple of 4, and at 760 least 8 (smallest IPv4 sub-object). 762 Sub-TLVs are organized as a last-in-first-out stack. The first -out 763 sub-TLV relative to the beginning of RTM_SET TLV is considered the 764 top. The last-out sub-TLV is considered the bottom. When a new sub- 765 TLV is added, it is always added to the top. Only a single RTM_SET 766 sub-TLV with the given Value field MUST be present in the RTM_SET 767 TLV. If more than one sub-TLV is found the LSP setup MUST fail with 768 the generation of a ResvErr message with the Error Code "Duplicate 769 sub-TLV" Section 7.9 and Error Value contains 16-bit value composed 770 of (Type of TLV, Type of sub-TLV). 772 Three kinds of sub-TLVs for RTM_SET are currently defined. 774 4.8.1.1. IPv4 Sub-TLV 776 0 1 2 3 777 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 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Type | Length | Reserved | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | IPv4 address | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 Figure 8: IPv4 sub-TLV format 786 Type 788 0x01 IPv4 address 790 Length 792 The Length contains the total length of the sub-TLV in bytes, 793 including the Type and Length fields. The Length is always 8. 795 IPv4 address 797 A 32-bit unicast host address. 799 Reserved 801 Zeroed on initiation and ignored on receipt. 803 4.8.1.2. IPv6 Sub-TLV 804 0 1 2 3 805 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 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Type | Length | Reserved | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | | 810 | IPv6 address | 811 | | 812 | | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 Figure 9: IPv6 sub-TLV format 817 Type 819 0x02 IPv6 address 821 Length 823 The Length contains the total length of the sub-TLV in bytes, 824 including the Type and Length fields. The Length is always 20. 826 IPv6 address 828 A 128-bit unicast host address. 830 Reserved 832 Zeroed on initiation and ignored on receipt. 834 4.8.1.3. Unnumbered Interface Sub-TLV 836 0 1 2 3 837 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 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Type | Length | Reserved | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Node ID | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Interface ID | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 Figure 10: IPv4 sub-TLV format 848 Type 850 0x03 Unnumbered interface 852 Length 854 The Length contains the total length of the sub-TLV in bytes, 855 including the Type and Length fields. The Length is always 12. 857 Node ID 859 The Node ID interpreted as Router ID as discussed in the Section 2 860 [RFC3477]. 862 Interface ID 864 The identifier assigned to the link by the node specified by the 865 Node ID. 867 Reserved 869 Zeroed on initiation and ignored on receipt. 871 5. Data Plane Theory of Operation 873 After instantiating an LSP for a path using RSVP-TE [RFC3209] as 874 described in Section 4.7, the ingress node MAY begin sending RTM 875 packets to the first downstream RTM capable node on that path. Each 876 RTM packet has its Scratch Pad field initialized and its TTL set to 877 expire on the next downstream RTM-capable node. Each RTM-capable 878 node on the explicit path receives an RTM packet and records the time 879 at which it receives that packet at its ingress interface as well as 880 the time at which it transmits that packet from its egress interface. 881 These actions should be done as close to the physical layer as 882 possible at the same point of packet processing striving to avoid 883 introducing the appearance of jitter in propagation delay whereas it 884 should be accounted as residence time. The RTM-capable node 885 determines the difference between those two times; for one-step 886 operation, this difference is determined just prior to or while 887 sending the packet, and the RTM-capable egress interface adds it to 888 the value in the Scratch Pad field of the message in progress. Note, 889 for the purpose of calculating a residence time, a common free 890 running clock synchronizing all the involved interfaces may be 891 sufficient, as, for example, 4.6 ppm accuracy leads to 4.6 nanosecond 892 error for residence time on the order of 1 millisecond. This may be 893 acceptable for applications where the target accuracy is in the order 894 of hundreds of ns. As an example several applications being 895 considered in the area of wireless applications are satisfied with an 896 accuracy of 1.5 microseconds [ITU-T.G.8271]. 898 For two-step operation, the difference between packet arrival time 899 (at an ingress interface) and subsequent departure time (from an 900 egress interface) is determined at some later time prior to sending a 901 subsequent follow-up message, so that this value can be used to 902 update the correctionField in the follow-up message. 904 See Section 2.1 for further details on the difference between one- 905 step and two-step operation. 907 The last RTM-capable node on the LSP MAY then use the value in the 908 Scratch Pad field to perform time correction, if there is no follow- 909 up message. For example, the egress node may be a PTP Boundary Clock 910 synchronized to a Master Clock and will use the value in the Scratch 911 Pad field to update PTP's correctionField. 913 6. Applicable PTP Scenarios 915 This approach can be directly integrated in a PTP network based on 916 the IEEE 1588 delay request-response mechanism. The RTM capable 917 nodes act as end-to-end transparent clocks, and typically boundary 918 clocks, at the edges of the MPLS network, use the value in the 919 Scratch Pad field to update the correctionField of the corresponding 920 PTP event packet prior to performing the usual PTP processing. 922 7. IANA Considerations 924 7.1. New RTM G-ACh 926 IANA is requested to reserve a new G-ACh as follows: 928 +-------+----------------------------+---------------+ 929 | Value | Description | Reference | 930 +-------+----------------------------+---------------+ 931 | TBA1 | Residence Time Measurement | This document | 932 +-------+----------------------------+---------------+ 934 Table 1: New Residence Time Measurement 936 7.2. New RTM TLV Registry 938 IANA is requested to create sub-registry in Generic Associated 939 Channel (G-ACh) Parameters Registry called "MPLS RTM TLV Registry". 940 All code points in the range 0 through 127 in this registry shall be 941 allocated according to the "IETF Review" procedure as specified in 942 [RFC5226] . Code points in the range 128 through 191 in this registry 943 shall be allocated according to the "First Come First Served" 944 procedure as specified in [RFC5226]. This document defines the 945 following new values RTM TLV type s: 947 +-----------+-------------------------------+---------------+ 948 | Value | Description | Reference | 949 +-----------+-------------------------------+---------------+ 950 | 0 | Reserved | This document | 951 | 1 | No payload | This document | 952 | 2 | PTPv2, Ethernet encapsulation | This document | 953 | 3 | PTPv2, IPv4 Encapsulation | This document | 954 | 4 | PTPv2, IPv6 Encapsulation | This document | 955 | 5 | NTP | This document | 956 | 6-127 | Unassigned | | 957 | 128 - 191 | Unassigned | | 958 | 192 - 254 | Private Use | This document | 959 | 255 | Reserved | This document | 960 +-----------+-------------------------------+---------------+ 962 Table 2: RTM TLV Type 964 7.3. New RTM Sub-TLV Registry 966 IANA is requested to create sub-registry in MPLS RTM TLV Registry, 967 requested in Section 7.2, called "MPLS RTM Sub-TLV Registry". All 968 code points in the range 0 through 127 in this registry shall be 969 allocated according to the "IETF Review" procedure as specified in 970 [RFC5226]. Code points in the range 128 through 191 in this registry 971 shall be allocated according to the "First Come First Served" 972 procedure as specified in [RFC5226]. This document defines the 973 following new values RTM sub-TLV types: 975 +-----------+-------------+---------------+ 976 | Value | Description | Reference | 977 +-----------+-------------+---------------+ 978 | 0 | Reserved | This document | 979 | 1 | PTP | This document | 980 | 2-127 | Unassigned | | 981 | 128 - 191 | Unassigned | | 982 | 192 - 254 | Private Use | This document | 983 | 255 | Reserved | This document | 984 +-----------+-------------+---------------+ 986 Table 3: RTM Sub-TLV Type 988 7.4. RTM Capability sub-TLV in OSPFv2 990 IANA is requested to assign a new type for RTM Capability sub-TLV 991 from OSPFv2 Extended Link TLV Sub-TLVs registry as follows: 993 +-------+----------------+---------------+ 994 | Value | Description | Reference | 995 +-------+----------------+---------------+ 996 | TBA2 | RTM Capability | This document | 997 +-------+----------------+---------------+ 999 Table 4: RTM Capability sub-TLV 1001 7.5. IS-IS RTM Capability sub-TLV 1003 IANA is requested to assign a new Type for RTM capability sub-TLV 1004 from the Sub-TLVs for TLVs 22, 23, 141, 222, and 223 registry as 1005 follows: 1007 +------+----------------+----+----+-----+-----+-----+---------------+ 1008 | Type | Description | 22 | 23 | 141 | 222 | 223 | Reference | 1009 +------+----------------+----+----+-----+-----+-----+---------------+ 1010 | TBA3 | RTM Capability | y | y | n | y | y | This document | 1011 +------+----------------+----+----+-----+-----+-----+---------------+ 1013 Table 5: IS-IS RTM Capability sub-TLV Registry Description 1015 7.6. RTM Capability TLV in BGP-LS 1017 IANA is requested to assign a new code point for RTM Capability TLV 1018 from BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and 1019 Attribute TLVs sub-registry in its Border Gateway Protocol - Link 1020 State (BGP-LS) Parameters registry as follows: 1022 +---------------+----------------+------------------+---------------+ 1023 | TLV Code | Description | IS-IS TLV/Sub- | Reference | 1024 | Point | | TLV | | 1025 +---------------+----------------+------------------+---------------+ 1026 | TBA9 | RTM Capability | 22/TBA3 | This document | 1027 +---------------+----------------+------------------+---------------+ 1029 Table 6: RTM Capability TLV in BGP-LS 1031 7.7. RTM_SET Sub-object RSVP Type and sub-TLVs 1033 IANA is requested to assign a new Type for RTM_SET sub-object from 1034 Attributes TLV Space sub-registry as follows: 1036 +-----+------------+-----------+---------------+---------+----------+ 1037 | Typ | Name | Allowed | Allowed on | Allowed | Referenc | 1038 | e | | on LSP_A | LSP_REQUIRED_ | on LSP | e | 1039 | | | TTRIBUTES | ATTRIBUTES | Hop Att | | 1040 | | | | | ributes | | 1041 +-----+------------+-----------+---------------+---------+----------+ 1042 | TBA | RTM_SET | Yes | No | No | This | 1043 | 4 | sub-object | | | | document | 1044 +-----+------------+-----------+---------------+---------+----------+ 1046 Table 7: RTM_SET Sub-object Type 1048 IANA requested to create new sub-registry for sub-TLV types of 1049 RTM_SET sub-object. All code points in the range 0 through 127 in 1050 this registry shall be allocated according to the "IETF Review" 1051 procedure as specified in [RFC5226] . Code points in the range 128 1052 through 191 in this registry shall be allocated according to the 1053 "First Come First Served" procedure as specified in [RFC5226]. This 1054 document defines the following new values of RTM_SET object sub- 1055 object types: 1057 +-----------+----------------------+---------------+ 1058 | Value | Description | Reference | 1059 +-----------+----------------------+---------------+ 1060 | 0 | Reserved | This document | 1061 | 1 | IPv4 address | This document | 1062 | 2 | IPv6 address | This document | 1063 | 3 | Unnumbered interface | This document | 1064 | 4-127 | Unassigned | | 1065 | 128 - 191 | Unassigned | | 1066 | 192 - 254 | Private Use | This document | 1067 | 255 | Reserved | This document | 1068 +-----------+----------------------+---------------+ 1070 Table 8: RTM_SET object sub-object types 1072 7.8. RTM_SET Attribute Flag 1074 IANA is requested to assign new flag from Attribute Flags registry 1075 +-----+--------+-----------+------------+-----+-----+---------------+ 1076 | Bit | Name | Attribute | Attribute | RRO | ERO | Reference | 1077 | No | | Flags | Flags Resv | | | | 1078 | | | Path | | | | | 1079 +-----+--------+-----------+------------+-----+-----+---------------+ 1080 | TBA | RTM_SE | Yes | Yes | No | No | This document | 1081 | 5 | T | | | | | | 1082 +-----+--------+-----------+------------+-----+-----+---------------+ 1084 Table 9: RTM_SET Attribute Flag 1086 7.9. New Error Codes 1088 IANA is requested to assign new Error Codes from Error Codes and 1089 Globally-Defined Error Value Sub-Codes registry 1091 +------------+--------------------+---------------+ 1092 | Error Code | Meaning | Reference | 1093 +------------+--------------------+---------------+ 1094 | TBA6 | Duplicate TLV | This document | 1095 | TBA7 | Duplicate sub-TLV | This document | 1096 | TBA8 | RTM_SET TLV Absent | This document | 1097 +------------+--------------------+---------------+ 1099 Table 10: New Error Codes 1101 8. Security Considerations 1103 Routers that support Residence Time Measurement are subject to the 1104 same security considerations as defined in [RFC4385] and [RFC5085] . 1106 In addition - particularly as applied to use related to PTP - there 1107 is a presumed trust model that depends on the existence of a trusted 1108 relationship of at least all PTP-aware nodes on the path traversed by 1109 PTP messages. This is necessary as these nodes are expected to 1110 correctly modify specific content of the data in PTP messages and 1111 proper operation of the protocol depends on this ability. In 1112 practice, this means that those portions of messages cannot be 1113 covered by either confidentiality or integrity protection. Though 1114 there are methods that make it possible in theory to provide either 1115 or both such protections and still allow for intermediate nodes to 1116 make detectable but authenticated modifications, such methods do not 1117 seem practical at present, particularly for timing protocols that are 1118 sensitive to latency and/or jitter. 1120 The ability for potentially authenticating and/or encrypting RTM and 1121 PTP data for scenarios both with and without participation of 1122 intermediate RTM/PTP-capable nodes is for further study. 1124 While it is possible for a supposed compromised node to intercept and 1125 modify the G-ACh content, this is an issue that exists for nodes in 1126 general - for any and all data that may be carried over an LSP - and 1127 is therefore the basis for an additional presumed trust model 1128 associated with existing LSPs and nodes. 1130 Security requirements of time protocols are provided in RFC 7384 1131 [RFC7384]. 1133 9. Acknowledgments 1135 Authors want to thank Loa Andersson, Lou Berger, Acee Lindem, Les 1136 Ginsberg, and Uma Chunduri for their thorough reviews, thoughtful 1137 comments and, most of all, patience. 1139 10. References 1141 10.1. Normative References 1143 [IEEE.1588.2008] 1144 "Standard for a Precision Clock Synchronization Protocol 1145 for Networked Measurement and Control Systems", 1146 IEEE Standard 1588, July 2008. 1148 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1149 Requirement Levels", BCP 14, RFC 2119, 1150 DOI 10.17487/RFC2119, March 1997, 1151 . 1153 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1154 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1155 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1156 . 1158 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1159 in Resource ReSerVation Protocol - Traffic Engineering 1160 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 1161 . 1163 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 1164 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 1165 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 1166 February 2006, . 1168 [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual 1169 Circuit Connectivity Verification (VCCV): A Control 1170 Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, 1171 December 2007, . 1173 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. 1174 Ayyangarps, "Encoding of Attributes for MPLS LSP 1175 Establishment Using Resource Reservation Protocol Traffic 1176 Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, 1177 February 2009, . 1179 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 1180 "MPLS Generic Associated Channel", RFC 5586, 1181 DOI 10.17487/RFC5586, June 2009, 1182 . 1184 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1185 "Network Time Protocol Version 4: Protocol and Algorithms 1186 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1187 . 1189 [RFC6423] Li, H., Martini, L., He, J., and F. Huang, "Using the 1190 Generic Associated Channel Label for Pseudowire in the 1191 MPLS Transport Profile (MPLS-TP)", RFC 6423, 1192 DOI 10.17487/RFC6423, November 2011, 1193 . 1195 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1196 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1197 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 1198 2015, . 1200 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1201 S. Ray, "North-Bound Distribution of Link-State and 1202 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1203 DOI 10.17487/RFC7752, March 2016, 1204 . 1206 10.2. Informative References 1208 [I-D.ietf-ospf-ospfv3-lsa-extend] 1209 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 1210 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-13 1211 (work in progress), October 2016. 1213 [I-D.ietf-tictoc-1588overmpls] 1214 Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. 1215 Montini, "Transporting Timing messages over MPLS 1216 Networks", draft-ietf-tictoc-1588overmpls-07 (work in 1217 progress), October 2015. 1219 [ITU-T.G.8271] 1220 "Packet over Transport aspects - Synchronization, quality 1221 and availability targets", ITU-T Recomendation 1222 G.8271/Y.1366, July 2016. 1224 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 1225 in Support of Generalized Multi-Protocol Label Switching 1226 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 1227 . 1229 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1230 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1231 DOI 10.17487/RFC5226, May 2008, 1232 . 1234 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1235 Measurement for MPLS Networks", RFC 6374, 1236 DOI 10.17487/RFC6374, September 2011, 1237 . 1239 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 1240 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 1241 October 2014, . 1243 Authors' Addresses 1245 Greg Mirsky 1246 ZTE Corp. 1248 Email: gregimirsky@gmail.com 1250 Stefano Ruffini 1251 Ericsson 1253 Email: stefano.ruffini@ericsson.com 1255 Eric Gray 1256 Ericsson 1258 Email: eric.gray@ericsson.com 1260 John Drake 1261 Juniper Networks 1263 Email: jdrake@juniper.net 1264 Stewart Bryant 1265 Huawei 1267 Email: stewart.bryant@gmail.com 1269 Alexander Vainshtein 1270 ECI Telecom 1272 Email: Alexander.Vainshtein@ecitele.com; Vainshtein.alex@gmail.com