idnits 2.17.1 draft-ietf-mpls-residence-time-07.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 965 has weird spacing: '...Allowed on ...' -- The document date (April 7, 2016) is 2912 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.2014' -- 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: October 9, 2016 Ericsson 6 J. Drake 7 Juniper Networks 8 S. Bryant 9 Cisco Systems 10 A. Vainshtein 11 ECI Telecom 12 April 7, 2016 14 Residence Time Measurement in MPLS network 15 draft-ietf-mpls-residence-time-07 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 October 9, 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 . . . . . . . . . . . . . . . . . . 13 79 5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 16 80 6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 16 81 7. One-step Clock and Two-step Clock Modes . . . . . . . . . . . 17 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 83 8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 19 84 8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 19 85 8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 20 86 8.4. RTM Capability sub-TLV in OSPFv2 . . . . . . . . . . . . 20 87 8.5. RTM Capability sub-TLV in OSPFv3 . . . . . . . . . . . . 21 88 8.6. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 21 89 8.7. RTM_SET Sub-object RSVP Type and sub-TLVs . . . . . . . . 21 90 8.8. RTM_SET Attribute Flag . . . . . . . . . . . . . . . . . 22 91 8.9. New Error Codes . . . . . . . . . . . . . . . . . . . . . 23 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 93 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 95 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 96 11.2. Informative References . . . . . . . . . . . . . . . . . 25 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 99 1. Introduction 101 Time synchronization protocols, e.g., Network Time Protocol version 4 102 (NTPv4) [RFC5905] and Precision Time Protocol (PTP) Version 2 103 [IEEE.1588.2014] define timing messages that can be used to 104 synchronize clocks across a network domain. Measurement of the 105 cumulative time one of these timing messages spends transiting the 106 nodes on the path from ingress node to egress node is termed 107 Residence Time and it is used to improve the accuracy of clock 108 synchronization. (I.e., it is the sum of the difference between the 109 time of receipt at an ingress interface and the time of transmission 110 from an egress interface for each node along the path from ingress 111 node to egress node.) This document defines a new Generalized 112 Associated Channel (G-ACh) value and an associated residence time 113 measurement (RTM) packet that can be used in a Multi-Protocol Label 114 Switching (MPLS) network to measure residence time over a Label 115 Switched Path (LSP). 117 Although it is possible to use RTM over an LSP instantiated using 118 LDP, that is outside the scope of this document. Rather, this 119 document describes RTM over an LSP signaled using RSVP-TE [RFC3209] 120 because the LSP's path can be either explicitly specified or 121 determined during signaling. 123 Comparison with alternative proposed solutions such as 124 [I-D.ietf-tictoc-1588overmpls] 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 OAM: Operations, Administration, and Maintenance 149 RRO: Record Route Object 151 RTM: Residence Time Measurement 153 IGP: Internal Gateway Protocol 155 1.1.2. Requirements Language 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 159 "OPTIONAL" in this document are to be interpreted as described in 160 [RFC2119]. 162 2. Residence Time Measurement 164 Packet Loss and Delay Measurement for MPLS Networks [RFC6374] can be 165 used to measure one-way or two-way end-to-end propagation delay over 166 LSP or PW. But these measurements are insufficient for use in some 167 applications, for example, time synchronization across a network as 168 defined in the Precision Time Protocol (PTP). In PTPv2 169 [IEEE.1588.2014] residence times is accumulated in the 170 correctionField of the PTP event message, as defined in 171 [IEEE.1588.2014], or in the associated follow-up message (or 172 Delay_Resp message associated with the Delay_Req message) in case of 173 two-step clocks (see the detailed discussion in Section 7). 175 IEEE 1588 uses this residence time to correct the transit time from 176 ingress node to egress node, effectively making the transit nodes 177 transparent. 179 This document proposes a mechanism that can be used as one of types 180 of on-path support for a clock synchronization protocol or to perform 181 one-way measurement of residence time. The proposed mechanism 182 accumulates residence time from all nodes that support this extension 183 along the path of a particular LSP in Scratch Pad field of an RTM 184 packet Figure 1. This value can then be used by the egress node to 185 update, for example, the correctionField of the PTP event packet 186 carried within the RTM packet prior to performing its PTP processing. 188 3. G-ACh for Residence Time Measurement 190 RFC 5586 [RFC5586] and RFC 6423 [RFC6423] define the G-ACh to extend 191 the applicability of the PW Associated Channel (ACH) [RFC5085] to 192 LSPs. G-ACh provides a mechanism to transport OAM and other control 193 messages over an LSP. Processing of these messages by select transit 194 nodes is controlled by the use of the Time-to-Live (TTL) value in the 195 MPLS header of these messages. 197 The packet format for Residence Time Measurement (RTM) is presented 198 in Figure 1 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 |0 0 0 1|Version| Reserved | RTM G-ACh | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | | 206 | Scratch Pad | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Type | Length | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Value | 211 ~ ~ 212 | | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 Figure 1: RTM G-ACh packet format for Residence Time Measurement 217 o First four octets are defined as G-ACh Header in [RFC5586] 219 o The Version field is set to 0, as defined in RFC 4385 [RFC4385]. 221 o The Reserved field MUST be set to 0 on transmit and ignored on 222 receipt. 224 o The RTM G-ACh field, value (TBA1) to be allocated by IANA, 225 identifies the packet as such. 227 o The Scratch Pad field is 8 octets in length. It is used to 228 accumulate the residence time spent in each RTM capable node 229 transited by the packet on its path from ingress node to egress 230 node. The first RTM-capable node MUST initialize the Scratch Pad 231 field with its residence time measurement. Its format is IEEE 232 double precision and its units are nanoseconds. Note that 233 depending on whether the timing procedure is one-step or two-step 234 operation (Section 7), the residence time is either for the timing 235 packet carried in the Value field of this RTM packet or for an 236 associated timing packet carried in the Value field of another RTM 237 packet. 239 o The Type field identifies the type and encapsulation of a timing 240 packet carried in the Value field, e.g., NTP [RFC5905] or PTP 241 [IEEE.1588.2014]. IANA will be asked to create a sub-registry in 242 Generic Associated Channel (G-ACh) Parameters Registry called 243 "MPLS RTM TLV Registry". 245 o The Length field contains the length, in octets , of the of the 246 timing packet carried in the Value field. 248 o The optional Value field MAY carry a packet of the time 249 synchronization protocol identified by Type field. It is 250 important to note that the packet may be authenticated or 251 encrypted and carried over LSP edge to edge unchanged while the 252 residence time is accumulated in the Scratch Pad field. 254 o The TLV MUST be included in the RTM message, even if the length of 255 the Value field is zero. 257 3.1. PTP Packet Sub-TLV 259 Figure 2 presents format of a PTP sub-TLV that MUST be included in 260 the Value field of an RTM packet preceding the carried timing packet 261 when the timing packet is PTP. 263 0 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Type | Length | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Flags |PTPType| 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Port ID | 271 | | 272 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | | Sequence ID | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Figure 2: PTP Sub-TLV format 278 where Flags field has format 279 0 1 2 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 |S| Reserved | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Figure 3: Flags field format of PTP Packet Sub-TLV 287 o The Type field identifies PTP sub-TLV defined in the Table 19 288 Values of messageType field in [IEEE.1588.2014]. 290 o The Length field of the PTP sub-TLV contains the number of octets 291 of the Value field and MUST be 20. 293 o The Flags field currently defines one bit, the S-bit, that defines 294 whether the current message has been processed by a 2-step node, 295 where the flag is cleared if the message has been handled 296 exclusively by 1-step nodes and there is no follow-up message, and 297 set if there has been at least one 2-step node and a follow-up 298 message is forthcoming. 300 o The PTPType indicates the type of PTP packet carried in the TLV. 301 PTPType is the messageType field of the PTPv2 packet whose values 302 are defined in the Table 19 [IEEE.1588.2014]. 304 o The 10 octets long Port ID field contains the identity of the 305 source port. 307 o The Sequence ID is the sequence ID of the PTP message carried in 308 the Value field of the message. 310 4. Control Plane Theory of Operation 312 The operation of RTM depends upon TTL expiry to deliver an RTM packet 313 from one RTM capable interface to the next along the path from 314 ingress node to egress node. This means that a node with RTM capable 315 interfaces MUST be able to compute a TTL which will cause the expiry 316 of an RTM packet at the next node with RTM capable interfaces. 318 4.1. RTM Capability 320 Note that the RTM capability of a node is with respect to the pair of 321 interfaces that will be used to forward an RTM packet. In general, 322 the ingress interface of this pair must be able to capture the 323 arrival time of the packet and encode it in some way such that this 324 information will be available to the egress interface. 326 The supported modes (1-step verses 2-step) of any pair of interfaces 327 is then determined by the capability of the egress interface. For 328 both modes, the egress interface implementation MUST be able to 329 determine the precise departure time of the same packet and determine 330 from this, and the arrival time information from the corresponding 331 ingress interface, the difference representing the residence time for 332 the packet. 334 An interface with the ability to do this and update the associated 335 Scratch Pad in real-time (i.e. while the packet is being forwarded) 336 is said to be 1-step capable. 338 Hence while both ingress and egress interfaces are required to 339 support RTM for the pair to be RTM-capable, it is the egress 340 interface that determines whether or not the node is 1-step or 2-step 341 capable with respect to the interface-pair. 343 The RTM capability used in the sub-TLV shown in Figure 4 is thus 344 associated with the egress port of the node making the advertisement, 345 while the ability of any pair of interfaces that includes this egress 346 interface to support any mode of RTM depends on the ability of that 347 interface to record packet arrival time in some way that can be 348 conveyed to and used by that egress interface. 350 When a node uses an IGP to carry the RTM capability sub-TLV, the sub- 351 TLV MUST reflect the RTM capability (1-step or 2-step) associated 352 with egress interfaces. 354 4.2. RTM Capability Sub-TLV 356 The format for the RTM Capabilities sub-TLV is presented in Figure 4 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Type | Length | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | RTM | Reserved | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 Figure 4: RTM Capability sub-TLV 368 o Type values TBA2 and TBA3 will be assigned by IANA from 369 appropriate registries for OSPFv2 and OSPFv3 respectively. 371 o Length MUST be set to 4. 373 o RTM (capability) - is a three-bit long bit-map field with values 374 defined as follows: 376 * 0b001 - one-step RTM supported; 378 * 0b010 - two-step RTM supported; 380 * 0b100 - reserved. 382 o Reserved field must be set to all zeroes on transmit and ignored 383 on receipt. 385 [RFC4202] explains that the Interface Switching Capability Descriptor 386 describes switching capability of an interface. For bi-directional 387 links, the switching capabilities of an interface are defined to be 388 the same in either direction. I.e., for data entering the node 389 through that interface and for data leaving the node through that 390 interface. That principle SHOULD be applied when a node advertises 391 RTM Capability. 393 A node that supports RTM MUST be able to act in two-step mode and MAY 394 also support one-step RTM mode. Detailed discussion of one-step and 395 two-step RTM modes in Section 7. 397 4.3. RTM Capability Advertisement in OSPFv2 399 The capability to support RTM on a particular link (interface) is 400 advertised in the OSPFv2 Extended Link Opaque LSA described in 401 Section 3 [RFC7684] via the RTM Capability sub-TLV. 403 Its Type value will be assigned by IANA from the OSPF Extended Link 404 TLV Sub-TLVs registry that will be created per [RFC7684] request. 406 4.4. RTM Capability Advertisement in OSPFv3 408 The capability to support RTM on a particular link (interface) is 409 advertised in the OSPFv3 be Intra-Area-Prefix TLV, IPv6 Link-Local 410 Address TLV, or the IPv4 Link-Local Address TLV described in 411 [I-D.ietf-ospf-ospfv3-lsa-extend] via the RTM Capability sub-TLV. 413 4.5. RTM Capability Advertisement in IS-IS 415 The capability to support RTM on a particular link (interface) is 416 advertised in the GENINFO TLV described in [RFC6823] via the RTM 417 Capability sub-TLV. 419 With respect to the Flags field of the GENINFO TLV: 421 o The S bit MUST be cleared to prevent the RTM Capability sub-TLV 422 from leaking between levels. 424 o The D bit of the Flags field MUST be cleared as required by 425 [RFC6823]. 427 o The I bit and the V bit MUST be set accordingly depending on 428 whether RTM capability being advertised is for an IPv4 or an IPv6 429 interface. 431 Application ID (TBA4) will be assigned from the Application 432 Identifiers for TLV 251 IANA registry. The RTM Capability sub-TLV 433 MUST be included in GENINFO TLV in Application Specific Information. 435 4.6. RSVP-TE Control Plane Operation to Support RTM 437 Throughout this document we refer to a node as RTM capable node when 438 at least one of its interfaces is RTM capable. Figure 5 provides an 439 example of roles a node may have with respect to RTM capability: 441 ----- ----- ----- ----- ----- ----- ----- 442 | A |-----| B |-----| C |-----| D |-----| E |-----| F |-----| G | 443 ----- ----- ----- ----- ----- ----- ----- 445 Figure 5: RTM capable roles 447 o A is a Boundary Clock with its egress port in Master state. Node 448 A transmits IP encapsulated timing packets whose destination IP 449 address is G. 451 o B is the ingress LER for the MPLS LSP and is the first RTM capable 452 node. It creates RTM packets and in each it places a timing 453 packet, possibly encrypted, in the Value field and initializes the 454 Scratch Pad field with its residence time measurement 456 o C is a transit node that is not RTM capable. It forwards RTM 457 packets without modification. 459 o D is RTM capable transit node. It updates the Scratch Pad filed 460 of the RTM packet without updating of the timing packet. 462 o E is a transit node that is not RTM capable. It forwards RTM 463 packets without modification. 465 o F is the egress LER and the last RTM capable node. It processes 466 the timing packet carried in the Value field using the value in 467 the Scratch Pad field. It updates the Correction field of the PTP 468 message with the value in the Scratch Pad field of the RTM ACH, 469 and removes the RTM ACH encapsulation. 471 o G is a Boundary Clock with its ingress port in Slave state. Node 472 G receives PTP messages. 474 An ingress node that is configured to perform RTM along a path 475 through an MPLS network to an egress node verifies that the selected 476 egress node has an interface that supports RTM via the egress node's 477 advertisement of the RTM Capability sub-TLV. In the Path message 478 that the ingress node uses to instantiate the LSP to that egress node 479 it places LSP_ATTRIBUTES Object [RFC5420] with RTM_SET Attribute Flag 480 set Section 8.8 which indicates to the egress node that RTM is 481 requested for this LSP. RTM_SET Attribute Flag SHOULD NOT be set in 482 the LSP_REQUIRED_ATTRIBUTES object [RFC5420] , unless it is known 483 that all nodes support RTM, because a node that does not recognize 484 RTM_SET Attribute Flag would reject the Path message. 486 If egress node receives Path message with RTM_SET Attribute Flag in 487 LSP_ATTRIBUTES object, it MUST include initialized RRO [RFC3209] and 488 LSP_ATTRIBUTES object where RTM_SET Attribute Flag is set and RTM_SET 489 TLV Section 4.7 is initialized. When Resv message received by 490 ingress node the RTM_SET TLV will contain an ordered list, from 491 egress node to ingress node, of the RTM capable node along the LSP's 492 path. 494 After the ingress node receives the Resv, it MAY begin sending RTM 495 packets on the LSP's path. Each RTM packet has its Scratch Pad field 496 initialized and its TTL set to expire on the closest downstream RTM 497 capable node. 499 It should be noted that RTM can also be used for LSPs instantiated 500 using [RFC3209] in an environment in which all interfaces in an IGP 501 support RTM. In this case the RTM_SET TLV and LSP_ATTRIBUTES Object 502 MAY be omitted. 504 4.7. RTM_SET TLV 506 RTM capable interfaces can be recorded via RTM_SET TLV. The RTM_SET 507 sub-object format is of generic Type, Length, Value (TLV), presented 508 in Figure 6 . 510 0 1 2 3 511 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Type | Length |I| Reserved | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 ~ Value ~ 516 | | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 Figure 6: RTM_SET TLV format 521 Type value (TBA5) will be assigned by IANA from its Attributes TLV 522 Space sub-registry. 524 The Length contains the total length of the sub-object in bytes, 525 including the Type and Length fields. 527 The I flag MUST be set to 0 if the node identified in the Value field 528 was able to find downstream RTM node and calculate distance to it. 529 If the node failed to find the downstream RTM node, then the I flag 530 MUST be set to 1. 532 Reserved field must be zeroed on initiation and ignored on receipt. 534 The content of an RTM_SET TLV is a series of variable-length sub- 535 TLVs. Only a single RTM_SET can be present in the LSP_ATTRIBUTES 536 object. The sub-TLVs are defined in Section 4.7.1 below. 538 The following processing procedures apply to every RTM capable node 539 along the LSP that in this paragraph is referred as node for sake of 540 brevity. Each node MUST examine Resv message whether RTM_SET 541 Attribute Flag in the LSP_ATTRIBUTES object is set. If the RTM_SET 542 flag set, the node MUST inspect the LSP_ATTRIBUTES object for 543 presence of RTM_SET TLV. If more than one found, then the LSP setup 544 MUST fail with generation of the ResvErr message with Error Code 545 Duplicate TLV Section 8.9 and Error Value that contains Type value in 546 its 8 least significant bits. If no RTM_SET TLV has been found, then 547 the LSP setup MUST fail with generation of the ResvErr message with 548 Error Code RTM_SET TLV Absent Section 8.9. If one RTM_SET TLV has 549 been found the node will use the ID of the first node in the RTM_SET 550 in conjunction with the RRO to compute the hop count to its 551 downstream node with reachable RTM capable interface. If the node 552 cannot find matching ID in RRO, then it MUST try to use ID of the 553 next node in the RTM_SET until it finds the match or reaches the end 554 of RTM_SET TLV. If match have been found, then the calculated value 555 is used by the node as TTL value in outgoing label to reach the next 556 RTM capable node on the LSP. Otherwise, the TTL value MUST be set to 557 255. The node MUST add RTM_SET sub-TLV with the same address it used 558 in RRO sub-object at the beginning of the RTM_SET TLV in associated 559 outgoing Resv message before forwarding it upstream. If the 560 calculated TTL value been set to 255, as described above, then the I 561 field in node RTM_SET TLV MUST be set to 1 before Resv message 562 forwarded upstream. 564 The ingress node MAY inspect values of I field in the received Resv 565 message that has RTM_SET Attribute Flag in the LSP_ATTRIBUTES object 566 set. Presence of the RTM_SET TLV with I field set to 1 indicates 567 that not all RTM nodes along the LSP could been included in the 568 calculation of the residence time. Re-signaling of the path MAY be 569 performed. 571 There are scenarios when some information is removed from an RRO due 572 to policy processing (e.g., as may happen between providers) or RRO 573 is limited due to size constraints . Such changes affect the core 574 assumption of the method to control processing of RTM packets. RTM 575 SHOULD NOT be used if it is not guaranteed that RRO contains complete 576 information. 578 4.7.1. RTM_SET Sub-TLVs 580 The RTM Set sub-object contains an ordered list, from egress node to 581 ingress node, of the RTM capable nodes along the LSP's path. 583 The contents of a RTM_SET sub-object are a series of variable-length 584 sub-TLVs. Each sub-TLV has its own Length field. The Length 585 contains the total length of the sub-TLV in bytes, including the Type 586 and Length fields. The Length MUST always be a multiple of 4, and at 587 least 8 (smallest IPv4 sub-object). 589 Sub-TLVs are organized as a last-in-first-out stack. The first -out 590 sub-TLV relative to the beginning of RTM_SET TLV is considered the 591 top. The last-out sub-TLV is considered the bottom. When a new sub- 592 TLV is added, it is always added to the top. Only a single RTM_SET 593 sub-TLV with the given Value field MUST be present in the RTM_SET 594 TLV. If more than one sub-TLV is found the LSP setup MUST fail with 595 the generation of a ResvErr message with the Error Code "Duplicate 596 sub-TLV" Section 8.9 and Error Value contains 16-bit value composed 597 of (Type of TLV, Type of sub-TLV). 599 Three kinds of sub-TLVs for RTM_SET are currently defined. 601 4.7.1.1. IPv4 Sub-TLV 602 0 1 2 3 603 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 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Type | Length | Reserved | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | IPv4 address | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 Figure 7: IPv4 sub-TLV format 612 Type 614 0x01 IPv4 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 8. 621 IPv4 address 623 A 32-bit unicast host address. 625 Reserved 627 Zeroed on initiation and ignored on receipt. 629 4.7.1.2. IPv6 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 | | 637 | IPv6 address | 638 | | 639 | | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 Figure 8: IPv6 sub-TLV format 644 Type 646 0x02 IPv6 address 648 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 20. 652 IPv6 address 654 A 128-bit unicast host address. 656 Reserved 658 Zeroed on initiation and ignored on receipt. 660 4.7.1.3. Unnumbered Interface Sub-TLV 662 0 1 2 3 663 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 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Type | Length | Reserved | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Node ID | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Interface ID | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 Figure 9: IPv4 sub-TLV format 674 Type 676 0x03 Unnumbered interface 678 Length 680 The Length contains the total length of the sub-TLV in bytes, 681 including the Type and Length fields. The Length is always 12. 683 Node ID 685 The Node ID interpreted as Router ID as discussed in the Section 2 686 [RFC3477]. 688 Interface ID 690 The identifier assigned to the link by the node specified by the 691 Node ID. 693 Reserved 695 Zeroed on initiation and ignored on receipt. 697 5. Data Plane Theory of Operation 699 After instantiating an LSP for a path using RSVP-TE [RFC3209] as 700 described in Section 4.6 or as described in the second paragraph of 701 Section 4 and in Section 4.6, ingress node MAY begin sending RTM 702 packets to the first downstream RTM capable node on that path. Each 703 RTM packet has its Scratch Pad field initialized and its TTL set to 704 expire on the next downstream RTM-capable node. Each RTM-capable 705 node on the explicit path receives an RTM packet and records the time 706 at which it receives that packet at its ingress interface as well as 707 the time at which it transmits that packet from its egress interface; 708 this should be done as close to the physical layer as possible to 709 ensure precise accuracy in time determination. The RTM-capable node 710 determines the difference between those two times; for 1-step 711 operation, this difference is determined just prior to or while 712 sending the packet, and the RTM-capable egress interface adds it to 713 the value in the Scratch Pad field of the message in progress. Note, 714 for the purpose of calculating a residence time, a common free 715 running clock synchronizing all the involved interfaces may be 716 sufficient, as, for example, 4.6 ppm accuracy leads to 4.6 nanosecond 717 error for residence time on the order of 1 millisecond. 719 For 2-step operation, the difference between packet arrival time (at 720 an ingress interface) and subsequent departure time (from an egress 721 interface) is determined at some later time prior to sending a 722 subsequent follow-up message, so that this value can be used to 723 update the correctionField in the follow-up message. 725 See Section 7 for further details on the difference between 1-step 726 and 2-step operation. 728 The last RTM-capable node on the LSP MAY then use the value in the 729 Scratch Pad field to perform time correction, if there is no follow- 730 up message. For example, the egress node may be a PTP Boundary Clock 731 synchronized to a Master Clock and will use the value in the Scratch 732 Pad field to update PTP's correctionField. 734 6. Applicable PTP Scenarios 736 The proposed approach can be directly integrated in a PTP network 737 based on the IEEE 1588 delay request-response mechanism. The RTM 738 capable node nodes act as end-to-end transparent clocks, and 739 typically boundary clocks, at the edges of the MPLS network, use the 740 value in the Scratch Pad field to update the correctionField of the 741 corresponding PTP event packet prior to performing the usual PTP 742 processing. 744 7. One-step Clock and Two-step Clock Modes 746 One-step mode refers to the mode of operation where an egress 747 interface updates the correctionField value of an original event 748 message. Two-step mode refers to the mode of operation where this 749 update is made in a subsequent follow-up message. 751 Processing of the follow-up message, if present, requires the 752 downstream end-point to wait for the arrival of the follow-up message 753 in order to combine correctionField values from both the original 754 (event) message and the subsequent (follow-up) message. In a similar 755 fashion, each 2-step node needs to wait for the related follow-up 756 message, if there is one, in order to update that follow-up message 757 (as opposed to creating a new one. Hence the first node that uses 758 2-step mode MUST do two things: 760 1. Mark the original event message to indicate that a follow-up 761 message will be forthcoming (this is necessary in order to 763 Let any subsequent 2-step node know that there is already a 764 follow-up message, and 766 Let the end-point know to wait for a follow-up message; 768 2. Create a follow-up message in which to put the RTM determined as 769 an initial correctionField value. 771 IEEE 1588v2 [IEEE.1588.2014] defines this behavior for PTP messages. 773 Thus, for example, with reference to the PTP protocol, the PTPType 774 field identifies whether the message is a Sync message, Follow_up 775 message, Delay_Req message, or Delay_Resp message. The 10 octet long 776 Port ID field contains the identity of the source port, that is, the 777 specific PTP port of the boundary clock connected to the MPLS 778 network. The Sequence ID is the sequence ID of the PTP message 779 carried in the Value field of the message. 781 PTP messages also include a bit that indicates whether or not a 782 follow-up message will be coming. This bit, once it is set by a 783 2-step mode device, MUST stay set accordingly until the original and 784 follow-up messages are combined by an end-point (such as a Boundary 785 Clock). 787 Thus, an RTM packet, containing residence time information relating 788 to an earlier packet, also contains information identifying that 789 earlier packet. 791 For compatibility with PTP, RTM (when used for PTP packets) must 792 behave in a similar fashion. To do this, a 2-step RTM capable egress 793 interface will need to examine the S-bit in the Flags field of the 794 PTP sub-TLV (for RTM messages that indicate they are for PTP) and - 795 if it is clear (set to zero), it MUST set it and create a follow-up 796 PTP Type RTM message. If the S bit is already set, then the RTM 797 capable node MUST wait for the RTM message with the PTP type of 798 follow-up and matching originator and sequence number to make the 799 corresponding residence time update to the Scratch Pad field. 801 In practice an RTM operating according to two-step clock behaves like 802 a two-steps transparent clock. 804 A 1-step capable RTM node MAY elect to operate in either 1-step mode 805 (by making an update to the Scratch Pad field of the RTM message 806 containing the PTP even message), or in 2-step mode (by making an 807 update to the Scratch Pad of a follow-up message when its presence is 808 indicated), but MUST NOT do both. 810 Two main subcases can be identified for an RTM node operating as a 811 two-step clock: 813 A) If any of the previous RTM capable node or the previous PTP clock 814 (e.g. the BC connected to the first node), is a two-step clock, the 815 residence time is added to the RTM packet that has been created to 816 include the associated PTP packet (i.e. follow-up message in the 817 downstream direction), if the local RTM-capable node is also 818 operating as a two-step clock. This RTM packet carries the related 819 accumulated residence time and the appropriate values of the Sequence 820 Id and Port Id (the same identifiers carried in the packet processed) 821 and the Two-step Flag set to 1. 823 Note that the fact that an upstream RTM-capable node operating in the 824 two-step mode has created a follow-up message does not require any 825 subsequent RTM capable node to also operate in the 2-step mode, as 826 long as that RTM-capable node forwards the follow-up message on the 827 same LSP on which it forwards the corresponding previous message. 829 A one-step capable RTM node MAY elect to update the RTM follow-up 830 message as if it were operating in two-step mode, however, it MUST 831 NOT update both messages. 833 A PTP event packet (sync) is carried in the RTM packet in order for 834 an RTM node to identify that residence time measurement must be 835 performed on that specific packet. 837 To handle the residence time of the Delay request message on the 838 upstream direction, an RTM packet must be created to carry the 839 residence time on the associated downstream Delay Resp message. 841 The last RTM node of the MPLS network in addition to update the 842 correctionField of the associated PTP packet, must also properly 843 handle the two-step flag of the PTP packets. 845 B) When the PTP network connected to the MPLS and RTM node, operates 846 in one-step clock mode, the associated RTM packet must be created by 847 the RTM node itself. The associated RTM packet including the PTP 848 event packet needs now to indicate that a follow up message will be 849 coming. 851 The last RTM node of the LSP, if it receives an RTM message with a 852 PTP payload indicating a follow-up message will be forthcoming, must 853 generate a follow-up message and properly set the two-step flag of 854 the PTP packets. 856 8. IANA Considerations 858 8.1. New RTM G-ACh 860 IANA is requested to reserve a new G-ACh as follows: 862 +-------+----------------------------+---------------+ 863 | Value | Description | Reference | 864 +-------+----------------------------+---------------+ 865 | TBA1 | Residence Time Measurement | This document | 866 +-------+----------------------------+---------------+ 868 Table 1: New Residence Time Measurement 870 8.2. New RTM TLV Registry 872 IANA is requested to create sub-registry in Generic Associated 873 Channel (G-ACh) Parameters Registry called "MPLS RTM TLV Registry". 874 All code points in the range 0 through 127 in this registry shall be 875 allocated according to the "IETF Review" procedure as specified in 876 [RFC5226] . Remaining code points are allocated according to the 877 table below. This document defines the following new values RTM TLV 878 type s: 880 +-----------+-----------------------------+-------------------------+ 881 | Value | Description | Reference | 882 +-----------+-----------------------------+-------------------------+ 883 | 0 | Reserved | This document | 884 | 1 | No payload | This document | 885 | 2 | PTPv2, Ethernet | This document | 886 | | encapsulation | | 887 | 3 | PTPv2, IPv4 Encapsulation | This document | 888 | 4 | PTPv2, IPv6 Encapsulation | This document | 889 | 5 | NTP | This document | 890 | 6-127 | Reserved | IETF Consensus | 891 | 128 - 191 | Reserved | First Come First Served | 892 | 192 - 255 | Reserved | Private Use | 893 +-----------+-----------------------------+-------------------------+ 895 Table 2: RTM TLV Type 897 8.3. New RTM Sub-TLV Registry 899 IANA is requested to create sub-registry in MPLS RTM TLV Registry, 900 requested in Section 8.2, called "MPLS RTM Sub-TLV Registry". All 901 code points in the range 0 through 127 in this registry shall be 902 allocated according to the "IETF Review" procedure as specified in 903 [RFC5226] . Remaining code points are allocated according to the 904 table below. This document defines the following new values RTM sub- 905 TLV types: 907 +-----------+-------------+-------------------------+ 908 | Value | Description | Reference | 909 +-----------+-------------+-------------------------+ 910 | 0 | Reserved | This document | 911 | 1 | PTP 2-step | This document | 912 | 2-127 | Reserved | IETF Consensus | 913 | 128 - 191 | Reserved | First Come First Served | 914 | 192 - 255 | Reserved | Private Use | 915 +-----------+-------------+-------------------------+ 917 Table 3: RTM Sub-TLV Type 919 8.4. RTM Capability sub-TLV in OSPFv2 921 IANA is requested to assign a new type for RTM Capability sub-TLV 922 from OSPFv2 Extended Link TLV Sub-TLVs registry as follows: 924 +-------+----------------+---------------+ 925 | Value | Description | Reference | 926 +-------+----------------+---------------+ 927 | TBA2 | RTM Capability | This document | 928 +-------+----------------+---------------+ 930 Table 4: RTM Capability sub-TLV 932 8.5. RTM Capability sub-TLV in OSPFv3 934 IANA is requested to assign a new type for RTM Capability sub-TLV 935 from future OSPFv3 Extended-LSA Sub-TLVs registry that would be part 936 of OSPFv3 IANA registry as follows: 938 +-------+----------------+---------------+ 939 | Value | Description | Reference | 940 +-------+----------------+---------------+ 941 | TBA3 | RTM Capability | This document | 942 +-------+----------------+---------------+ 944 Table 5: RTM Capability sub-TLV 946 8.6. IS-IS RTM Application ID 948 IANA is requested to assign a new Application ID for RTM from the 949 Application Identifiers for TLV 251 registry as follows: 951 +-------+-------------+---------------+ 952 | Value | Description | Reference | 953 +-------+-------------+---------------+ 954 | TBA4 | RTM | This document | 955 +-------+-------------+---------------+ 957 Table 6: IS-IS RTM Application ID 959 8.7. RTM_SET Sub-object RSVP Type and sub-TLVs 961 IANA is requested to assign a new Type for RTM_SET sub-object from 962 Attributes TLV Space sub-registry as follows: 964 +-----+------------+-----------+---------------+---------+----------+ 965 | Typ | Name | Allowed | Allowed on | Allowed | Referenc | 966 | e | | on LSP_A | LSP_REQUIRED_ | on LSP | e | 967 | | | TTRIBUTES | ATTRIBUTES | Hop Att | | 968 | | | | | ributes | | 969 +-----+------------+-----------+---------------+---------+----------+ 970 | TBA | RTM_SET | Yes | No | No | This | 971 | 5 | sub-object | | | | document | 972 +-----+------------+-----------+---------------+---------+----------+ 974 Table 7: RTM_SET Sub-object Type 976 IANA requested to create new sub-registry for sub-TLV types of 977 RTM_SET sub-object as follows: 979 +-----------+----------------------+-------------------------+ 980 | Value | Description | Reference | 981 +-----------+----------------------+-------------------------+ 982 | 0 | Reserved | | 983 | 1 | IPv4 address | This document | 984 | 2 | IPv6 address | This document | 985 | 3 | Unnumbered interface | This document | 986 | 4-127 | Reserved | IETF Consensus | 987 | 128 - 191 | Reserved | First Come First Served | 988 | 192 - 255 | Reserved | Private Use | 989 +-----------+----------------------+-------------------------+ 991 Table 8: RTM_SET object sub-object types 993 8.8. RTM_SET Attribute Flag 995 IANA is requested to assign new flag from Attribute Flags registry 997 +-----+--------+-----------+------------+-----+-----+---------------+ 998 | Bit | Name | Attribute | Attribute | RRO | ERO | Reference | 999 | No | | Flags | Flags Resv | | | | 1000 | | | Path | | | | | 1001 +-----+--------+-----------+------------+-----+-----+---------------+ 1002 | TBA | RTM_SE | Yes | Yes | No | No | This document | 1003 | 6 | T | | | | | | 1004 +-----+--------+-----------+------------+-----+-----+---------------+ 1006 Table 9: RTM_SET Attribute Flag 1008 8.9. New Error Codes 1010 IANA is requested to assign new Error Codes from Error Codes and 1011 Globally-Defined Error Value Sub-Codes registry 1013 +------------+--------------------+---------------+ 1014 | Error Code | Meaning | Reference | 1015 +------------+--------------------+---------------+ 1016 | TBA7 | Duplicate TLV | This document | 1017 | TBA8 | Duplicate sub-TLV | This document | 1018 | TBA9 | RTM_SET TLV Absent | This document | 1019 +------------+--------------------+---------------+ 1021 Table 10: New Error Codes 1023 9. Security Considerations 1025 Routers that support Residence Time Measurement are subject to the 1026 same security considerations as defined in [RFC5586] . 1028 In addition - particularly as applied to use related to PTP - there 1029 is a presumed trust model that depends on the existence of a trusted 1030 relationship of at least all PTP-aware nodes on the path traversed by 1031 PTP messages. This is necessary as these nodes are expected to 1032 correctly modify specific content of the data in PTP messages and 1033 proper operation of the protocol depends on this ability. 1035 As a result, the content of the PTP-related data in RTM messages that 1036 will be modified by intermediate nodes cannot be authenticated, and 1037 the additional information that must be accessible for proper 1038 operation of PTP 1-step and 2-step modes MUST be accessible to 1039 intermediate nodes (i.e. - MUST NOT be encrypted in a manner that 1040 makes this data inaccessible). 1042 While it is possible for a supposed compromised node to intercept and 1043 modify the G-ACh content, this is an issue that exists for nodes in 1044 general - for any and all data that may be carried over an LSP - and 1045 is therefore the basis for an additional presumed trust model 1046 associated with existing LSPs and nodes. 1048 The ability for potentially authenticating and/or encrypting RTM and 1049 PTP data that is not needed by intermediate RTM/PTP-capable nodes is 1050 for further study. 1052 Security requirements of time protocols are provided in RFC 7384 1053 [RFC7384]. 1055 10. Acknowledgements 1057 Authors want to thank Loa Andersson, Lou Berger and Acee Lindem for 1058 their thorough reviews, thoughtful comments and, most of, patience. 1060 11. References 1062 11.1. Normative References 1064 [I-D.ietf-ospf-ospfv3-lsa-extend] 1065 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 1066 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-09 1067 (work in progress), November 2015. 1069 [IEEE.1588.2014] 1070 "Standard for a Precision Clock Synchronization Protocol 1071 for Networked Measurement and Control Systems", 1072 IEEE Standard 1588, August 2014. 1074 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1075 Requirement Levels", BCP 14, RFC 2119, 1076 DOI 10.17487/RFC2119, March 1997, 1077 . 1079 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1080 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1081 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1082 . 1084 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1085 in Resource ReSerVation Protocol - Traffic Engineering 1086 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 1087 . 1089 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 1090 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 1091 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 1092 February 2006, . 1094 [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual 1095 Circuit Connectivity Verification (VCCV): A Control 1096 Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, 1097 December 2007, . 1099 [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. 1100 Ayyangarps, "Encoding of Attributes for MPLS LSP 1101 Establishment Using Resource Reservation Protocol Traffic 1102 Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, 1103 February 2009, . 1105 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 1106 "MPLS Generic Associated Channel", RFC 5586, 1107 DOI 10.17487/RFC5586, June 2009, 1108 . 1110 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1111 "Network Time Protocol Version 4: Protocol and Algorithms 1112 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1113 . 1115 [RFC6423] Li, H., Martini, L., He, J., and F. Huang, "Using the 1116 Generic Associated Channel Label for Pseudowire in the 1117 MPLS Transport Profile (MPLS-TP)", RFC 6423, 1118 DOI 10.17487/RFC6423, November 2011, 1119 . 1121 [RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising 1122 Generic Information in IS-IS", RFC 6823, 1123 DOI 10.17487/RFC6823, December 2012, 1124 . 1126 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1127 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1128 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 1129 2015, . 1131 11.2. Informative References 1133 [I-D.ietf-tictoc-1588overmpls] 1134 Davari, S., Oren, A., Bhatia, M., Roberts, P., and L. 1135 Montini, "Transporting Timing messages over MPLS 1136 Networks", draft-ietf-tictoc-1588overmpls-07 (work in 1137 progress), October 2015. 1139 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 1140 in Support of Generalized Multi-Protocol Label Switching 1141 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 1142 . 1144 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1145 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1146 DOI 10.17487/RFC5226, May 2008, 1147 . 1149 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1150 Measurement for MPLS Networks", RFC 6374, 1151 DOI 10.17487/RFC6374, September 2011, 1152 . 1154 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 1155 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 1156 October 2014, . 1158 Authors' Addresses 1160 Greg Mirsky 1161 Ericsson 1163 Email: gregory.mirsky@ericsson.com 1165 Stefano Ruffini 1166 Ericsson 1168 Email: stefano.ruffini@ericsson.com 1170 Eric Gray 1171 Ericsson 1173 Email: eric.gray@ericsson.com 1175 John Drake 1176 Juniper Networks 1178 Email: jdrake@juniper.net 1180 Stewart Bryant 1181 Cisco Systems 1183 Email: stbryant@cisco.com 1184 Alexander Vainshtein 1185 ECI Telecom 1187 Email: Alexander.Vainshtein@ecitele.com