idnits 2.17.1 draft-ietf-mpls-residence-time-00.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 24 pages 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 -- The document date (August 4, 2015) is 3188 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-06 == Outdated reference: A later version (-13) exists of draft-ietf-ospf-prefix-link-attr-06 -- 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 (~~), 4 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: February 5, 2016 Ericsson 6 J. Drake 7 Juniper Networks 8 S. Bryant 9 Cisco Systems 10 A. Vainshtein 11 ECI Telecom 12 August 4, 2015 14 Residence Time Measurement in MPLS network 15 draft-ietf-mpls-residence-time-00 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 February 5, 2016. 46 Copyright Notice 48 Copyright (c) 2015 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 . . . . . . . . . . . . 4 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 Object . . . . . . . . . . . . . . . . . . . . . 11 78 4.7.1. RSO Sub-objects . . . . . . . . . . . . . . . . . . . 12 79 5. Data Plane Theory of Operation . . . . . . . . . . . . . . . 14 80 6. Applicable PTP Scenarios . . . . . . . . . . . . . . . . . . 15 81 7. One-step Clock and Two-step Clock Modes . . . . . . . . . . . 15 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 83 8.1. New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . . 17 84 8.2. New RTM TLV Registry . . . . . . . . . . . . . . . . . . 18 85 8.3. New RTM Sub-TLV Registry . . . . . . . . . . . . . . . . 18 86 8.4. RTM Capability sub-TLV . . . . . . . . . . . . . . . . . 19 87 8.5. IS-IS RTM Application ID . . . . . . . . . . . . . . . . 19 88 8.6. RTM_SET Object RSVP Class Number, Class Type and Sub- 89 object Types . . . . . . . . . . . . . . . . . . . . . . 19 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 91 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 94 11.2. Informative References . . . . . . . . . . . . . . . . . 23 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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, can be used to improve the accuracy of clock synchronization. 106 This document defines new Generalized Associated Channel (G-ACh) that 107 can be used in Multi-Protocol Label Switching (MPLS) network to 108 measure Residence Time over Label Switched Path (LSP). Mechanisms 109 for transport of time synchronization protocol packets over MPLS are 110 out of scope in this document. 112 Though it is possible to use RTM over LSPs instantiated using LDP 113 such scenarios are outside the scope of this document. The scope of 114 this document is on LSPs instantiated using RSVP-TE [RFC3209] because 115 the LSP's path can be determined. 117 1.1. Conventions used in this document 119 1.1.1. Terminology 121 MPLS: Multi-Protocol Label Switching 123 ACH: Associated Channel 125 TTL: Time-to-Live 127 G-ACh: Generic Associated Channel 129 GAL: Generic Associated Channel Label 131 NTP: Network Time Protocol 133 ppm: parts per million 135 PTP: Precision Time Protocol 137 LSP: Label Switched Path 139 LSR: Label Switching Router 141 OAM: Operations, Administration, and Maintenance 142 RRO: Record Route Object 144 RSO: RTM Set Object 146 RTM: Residence Time Measurement 148 IGP: Internal Gateway Protocol 150 1.1.2. Requirements Language 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in 155 [RFC2119]. 157 2. Residence Time Measurement 159 Packet Loss and Delay Measurement for MPLS Networks [RFC6374] can be 160 used to measure one-way or two-way end-to-end propagation delay over 161 LSP or PW. But these metrics are insufficient for use in some 162 applications, for example, time synchronization across a network as 163 defined in the Precision Time Protocol (PTP). PTPv2 [IEEE.1588.2008] 164 uses "residence time", the time it takes for a PTPv2 event packet to 165 transit a node. Residence times are accumulated in the 166 correctionField of the PTP event messages, as defined in 167 [IEEE.1588.2008], or of the associated follow-up messages (or 168 Delay_Resp message associated with the Delay_Req message) in case of 169 two-step clocks (detailed discussion in Section 7). The residence 170 time values are specific to each output PTP port and message. 172 IEEE 1588 uses this residence time to correct the propagated time, 173 effectively making these nodes transparent. 175 This document proposes mechanism to accumulate packet residence time 176 from all LSRs that support the mechanism across a particular LSP. 177 The values accumulated in scratchpad fields of MPLS RTM messages can 178 be used by the last RTM-capable LSR on an LSP to update the 179 correctionField of the corresponding PTP event packet prior to 180 performing the usual PTP processing. 182 3. G-ACh for Residence Time Measurement 184 RFC 5586 [RFC5586] and RFC 6423 [RFC6423] extended applicability of 185 PW Associated Channel (ACH) [RFC5085] to LSPs. G-ACh provides a 186 mechanism to transport OAM and other control messages. Processing by 187 arbitrary transit LSRs can be triggered through controlled use of the 188 Time-to-Live (TTL) value. In a way that is analogous to PTP 189 operations, the packet residence time can be handled by the RTM 190 capable node either as "one-step clock" or as a "two-step clock". 192 The packet format for Residence Time Measurement (RTM) is presented 193 in Figure 1 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 |0 0 0 1|Version| Reserved | RTM Channel | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | | 201 | Scratch Pad | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Type | Length | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Value | 206 ~ ~ 207 | | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Figure 1: RTM G-ACh packet format for Residence Time Measurement 212 o First four octets are defined as G-ACh Header in [RFC5586] 214 o The Version field is set to 0, as defined in RFC 4385 [RFC4385]. 216 o The Reserved field MUST be set to 0 on transmit and ignored on 217 receipt. 219 o The RTM G-ACh field, value to be allocated by IANA, identifies the 220 packet as such. 222 o The Scratch Pad field is 8 octets in length. The first RTM- 223 capable LSR MUST initialize the Scratch Pad field, it SHOULD set 224 it to zero value. The Scratch Pad is used to accumulate the 225 residence time spent in each RTM capable LSR transited by the 226 packet on its path from ingress LSR to egress LSR. Its format is 227 IEEE double precision and its units are nanoseconds. Note: 228 depending on one-step or two-step operation (Section 7), the 229 residence time might be related to the same packet carried in the 230 Value field or to a packet carried in a different RTM packet. 232 o The Type field identifies the type of Value that the TLV carries. 233 IANA will be asked to create a sub-registry in Generic Associated 234 Channel (G-ACh) Parameters Registry called "MPLS RTM TLV 235 Registry". 237 o The Length field contains the number of octets of the Value field. 239 o The optional Value field may be used to carry a packet of a given 240 time synchronization protocol. If packet data is carried in the 241 RTM message, then this is identified by Type accordingly. The 242 data MAY be NTP [RFC5905] or PTP [IEEE.1588.2008]. It is 243 important to note that the packet may be authenticated or 244 encrypted and carried over MPLS LSP edge to edge unchanged while 245 residence time being accumulated in the Scratch Pad field. Sub- 246 TLVs MAY be included in the Value field. 248 o The TLV MUST be included in the RTM message, even if the length of 249 the Value field is zero. 251 3.1. PTP Packet Sub-TLV 253 Figure 2 presents format of a PTP sub-TLV that MUST be precede every 254 PTP packet carried in RTM TLV. 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Type | Length | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Flags |PTPType| 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Port ID | 264 | | 265 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | | Sequence ID | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 Figure 2: PTP Sub-TLV format 271 where Flags field has format 273 0 1 2 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 |S| Reserved | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Figure 3: Flags field format of PTP Packet Sub-TLV 281 o The Type field identifies PTP sub-TLV defined in the Table 19 282 Values of messageType field in [IEEE.1588.2008]. 284 o The Length field of the PTP sub-TLV contains the number of octets 285 of the Value field and MUST be 20. 287 o The Flags field currently defines one bit, the S-bit, that defines 288 whether or not the current message has been processed by a 2-step 289 node, where the flag is cleared if the message has been handled 290 exclusively by 1-step nodes and there is no follow-up message, and 291 set if there has been at least one 2-step node and a follow-up 292 message is forthcoming. 294 o The PTPType indicates the type of PTP packet carried in the TLV. 295 PTPType is the messageType field of the PTPv2 packet whose values 296 are defined in the Table 19 [IEEE.1588.2008]. 298 o The 10 octets long Port ID field contains the identity of the 299 source port. 301 o The Sequence ID is the sequence ID of the PTP message carried in 302 the Value field of the message. 304 4. Control Plane Theory of Operation 306 The operation of RTM depends upon TTL expiry to deliver an RTM packet 307 from one RTM capable interface to the next along the path from 308 ingress LSR to egress LSR. This means that an LSR with RTM capable 309 interfaces MUST be able to compute a TTL which will cause the expiry 310 of an RTM packet at the next LSR with RTM capable interfaces. 312 4.1. RTM Capability 314 Note that RTM capability of a node is with respect to the pair of 315 interfaces that will be used to forward an RTM packet. In general, 316 the ingress interface of this pair must be able to capture the 317 arrival time of the packet and encode it in some way such that this 318 information will be available to the egress interface. 320 The supported modes (1-step verses 2-step) of any pair of interfaces 321 is then determined by the capability of the egress interface. In 322 both cases, the egress interface implementation MUST be able to 323 determine the precise departure time of the same packet and determine 324 from this, and the arrival time information from the corresponding 325 ingress interface, the difference representing the residence time for 326 the packet. 328 An interface with the ability to do this and update the associated 329 ScratchPad in real-time (i.e. while the packet is being forwarded) is 330 said to be 1-step capable. 332 Hence while both ingress and egress interfaces are required to 333 support RTM, for the pair to be RTM-capable, it is the egress 334 interface that determines whether or not the node is 1-step or 2-step 335 capable with respect to the interface-pair. 337 The RTM capability used in the sub-TLV shown in Figure 4 is thus 338 associated with the egress port of the node making the advertisement, 339 while the ability of any pair of interfaces that includes this egress 340 interface to support any mode of RTM depends on the ability of that 341 interface to record packet arrival time in some way that can be 342 conveyed to and used by that egress interface. 344 When an LSR uses an IGP to carry the RTM capability sub-TLV, the sub- 345 TLV MUST reflect the RTM capability (1-step or 2-step) associated 346 with egress interfaces and MUST NOT propagate this sub-TLV in IGP 347 LSAs sent from a router which describe a particular interface that 348 does not support the same capability for RTM messages it receives. 350 4.2. RTM Capability Sub-TLV 352 The format for the RTM Capabilities sub-TLV is presented in Figure 4 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Type(TBA5) | Length | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | RTM | Reserved | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Figure 4: RTM Capability sub-TLV 364 o Type value will be assigned by IANA from appropriate registries. 366 o Length MUST be set to 4. 368 o RTM (capability) - is a three-bit long bit-map field with values 369 defined as follows: 371 * 0b001 - one-step RTM supported; 373 * 0b010 - two-step RTM supported; 375 * 0b100 - reserved. 377 o Reserved field must be set to all zeroes on transmit and ignored 378 on receipt. 380 [RFC4202] explains that the Interface Switching Capability Descriptor 381 describes switching capability of an interface. For bi-directional 382 links, the switching capabilities of an interface are defined to be 383 the same in either direction. I.e., for data entering the node 384 through that interface and for data leaving the node through that 385 interface". That principle SHOULD be applied when a node advertises 386 RTM Capability. 388 A node that supports RTM MUST be able to act in two-step mode and MAY 389 also support one-step RTM mode. Detailed discussion of one-step and 390 two-step RTM modes in Section 7. 392 4.3. RTM Capability Advertisement in OSPFv2 394 The capability to support RTM on a particular link advertised in the 395 OSPFv2 Extended Link Opaque LSA [I-D.ietf-ospf-prefix-link-attr] as 396 RTM Capability sub-TLV, presented in Figure 4, of the OSPFv2 Extended 397 Link TLV. 399 Type value will be assigned by IANA from the OSPF Extended Link TLV 400 Sub-TLVs registry that will be created per 401 [I-D.ietf-ospf-prefix-link-attr] request. 403 4.4. RTM Capability Advertisement in OSPFv3 405 The capability to support RTM on a particular link in OSPFv3 can be 406 advertised by including an RTM Capability sub-TLV defined in 407 Section 4.3 in the following TLVs defined in 408 [I-D.ietf-ospf-ospfv3-lsa-extend] Intra-Area-Prefix TLV, IPv6 Link- 409 Local Address TLV, or IPv4 Link-Local Address TLV when these are 410 included in E-Link-LSA. 412 4.5. RTM Capability Advertisement in IS-IS 414 The RTM capability logically belongs to a group of parameters 415 characterized as "generic information not directly related to the 416 operation of the IS-IS protocol" [RFC6823]. Hence the capability to 417 process RTM messages can be advertised by including RTM Capability 418 sub-TLV in GENINFO TLV [RFC6823]. 420 With respect to the Flags field of the GENINFO TLV: 422 o The S bit MUST be cleared to prevent the RTM Capability sub-TLV 423 from leaking between levels. 425 o The D bit of the Flags field MUST be cleared as required by 426 [RFC6823]. 428 o The I bit and the V bit MUST be set accordingly depending on 429 whether RTM capability being advertised for IPv4 or IPv6 interface 430 of the node. 432 Application ID (TBA6) will be assigned from the Application 433 Identifiers for TLV 251 IANA registry. The RTM Capability sub-TLV, 434 presented in Figure 4, MUST be included in GENINFO TLV in Application 435 Specific Information. 437 4.6. RSVP-TE Control Plane Operation to Support RTM 439 Throughout this document we refer to an LSR as RTM capable LSR when 440 at least one of its interfaces is RTM capable. Figure 5 provides an 441 example of relationship between roles a network element may have in 442 PTP over MPLS scenario and RTM capability: 444 ----- ----- ----- ----- ----- ----- ----- 445 | A |-----| B |-----| C |-----| D |-----| E |-----| F |-----| G | 446 ----- ----- ----- ----- ----- ----- ----- 448 Figure 5: RTM capable roles 450 o A is a Boundary Clock with its egress port in Master state. Node 451 A transmits PTP messages; 453 o B is the ingress LER for the MPLS LSP and is not RTM capable; 455 o C is the first RTM capable LSR; it initializes the RTM Scratch Pad 456 field and encapsulates PTP messages in the RTM ACH; the 457 transmitted Scratch Pad information includes the residence time 458 measured by C; 460 o D is a transit LSR that is not RTM capable; it passes along the 461 RTM ACH encapsulated PTP message unmodified; 463 o E is the last RTM capable LSR; it updates the Correction field of 464 the PTP message with the value in the Scratch Pad field of the RTM 465 ACH, and removes the RTM ACH encapsulation; 467 o F is the egress LER for the MPLS LSP and is not RTM capable; 469 o G is a Boundary Clock with its ingress port in Slave state. Node 470 G receives PTP messages. 472 An ingress LSR that is configured to perform RTM along a path through 473 an MPLS network to an egress LSR verifies that the selected egress 474 LSR has an interface that supports RTM via the egress LSR's 475 advertisement of the RTM Capability sub-TLV. In the Path message 476 that the ingress LSR uses to instantiate the LSP to that egress LSR 477 it places initialized Record Route Object (RRO) [RFC3209] and RTM Set 478 Object (RSO) [Section 4.7], which tell the egress LSR that RTM is 479 requested for this LSP. 481 In the Resv message that the egress LSR sends in response to the 482 received Path message, it includes initialized RRO and RSO. The RSO 483 contains an ordered list, from egress LSR to ingress LSR, of the RTM 484 capable LSRs along the LSP's path. Each such LSR will use the ID of 485 the first LSR in the RSO in conjunction with the RRO to compute the 486 hop count to its downstream LSR with reachable RTM capable interface. 487 It will also insert its ID at the beginning of the RTM Set Object 488 before forwarding the Resv upstream. 490 After the ingress LSR receives the Resv, it MAY begin sending RTM 491 packets to the first RTM capable LSR on the LSP's path. Each RTM 492 packet has its Scratch Pad field initialized and its TTL set to 493 expire on that first subsequent RTM capable LSR. 495 It should be noted that RTM can also be used for LSPs instantiated 496 using [RFC3209] in an environment in which all interfaces in an IGP 497 support RTM. In this case the RSO MAY be omitted. 499 4.7. RTM_SET Object 501 RTM capable interfaces can be recorded via RTM_SET object (RSO). The 502 RTM Set Class is TBA7. This document defines one C_Type, Type TBA8 503 RTM Set. The RTM_SET object format presented in Figure 6 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | | 509 ~ Sub-objects ~ 510 | | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 Figure 6: RTM Set object format 515 The contents of a RTM_SET object are a series of variable-length data 516 items called sub-objects. The sub-objects are defined in 517 Section 4.7.1 below. 519 The RSO can be present in both RSVP Path and Resv messages. If a 520 Path message contains multiple RSOs, only the first RSO is 521 meaningful. Subsequent RSOs SHOULD be ignored and SHOULD NOT be 522 propagated. Similarly, if in a Resv message multiple RSOs are 523 encountered following a FILTER_SPEC before another FILTER_SPEC is 524 encountered, only the first RSO is meaningful. Subsequent RSOs 525 SHOULD be ignored and SHOULD NOT be propagated. 527 4.7.1. RSO Sub-objects 529 The RTM Set object contains an ordered list, from egress LSR to 530 ingress LSR, of the RTM capable LSRs along the LSP's path. 532 The contents of a RTM_SET object are a series of variable-length data 533 items called sub-objects. Each sub-object has its own Length field. 534 The length contains the total length of the sub-object in bytes, 535 including the Type and Length fields. The length MUST always be a 536 multiple of 4, and at least 8 (smallest IPv4 sub-object). 538 Sub-objects are organized as a last-in-first-out stack. The first 539 -out sub-object relative to the beginning of RSO is considered the 540 top. The last-out sub-object is considered the bottom. When a new 541 sub-object is added, it is always added to the top. 543 Three kinds of sub-objects for RSO are currently defined. 545 4.7.1.1. IPv4 Sub-object 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Type | Length | Flags | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | IPv4 address | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 Figure 7: IPv4 sub-object format 557 Type 559 0x01 IPv4 address 561 Length 563 The Length contains the total length of the sub-object in bytes, 564 including the Type and Length fields. The Length is always 8. 566 IPv4 address 568 A 32-bit unicast host address. 570 Flags 571 TBD 573 4.7.1.2. IPv6 Sub-object 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Type | Length | Flags | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | | 581 | IPv6 address | 582 | | 583 | | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Figure 8: IPv6 sub-object format 588 Type 590 0x02 IPv6 address 592 Length 594 The Length contains the total length of the sub-object in bytes, 595 including the Type and Length fields. The Length is always 20. 597 IPv6 address 599 A 128-bit unicast host address. 601 Flags 603 TBD 605 4.7.1.3. Unnumbered Interface Sub-object 607 0 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Type | Length | Flags | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Router ID | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Interface ID | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 Figure 9: IPv4 sub-object format 619 Type 621 0x03 Unnumbered interface 623 Length 625 The Length contains the total length of the sub-object in bytes, 626 including the Type and Length fields. The Length is always 12. 628 Router ID 630 The Router ID interpreted as discussed in the Section 2 of RFC 631 3447 [RFC3477]. 633 Interface ID 635 The identifier assigned to the link by the LSR specified by the 636 Router ID. 638 Flags 640 TBD 642 5. Data Plane Theory of Operation 644 After instantiating an LSP for a path using RSVP-TE [RFC3209] as 645 described in Section 4.6 or as described in the second paragraph of 646 Section 4 and in Section 4.6, ingress LSR MAY begin sending RTM 647 packets to the first downstream RTM capable LSR on that path. Each 648 RTM packet has its Scratch Pad field initialized and its TTL set to 649 expire on the next downstream RTM-capable LSR. Each RTM-capable LSR 650 on the explicit path receives an RTM packet and records the time at 651 which it receives that packet at its ingress interface as well as the 652 time at which it transmits that packet from its egress interface; 653 this should be done as close to the physical layer as possible to 654 ensure precise accuracy in time determination. The RTM-capable LSR 655 determines the difference between those two times; for 1-step 656 operation, this difference is determined just prior to or while 657 sending the packet, and the RTM-capable egress interface adds it to 658 the value in the Scratch Pad field of the message in progress. Note, 659 for the purpose of calculating a residence time, a common free 660 running clock synchronizing all the involved interfaces may be 661 sufficient, as, for example, 4.6 ppm accuracy leads to 4.6 nanosecond 662 error for residence time on the order of 1 millisecond. 664 For 2-step operation, the difference between packet arrival time (at 665 an ingress interface) and subsequent departure time (from an egress 666 interface) is determined at some later time prior to sending a 667 subsequent follow-up message, so that this value can be used to 668 update the correctionField in the follow-up message. 670 See Section 7 for further details on the difference between 1-step 671 and 2-step operation. 673 The last RTM-capable LSR on the LSP MAY then use the value in the 674 Scratch Pad field to perform time correction, if there is no follow- 675 up message. For example, the egress LSR may be a PTP Boundary Clock 676 synchronized to a Master Clock and will use the value in the Scratch 677 Pad field to update PTP's correctionField. 679 6. Applicable PTP Scenarios 681 The proposed approach can be directly integrated in a PTP network 682 based on the IEEE 1588 delay reqest-response mechanism. The RTM 683 capable LSR nodes act as end-to-end transparent clocks, and typically 684 boundary clocks, at the edges of the MPLS network, use the value in 685 the Scratch Pad field to update the correctionField of the 686 corresponding PTP event packet prior to performing the usual PTP 687 processing. 689 7. One-step Clock and Two-step Clock Modes 691 One-step mode refers to the mode of operation where an egress 692 interface updates the correctionField value of an original event 693 message. Two-step mode refers to the mode of operation where this 694 update is made in a subsequent follow-up message. 696 Processing of the follow-up message, if present, requires the 697 downstream end-point to wait for the arrival of the follow-up message 698 in order to combine correctionField values from both the original 699 (event) message and the subsequent (follow-up) message. In a similar 700 fashion, each 2-step node needs to wait for the related follow-up 701 message, if there is one, in order to update that follow-up message 702 (as opposed to creating a new one. Hence the first node that uses 703 2-step mode MUST do two things: 705 1. Mark the original event message to indicate that a follow-up 706 message will be forthcoming (this is necessary in order to 708 Let any subsequent 2-step node know that there is already a 709 follow-up message, and 711 Let the end-point know to wait for a follow-up message; 713 2. Create a follow-up message in which to put the RTM determined as 714 an initial correctionField value. 716 IEEE 1588v2 [IEEE.1588.2008] defines this behaviour for PTP messages. 718 Thus, for example, with reference to the PTP protocol, the PTPType 719 field identifies whether the message is a Sync message, Follow_up 720 message, Delay_Req message, or Delay_Resp message. The 10 octet long 721 Port ID field contains the identity of the source port, that is, the 722 specific PTP port of the boundary clock connected to the MPLS 723 network. The Sequence ID is the sequence ID of the PTP message 724 carried in the Value field of the message. 726 PTP messages also include a bit that indicates whether or not a 727 follow-up message will be coming. This bit, once it is set by a 728 2-step mode device, MUST stay set accordingly until the original and 729 follow-up messages are combined by an end-point (such as a Boundary 730 Clock). 732 Thus, an RTM packet, containing residence time information relating 733 to an earlier packet, also contains information identifying that 734 earlier packet. 736 For compatibility with PTP, RTM (when used for PTP packets) must 737 behave in a similar fashion. To do this, a 2-step RTM capable egress 738 interface will need to examine the S-bit in the Flags field of the 739 PTP sub-TLV (for RTM messages that indicate they are for PTP) and - 740 if it is clear (set to zero), it MUST set it and create a follow-up 741 PTP Type RTM message. If the S bit is already set, then the RTM 742 capable node MUST wait for the RTM message with the PTP type of 743 follow-up and matching originator and sequence number to make the 744 corresponding residence time update to the Scratch Pad field. 746 In practice an RTM operating according to two-step clock behaves like 747 a two-steps transparent clock. 749 A 1-step capable RTM node MAY elect to operate in either 1-step mode 750 (by making an update to the Scratch Pad field of the RTM message 751 containing the PTP even message), or in 2-step mode (by making an 752 update to the Scratch Pad of a follow-up message when its presence is 753 indicated), but MUST NOT do both. 755 Two main subcases can be identified for an RTM node operating as a 756 two-step clock: 758 A) If any of the previous RTM capable node or the previous PTP clock 759 (e.g. the BC connected to the first LSR), is a two-step clock, the 760 residence time is added to the RTM packet that has been created to 761 include the associated PTP packet (i.e. follow-up message in the 762 downstream direction), if the local RTM-capable LSR is also operating 763 as a two-step clock. This RTM packet carries the related accumulated 764 residence time and the appropriate values of the Sequence Id and Port 765 Id (the same identifiers carried in the packet processed) and the 766 Two-step Flag set to 1. 768 Note that the fact that an upstream RTM-capable node operating in the 769 two-step mode has created a follow-up message does not require any 770 subsequent RTM capable LSR to also operate in the 2-step mode, as 771 long as that RTM-capable LSR forwards the follow-up message on the 772 same LSP on which it forwards the corresponding previous message. 774 A one-step capable RTM node MAY elect to update the RTM follow-up 775 message as if it were operating in two-step mode, however, it MUST 776 NOT update both messages. 778 A PTP event packet (sync) is carried in the RTM packet in order for 779 an RTM node to identify that residence time measurement must be 780 performed on that specific packet. 782 To handle the residence time of the Delay request message on the 783 upstream direction, an RTM packet must be created to carry the 784 residence time on the associated downstream Delay Resp message. 786 The last RTM node of the MPLS network in addition to update the 787 correctionField of the associated PTP packet, must also properly 788 handle the two-step flag of the PTP packets. 790 B) When the PTP network connected to the MPLS and RTM node, operates 791 in one-step clock mode, the associated RTM packet must be created by 792 the RTM node itself. The associated RTM packet including the PTP 793 event packet needs now to indicate that a follow up message will be 794 coming. 796 The last RTM node of the LSP, modeif it receives an RTM message with 797 a PTP payload indicating a follow-up message will be forthcoming, 798 must generate a follow-up message and properly set the two-step flag 799 of the PTP packets. 801 8. IANA Considerations 803 8.1. New RTM G-ACh 805 IANA is requested to reserve a new G-ACh as follows: 807 +-------+----------------------------+---------------+ 808 | Value | Description | Reference | 809 +-------+----------------------------+---------------+ 810 | TBA1 | Residence Time Measurement | This document | 811 +-------+----------------------------+---------------+ 813 Table 1: New Residence Time Measurement 815 8.2. New RTM TLV Registry 817 IANA is requested to create sub-registry in Generic Associated 818 Channel (G-ACh) Parameters Registry called "MPLS RTM TLV Registry". 819 All code points in the range 0 through 127 in this registry shall be 820 allocated according to the "IETF Review" procedure as specified in 821 [RFC5226] . Remaining code points are allocated according to the 822 table below. This document defines the following new values RTM TLV 823 type s: 825 +-----------+-------------+-------------------------+ 826 | Value | Description | Reference | 827 +-----------+-------------+-------------------------+ 828 | 0 | Reserved | This document | 829 | 1 | No payload | This document | 830 | 2 | PTPv2 | This document | 831 | 3 | NTP | This document | 832 | 4-127 | Reserved | IETF Consensus | 833 | 128 - 191 | Reserved | First Come First Served | 834 | 192 - 255 | Reserved | Private Use | 835 +-----------+-------------+-------------------------+ 837 Table 2: RTM TLV Type 839 8.3. New RTM Sub-TLV Registry 841 IANA is requested to create sub-registry in MPLS RTM TLV Registry, 842 requested in Section 8.2, called "MPLS RTM Sub-TLV Registry". All 843 code points in the range 0 through 127 in this registry shall be 844 allocated according to the "IETF Review" procedure as specified in 845 [RFC5226] . Remaining code points are allocated according to the 846 table below. This document defines the following new values RTM sub- 847 TLV types: 849 +-----------+-------------+-------------------------+ 850 | Value | Description | Reference | 851 +-----------+-------------+-------------------------+ 852 | 0 | Reserved | This document | 853 | 1 | PTP 2-step | This document | 854 | 2-127 | Reserved | IETF Consensus | 855 | 128 - 191 | Reserved | First Come First Served | 856 | 192 - 255 | Reserved | Private Use | 857 +-----------+-------------+-------------------------+ 859 Table 3: RTM Sub-TLV Type 861 8.4. RTM Capability sub-TLV 863 IANA is requested to assign a new type for RTM Capability sub-TLV 864 from future OSPF Extended Link TLV Sub-TLVs registry as follows: 866 +-------+----------------+---------------+ 867 | Value | Description | Reference | 868 +-------+----------------+---------------+ 869 | TBA2 | RTM Capability | This document | 870 +-------+----------------+---------------+ 872 Table 4: RTM Capability sub-TLV 874 8.5. IS-IS RTM Application ID 876 IANA is requested to assign a new Application ID for RTM from the 877 Application Identifiers for TLV 251 registry as follows: 879 +-------+-------------+---------------+ 880 | Value | Description | Reference | 881 +-------+-------------+---------------+ 882 | TBA3 | RTM | This document | 883 +-------+-------------+---------------+ 885 Table 5: IS-IS RTM Application ID 887 8.6. RTM_SET Object RSVP Class Number, Class Type and Sub-object Types 889 IANA is requested to assign a new Class Number for RTM_SET object as 890 follows: 892 +-------+----------------+---------------+ 893 | Value | Description | Reference | 894 +-------+----------------+---------------+ 895 | TBA4 | RTM_SET object | This document | 896 +-------+----------------+---------------+ 898 Table 6: RTM_SET object Class 900 IANA is requested to assign a new Class Type for RTM_SET object as 901 follows: 903 +-------+-------------+---------------+ 904 | Value | Description | Reference | 905 +-------+-------------+---------------+ 906 | TBA5 | RTM Set | This document | 907 +-------+-------------+---------------+ 909 Table 7: RTM_SET object Class Type 911 IANA requested to create new sub-registry for sub-object types of 912 RTM_SET object as follows: 914 +-----------+----------------------+-------------------------+ 915 | Value | Description | Reference | 916 +-----------+----------------------+-------------------------+ 917 | 0 | Reserved | | 918 | 1 | IPv4 address | This document | 919 | 2 | IPv6 address | This document | 920 | 3 | Unnumbered interface | This document | 921 | 4-127 | Reserved | IETF Consensus | 922 | 128 - 191 | Reserved | First Come First Served | 923 | 192 - 255 | Reserved | Private Use | 924 +-----------+----------------------+-------------------------+ 926 Table 8: RTM_SET object sub-object types 928 9. Security Considerations 930 Routers that support Residence Time Measurement are subject to the 931 same security considerations as defined in [RFC5586] . 933 In addition - particularly as applied to use related to PTP - there 934 is a presumed trust model that depends on the existence of a trusted 935 relationship of at least all PTP-aware nodes on the path traversed by 936 PTP messages. This is necessary as these nodes are expected to 937 correctly modify specific content of the data in PTP messages and 938 proper operation of the protocol depends on this ability. 940 As a result, the content of the PTP-related data in RTM messages that 941 will be modified by intermediate nodes cannot be authenticated, and 942 the additional information that must be accessible for proper 943 operation of PTP 1-step and 2-step modes MUST be accessible to 944 intermediate nodes (i.e. - MUST NOT be encrypted in a manner that 945 makes this data inaccessible). 947 While it is possible for a supposed compromised LSR to intercept and 948 modify the G-ACh content, this is an issue that exists for LSRs in 949 general - for any and all data that may be carried over an LSP - and 950 is therefore the basis for an additional presumed trust model 951 associated with existing LSPs and LSRs. 953 The ability for potentially authenticating and/or encrypting RTM and 954 PTP data that is not needed by intermediate RTM/PTP-capable nodes is 955 for further study. 957 Security requirements of time protocols are provided in RFC 7384 958 [RFC7384]. 960 10. Acknowledgements 962 Authors want to thank Loa Andersson for his thorough review and 963 thoghtful comments. 965 11. References 967 11.1. Normative References 969 [I-D.ietf-ospf-ospfv3-lsa-extend] 970 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 971 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-06 972 (work in progress), February 2015. 974 [I-D.ietf-ospf-prefix-link-attr] 975 Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 976 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 977 Advertisement", draft-ietf-ospf-prefix-link-attr-06 (work 978 in progress), June 2015. 980 [IEEE.1588.2008] 981 "Standard for a Precision Clock Synchronization Protocol 982 for Networked Measurement and Control Systems", 983 IEEE Standard 1588, March 2008. 985 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 986 Requirement Levels", BCP 14, RFC 2119, 987 DOI 10.17487/RFC2119, March 1997, 988 . 990 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 991 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 992 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 993 . 995 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 996 in Resource ReSerVation Protocol - Traffic Engineering 997 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 998 . 1000 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 1001 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 1002 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 1003 February 2006, . 1005 [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual 1006 Circuit Connectivity Verification (VCCV): A Control 1007 Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, 1008 December 2007, . 1010 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 1011 "MPLS Generic Associated Channel", RFC 5586, 1012 DOI 10.17487/RFC5586, June 2009, 1013 . 1015 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1016 "Network Time Protocol Version 4: Protocol and Algorithms 1017 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1018 . 1020 [RFC6423] Li, H., Martini, L., He, J., and F. Huang, "Using the 1021 Generic Associated Channel Label for Pseudowire in the 1022 MPLS Transport Profile (MPLS-TP)", RFC 6423, 1023 DOI 10.17487/RFC6423, November 2011, 1024 . 1026 [RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising 1027 Generic Information in IS-IS", RFC 6823, 1028 DOI 10.17487/RFC6823, December 2012, 1029 . 1031 11.2. Informative References 1033 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 1034 in Support of Generalized Multi-Protocol Label Switching 1035 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 1036 . 1038 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1039 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1040 DOI 10.17487/RFC5226, May 2008, 1041 . 1043 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 1044 Measurement for MPLS Networks", RFC 6374, 1045 DOI 10.17487/RFC6374, September 2011, 1046 . 1048 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 1049 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 1050 October 2014, . 1052 Authors' Addresses 1054 Greg Mirsky 1055 Ericsson 1057 Email: gregory.mirsky@ericsson.com 1059 Stefano Ruffini 1060 Ericsson 1062 Email: stefano.ruffini@ericsson.com 1064 Eric Gray 1065 Ericsson 1067 Email: eric.gray@ericsson.com 1069 John Drake 1070 Juniper Networks 1072 Email: jdrake@juniper.net 1073 Stewart Bryant 1074 Cisco Systems 1076 Email: stbryant@cisco.com 1078 Alexander Vainshtein 1079 ECI Telecom 1081 Email: Alexander.Vainshtein@ecitele.com