idnits 2.17.1 draft-ietf-mpls-residence-time-04.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 944 has weird spacing: '...Allowed on ...' -- The document date (February 18, 2016) is 2961 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) == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-lsa-extend-09 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.1588.2008' -- 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 S. Ruffini 4 Intended status: Standards Track E. Gray 5 Expires: August 21, 2016 Ericsson 6 J. Drake 7 Juniper Networks 8 S. Bryant 9 Cisco Systems 10 A. Vainshtein 11 ECI Telecom 12 February 18, 2016 14 Residence Time Measurement in MPLS network 15 draft-ietf-mpls-residence-time-04 17 Abstract 19 This document specifies G-ACh based Residence Time Measurement and 20 how it can be used by time synchronization protocols being 21 transported over MPLS domain. 23 Residence time is the variable part of propagation delay of timing 24 and synchronization messages and knowing what this delay is for each 25 message allows for a more accurate determination of the delay to be 26 taken into account in applying the value included in a PTP event 27 message. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 21, 2016. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Conventions used in this document . . . . . . . . . . . . 3 65 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 66 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4 67 2. Residence Time Measurement . . . . . . . . . . . . . . . . . 4 68 3. G-ACh for Residence Time Measurement . . . . . . . . . . . . 5 69 3.1. PTP Packet Sub-TLV . . . . . . . . . . . . . . . . . . . 6 70 4. Control Plane Theory of Operation . . . . . . . . . . . . . . 7 71 4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 7 72 4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 8 73 4.3. RTM Capability Advertisement in OSPFv2 . . . . . . . . . 9 74 4.4. RTM Capability Advertisement in OSPFv3 . . . . . . . . . 9 75 4.5. RTM Capability Advertisement in IS-IS . . . . . . . . . . 9 76 4.6. RSVP-TE Control Plane Operation to Support RTM . . . . . 10 77 4.7. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . . . 11 78 4.7.1. RTM_SET Sub-TLVs . . . . . . . . . . . . . . . . . . 12 79 5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 15 80 6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 15 81 7. One-step Clock and Two-step Clock Modes . . . . . . . . . . . 16 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 83 8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 18 84 8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 18 85 8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 19 86 8.4. New Error Codes . . . . . . . . . . . . . . . . . . . . . 19 87 8.5. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 20 88 8.6. RTM Capability sub-TLV in OSPFv3 . . . . . . . . . . . . 20 89 8.7. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 20 90 8.8. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 21 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 95 11.2. Informative References . . . . . . . . . . . . . . . . . 24 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 98 1. Introduction 100 Time synchronization protocols, Network Time Protocol version 4 101 (NTPv4) [RFC5905] and Precision Time Protocol (PTP) Version 2 102 [IEEE.1588.2008] can be used to synchronize clocks across network 103 domain. Measurement of the time a PTP event message spends 104 traversing a node (using precise times of receipt at an ingress 105 interface and transmission at an egress interface), called Residence 106 Time, is one of on-path support types defined in [IEEE.1588.2008] and 107 can be used to improve the accuracy of clock synchronization. This 108 document defines new Generalized Associated Channel (G-ACh) that can 109 be used in Multi-Protocol Label Switching (MPLS) network to measure 110 Residence Time over Label Switched Path (LSP). Mechanisms for 111 transport of time synchronization protocol packets over MPLS are out 112 of scope in this document. 114 Though it is possible to use RTM over LSPs instantiated using LDP 115 such scenarios are outside the scope of this document. The scope of 116 this document is on Traffic Engineered LSPs because the LSP's path 117 can be either explicitly specified or, at the minimum, can be 118 determined when signaling. Such LSP can be instantiated either by 119 using RSVP-TE [RFC3209] or Path Computation Element [RFC4655]. The 120 PCE-based scenario is for further study and is outside the scope of 121 this document. 123 [I-D.ietf-tictoc-1588overmpls] describes alternative method of on- 124 path support for timing distribution protocols. Comparison of 125 proposed solutions is outside the scope of this document. 127 1.1. Conventions used in this document 129 1.1.1. Terminology 131 MPLS: Multi-Protocol Label Switching 133 ACH: Associated Channel 135 TTL: Time-to-Live 137 G-ACh: Generic Associated Channel 139 GAL: Generic Associated Channel Label 141 NTP: Network Time Protocol 142 ppm: parts per million 144 PTP: Precision Time Protocol 146 LSP: Label Switched Path 148 LSR: Label Switching Router 150 OAM: Operations, Administration, and Maintenance 152 RRO: Record Route Object 154 RTM: Residence Time Measurement 156 IGP: Internal Gateway Protocol 158 1.1.2. Requirements Language 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in 163 [RFC2119]. 165 2. Residence Time Measurement 167 Packet Loss and Delay Measurement for MPLS Networks [RFC6374] can be 168 used to measure one-way or two-way end-to-end propagation delay over 169 LSP or PW. But these metrics are insufficient for use in some 170 applications, for example, time synchronization across a network as 171 defined in the Precision Time Protocol (PTP). PTPv2 [IEEE.1588.2008] 172 uses "residence time", the time it takes for a PTPv2 event packet to 173 transit a node. Residence times are accumulated in the 174 correctionField of the PTP event messages, as defined in 175 [IEEE.1588.2008], or of the associated follow-up messages (or 176 Delay_Resp message associated with the Delay_Req message) in case of 177 two-step clocks (detailed discussion in Section 7). The residence 178 time values are specific to each output PTP port and message. 180 IEEE 1588 uses this residence time to correct the propagated time, 181 effectively making these nodes transparent. 183 This document proposes mechanism to accumulate packet residence time 184 from all LSRs that support the mechanism across a particular LSP. 185 The values accumulated in scratchpad fields of MPLS RTM messages can 186 be used by the last RTM-capable LSR on an LSP to update the 187 correctionField of the corresponding PTP event packet prior to 188 performing the usual PTP processing. 190 3. G-ACh for Residence Time Measurement 192 RFC 5586 [RFC5586] and RFC 6423 [RFC6423] extended applicability of 193 PW Associated Channel (ACH) [RFC5085] to LSPs. G-ACh provides a 194 mechanism to transport OAM and other control messages. Processing by 195 arbitrary transit LSRs can be triggered through controlled use of the 196 Time-to-Live (TTL) value. In a way that is analogous to PTP 197 operations, the packet residence time can be handled by the RTM 198 capable node either as "one-step clock" or as a "two-step clock". 200 The packet format for Residence Time Measurement (RTM) is presented 201 in Figure 1 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 |0 0 0 1|Version| Reserved | RTM Channel | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | | 209 | Scratch Pad | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Type | Length | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Value | 214 ~ ~ 215 | | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 Figure 1: RTM G-ACh packet format for Residence Time Measurement 220 o First four octets are defined as G-ACh Header in [RFC5586] 222 o The Version field is set to 0, as defined in RFC 4385 [RFC4385]. 224 o The Reserved field MUST be set to 0 on transmit and ignored on 225 receipt. 227 o The RTM G-ACh field, value (TBA1) to be allocated by IANA, 228 identifies the packet as such. 230 o The Scratch Pad field is 8 octets in length. The first RTM- 231 capable LSR MUST initialize the Scratch Pad field, it SHOULD set 232 it to zero value. The Scratch Pad is used to accumulate the 233 residence time spent in each RTM capable LSR transited by the 234 packet on its path from ingress LSR to egress LSR. Its format is 235 IEEE double precision and its units are nanoseconds. Note: 236 depending on one-step or two-step operation (Section 7), the 237 residence time might be related to the same packet carried in the 238 Value field or to a packet carried in a different RTM packet. 240 o The Type field identifies the type of Value that the TLV carries. 241 IANA will be asked to create a sub-registry in Generic Associated 242 Channel (G-ACh) Parameters Registry called "MPLS RTM TLV 243 Registry". 245 o The Length field contains the number of octets of the Value field. 247 o The optional Value field may be used to carry a packet of a given 248 time synchronization protocol. If packet data is carried in the 249 RTM message, then this is identified by Type accordingly. The 250 data MAY be NTP [RFC5905] or PTP [IEEE.1588.2008]. It is 251 important to note that the packet may be authenticated or 252 encrypted and carried over MPLS LSP edge to edge unchanged while 253 residence time being accumulated in the Scratch Pad field. Sub- 254 TLVs MAY be included in the Value field. 256 o The TLV MUST be included in the RTM message, even if the length of 257 the Value field is zero. 259 3.1. PTP Packet Sub-TLV 261 Figure 2 presents format of a PTP sub-TLV that MUST be precede every 262 PTP packet carried in RTM TLV. 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Type | Length | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Flags |PTPType| 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Port ID | 272 | | 273 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | | Sequence ID | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Figure 2: PTP Sub-TLV format 279 where Flags field has format 280 0 1 2 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 |S| Reserved | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 Figure 3: Flags field format of PTP Packet Sub-TLV 288 o The Type field identifies PTP sub-TLV defined in the Table 19 289 Values of messageType field in [IEEE.1588.2008]. 291 o The Length field of the PTP sub-TLV contains the number of octets 292 of the Value field and MUST be 20. 294 o The Flags field currently defines one bit, the S-bit, that defines 295 whether or not the current message has been processed by a 2-step 296 node, where the flag is cleared if the message has been handled 297 exclusively by 1-step nodes and there is no follow-up message, and 298 set if there has been at least one 2-step node and a follow-up 299 message is forthcoming. 301 o The PTPType indicates the type of PTP packet carried in the TLV. 302 PTPType is the messageType field of the PTPv2 packet whose values 303 are defined in the Table 19 [IEEE.1588.2008]. 305 o The 10 octets long Port ID field contains the identity of the 306 source port. 308 o The Sequence ID is the sequence ID of the PTP message carried in 309 the Value field of the message. 311 4. Control Plane Theory of Operation 313 The operation of RTM depends upon TTL expiry to deliver an RTM packet 314 from one RTM capable interface to the next along the path from 315 ingress LSR to egress LSR. This means that an LSR with RTM capable 316 interfaces MUST be able to compute a TTL which will cause the expiry 317 of an RTM packet at the next LSR with RTM capable interfaces. 319 4.1. RTM Capability 321 Note that RTM capability of a node is with respect to the pair of 322 interfaces that will be used to forward an RTM packet. In general, 323 the ingress interface of this pair must be able to capture the 324 arrival time of the packet and encode it in some way such that this 325 information will be available to the egress interface. 327 The supported modes (1-step verses 2-step) of any pair of interfaces 328 is then determined by the capability of the egress interface. In 329 both cases, the egress interface implementation MUST be able to 330 determine the precise departure time of the same packet and determine 331 from this, and the arrival time information from the corresponding 332 ingress interface, the difference representing the residence time for 333 the packet. 335 An interface with the ability to do this and update the associated 336 ScratchPad in real-time (i.e. while the packet is being forwarded) is 337 said to be 1-step capable. 339 Hence while both ingress and egress interfaces are required to 340 support RTM, for the pair to be RTM-capable, it is the egress 341 interface that determines whether or not the node is 1-step or 2-step 342 capable with respect to the interface-pair. 344 The RTM capability used in the sub-TLV shown in Figure 4 is thus 345 associated with the egress port of the node making the advertisement, 346 while the ability of any pair of interfaces that includes this egress 347 interface to support any mode of RTM depends on the ability of that 348 interface to record packet arrival time in some way that can be 349 conveyed to and used by that egress interface. 351 When an LSR uses an IGP to carry the RTM capability sub-TLV, the sub- 352 TLV MUST reflect the RTM capability (1-step or 2-step) associated 353 with egress interfaces and MUST NOT propagate this sub-TLV in IGP 354 LSAs sent from a router which describe a particular interface that 355 does not support the same capability for RTM messages it receives. 357 4.2. RTM Capability Sub-TLV 359 The format for the RTM Capabilities sub-TLV is presented in Figure 4 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Type | Length | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | RTM | Reserved | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 Figure 4: RTM Capability sub-TLV 371 o Type values TBA2 and TBA3 will be assigned by IANA from 372 appropriate registries for OSPFv2 and OSPFv3 respectively. 374 o Length MUST be set to 4. 376 o RTM (capability) - is a three-bit long bit-map field with values 377 defined as follows: 379 * 0b001 - one-step RTM supported; 381 * 0b010 - two-step RTM supported; 383 * 0b100 - reserved. 385 o Reserved field must be set to all zeroes on transmit and ignored 386 on receipt. 388 [RFC4202] explains that the Interface Switching Capability Descriptor 389 describes switching capability of an interface. For bi-directional 390 links, the switching capabilities of an interface are defined to be 391 the same in either direction. I.e., for data entering the node 392 through that interface and for data leaving the node through that 393 interface". That principle SHOULD be applied when a node advertises 394 RTM Capability. 396 A node that supports RTM MUST be able to act in two-step mode and MAY 397 also support one-step RTM mode. Detailed discussion of one-step and 398 two-step RTM modes in Section 7. 400 4.3. RTM Capability Advertisement in OSPFv2 402 The capability to support RTM on a particular link advertised in the 403 OSPFv2 Extended Link Opaque LSA described in Section 3 [RFC7684] as 404 RTM Capability sub-TLV, presented in Figure 4, of the OSPFv2 Extended 405 Link TLV. 407 Type value will be assigned by IANA from the OSPF Extended Link TLV 408 Sub-TLVs registry that will be created per [RFC7684] request. 410 4.4. RTM Capability Advertisement in OSPFv3 412 The capability to support RTM on a particular link in OSPFv3 can be 413 advertised by including an RTM Capability sub-TLV defined in 414 Section 4.3 in the following TLVs defined in 415 [I-D.ietf-ospf-ospfv3-lsa-extend] Intra-Area-Prefix TLV, IPv6 Link- 416 Local Address TLV, or IPv4 Link-Local Address TLV when these are 417 included in E-Link-LSA. 419 4.5. RTM Capability Advertisement in IS-IS 421 The RTM capability logically belongs to a group of parameters 422 characterized as "generic information not directly related to the 423 operation of the IS-IS protocol" [RFC6823]. Hence the capability to 424 process RTM messages can be advertised by including RTM Capability 425 sub-TLV in GENINFO TLV [RFC6823]. 427 With respect to the Flags field of the GENINFO TLV: 429 o The S bit MUST be cleared to prevent the RTM Capability sub-TLV 430 from leaking between levels. 432 o The D bit of the Flags field MUST be cleared as required by 433 [RFC6823]. 435 o The I bit and the V bit MUST be set accordingly depending on 436 whether RTM capability being advertised for IPv4 or IPv6 interface 437 of the node. 439 Application ID (TBA4) will be assigned from the Application 440 Identifiers for TLV 251 IANA registry. The RTM Capability sub-TLV, 441 presented in Figure 4, MUST be included in GENINFO TLV in Application 442 Specific Information. 444 4.6. RSVP-TE Control Plane Operation to Support RTM 446 Throughout this document we refer to an LSR as RTM capable LSR when 447 at least one of its interfaces is RTM capable. Figure 5 provides an 448 example of relationship between roles a network element may have in 449 PTP over MPLS scenario and RTM capability: 451 ----- ----- ----- ----- ----- ----- ----- 452 | A |-----| B |-----| C |-----| D |-----| E |-----| F |-----| G | 453 ----- ----- ----- ----- ----- ----- ----- 455 Figure 5: RTM capable roles 457 o A is a Boundary Clock with its egress port in Master state. Node 458 A transmits PTP messages; 460 o B is the ingress LER for the MPLS LSP and is not RTM capable; 462 o C is the first RTM capable LSR; it initializes the RTM Scratch Pad 463 field and encapsulates PTP messages in the RTM ACH; the 464 transmitted Scratch Pad information includes the residence time 465 measured by C; 467 o D is a transit LSR that is not RTM capable; it passes along the 468 RTM ACH encapsulated PTP message unmodified; 470 o E is the last RTM capable LSR; it updates the Correction field of 471 the PTP message with the value in the Scratch Pad field of the RTM 472 ACH, and removes the RTM ACH encapsulation; 474 o F is the egress LER for the MPLS LSP and is not RTM capable; 476 o G is a Boundary Clock with its ingress port in Slave state. Node 477 G receives PTP messages. 479 An ingress LSR that is configured to perform RTM along a path through 480 an MPLS network to an egress LSR verifies that the selected egress 481 LSR has an interface that supports RTM via the egress LSR's 482 advertisement of the RTM Capability sub-TLV. In the Path message 483 that the ingress LSR uses to instantiate the LSP to that egress LSR 484 it places initialized Record Route Object (RRO) [RFC3209] and 485 LSP_ATTRIBUTES Object [RFC5420] with RTM_SET TLV [Section 4.7], also 486 referred as RTM_SET in this document, which indicates to the egress 487 LSR that RTM is requested for this LSP. RTM_SET SHOULD NOT be 488 included in the LSP_REQUIRED_ATTRIBUTES object [RFC5420] , unless it 489 is known that all LSRs support RTM_SET TLV, because an LSR that does 490 not recognize RTM_SET would reject the Path message. 492 In the Resv message that the egress LSR sends in response to the 493 received Path message, it includes initialized RRO and RTM_SET TLV in 494 LSP_ATTRIBUTES object. The RTM_SET contains an ordered list, from 495 egress LSR to ingress LSR, of the RTM capable LSRs along the LSP's 496 path. Each such LSR will use the ID of the first LSR in the RTM_SET 497 in conjunction with the RRO to compute the hop count to its 498 downstream LSR with reachable RTM capable interface. The calculated 499 value is used by the LSR as TTL value in outgoing label to reach the 500 next RTM capable LSR on the LSP. It will also insert its ID at the 501 beginning of the RTM_SET before forwarding the Resv message upstream. 503 After the ingress LSR receives the Resv, it MAY begin sending RTM 504 packets to the first RTM capable LSR on the LSP's path. Each RTM 505 packet has its Scratch Pad field initialized and its TTL set to 506 expire on that first subsequent RTM capable LSR. 508 It should be noted that RTM can also be used for LSPs instantiated 509 using [RFC3209] in an environment in which all interfaces in an IGP 510 support RTM. In this case the RTM_SET TLV and LSP_ATTRIBUTES Object 511 MAY be omitted. 513 4.7. RTM_SET TLV 515 RTM capable interfaces can be recorded via RTM_SET TLV. The RTM_SET 516 sub-object format is of generic Type, Length, Value (TLV), presented 517 in Figure 6 518 0 1 2 3 519 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 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Type | Length | Reserved | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 ~ Value ~ 524 | | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 Figure 6: RTM_SET TLV format 529 Type value (TBA5) will be assigned by IANA from its Attributes TLV 530 Space sub-registry. 532 The Length contains the total length of the sub-object in bytes, 533 including the Type and Length fields. 535 Reserved field must be zeroed on transmit and ignored on receipt. 537 The content of an RTM_SET TLV is a series of variable-length sub- 538 TLVs. The sub-TLVs are defined in Section 4.7.1 below. 540 Only a single RTM_SET can be present in the LSP_ATTRIBUTES object. 541 If more than one RTM_SET TLV is found in the LSP_ATTRIBUTES object 542 the LSP setup MUST fail with generation of the PathErr message with 543 Error Code Duplicate TLV Section 8.4 and Error Value contains Type 544 value in its 8 least significant bits. 546 4.7.1. RTM_SET Sub-TLVs 548 The RTM Set sub-object contains an ordered list, from egress LSR to 549 ingress LSR, of the RTM capable LSRs along the LSP's path. 551 The contents of a RTM_SET sub-object are a series of variable-length 552 sub-TLVs. Each sub-TLV has its own Length field. The Length 553 contains the total length of the sub-TLV in bytes, including the Type 554 and Length fields. The Length MUST always be a multiple of 4, and at 555 least 8 (smallest IPv4 sub-object). 557 Sub-TLVs are organized as a last-in-first-out stack. The first -out 558 sub-TLV relative to the beginning of RTM_SET TLV is considered the 559 top. The last-out sub-TLV is considered the bottom. When a new sub- 560 TLV is added, it is always added to the top. Only a single RTM_SET 561 sub-TLV with the given Value field MUST be present in the RTM_SET 562 TLV. If more than one sub-TLV is found the LSP setup MUST fail with 563 the generation of a PathErr message with the Error Code "Duplicate 564 sub-TLV" Section 8.4 and Error Value contains 16-bit value composed 565 of (Type of TLV, Type of sub-TLV). 567 Three kinds of sub-TLVs for RTM_SET are currently defined. 569 4.7.1.1. IPv4 Sub-TLV 571 0 1 2 3 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 6 7 8 9 0 1 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Type | Length | Reserved | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | IPv4 address | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 Figure 7: IPv4 sub-TLV format 581 Type 583 0x01 IPv4 address 585 Length 587 The Length contains the total length of the sub-TLV in bytes, 588 including the Type and Length fields. The Length is always 8. 590 IPv4 address 592 A 32-bit unicast host address. 594 Reserved 596 Zeroed on transmission and ignored on receipt. 598 4.7.1.2. IPv6 Sub-TLV 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Type | Length | Reserved | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | | 606 | IPv6 address | 607 | | 608 | | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 Figure 8: IPv6 sub-TLV format 613 Type 614 0x02 IPv6 address 616 Length 618 The Length contains the total length of the sub-TLV in bytes, 619 including the Type and Length fields. The Length is always 20. 621 IPv6 address 623 A 128-bit unicast host address. 625 Reserved 627 Zeroed on transmission and ignored on receipt. 629 4.7.1.3. Unnumbered Interface Sub-TLV 631 0 1 2 3 632 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 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Type | Length | Reserved | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Router ID | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Interface ID | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 Figure 9: IPv4 sub-TLV format 643 Type 645 0x03 Unnumbered interface 647 Length 649 The Length contains the total length of the sub-TLV in bytes, 650 including the Type and Length fields. The Length is always 12. 652 Router ID 654 The Router ID interpreted as discussed in the Section 2 of RFC 655 3447 [RFC3477]. 657 Interface ID 659 The identifier assigned to the link by the LSR specified by the 660 Router ID. 662 Reserved 664 Zeroed on transmission and ignored on receipt. 666 5. Data Plane Theory of Operation 668 After instantiating an LSP for a path using RSVP-TE [RFC3209] as 669 described in Section 4.6 or as described in the second paragraph of 670 Section 4 and in Section 4.6, ingress LSR MAY begin sending RTM 671 packets to the first downstream RTM capable LSR on that path. Each 672 RTM packet has its Scratch Pad field initialized and its TTL set to 673 expire on the next downstream RTM-capable LSR. Each RTM-capable LSR 674 on the explicit path receives an RTM packet and records the time at 675 which it receives that packet at its ingress interface as well as the 676 time at which it transmits that packet from its egress interface; 677 this should be done as close to the physical layer as possible to 678 ensure precise accuracy in time determination. The RTM-capable LSR 679 determines the difference between those two times; for 1-step 680 operation, this difference is determined just prior to or while 681 sending the packet, and the RTM-capable egress interface adds it to 682 the value in the Scratch Pad field of the message in progress. Note, 683 for the purpose of calculating a residence time, a common free 684 running clock synchronizing all the involved interfaces may be 685 sufficient, as, for example, 4.6 ppm accuracy leads to 4.6 nanosecond 686 error for residence time on the order of 1 millisecond. 688 For 2-step operation, the difference between packet arrival time (at 689 an ingress interface) and subsequent departure time (from an egress 690 interface) is determined at some later time prior to sending a 691 subsequent follow-up message, so that this value can be used to 692 update the correctionField in the follow-up message. 694 See Section 7 for further details on the difference between 1-step 695 and 2-step operation. 697 The last RTM-capable LSR on the LSP MAY then use the value in the 698 Scratch Pad field to perform time correction, if there is no follow- 699 up message. For example, the egress LSR may be a PTP Boundary Clock 700 synchronized to a Master Clock and will use the value in the Scratch 701 Pad field to update PTP's correctionField. 703 6. Applicable PTP Scenarios 705 The proposed approach can be directly integrated in a PTP network 706 based on the IEEE 1588 delay reqest-response mechanism. The RTM 707 capable LSR nodes act as end-to-end transparent clocks, and typically 708 boundary clocks, at the edges of the MPLS network, use the value in 709 the Scratch Pad field to update the correctionField of the 710 corresponding PTP event packet prior to performing the usual PTP 711 processing. 713 7. One-step Clock and Two-step Clock Modes 715 One-step mode refers to the mode of operation where an egress 716 interface updates the correctionField value of an original event 717 message. Two-step mode refers to the mode of operation where this 718 update is made in a subsequent follow-up message. 720 Processing of the follow-up message, if present, requires the 721 downstream end-point to wait for the arrival of the follow-up message 722 in order to combine correctionField values from both the original 723 (event) message and the subsequent (follow-up) message. In a similar 724 fashion, each 2-step node needs to wait for the related follow-up 725 message, if there is one, in order to update that follow-up message 726 (as opposed to creating a new one. Hence the first node that uses 727 2-step mode MUST do two things: 729 1. Mark the original event message to indicate that a follow-up 730 message will be forthcoming (this is necessary in order to 732 Let any subsequent 2-step node know that there is already a 733 follow-up message, and 735 Let the end-point know to wait for a follow-up message; 737 2. Create a follow-up message in which to put the RTM determined as 738 an initial correctionField value. 740 IEEE 1588v2 [IEEE.1588.2008] defines this behaviour for PTP messages. 742 Thus, for example, with reference to the PTP protocol, the PTPType 743 field identifies whether the message is a Sync message, Follow_up 744 message, Delay_Req message, or Delay_Resp message. The 10 octet long 745 Port ID field contains the identity of the source port, that is, the 746 specific PTP port of the boundary clock connected to the MPLS 747 network. The Sequence ID is the sequence ID of the PTP message 748 carried in the Value field of the message. 750 PTP messages also include a bit that indicates whether or not a 751 follow-up message will be coming. This bit, once it is set by a 752 2-step mode device, MUST stay set accordingly until the original and 753 follow-up messages are combined by an end-point (such as a Boundary 754 Clock). 756 Thus, an RTM packet, containing residence time information relating 757 to an earlier packet, also contains information identifying that 758 earlier packet. 760 For compatibility with PTP, RTM (when used for PTP packets) must 761 behave in a similar fashion. To do this, a 2-step RTM capable egress 762 interface will need to examine the S-bit in the Flags field of the 763 PTP sub-TLV (for RTM messages that indicate they are for PTP) and - 764 if it is clear (set to zero), it MUST set it and create a follow-up 765 PTP Type RTM message. If the S bit is already set, then the RTM 766 capable node MUST wait for the RTM message with the PTP type of 767 follow-up and matching originator and sequence number to make the 768 corresponding residence time update to the Scratch Pad field. 770 In practice an RTM operating according to two-step clock behaves like 771 a two-steps transparent clock. 773 A 1-step capable RTM node MAY elect to operate in either 1-step mode 774 (by making an update to the Scratch Pad field of the RTM message 775 containing the PTP even message), or in 2-step mode (by making an 776 update to the Scratch Pad of a follow-up message when its presence is 777 indicated), but MUST NOT do both. 779 Two main subcases can be identified for an RTM node operating as a 780 two-step clock: 782 A) If any of the previous RTM capable node or the previous PTP clock 783 (e.g. the BC connected to the first LSR), is a two-step clock, the 784 residence time is added to the RTM packet that has been created to 785 include the associated PTP packet (i.e. follow-up message in the 786 downstream direction), if the local RTM-capable LSR is also operating 787 as a two-step clock. This RTM packet carries the related accumulated 788 residence time and the appropriate values of the Sequence Id and Port 789 Id (the same identifiers carried in the packet processed) and the 790 Two-step Flag set to 1. 792 Note that the fact that an upstream RTM-capable node operating in the 793 two-step mode has created a follow-up message does not require any 794 subsequent RTM capable LSR to also operate in the 2-step mode, as 795 long as that RTM-capable LSR forwards the follow-up message on the 796 same LSP on which it forwards the corresponding previous message. 798 A one-step capable RTM node MAY elect to update the RTM follow-up 799 message as if it were operating in two-step mode, however, it MUST 800 NOT update both messages. 802 A PTP event packet (sync) is carried in the RTM packet in order for 803 an RTM node to identify that residence time measurement must be 804 performed on that specific packet. 806 To handle the residence time of the Delay request message on the 807 upstream direction, an RTM packet must be created to carry the 808 residence time on the associated downstream Delay Resp message. 810 The last RTM node of the MPLS network in addition to update the 811 correctionField of the associated PTP packet, must also properly 812 handle the two-step flag of the PTP packets. 814 B) When the PTP network connected to the MPLS and RTM node, operates 815 in one-step clock mode, the associated RTM packet must be created by 816 the RTM node itself. The associated RTM packet including the PTP 817 event packet needs now to indicate that a follow up message will be 818 coming. 820 The last RTM node of the LSP, modeif it receives an RTM message with 821 a PTP payload indicating a follow-up message will be forthcoming, 822 must generate a follow-up message and properly set the two-step flag 823 of the PTP packets. 825 8. IANA Considerations 827 8.1. New RTM G-ACh 829 IANA is requested to reserve a new G-ACh as follows: 831 +-------+----------------------------+---------------+ 832 | Value | Description | Reference | 833 +-------+----------------------------+---------------+ 834 | TBA1 | Residence Time Measurement | This document | 835 +-------+----------------------------+---------------+ 837 Table 1: New Residence Time Measurement 839 8.2. New RTM TLV Registry 841 IANA is requested to create sub-registry in Generic Associated 842 Channel (G-ACh) Parameters Registry called "MPLS RTM TLV Registry". 843 All code points in the range 0 through 127 in this registry shall be 844 allocated according to the "IETF Review" procedure as specified in 845 [RFC5226] . Remaining code points are allocated according to the 846 table below. This document defines the following new values RTM TLV 847 type s: 849 +-----------+-------------+-------------------------+ 850 | Value | Description | Reference | 851 +-----------+-------------+-------------------------+ 852 | 0 | Reserved | This document | 853 | 1 | No payload | This document | 854 | 2 | PTPv2 | This document | 855 | 3 | NTP | This document | 856 | 4-127 | Reserved | IETF Consensus | 857 | 128 - 191 | Reserved | First Come First Served | 858 | 192 - 255 | Reserved | Private Use | 859 +-----------+-------------+-------------------------+ 861 Table 2: RTM TLV Type 863 8.3. New RTM Sub-TLV Registry 865 IANA is requested to create sub-registry in MPLS RTM TLV Registry, 866 requested in Section 8.2, called "MPLS RTM Sub-TLV Registry". All 867 code points in the range 0 through 127 in this registry shall be 868 allocated according to the "IETF Review" procedure as specified in 869 [RFC5226] . Remaining code points are allocated according to the 870 table below. This document defines the following new values RTM sub- 871 TLV types: 873 +-----------+-------------+-------------------------+ 874 | Value | Description | Reference | 875 +-----------+-------------+-------------------------+ 876 | 0 | Reserved | This document | 877 | 1 | PTP 2-step | This document | 878 | 2-127 | Reserved | IETF Consensus | 879 | 128 - 191 | Reserved | First Come First Served | 880 | 192 - 255 | Reserved | Private Use | 881 +-----------+-------------+-------------------------+ 883 Table 3: RTM Sub-TLV Type 885 8.4. New Error Codes 887 IANA is requested to assign new Error Codes from Error Codes and 888 Globally-Defined Error Value Sub-Codes registry 889 +------------+-------------------+---------------+ 890 | Error Code | Meaning | Reference | 891 +------------+-------------------+---------------+ 892 | TBA6 | Duplicate TLV | This document | 893 | TBA7 | Duplicate sub-TLV | This document | 894 +------------+-------------------+---------------+ 896 Table 4: New Error Codes 898 8.5. RTM Capability sub-TLV in OSPFv2 900 IANA is requested to assign a new type for RTM Capability sub-TLV 901 from OSPFv2 Extended Link TLV Sub-TLVs registry as follows: 903 +-------+----------------+---------------+ 904 | Value | Description | Reference | 905 +-------+----------------+---------------+ 906 | TBA2 | RTM Capability | This document | 907 +-------+----------------+---------------+ 909 Table 5: RTM Capability sub-TLV 911 8.6. RTM Capability sub-TLV in OSPFv3 913 IANA is requested to assign a new type for RTM Capability sub-TLV 914 from future OSPFv3 Extended-LSA Sub-TLVs registry that would be part 915 of OSPFv3 IANA registry as follows: 917 +-------+----------------+---------------+ 918 | Value | Description | Reference | 919 +-------+----------------+---------------+ 920 | TBA3 | RTM Capability | This document | 921 +-------+----------------+---------------+ 923 Table 6: RTM Capability sub-TLV 925 8.7. IS-IS RTM Application ID 927 IANA is requested to assign a new Application ID for RTM from the 928 Application Identifiers for TLV 251 registry as follows: 930 +-------+-------------+---------------+ 931 | Value | Description | Reference | 932 +-------+-------------+---------------+ 933 | TBA4 | RTM | This document | 934 +-------+-------------+---------------+ 936 Table 7: IS-IS RTM Application ID 938 8.8. RTM_SET Sub-object RSVP Type and sub-TLVs 940 IANA is requested to assign a new Type for RTM_SET sub-object from 941 Attributes TLV Space sub-registry as follows: 943 +-----+------------+-----------+---------------+---------+----------+ 944 | Typ | Name | Allowed | Allowed on | Allowed | Referenc | 945 | e | | on LSP_A | LSP_REQUIRED_ | on LSP | e | 946 | | | TTRIBUTES | ATTRIBUTES | Hop Att | | 947 | | | | | ributes | | 948 +-----+------------+-----------+---------------+---------+----------+ 949 | TBA | RTM_SET | Yes | No | No | This | 950 | 5 | sub-object | | | | document | 951 +-----+------------+-----------+---------------+---------+----------+ 953 Table 8: RTM_SET Sub-object Type 955 IANA requested to create new sub-registry for sub-TLV types of 956 RTM_SET sub-object as follows: 958 +-----------+----------------------+-------------------------+ 959 | Value | Description | Reference | 960 +-----------+----------------------+-------------------------+ 961 | 0 | Reserved | | 962 | 1 | IPv4 address | This document | 963 | 2 | IPv6 address | This document | 964 | 3 | Unnumbered interface | This document | 965 | 4-127 | Reserved | IETF Consensus | 966 | 128 - 191 | Reserved | First Come First Served | 967 | 192 - 255 | Reserved | Private Use | 968 +-----------+----------------------+-------------------------+ 970 Table 9: RTM_SET object sub-object types 972 9. Security Considerations 974 Routers that support Residence Time Measurement are subject to the 975 same security considerations as defined in [RFC5586] . 977 In addition - particularly as applied to use related to PTP - there 978 is a presumed trust model that depends on the existence of a trusted 979 relationship of at least all PTP-aware nodes on the path traversed by 980 PTP messages. This is necessary as these nodes are expected to 981 correctly modify specific content of the data in PTP messages and 982 proper operation of the protocol depends on this ability. 984 As a result, the content of the PTP-related data in RTM messages that 985 will be modified by intermediate nodes cannot be authenticated, and 986 the additional information that must be accessible for proper 987 operation of PTP 1-step and 2-step modes MUST be accessible to 988 intermediate nodes (i.e. - MUST NOT be encrypted in a manner that 989 makes this data inaccessible). 991 While it is possible for a supposed compromised LSR to intercept and 992 modify the G-ACh content, this is an issue that exists for LSRs in 993 general - for any and all data that may be carried over an LSP - and 994 is therefore the basis for an additional presumed trust model 995 associated with existing LSPs and LSRs. 997 The ability for potentially authenticating and/or encrypting RTM and 998 PTP data that is not needed by intermediate RTM/PTP-capable nodes is 999 for further study. 1001 Security requirements of time protocols are provided in RFC 7384 1002 [RFC7384]. 1004 10. Acknowledgements 1006 Authors want to thank Loa Andersson for his thorough review and 1007 thoghtful comments. 1009 11. References 1011 11.1. Normative References 1013 [I-D.ietf-ospf-ospfv3-lsa-extend] 1014 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 1015 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-09 1016 (work in progress), November 2015. 1018 [IEEE.1588.2008] 1019 "Standard for a Precision Clock Synchronization Protocol 1020 for Networked Measurement and Control Systems", 1021 IEEE Standard 1588, March 2008. 1023 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1024 Requirement Levels", BCP 14, RFC 2119, 1025 DOI 10.17487/RFC2119, March 1997, 1026 . 1028 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1029 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1030 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1031 . 1033 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1034 in Resource ReSerVation Protocol - Traffic Engineering 1035 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 1036 . 1038 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 1039 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 1040 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 1041 February 2006, . 1043 [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual 1044 Circuit Connectivity Verification (VCCV): A Control 1045 Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, 1046 December 2007, . 1048 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. 1049 Ayyangarps, "Encoding of Attributes for MPLS LSP 1050 Establishment Using Resource Reservation Protocol Traffic 1051 Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, 1052 February 2009, . 1054 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 1055 "MPLS Generic Associated Channel", RFC 5586, 1056 DOI 10.17487/RFC5586, June 2009, 1057 . 1059 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1060 "Network Time Protocol Version 4: Protocol and Algorithms 1061 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1062 . 1064 [RFC6423] Li, H., Martini, L., He, J., and F. Huang, "Using the 1065 Generic Associated Channel Label for Pseudowire in the 1066 MPLS Transport Profile (MPLS-TP)", RFC 6423, 1067 DOI 10.17487/RFC6423, November 2011, 1068 . 1070 [RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising 1071 Generic Information in IS-IS", RFC 6823, 1072 DOI 10.17487/RFC6823, December 2012, 1073 . 1075 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1076 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1077 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 1078 2015, . 1080 11.2. Informative References 1082 [I-D.ietf-tictoc-1588overmpls] 1083 Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. 1084 Montini, "Transporting Timing messages over MPLS 1085 Networks", draft-ietf-tictoc-1588overmpls-07 (work in 1086 progress), October 2015. 1088 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 1089 in Support of Generalized Multi-Protocol Label Switching 1090 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 1091 . 1093 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1094 Element (PCE)-Based Architecture", RFC 4655, 1095 DOI 10.17487/RFC4655, August 2006, 1096 . 1098 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1099 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1100 DOI 10.17487/RFC5226, May 2008, 1101 . 1103 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1104 Measurement for MPLS Networks", RFC 6374, 1105 DOI 10.17487/RFC6374, September 2011, 1106 . 1108 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 1109 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 1110 October 2014, . 1112 Authors' Addresses 1114 Greg Mirsky 1115 Ericsson 1117 Email: gregory.mirsky@ericsson.com 1119 Stefano Ruffini 1120 Ericsson 1122 Email: stefano.ruffini@ericsson.com 1123 Eric Gray 1124 Ericsson 1126 Email: eric.gray@ericsson.com 1128 John Drake 1129 Juniper Networks 1131 Email: jdrake@juniper.net 1133 Stewart Bryant 1134 Cisco Systems 1136 Email: stbryant@cisco.com 1138 Alexander Vainshtein 1139 ECI Telecom 1141 Email: Alexander.Vainshtein@ecitele.com