idnits 2.17.1 draft-ietf-mpls-residence-time-03.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 927 has weird spacing: '...Allowed on ...' -- The document date (February 12, 2016) is 2996 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 15, 2016 Ericsson 6 J. Drake 7 Juniper Networks 8 S. Bryant 9 Cisco Systems 10 A. Vainshtein 11 ECI Telecom 12 February 12, 2016 14 Residence Time Measurement in MPLS network 15 draft-ietf-mpls-residence-time-03 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 15, 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 Sub-object . . . . . . . . . . . . . . . . . . . 11 78 4.7.1. RSSO 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. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 19 87 8.5. RTM Capability sub-TLV in OSPFv3 . . . . . . . . . . . . 20 88 8.6. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 20 89 8.7. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 20 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 91 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 94 11.2. Informative References . . . . . . . . . . . . . . . . . 23 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 97 1. Introduction 99 Time synchronization protocols, Network Time Protocol version 4 100 (NTPv4) [RFC5905] and Precision Time Protocol (PTP) Version 2 101 [IEEE.1588.2008] can be used to synchronize clocks across network 102 domain. Measurement of the time a PTP event message spends 103 traversing a node (using precise times of receipt at an ingress 104 interface and transmission at an egress interface), called Residence 105 Time, is one of on-path support types defined in [IEEE.1588.2008] and 106 can be used to improve the accuracy of clock synchronization. This 107 document defines new Generalized Associated Channel (G-ACh) that can 108 be used in Multi-Protocol Label Switching (MPLS) network to measure 109 Residence Time over Label Switched Path (LSP). Mechanisms for 110 transport of time synchronization protocol packets over MPLS are out 111 of scope in this document. 113 Though it is possible to use RTM over LSPs instantiated using LDP 114 such scenarios are outside the scope of this document. The scope of 115 this document is on Traffic Engineered LSPs because the LSP's path 116 can be either explicitly specified or, at the minimum, can be 117 determined when signaling. Such LSP can be instantiated either by 118 using RSVP-TE [RFC3209] or Path Computation Element [RFC4655]. The 119 PCE-based scenario is for further study and is outside the scope of 120 this document. 122 [I-D.ietf-tictoc-1588overmpls] describes alternative method of on- 123 path support for timing distribution protocols. Comparison of 124 proposed solutions is outside the scope of this document. 126 1.1. Conventions used in this document 128 1.1.1. Terminology 130 MPLS: Multi-Protocol Label Switching 132 ACH: Associated Channel 134 TTL: Time-to-Live 136 G-ACh: Generic Associated Channel 138 GAL: Generic Associated Channel Label 140 NTP: Network Time Protocol 141 ppm: parts per million 143 PTP: Precision Time Protocol 145 LSP: Label Switched Path 147 LSR: Label Switching Router 149 OAM: Operations, Administration, and Maintenance 151 RRO: Record Route Object 153 RSSO: RTM Set Sub-object 155 RTM: Residence Time Measurement 157 IGP: Internal Gateway Protocol 159 1.1.2. Requirements Language 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in 164 [RFC2119]. 166 2. Residence Time Measurement 168 Packet Loss and Delay Measurement for MPLS Networks [RFC6374] can be 169 used to measure one-way or two-way end-to-end propagation delay over 170 LSP or PW. But these metrics are insufficient for use in some 171 applications, for example, time synchronization across a network as 172 defined in the Precision Time Protocol (PTP). PTPv2 [IEEE.1588.2008] 173 uses "residence time", the time it takes for a PTPv2 event packet to 174 transit a node. Residence times are accumulated in the 175 correctionField of the PTP event messages, as defined in 176 [IEEE.1588.2008], or of the associated follow-up messages (or 177 Delay_Resp message associated with the Delay_Req message) in case of 178 two-step clocks (detailed discussion in Section 7). The residence 179 time values are specific to each output PTP port and message. 181 IEEE 1588 uses this residence time to correct the propagated time, 182 effectively making these nodes transparent. 184 This document proposes mechanism to accumulate packet residence time 185 from all LSRs that support the mechanism across a particular LSP. 186 The values accumulated in scratchpad fields of MPLS RTM messages can 187 be used by the last RTM-capable LSR on an LSP to update the 188 correctionField of the corresponding PTP event packet prior to 189 performing the usual PTP processing. 191 3. G-ACh for Residence Time Measurement 193 RFC 5586 [RFC5586] and RFC 6423 [RFC6423] extended applicability of 194 PW Associated Channel (ACH) [RFC5085] to LSPs. G-ACh provides a 195 mechanism to transport OAM and other control messages. Processing by 196 arbitrary transit LSRs can be triggered through controlled use of the 197 Time-to-Live (TTL) value. In a way that is analogous to PTP 198 operations, the packet residence time can be handled by the RTM 199 capable node either as "one-step clock" or as a "two-step clock". 201 The packet format for Residence Time Measurement (RTM) is presented 202 in Figure 1 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 |0 0 0 1|Version| Reserved | RTM Channel | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | | 210 | Scratch Pad | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Type | Length | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Value | 215 ~ ~ 216 | | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 Figure 1: RTM G-ACh packet format for Residence Time Measurement 221 o First four octets are defined as G-ACh Header in [RFC5586] 223 o The Version field is set to 0, as defined in RFC 4385 [RFC4385]. 225 o The Reserved field MUST be set to 0 on transmit and ignored on 226 receipt. 228 o The RTM G-ACh field, value (TBA1) to be allocated by IANA, 229 identifies the packet as such. 231 o The Scratch Pad field is 8 octets in length. The first RTM- 232 capable LSR MUST initialize the Scratch Pad field, it SHOULD set 233 it to zero value. The Scratch Pad is used to accumulate the 234 residence time spent in each RTM capable LSR transited by the 235 packet on its path from ingress LSR to egress LSR. Its format is 236 IEEE double precision and its units are nanoseconds. Note: 237 depending on one-step or two-step operation (Section 7), the 238 residence time might be related to the same packet carried in the 239 Value field or to a packet carried in a different RTM packet. 241 o The Type field identifies the type of Value that the TLV carries. 242 IANA will be asked to create a sub-registry in Generic Associated 243 Channel (G-ACh) Parameters Registry called "MPLS RTM TLV 244 Registry". 246 o The Length field contains the number of octets of the Value field. 248 o The optional Value field may be used to carry a packet of a given 249 time synchronization protocol. If packet data is carried in the 250 RTM message, then this is identified by Type accordingly. The 251 data MAY be NTP [RFC5905] or PTP [IEEE.1588.2008]. It is 252 important to note that the packet may be authenticated or 253 encrypted and carried over MPLS LSP edge to edge unchanged while 254 residence time being accumulated in the Scratch Pad field. Sub- 255 TLVs MAY be included in the Value field. 257 o The TLV MUST be included in the RTM message, even if the length of 258 the Value field is zero. 260 3.1. PTP Packet Sub-TLV 262 Figure 2 presents format of a PTP sub-TLV that MUST be precede every 263 PTP packet carried in RTM TLV. 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Type | Length | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Flags |PTPType| 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Port ID | 273 | | 274 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | | Sequence ID | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Figure 2: PTP Sub-TLV format 280 where Flags field has format 281 0 1 2 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 |S| Reserved | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 3: Flags field format of PTP Packet Sub-TLV 289 o The Type field identifies PTP sub-TLV defined in the Table 19 290 Values of messageType field in [IEEE.1588.2008]. 292 o The Length field of the PTP sub-TLV contains the number of octets 293 of the Value field and MUST be 20. 295 o The Flags field currently defines one bit, the S-bit, that defines 296 whether or not the current message has been processed by a 2-step 297 node, where the flag is cleared if the message has been handled 298 exclusively by 1-step nodes and there is no follow-up message, and 299 set if there has been at least one 2-step node and a follow-up 300 message is forthcoming. 302 o The PTPType indicates the type of PTP packet carried in the TLV. 303 PTPType is the messageType field of the PTPv2 packet whose values 304 are defined in the Table 19 [IEEE.1588.2008]. 306 o The 10 octets long Port ID field contains the identity of the 307 source port. 309 o The Sequence ID is the sequence ID of the PTP message carried in 310 the Value field of the message. 312 4. Control Plane Theory of Operation 314 The operation of RTM depends upon TTL expiry to deliver an RTM packet 315 from one RTM capable interface to the next along the path from 316 ingress LSR to egress LSR. This means that an LSR with RTM capable 317 interfaces MUST be able to compute a TTL which will cause the expiry 318 of an RTM packet at the next LSR with RTM capable interfaces. 320 4.1. RTM Capability 322 Note that RTM capability of a node is with respect to the pair of 323 interfaces that will be used to forward an RTM packet. In general, 324 the ingress interface of this pair must be able to capture the 325 arrival time of the packet and encode it in some way such that this 326 information will be available to the egress interface. 328 The supported modes (1-step verses 2-step) of any pair of interfaces 329 is then determined by the capability of the egress interface. In 330 both cases, the egress interface implementation MUST be able to 331 determine the precise departure time of the same packet and determine 332 from this, and the arrival time information from the corresponding 333 ingress interface, the difference representing the residence time for 334 the packet. 336 An interface with the ability to do this and update the associated 337 ScratchPad in real-time (i.e. while the packet is being forwarded) is 338 said to be 1-step capable. 340 Hence while both ingress and egress interfaces are required to 341 support RTM, for the pair to be RTM-capable, it is the egress 342 interface that determines whether or not the node is 1-step or 2-step 343 capable with respect to the interface-pair. 345 The RTM capability used in the sub-TLV shown in Figure 4 is thus 346 associated with the egress port of the node making the advertisement, 347 while the ability of any pair of interfaces that includes this egress 348 interface to support any mode of RTM depends on the ability of that 349 interface to record packet arrival time in some way that can be 350 conveyed to and used by that egress interface. 352 When an LSR uses an IGP to carry the RTM capability sub-TLV, the sub- 353 TLV MUST reflect the RTM capability (1-step or 2-step) associated 354 with egress interfaces and MUST NOT propagate this sub-TLV in IGP 355 LSAs sent from a router which describe a particular interface that 356 does not support the same capability for RTM messages it receives. 358 4.2. RTM Capability Sub-TLV 360 The format for the RTM Capabilities sub-TLV is presented in Figure 4 362 0 1 2 3 363 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 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Type | Length | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | RTM | Reserved | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 Figure 4: RTM Capability sub-TLV 372 o Type values TBA2 and TBA3 will be assigned by IANA from 373 appropriate registries for OSPFv2 and OSPFv3 respectively. 375 o Length MUST be set to 4. 377 o RTM (capability) - is a three-bit long bit-map field with values 378 defined as follows: 380 * 0b001 - one-step RTM supported; 382 * 0b010 - two-step RTM supported; 384 * 0b100 - reserved. 386 o Reserved field must be set to all zeroes on transmit and ignored 387 on receipt. 389 [RFC4202] explains that the Interface Switching Capability Descriptor 390 describes switching capability of an interface. For bi-directional 391 links, the switching capabilities of an interface are defined to be 392 the same in either direction. I.e., for data entering the node 393 through that interface and for data leaving the node through that 394 interface". That principle SHOULD be applied when a node advertises 395 RTM Capability. 397 A node that supports RTM MUST be able to act in two-step mode and MAY 398 also support one-step RTM mode. Detailed discussion of one-step and 399 two-step RTM modes in Section 7. 401 4.3. RTM Capability Advertisement in OSPFv2 403 The capability to support RTM on a particular link advertised in the 404 OSPFv2 Extended Link Opaque LSA described in Section 3 [RFC7684] as 405 RTM Capability sub-TLV, presented in Figure 4, of the OSPFv2 Extended 406 Link TLV. 408 Type value will be assigned by IANA from the OSPF Extended Link TLV 409 Sub-TLVs registry that will be created per [RFC7684] request. 411 4.4. RTM Capability Advertisement in OSPFv3 413 The capability to support RTM on a particular link in OSPFv3 can be 414 advertised by including an RTM Capability sub-TLV defined in 415 Section 4.3 in the following TLVs defined in 416 [I-D.ietf-ospf-ospfv3-lsa-extend] Intra-Area-Prefix TLV, IPv6 Link- 417 Local Address TLV, or IPv4 Link-Local Address TLV when these are 418 included in E-Link-LSA. 420 4.5. RTM Capability Advertisement in IS-IS 422 The RTM capability logically belongs to a group of parameters 423 characterized as "generic information not directly related to the 424 operation of the IS-IS protocol" [RFC6823]. Hence the capability to 425 process RTM messages can be advertised by including RTM Capability 426 sub-TLV in GENINFO TLV [RFC6823]. 428 With respect to the Flags field of the GENINFO TLV: 430 o The S bit MUST be cleared to prevent the RTM Capability sub-TLV 431 from leaking between levels. 433 o The D bit of the Flags field MUST be cleared as required by 434 [RFC6823]. 436 o The I bit and the V bit MUST be set accordingly depending on 437 whether RTM capability being advertised for IPv4 or IPv6 interface 438 of the node. 440 Application ID (TBA4) will be assigned from the Application 441 Identifiers for TLV 251 IANA registry. The RTM Capability sub-TLV, 442 presented in Figure 4, MUST be included in GENINFO TLV in Application 443 Specific Information. 445 4.6. RSVP-TE Control Plane Operation to Support RTM 447 Throughout this document we refer to an LSR as RTM capable LSR when 448 at least one of its interfaces is RTM capable. Figure 5 provides an 449 example of relationship between roles a network element may have in 450 PTP over MPLS scenario and RTM capability: 452 ----- ----- ----- ----- ----- ----- ----- 453 | A |-----| B |-----| C |-----| D |-----| E |-----| F |-----| G | 454 ----- ----- ----- ----- ----- ----- ----- 456 Figure 5: RTM capable roles 458 o A is a Boundary Clock with its egress port in Master state. Node 459 A transmits PTP messages; 461 o B is the ingress LER for the MPLS LSP and is not RTM capable; 463 o C is the first RTM capable LSR; it initializes the RTM Scratch Pad 464 field and encapsulates PTP messages in the RTM ACH; the 465 transmitted Scratch Pad information includes the residence time 466 measured by C; 468 o D is a transit LSR that is not RTM capable; it passes along the 469 RTM ACH encapsulated PTP message unmodified; 471 o E is the last RTM capable LSR; it updates the Correction field of 472 the PTP message with the value in the Scratch Pad field of the RTM 473 ACH, and removes the RTM ACH encapsulation; 475 o F is the egress LER for the MPLS LSP and is not RTM capable; 477 o G is a Boundary Clock with its ingress port in Slave state. Node 478 G receives PTP messages. 480 An ingress LSR that is configured to perform RTM along a path through 481 an MPLS network to an egress LSR verifies that the selected egress 482 LSR has an interface that supports RTM via the egress LSR's 483 advertisement of the RTM Capability sub-TLV. In the Path message 484 that the ingress LSR uses to instantiate the LSP to that egress LSR 485 it places initialized Record Route Object (RRO) [RFC3209] and 486 LSP_ATTRIBUTES Object [RFC5420] with RTM Set Sub-object (RSSO) 487 [Section 4.7], which indicates to the egress LSR that RTM is 488 requested for this LSP. RSSO SHOULD NOT be included into the 489 LSP_REQUIRED_ATTRIBUTES object [RFC5420] , unless it is known that 490 all LSRs support RSSO, because then LSR that does not recognize RSSO 491 would reject the Path message. 493 In the Resv message that the egress LSR sends in response to the 494 received Path message, it includes initialized RRO and RSSO. The 495 RSSO contains an ordered list, from egress LSR to ingress LSR, of the 496 RTM capable LSRs along the LSP's path. Each such LSR will use the ID 497 of the first LSR in the RSSO in conjunction with the RRO to compute 498 the hop count to its downstream LSR with reachable RTM capable 499 interface. It will also insert its ID at the beginning of the RSSO 500 before forwarding the Resv message upstream. 502 After the ingress LSR receives the Resv, it MAY begin sending RTM 503 packets to the first RTM capable LSR on the LSP's path. Each RTM 504 packet has its Scratch Pad field initialized and its TTL set to 505 expire on that first subsequent RTM capable LSR. 507 It should be noted that RTM can also be used for LSPs instantiated 508 using [RFC3209] in an environment in which all interfaces in an IGP 509 support RTM. In this case the RSSO and LSP_ATTRIBUTES Object MAY be 510 omitted. 512 4.7. RTM_SET Sub-object 514 RTM capable interfaces can be recorded via RTM_SET sub-object (RSSO). 515 The RTM_SET sub-object format is of generic Type, Length, Value 516 (TLV), presented in Figure 6 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Type | Length | Reserved | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 ~ Value ~ 523 | | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 Figure 6: RTM Set Sub-object format 528 Type value (TBA5) will be assigned by IANA from its Attributes TLV 529 Space sub-registry. 531 The Length contains the total length of the sub-object in bytes, 532 including the Type and Length fields. 534 Reserved field must be zeroed on transmit and ignored on receipt. 536 The content of an RSSO is a series of variable-length sub-TLVs. The 537 sub-TLVs are defined in Section 4.7.1 below. 539 The RSSO can be present in both RSVP Path and Resv messages. If a 540 Path message contains multiple RSSOs, only the first RSSO is 541 meaningful. Subsequent RSSOs SHOULD be ignored and SHOULD NOT be 542 propagated. Similarly, if in a Resv message multiple RSSOs are 543 encountered following a FILTER_SPEC before another FILTER_SPEC is 544 encountered, only the first RSSO is meaningful. Subsequent RSSOs 545 SHOULD be ignored and SHOULD NOT be propagated. 547 4.7.1. RSSO Sub-TLVs 549 The RTM Set sub-object contains an ordered list, from egress LSR to 550 ingress LSR, of the RTM capable LSRs along the LSP's path. 552 The contents of a RTM_SET sub-object are a series of variable-length 553 sub-TLVs. Each sub-TLV has its own Length field. The Length 554 contains the total length of the sub-TLV in bytes, including the Type 555 and Length fields. The Length MUST always be a multiple of 4, and at 556 least 8 (smallest IPv4 sub-object). 558 Sub-TLVs are organized as a last-in-first-out stack. The first -out 559 sub-TLV relative to the beginning of RSSO is considered the top. The 560 last-out sub-TLV is considered the bottom. When a new sub-TLV is 561 added, it is always added to the top. 563 Three kinds of sub-TLVs for RSSO are currently defined. 565 4.7.1.1. IPv4 Sub-TLV 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Type | Length | Flags | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | IPv4 address | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 Figure 7: IPv4 sub-TLV format 577 Type 579 0x01 IPv4 address 581 Length 583 The Length contains the total length of the sub-TLV in bytes, 584 including the Type and Length fields. The Length is always 8. 586 IPv4 address 588 A 32-bit unicast host address. 590 Flags 592 TBD 594 4.7.1.2. IPv6 Sub-TLV 596 0 1 2 3 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Type | Length | Flags | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | | 602 | IPv6 address | 603 | | 604 | | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 Figure 8: IPv6 sub-TLV format 609 Type 611 0x02 IPv6 address 613 Length 615 The Length contains the total length of the sub-TLV in bytes, 616 including the Type and Length fields. The Length is always 20. 618 IPv6 address 620 A 128-bit unicast host address. 622 Flags 624 TBD 626 4.7.1.3. Unnumbered Interface Sub-TLV 628 0 1 2 3 629 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 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Type | Length | Flags | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Router ID | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Interface ID | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 Figure 9: IPv4 sub-TLV format 640 Type 642 0x03 Unnumbered interface 644 Length 646 The Length contains the total length of the sub-TLV in bytes, 647 including the Type and Length fields. The Length is always 12. 649 Router ID 651 The Router ID interpreted as discussed in the Section 2 of RFC 652 3447 [RFC3477]. 654 Interface ID 656 The identifier assigned to the link by the LSR specified by the 657 Router ID. 659 Flags 660 TBD 662 5. Data Plane Theory of Operation 664 After instantiating an LSP for a path using RSVP-TE [RFC3209] as 665 described in Section 4.6 or as described in the second paragraph of 666 Section 4 and in Section 4.6, ingress LSR MAY begin sending RTM 667 packets to the first downstream RTM capable LSR on that path. Each 668 RTM packet has its Scratch Pad field initialized and its TTL set to 669 expire on the next downstream RTM-capable LSR. Each RTM-capable LSR 670 on the explicit path receives an RTM packet and records the time at 671 which it receives that packet at its ingress interface as well as the 672 time at which it transmits that packet from its egress interface; 673 this should be done as close to the physical layer as possible to 674 ensure precise accuracy in time determination. The RTM-capable LSR 675 determines the difference between those two times; for 1-step 676 operation, this difference is determined just prior to or while 677 sending the packet, and the RTM-capable egress interface adds it to 678 the value in the Scratch Pad field of the message in progress. Note, 679 for the purpose of calculating a residence time, a common free 680 running clock synchronizing all the involved interfaces may be 681 sufficient, as, for example, 4.6 ppm accuracy leads to 4.6 nanosecond 682 error for residence time on the order of 1 millisecond. 684 For 2-step operation, the difference between packet arrival time (at 685 an ingress interface) and subsequent departure time (from an egress 686 interface) is determined at some later time prior to sending a 687 subsequent follow-up message, so that this value can be used to 688 update the correctionField in the follow-up message. 690 See Section 7 for further details on the difference between 1-step 691 and 2-step operation. 693 The last RTM-capable LSR on the LSP MAY then use the value in the 694 Scratch Pad field to perform time correction, if there is no follow- 695 up message. For example, the egress LSR may be a PTP Boundary Clock 696 synchronized to a Master Clock and will use the value in the Scratch 697 Pad field to update PTP's correctionField. 699 6. Applicable PTP Scenarios 701 The proposed approach can be directly integrated in a PTP network 702 based on the IEEE 1588 delay reqest-response mechanism. The RTM 703 capable LSR nodes act as end-to-end transparent clocks, and typically 704 boundary clocks, at the edges of the MPLS network, use the value in 705 the Scratch Pad field to update the correctionField of the 706 corresponding PTP event packet prior to performing the usual PTP 707 processing. 709 7. One-step Clock and Two-step Clock Modes 711 One-step mode refers to the mode of operation where an egress 712 interface updates the correctionField value of an original event 713 message. Two-step mode refers to the mode of operation where this 714 update is made in a subsequent follow-up message. 716 Processing of the follow-up message, if present, requires the 717 downstream end-point to wait for the arrival of the follow-up message 718 in order to combine correctionField values from both the original 719 (event) message and the subsequent (follow-up) message. In a similar 720 fashion, each 2-step node needs to wait for the related follow-up 721 message, if there is one, in order to update that follow-up message 722 (as opposed to creating a new one. Hence the first node that uses 723 2-step mode MUST do two things: 725 1. Mark the original event message to indicate that a follow-up 726 message will be forthcoming (this is necessary in order to 728 Let any subsequent 2-step node know that there is already a 729 follow-up message, and 731 Let the end-point know to wait for a follow-up message; 733 2. Create a follow-up message in which to put the RTM determined as 734 an initial correctionField value. 736 IEEE 1588v2 [IEEE.1588.2008] defines this behaviour for PTP messages. 738 Thus, for example, with reference to the PTP protocol, the PTPType 739 field identifies whether the message is a Sync message, Follow_up 740 message, Delay_Req message, or Delay_Resp message. The 10 octet long 741 Port ID field contains the identity of the source port, that is, the 742 specific PTP port of the boundary clock connected to the MPLS 743 network. The Sequence ID is the sequence ID of the PTP message 744 carried in the Value field of the message. 746 PTP messages also include a bit that indicates whether or not a 747 follow-up message will be coming. This bit, once it is set by a 748 2-step mode device, MUST stay set accordingly until the original and 749 follow-up messages are combined by an end-point (such as a Boundary 750 Clock). 752 Thus, an RTM packet, containing residence time information relating 753 to an earlier packet, also contains information identifying that 754 earlier packet. 756 For compatibility with PTP, RTM (when used for PTP packets) must 757 behave in a similar fashion. To do this, a 2-step RTM capable egress 758 interface will need to examine the S-bit in the Flags field of the 759 PTP sub-TLV (for RTM messages that indicate they are for PTP) and - 760 if it is clear (set to zero), it MUST set it and create a follow-up 761 PTP Type RTM message. If the S bit is already set, then the RTM 762 capable node MUST wait for the RTM message with the PTP type of 763 follow-up and matching originator and sequence number to make the 764 corresponding residence time update to the Scratch Pad field. 766 In practice an RTM operating according to two-step clock behaves like 767 a two-steps transparent clock. 769 A 1-step capable RTM node MAY elect to operate in either 1-step mode 770 (by making an update to the Scratch Pad field of the RTM message 771 containing the PTP even message), or in 2-step mode (by making an 772 update to the Scratch Pad of a follow-up message when its presence is 773 indicated), but MUST NOT do both. 775 Two main subcases can be identified for an RTM node operating as a 776 two-step clock: 778 A) If any of the previous RTM capable node or the previous PTP clock 779 (e.g. the BC connected to the first LSR), is a two-step clock, the 780 residence time is added to the RTM packet that has been created to 781 include the associated PTP packet (i.e. follow-up message in the 782 downstream direction), if the local RTM-capable LSR is also operating 783 as a two-step clock. This RTM packet carries the related accumulated 784 residence time and the appropriate values of the Sequence Id and Port 785 Id (the same identifiers carried in the packet processed) and the 786 Two-step Flag set to 1. 788 Note that the fact that an upstream RTM-capable node operating in the 789 two-step mode has created a follow-up message does not require any 790 subsequent RTM capable LSR to also operate in the 2-step mode, as 791 long as that RTM-capable LSR forwards the follow-up message on the 792 same LSP on which it forwards the corresponding previous message. 794 A one-step capable RTM node MAY elect to update the RTM follow-up 795 message as if it were operating in two-step mode, however, it MUST 796 NOT update both messages. 798 A PTP event packet (sync) is carried in the RTM packet in order for 799 an RTM node to identify that residence time measurement must be 800 performed on that specific packet. 802 To handle the residence time of the Delay request message on the 803 upstream direction, an RTM packet must be created to carry the 804 residence time on the associated downstream Delay Resp message. 806 The last RTM node of the MPLS network in addition to update the 807 correctionField of the associated PTP packet, must also properly 808 handle the two-step flag of the PTP packets. 810 B) When the PTP network connected to the MPLS and RTM node, operates 811 in one-step clock mode, the associated RTM packet must be created by 812 the RTM node itself. The associated RTM packet including the PTP 813 event packet needs now to indicate that a follow up message will be 814 coming. 816 The last RTM node of the LSP, modeif it receives an RTM message with 817 a PTP payload indicating a follow-up message will be forthcoming, 818 must generate a follow-up message and properly set the two-step flag 819 of the PTP packets. 821 8. IANA Considerations 823 8.1. New RTM G-ACh 825 IANA is requested to reserve a new G-ACh as follows: 827 +-------+----------------------------+---------------+ 828 | Value | Description | Reference | 829 +-------+----------------------------+---------------+ 830 | TBA1 | Residence Time Measurement | This document | 831 +-------+----------------------------+---------------+ 833 Table 1: New Residence Time Measurement 835 8.2. New RTM TLV Registry 837 IANA is requested to create sub-registry in Generic Associated 838 Channel (G-ACh) Parameters Registry called "MPLS RTM TLV Registry". 839 All code points in the range 0 through 127 in this registry shall be 840 allocated according to the "IETF Review" procedure as specified in 841 [RFC5226] . Remaining code points are allocated according to the 842 table below. This document defines the following new values RTM TLV 843 type s: 845 +-----------+-------------+-------------------------+ 846 | Value | Description | Reference | 847 +-----------+-------------+-------------------------+ 848 | 0 | Reserved | This document | 849 | 1 | No payload | This document | 850 | 2 | PTPv2 | This document | 851 | 3 | NTP | This document | 852 | 4-127 | Reserved | IETF Consensus | 853 | 128 - 191 | Reserved | First Come First Served | 854 | 192 - 255 | Reserved | Private Use | 855 +-----------+-------------+-------------------------+ 857 Table 2: RTM TLV Type 859 8.3. New RTM Sub-TLV Registry 861 IANA is requested to create sub-registry in MPLS RTM TLV Registry, 862 requested in Section 8.2, called "MPLS RTM Sub-TLV Registry". All 863 code points in the range 0 through 127 in this registry shall be 864 allocated according to the "IETF Review" procedure as specified in 865 [RFC5226] . Remaining code points are allocated according to the 866 table below. This document defines the following new values RTM sub- 867 TLV types: 869 +-----------+-------------+-------------------------+ 870 | Value | Description | Reference | 871 +-----------+-------------+-------------------------+ 872 | 0 | Reserved | This document | 873 | 1 | PTP 2-step | This document | 874 | 2-127 | Reserved | IETF Consensus | 875 | 128 - 191 | Reserved | First Come First Served | 876 | 192 - 255 | Reserved | Private Use | 877 +-----------+-------------+-------------------------+ 879 Table 3: RTM Sub-TLV Type 881 8.4. RTM Capability sub-TLV in OSPFv2 883 IANA is requested to assign a new type for RTM Capability sub-TLV 884 from OSPFv2 Extended Link TLV Sub-TLVs registry as follows: 886 +-------+----------------+---------------+ 887 | Value | Description | Reference | 888 +-------+----------------+---------------+ 889 | TBA2 | RTM Capability | This document | 890 +-------+----------------+---------------+ 892 Table 4: RTM Capability sub-TLV 894 8.5. RTM Capability sub-TLV in OSPFv3 896 IANA is requested to assign a new type for RTM Capability sub-TLV 897 from future OSPFv3 Extended-LSA Sub-TLVs registry that would be part 898 of OSPFv3 IANA registry as follows: 900 +-------+----------------+---------------+ 901 | Value | Description | Reference | 902 +-------+----------------+---------------+ 903 | TBA3 | RTM Capability | This document | 904 +-------+----------------+---------------+ 906 Table 5: RTM Capability sub-TLV 908 8.6. IS-IS RTM Application ID 910 IANA is requested to assign a new Application ID for RTM from the 911 Application Identifiers for TLV 251 registry as follows: 913 +-------+-------------+---------------+ 914 | Value | Description | Reference | 915 +-------+-------------+---------------+ 916 | TBA4 | RTM | This document | 917 +-------+-------------+---------------+ 919 Table 6: IS-IS RTM Application ID 921 8.7. RTM_SET Sub-object RSVP Type and sub-TLVs 923 IANA is requested to assign a new Type for RTM_SET sub-object from 924 Attributes TLV Space sub-registry as follows: 926 +-----+------------+-----------+---------------+---------+----------+ 927 | Typ | Name | Allowed | Allowed on | Allowed | Referenc | 928 | e | | on LSP_A | LSP_REQUIRED_ | on LSP | e | 929 | | | TTRIBUTES | ATTRIBUTES | Hop Att | | 930 | | | | | ributes | | 931 +-----+------------+-----------+---------------+---------+----------+ 932 | TBA | RTM_SET | Yes | No | No | This | 933 | 5 | sub-object | | | | document | 934 +-----+------------+-----------+---------------+---------+----------+ 936 Table 7: RTM_SET Sub-object Type 938 IANA requested to create new sub-registry for sub-TLV types of 939 RTM_SET sub-object as follows: 941 +-----------+----------------------+-------------------------+ 942 | Value | Description | Reference | 943 +-----------+----------------------+-------------------------+ 944 | 0 | Reserved | | 945 | 1 | IPv4 address | This document | 946 | 2 | IPv6 address | This document | 947 | 3 | Unnumbered interface | This document | 948 | 4-127 | Reserved | IETF Consensus | 949 | 128 - 191 | Reserved | First Come First Served | 950 | 192 - 255 | Reserved | Private Use | 951 +-----------+----------------------+-------------------------+ 953 Table 8: RTM_SET object sub-object types 955 9. Security Considerations 957 Routers that support Residence Time Measurement are subject to the 958 same security considerations as defined in [RFC5586] . 960 In addition - particularly as applied to use related to PTP - there 961 is a presumed trust model that depends on the existence of a trusted 962 relationship of at least all PTP-aware nodes on the path traversed by 963 PTP messages. This is necessary as these nodes are expected to 964 correctly modify specific content of the data in PTP messages and 965 proper operation of the protocol depends on this ability. 967 As a result, the content of the PTP-related data in RTM messages that 968 will be modified by intermediate nodes cannot be authenticated, and 969 the additional information that must be accessible for proper 970 operation of PTP 1-step and 2-step modes MUST be accessible to 971 intermediate nodes (i.e. - MUST NOT be encrypted in a manner that 972 makes this data inaccessible). 974 While it is possible for a supposed compromised LSR to intercept and 975 modify the G-ACh content, this is an issue that exists for LSRs in 976 general - for any and all data that may be carried over an LSP - and 977 is therefore the basis for an additional presumed trust model 978 associated with existing LSPs and LSRs. 980 The ability for potentially authenticating and/or encrypting RTM and 981 PTP data that is not needed by intermediate RTM/PTP-capable nodes is 982 for further study. 984 Security requirements of time protocols are provided in RFC 7384 985 [RFC7384]. 987 10. Acknowledgements 989 Authors want to thank Loa Andersson for his thorough review and 990 thoghtful comments. 992 11. References 994 11.1. Normative References 996 [I-D.ietf-ospf-ospfv3-lsa-extend] 997 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 998 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-09 999 (work in progress), November 2015. 1001 [IEEE.1588.2008] 1002 "Standard for a Precision Clock Synchronization Protocol 1003 for Networked Measurement and Control Systems", 1004 IEEE Standard 1588, March 2008. 1006 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1007 Requirement Levels", BCP 14, RFC 2119, 1008 DOI 10.17487/RFC2119, March 1997, 1009 . 1011 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1012 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1013 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1014 . 1016 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1017 in Resource ReSerVation Protocol - Traffic Engineering 1018 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 1019 . 1021 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 1022 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 1023 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 1024 February 2006, . 1026 [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual 1027 Circuit Connectivity Verification (VCCV): A Control 1028 Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, 1029 December 2007, . 1031 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. 1032 Ayyangarps, "Encoding of Attributes for MPLS LSP 1033 Establishment Using Resource Reservation Protocol Traffic 1034 Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, 1035 February 2009, . 1037 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 1038 "MPLS Generic Associated Channel", RFC 5586, 1039 DOI 10.17487/RFC5586, June 2009, 1040 . 1042 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1043 "Network Time Protocol Version 4: Protocol and Algorithms 1044 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1045 . 1047 [RFC6423] Li, H., Martini, L., He, J., and F. Huang, "Using the 1048 Generic Associated Channel Label for Pseudowire in the 1049 MPLS Transport Profile (MPLS-TP)", RFC 6423, 1050 DOI 10.17487/RFC6423, November 2011, 1051 . 1053 [RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising 1054 Generic Information in IS-IS", RFC 6823, 1055 DOI 10.17487/RFC6823, December 2012, 1056 . 1058 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1059 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1060 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 1061 2015, . 1063 11.2. Informative References 1065 [I-D.ietf-tictoc-1588overmpls] 1066 Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. 1067 Montini, "Transporting Timing messages over MPLS 1068 Networks", draft-ietf-tictoc-1588overmpls-07 (work in 1069 progress), October 2015. 1071 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 1072 in Support of Generalized Multi-Protocol Label Switching 1073 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 1074 . 1076 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1077 Element (PCE)-Based Architecture", RFC 4655, 1078 DOI 10.17487/RFC4655, August 2006, 1079 . 1081 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1082 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1083 DOI 10.17487/RFC5226, May 2008, 1084 . 1086 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1087 Measurement for MPLS Networks", RFC 6374, 1088 DOI 10.17487/RFC6374, September 2011, 1089 . 1091 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 1092 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 1093 October 2014, . 1095 Authors' Addresses 1097 Greg Mirsky 1098 Ericsson 1100 Email: gregory.mirsky@ericsson.com 1102 Stefano Ruffini 1103 Ericsson 1105 Email: stefano.ruffini@ericsson.com 1107 Eric Gray 1108 Ericsson 1110 Email: eric.gray@ericsson.com 1112 John Drake 1113 Juniper Networks 1115 Email: jdrake@juniper.net 1116 Stewart Bryant 1117 Cisco Systems 1119 Email: stbryant@cisco.com 1121 Alexander Vainshtein 1122 ECI Telecom 1124 Email: Alexander.Vainshtein@ecitele.com