idnits 2.17.1 draft-ietf-tictoc-1588overmpls-06.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 : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost Multipath). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: To ensure that the label on the top of the label stack is the Timing LSP Label, PHP MUST not be used. -- The document date (April 28, 2014) is 3649 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC-4448' is mentioned on line 464, but not defined == Unused Reference: 'RFC3630' is defined on line 842, but no explicit reference was found in the text == Unused Reference: 'RFC3784' is defined on line 846, but no explicit reference was found in the text == Unused Reference: 'RFC4970' is defined on line 850, but no explicit reference was found in the text == Unused Reference: 'RFC4971' is defined on line 854, but no explicit reference was found in the text == Unused Reference: 'RFC5120' is defined on line 858, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 862, but no explicit reference was found in the text == Unused Reference: 'RFC5329' is defined on line 865, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) -- Obsolete informational reference (is this intentional?): RFC 3784 (Obsoleted by RFC 5305) -- Obsolete informational reference (is this intentional?): RFC 4970 (Obsoleted by RFC 7770) -- Obsolete informational reference (is this intentional?): RFC 4971 (Obsoleted by RFC 7981) Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TICTOC Working Group S. Davari 3 Internet-Draft A. Oren 4 Intended status: Experimental Broadcom Corp. 5 Expires: October 30, 2014 M. Bhatia 6 P. Roberts 7 Alcatel-Lucent 8 L. Montini 9 Cisco Systems 10 April 28, 2014 12 Transporting Timing messages over MPLS Networks 13 draft-ietf-tictoc-1588overmpls-06 15 Abstract 17 This document defines the method for transporting Timing messages 18 such as PTP and NTP over an MPLS network. The method allows for the 19 easy identification of these PDUs at the port level to allow for port 20 level processing of these PDUs in both LERs and LSRs. 22 The basic idea is to transport Timing messages inside dedicated MPLS 23 LSPs. These LSPs only carry Timing messages and possibly Control and 24 Management packets, but they do not carry customer traffic. 26 Two methods for transporting Timing messages over MPLS are defined. 27 The first method is to transport Timing messages directly over the 28 dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for 29 MPLS networks. The second method is to transport Timing messages 30 inside a PW via Ethernet encapsulation. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on October 30, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9 72 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . 10 74 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . . 13 76 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . 14 77 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . . 14 78 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . . 14 79 6.3. Other Timing Encapsulation methods . . . . . . . . . . . . 15 81 7. Timing message Processing . . . . . . . . . . . . . . . . . . 16 83 8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 17 85 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 91 12. OAM, Control and Management . . . . . . . . . . . . . . . . . 21 93 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 22 95 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . . 23 97 15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 24 98 15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . . 24 99 15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . . 24 100 15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . . 24 102 16. Other considerations . . . . . . . . . . . . . . . . . . . . . 26 104 17. Security Considerations . . . . . . . . . . . . . . . . . . . 27 106 18. Applicability Statement . . . . . . . . . . . . . . . . . . . 28 108 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 110 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 111 21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 112 21.1. Normative References . . . . . . . . . . . . . . . . . . . 31 113 21.2. Informative References . . . . . . . . . . . . . . . . . . 31 115 Appendix 1. Appendix . . . . . . . . . . . . . . . . . . . . . . 34 116 1.1. Routing extensions for Timing-aware Routers . . . . . . . 34 117 1.2. Signaling Extensions for Creating Timing LSPs . . . . . . 34 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC2119 [RFC2119]. 124 When used in lower case, these words convey their typical use in 125 common language, and are not to be interpreted as described in 126 RFC2119 [RFC2119]. 128 1. Introduction 130 The objective of Precision Time Protocol (PTP) and Network Timing 131 Protocol (NTP) are to synchronize independent clocks running on 132 separate nodes of a distributed system. 134 [IEEE-1588] defines PTP messages for frequency, phase and time 135 synchronization. The PTP messages include PTP PDUs over UDP/IP 136 (Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Annex F of 137 [IEEE-1588]). This document defines mapping and transport of the PTP 138 messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PTP 139 defines several clock types: ordinary clocks, boundary clocks, end- 140 to-end transparent clocks, and peer-to-peer transparent clocks. 141 Transparent clocks require intermediate nodes to update correction 142 field inside PTP message that reflects the transit time in the node. 144 [RFC5905] defines NTP messages for clock and time synchronization. 145 The PTP messages (PDUs) are transported over UDP/IP. This document 146 defines mapping and transport of the NTP messages defined in 147 [RFC5905] over MPLS networks. 149 One key attribute of all of these Timing messages is that the Time 150 stamp processing should occur as close as possible to the actual 151 transmission and reception at the physical port interface. This 152 targets optimal time and/or frequency recovery by avoiding variable 153 delay introduced by queues internal to the clocks. 155 To facilitate the fast and efficient recognition of Timing messages 156 at the port level when the Timing messages are carried over MPLS 157 LSPs, this document defines the specific encapsulations that should 158 be used. In addition, it can be expected that there will exist LSR/ 159 LERs where only a subset of the physical ports will have the port- 160 based Timing message processing capabilities. In order to ensure 161 that the LSPs carrying Timing packets always enter and exit ports 162 with this capability, routing extensions can be defined to advertise 163 this capability on a port basis and to allow for the establishment of 164 LSPs that only transit such ports. While this path establishment 165 restriction may be applied only at the LER Ingress and/or egress 166 ports, it becomes more important when using transparent clock capable 167 LSRs in the path. 169 Port based Timing message processing involves Timing message 170 recognition. Once the Timing messages are recognized they can be 171 modified based on the reception or transmission Time-stamp. 173 This document provides two methods for transporting Timing messages 174 over MPLS. One is applicable to MPLS environment and the other one 175 is applicable to MPLS/MPLS-TP environment. 177 The solution involves transporting Timing messages over dedicated 178 LSPs called Timing LSPs. These LSPs carry Timing messages and MAY 179 carry Management and control messages, but not data plane client 180 traffic. Timing LSPs can be established statically or via signaling. 181 Extensions to control plane (OSPF, ISIS, etc.) is required to enable 182 routers to distribute their Timing processing capabilities over MPLS 183 to other routers. However such extensions are outside the scope of 184 this document. 186 When signaling is used to setup the PTP LSP, extensions to signaling 187 protocols (e.g., RSVP-TE) are required for establishing PTP LSPs. 188 However such extensions are outside the scope of this document. 190 While the techniques included herein allow for the establishment of 191 paths optimized to include Time-stamping capable links, the 192 performance of the Slave clocks is outside the scope of this 193 document. 195 At the time of publishing this specification, Transparent Clocking 196 (TC) is only defined for PTP. Therefore at this time any part of 197 this specification that talks about Transparent Clocking applies only 198 to PTP. 200 2. Terminology 202 1588: The timing and synchronization as defined by IEEE 1588. 204 NTP: The timing and synchronization protocol defined by IETF RFC-1305 205 and RFC-5905. 207 PTP: The timing and synchronization protocol used by 1588. 209 Master Clock: The source of 1588 timing to a set of slave clocks. 211 Master Port: A port on a ordinary or boundary clock that is in Master 212 state. This is the source of timing toward slave ports. 214 Slave Clock: A receiver of 1588 timing from a master clock. 216 Slave Port: A port on a boundary clock or ordinary clock that is 217 receiving timing from a master clock. 219 Ordinary Clock: A device with a single PTP port. 221 Transparent Clock. A device that measures the time taken for a PTP 222 event message to transit the device and then updates the 223 correctionField of the message with this transit time. 225 Boundary Clock: A device with more than one PTP port. Generally 226 boundary clocks will have one port in slave state to receive timing 227 and then other ports in master state to re-distribute the timing. 229 PTP LSP: An LSP dedicated to carry PTP messages 231 PTP PW: A PW within a PTP LSP that is dedicated to carry PTP 232 messages. 234 CW: Pseudowire Control Word 236 LAG: Link Aggregation 238 ECMP: Equal Cost Multipath 240 CF: Correction Field, a field inside certain PTP messages (message 241 type 0-3)that holds the accumulative transit time inside intermediate 242 switches 244 Timing messages: Timing Protocol messages that are exchanged between 245 routers in order to establish a synchronized clock. 247 3. Problem Statement 249 [IEEE-1588] has defined methods for transporting PTP messages over 250 Ethernet and IP networks. [RFC5905] has defined the method of 251 transporting NTP messages over IP networks. There is a need to 252 transport Timing messages over MPLS networks while supporting the 253 Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (OC) 254 functionality in the LER and LSRs in the MPLS network. 256 There are multiple ways of transporting Timing over MPLS. However, 257 there is a requirement to limit the possible encapsulation options to 258 simplify the Timing message identification and processing required at 259 the port level. 261 When Timing-awareness is needed, Timing messages should not be 262 transported over LSPs or PWs that are carrying customer traffic 263 because LSRs perform Label switching based on the top label in the 264 stack. To detect Timing messages inside such LSPs require special 265 hardware to do deep packet inspection at line rate. Even if such 266 hardware exists, the payload cant be deterministically identified by 267 LSRs because the payload type is a context of the PW label, and the 268 PW label and its context are only known to the Edge routers (PEs/ 269 LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, CES, 270 etc). Even if one restricts an LSP to only carry Ethernet PWs, the 271 LSRs dont have the knowledge of whether PW Control Word (CW) is 272 present or not and therefore can not deterministically identify the 273 payload. 275 A generic method is defined in this document that does not require 276 deep packet inspection at line rate, and can deterministically 277 identify Timing messages. This method can be used to detect Timing 278 Messages in both one-step and two-step clock implementations of 279 ordinary, boundary and transparent clocks. 281 4. Timing over MPLS Architecture 283 Timing messages are exchange between Timing ports on ordinary and 284 boundary clocks. Boundary clocks terminate the Timing messages and 285 act as master for other boundary clocks or for slave clocks. End-to- 286 End Transparent clocks do not terminate the Timing messages but they 287 do modify the contents of the Timing messages as they transit across 288 the transparent clock. 290 Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent Clock 291 (TC) could be implemented in either LERs or LSRs. 293 An example is shown in Figure 1, where the LERs act as Ordinary Clock 294 (OC) and are the initiating/terminating point for Timing messages. 295 The ingress LER encapsulates the Timing messages in Timing LSP and 296 the Egress LER terminates the Timing LSP. The LSRs act as 297 Transparent Clock (TC) and just update the Timing field in the Timing 298 messages. 300 +--------+ +-------+ +-------+ +-------+ +--------+ 301 |Switch, | | | | | | | |Switch, | 302 | Router |-----| LER |-----| LSR |-----| LER |-----| Router | 303 | | | OC | | TC | | OC | | | 304 +--------+ +-------+ +-------+ +-------+ +--------+ 305 / \ 306 +-------+ / \ +-------+ 307 | LER | / \ | LER | 308 | Master|---/ \---| Slave | 309 | Clock | | Clock | 310 +-------+ +-------+ 312 Figure (1) - Deployment example 1 of timing over MPLS network 314 Another example is shown in Figure 2, where LERs terminate the Timing 315 messages received from switch/routers that are outside of the MPLS 316 network acting as OC or BC. In this example LERs regenerate the 317 clock and initiate timing messages encapsulated in Timing LSP toward 318 the MPLS network, while the LSRs act as Transparent Clock (TC) and 319 just update the Timing field in the Timing messages, which are 320 already encapsulated in Timing LSPs. 322 +--------+ +-------+ +-------+ +-------+ +--------+ 323 |Switch, | | | | | | | |Switch, | 324 | Router |-----| LER |-----| LSR |-----| LER |-----| Router | 325 | OC/BC | | BC | | TC | | BC | | OC/BC | 326 +--------+ +-------+ +-------+ +-------+ +--------+ 327 Figure (2) - Deployment example 2 of timing over MPLS network 329 Another example is shown in Figure 3, where LERs do not terminate the 330 Timing messages received from switch/routers that are outside of the 331 MPLS network acting as OC, TC or BC. The LERs act as TC and update 332 the Timing field in the Timing messages as they transit the LER, 333 while encapsulating them in timing LSP. The LSRs also act as 334 Transparent Clock (TC) and just update the Timing field in the Timing 335 messages which are already encapsulated in Timing LSPs. 337 +--------+ +-------+ +-------+ +-------+ +--------+ 338 |Switch, | | | | | | | |Switch, | 339 | Router |-----| LER |-----| LSR |-----| LER |-----| Router | 340 |OC/TC/BC| | TC | | TC | | TC | |OC/TC/BC| 341 +--------+ +-------+ +-------+ +-------+ +--------+ 343 Figure (3) - Deployment example 3 of timing over MPLS network 345 Another example is shown in Figure 4, where LERs and LSRs support 346 Boundary Clocks. A single-hop LSP is created between two adjacent 347 LSRs engaged in BC operation. Other methods such as PTP transport 348 over Ethernet MAY be used for transporting timing messages if the 349 link between the two routers is Ethernet. 351 +--------+ +-------+ +-------+ +-------+ +--------+ 352 |Switch, | | | | | | | |Switch, | 353 | Router |-----| LER |-----| LSR |-----| LER |-----| Router | 354 | OC/BC | | BC | | BC | | BC | | OC/BC | 355 +--------+ +-------+ +-------+ +-------+ +--------+ 357 Figure (4) - Deployment example 3 of timing over MPLS network 359 An MPLS domain MAY serve multiple customers. In these cases the MPLS 360 domain (maintained by a service provider) may provide timing services 361 to multiple customers, each having their own Timing domain. 363 The Timing over MPLS architecture assumes full mesh of Timing LSPs 364 between all LERs supporting this specification. It supports 365 Point-to- point (VPWS) and Multipoint (VPLS) services. This means 366 that a customer may purchase a Point-to-point Timing service between 367 two customer sites or a Multipoint Timing service between more than 368 two customer sites. 370 The Timing over MPLS architecture supports P2P or P2MP Timing LSPs. 371 This means that the Timing Multicast messages such as PTP Multicast 372 event messages can be transported over P2MP Timing LSP or be 373 replicated and transported over many P2P Timing LSPs. 375 Timing messages, that do not require Time stamping or Correction 376 Field update MAY be transported over Timing LSPs to simplify hardware 377 and software. 379 PTP Announce messages that determine the Timing LSP terminating point 380 behavior such as BC/OC/TC SHOULD be transported over the Timing LSP 381 to simplify hardware and software. 383 5. Dedicated LSPs for Timing messages 385 Many methods have been considered for identifying the Timing messages 386 when they are encapsulated in MPLS such as using GAL/G-ACH or a new 387 reserved label. These methods were not attractive since they either 388 required deep packet inspection at line rate in the intermediate LSRs 389 or they required use of a scarce new reserved label. Also one of the 390 goals was to reuse existing OAM mechanisms. 392 The method defined in this document can be used by LER and LSRs to 393 identify Timing messages in MPLS tunnels by just looking at the top 394 label in the MPLS label stack, which only carry Timing messages as 395 well as OAM, but not data plane client traffic. 397 Compliant implementations MUST use dedicated LSPs to carry Timing 398 messages over MPLS. These LSPs are herein referred to as "Timing 399 LSPs" and the labels associated with these LSPs as "Timing LSP 400 labels". The Timing LSPs that runs between Ingress and Egress LERs 401 MUST be co-routed. Alternatively, a single bidirectional co-routed 402 LSP can be used. 404 Co-routing of the two directions is required to limit the difference 405 in the delays in the Master clock to Slave clock direction compared 406 to the Slave clock to Master clock direction. The Timing LSP MAY be 407 MPLS LSP/MPLS-TP LSP. 409 The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS. 410 New Extensions to RSVP-TE/GMPLS TLVs are required; however they are 411 outside the scope of this document. 413 The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such as 414 BFD and LSP Ping but the LSP data plane client plane traffic MUST be 415 Timing packets only. 417 6. Timing over LSP Encapsulation 419 This standard defines two methods for carrying Timing messages over 420 MPLS. The first method is carrying UDP/IP encapsulated Timing 421 messages over Timing LSPs, and the second method, is carrying 422 Ethernet encapsulated Timing messages over Ethernet PWs inside Timing 423 LSPs. 425 6.1. Timing over UDP/IP over MPLS Encapsulation 427 The simplest method of transporting Timing messages over MPLS is to 428 encapsulate Timing PDUs in UDP/IP and then encapsulate them in Timing 429 LSP. This format is shown in Figure 4. 431 +----------------------+ 432 | Timing LSP Label | 433 +----------------------+ 434 | IPv4/6 | 435 +----------------------+ 436 | UDP | 437 +----------------------+ 438 | Timing PDU | 439 +----------------------+ 441 Figure (4) - Timing over UDP/IP over MPLS Encapsulation 443 This encapsulation is very simple and is useful when the network 444 between Timing Master Clock and Slave Clock is MPLS network. 446 In order for an LER/LSR to process Timing messages, the Timing LSP 447 Label must be at the top label of the label stack. The LER/LSR MUST 448 know that the Timing LSP Label is used for carrying Timing messages. 449 This can be accomplished via static configuration or via RSVP-TE 450 signaling. 452 The UDP/IP encapsulation of PTP MUST follow Annex D and E of 453 [IEEE-1588]. While the UDP/IP encapsulation of NTP MUST follow 454 [RFC5905]. 456 6.2. Timing over PW Encapsulation 458 Another method of transporting Timing over MPLS networks is by 459 encapsulating Timing PDUs in PW which in turn is transported over 460 Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448], 461 shown in Fig 5(A) MUST be used and the Ethernet encapsulation of PTP 462 MUST follow Annex F of [IEEE-1588]. 464 The RAW mode or Tagged mode defined in [RFC-4448] MAY be used and the 465 Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The 466 Timing over PW encapsulation MUST use the Control Word (CW) as 467 specified in [RFC4448] to ensure proper detection of PTP messages 468 inside the MPLS packets for Timing over LSP and Timing over PW 469 encapsulation. The use of Sequence Number in the CW is optional. 471 Timing over PW encapsulation for NTP MUST use NTP over UDP/IP over PW 472 (the IP PW discussed in [RFC4447]) shown in Fig 5(B). 474 +-----------------+ +----------------+ 475 |Timing LSP Label | |Timing LSP Label| 476 +-----------------+ +----------------+ 477 | PW Label | | PW Label | 478 +-----------------+ +----------------+ 479 | Control Word | | IP | 480 +-----------------+ +----------------+ 481 | Ethernet | | UDP | 482 | Header | +----------------+ 483 +-----------------+ | Timing PDU | 484 |S-VLAN (Optional)| | | 485 +-----------------+ +----------------+ 486 |C-VLAN (Optional)| (B) 487 +-----------------+ 488 | Timing PDU | 489 | | 490 +-----------------+ 491 (A) 493 Figure (5) - Timing over PW Encapsulations 495 In order for an LSR to process PTP messages, the top label of the 496 label stack (the Tunnel Label) MUST be a Timing label. 498 6.3. Other Timing Encapsulation methods 500 In future other timing encapsulation methods may be introduced, such 501 as a new shim header after the Bottom of Stack to carry the Timing 502 information. Such new encapsulations are outside the scope of this 503 document. 505 7. Timing message Processing 507 Each Timing protocol such as PTP and NTP, define their set of Timing 508 messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, 509 FOLLOW_UP, etc messages. 511 Some of the Timing messages require time stamping or correction field 512 update at port level and some dont. It is the job of the LER/LSR to 513 parse the timing message and find out the type of the Timing message 514 and decide whether and how to Time- stamp it (e.g., BC) or update 515 correction field(e.g., TC). 517 For example the following PTP messages (called Event messages) 518 require time-stamping or correction field update: 520 o SYNC 522 o DELAY_REQ (Delay Request) 524 o PDELAY_REQ (Peer Delay Request) 526 o PDELAY_RESP (Peer Delay Response) 528 SYNC and DELAY_REQ are exchanged between Master Clock and Slave Clock 529 and MUST be transported over PTP LSPs. PDELAY_REQ and PDELAY_RESP 530 are exchanged between adjacent PTP clocks (i.e. Master, Slave, 531 Boundary, or Transparent) and SHOULD be transported over single hop 532 PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP, 533 and PDELAY_RESP_FOLLOW_UP messages MUST also be transported over the 534 PTP LSPs. 536 For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be 537 transported over two PTP LSPs that are in opposite directions. These 538 PTP LSPs, which are in opposite directions MUST be congruent and co- 539 routed. Alternatively, a single bidirectional co-routed LSP can be 540 used. 542 Except as indicated above for the two-step PTP clocks, Non-Event PTP 543 message types do not need to be processed by intermediate routers. 544 These message types MAY be carried in PTP Tunnel LSPs. 546 8. Protection and Redundancy 548 In order to ensure continuous uninterrupted operation of slave 549 clocks, usually as a general practice, slave clocks (or ports) track 550 redundant master clocks. 552 It is the responsibility of the network operator to ensure that 553 physically disjoint Timing LSPs are established between a slave clock 554 (or port) and redundant master clocks (or ports). 556 When a slave clock (or port) listens to redundant master clocks or 557 ports, any prolonged Timing LSP outage will trigger the slave clock 558 or port to switch to a redundant master clock or port. 560 LSP/PW protection such as Linear protection Switching (1:1, 1+1), 561 Ring protection switching or MPLS Fast Reroute (FRR) can switch to an 562 alternative path that can cause a change in delay, which if 563 undetected by the slave clock, can reduce accuracy of the slave 564 clock. While it is expected that most Slave clocks will be able to 565 detect the change in delay, this specification still recommends that 566 protection switching MUST NOT be used, unless the operator knows that 567 the protection switching will not have any adverse effect on the 568 slave clock. 570 9. ECMP 572 To ensure the optimal operation of slave clocks and avoid error 573 introduced by forward and reverse path delay asymmetry, the physical 574 path for Timing messages from master clock to slave Clock and vice 575 versa must be the same for all Event Timing messages listed in 576 section 7. 578 Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost 579 Multipath). 581 10. PHP 583 To ensure that the label on the top of the label stack is the Timing 584 LSP Label, PHP MUST not be used. 586 11. Entropy 588 To ensure all Timing messages in a Timing LSP take the same path, 589 Entropy Label MUST NOT be used for the Timing LSP [RFC6790] and 590 Entropy Label MUST NOT be used for the PWs that are carried inside 591 Timing LSP [RFC6391]. 593 12. OAM, Control and Management 595 In order to monitor Timing LSPs and their encapsulated PWs, they MUST 596 be able to carry OAM and management messages. These management 597 messages MUST be differentiated from Timing messages via already 598 defined IETF methods. 600 For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY run 601 over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These 602 Management protocols can easily be identified by the UDP Destination 603 Port number or by GAL/G-ACH respectively. 605 Also BFD, LSP-Ping and other management messages MAY run over the PWs 606 encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3 or 607 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is going 608 to be deprecated by IETF). In this case G-ACH, PW label (TTL=1) or 609 GAL-ACH are used to identify such management messages. 611 13. QoS Considerations 613 In network deployments where not every LSR/LER is Timing-aware, it is 614 important to reduce the impact of the non-Timing-aware LSR/LERs on 615 the timing recovery in the slave clock. The Timing messages are time 616 critical and must be treated with the highest priority. Therefore 617 Timing over MPLS messages must be treated with the highest priority 618 in the routers. This can be achieved by proper setup of Timing LSPs. 620 It is recommended that the Timing LSPs are setup or configured 621 properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC2697] 622 for drop eligibility. 624 14. FCS and Checksum Recalculation 626 When time-stamp generation and timing packet adjustment is performed 627 near the physical port hardware, the process MUST include 628 recalculation of the Ethernet FCS. Also FCS retention for the 629 payload Ethernet described in [RFC4720] MUST NOT be used. 631 For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum 632 may be required as per UDP transport standards. 634 When UDP checksum is used, each Timing-aware LER/LSR must either 635 incrementally update the UDP checksum after Time stamping or 636 Correction Field update or verify the UDP checksum on reception from 637 upstream and recalculate the checksum completely on transmission to 638 downstream node after Time stamping or Correction Field update. 640 15. Behavior of LER/LSR 642 Timing-capable/aware LERs and LSRs are routers that have one or more 643 interfaces that can perform Timing operations (OC/BC/TC) on Timing 644 packets and are configured to do so. Timing-capable/aware LERs and 645 LSRs can advertise their Timing-capability per-interface via control 646 plane such as OSPF or IS-IS. The Timing-capable/aware LERs can then 647 signals Timing LSPs via RSVP-TE signaling. Alternatively the Timing 648 capability of LER and LSRs may be configured in a centralized 649 controller and the Timing LSP may be setup using manual configuration 650 or other methods such as SDN. 652 15.1. Behavior of Timing-capable/aware LER 654 When a Timing-capable/aware LER behaves as a Transparent clock and 655 receives a Timing message from a Timing-capable/aware non-MPLS 656 interface, the LER updates the Correction Field (CF) and encapsulates 657 and forwards the timing message over previously established Timing 658 LSP. Also when a Timing message is received from a Timing-capable/ 659 aware MPLS interface, LER updates the Correction Filed (CF) and 660 decapsulates the MPLS encapsulation and forwards the timing message 661 to a non-MPLS interface. 663 When a Timing-capable/aware LER behaves as a Boundary clock and 664 receives a Timing message from a Timing-capable/aware non MPLS 665 interface, the LER Timestamps the Timing packet and sends it to the 666 LERs Boundary clock processing module. Also when a Timing message is 667 received from a Timing- capable/aware MPLS interface, the LER 668 Timestamps the Timing packet and sends it to the LERs Boundary clock 669 processing module. 671 When a Timing-capable/aware LER behaves as an Ordinary Clock toward 672 the MPLS network, and receives a Timing message from a Timing- 673 capable/aware MPLS interface, the LER Timestamps the Timing packet 674 and sends it to the LERs Ordinary clock processing module. 676 15.2. Behavior of Timing-capable/aware LSR 678 A Timing-capable/aware LSR behaves as a Transparent clock and 679 receives a Timing message from a Timing-capable/aware MPLS interface. 680 The LSR updates the Correction Filed (CF) and forwards the timing 681 message over another MPLS interface. 683 15.3. Behavior of non-Timing-capable/aware LSR 685 It is most beneficial when all LSRs in the path of a Timing LSP be 686 timing-Capable/aware LSRs. This would ensure the highest quality 687 time and clock synchronization by Timing Slave Clocks. However, this 688 specification does not mandate that all LSRs in path of a Timing LSP 689 be Timing- capable/aware. 691 Non-Timing-capable/aware LSRs just switch the packets encapsulated in 692 Timing LSPs and dont perform any Timing operation (TC). However as 693 explained in QoS section the Timing over MPLS packets MUST be still 694 be treated with the highest priority based on their Traffic Class 695 (TC) marking. 697 16. Other considerations 699 [IEEE-1588] defines an optional peer-to-peer Transparent clocking 700 that requires peer delay measurement between two adjacent Timing- 701 capable/ aware routers/switches. Peer delay measurement messages 702 need to be time stamped and terminated by the Timing-capable/aware 703 routers/ switches. This means that two adjacent LSRs may be engaged 704 in a peer delay measurement. 706 For transporting such peer delay measurement messages a single-hop 707 LSP SHOULD to be created between the two adjacent LSRs engaged in 708 peer delay measurement to carry peer delay measurement messages. 709 Other methods such as PTP transport over Ethernet MAY be used for 710 transporting peer delay measurement messages if the link between the 711 two routers is Ethernet. 713 In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/ ware 714 routers/switches MUST maintain a list of all the neighbors it needs 715 to send a PDelay_Req to, where each neighbor corresponds to a timing 716 LSP. 718 The use of Explicit Null Label (Label= 0 or 2) is acceptable as long 719 as either the Explicit Null label is the bottom of stack label 720 (applicable only to UDP/IP encapsulation) or the label below the 721 Explicit Null label is a PTP label. 723 17. Security Considerations 725 MPLS PW security considerations in general are discussed in [RFC3985] 726 and [RFC4447],and those considerations also apply to this document. 728 An experimental security protocol is defined in [IEEE-1588].The PTP 729 security extension and protocol provides group source authentication, 730 message integrity, and replay attack protection for PTP messages. 732 When the MPLS network (provider network) serves multiple customers, 733 it is important to maintain and process each customers clock and 734 Timing messages separately from other customers to ensure there is no 735 cross- customer effect. For example if an LER BC is synchronized to 736 a specific grandmaster, belonging to customer A, then the LER MUST 737 use that BC clock only for customer A to ensure that customer A 738 cannot attack other customers by manipulating its time. 740 Timing messages MAY be encrypted or authenticated, provided that the 741 LERs/LSRs that are Timing capable/aware can authenticate/ decrypt the 742 timing messages. 744 18. Applicability Statement 746 The Timing over MPLS transport methods described in this document 747 apply to the following network Elements: 749 o An LER receives IP or Ethernet Encapsulated Timing messages from a 750 non-MPLS interface and forwards them as MPLS encapsulated Timing 751 messages over Timing LSP, while performing Transparent Clock 752 functionality 754 o An LER receives MPLS encapsulated Timing messages from a Timing 755 LSP and forwards them to non-MPLS interface as IP or Ethernet 756 Encapsulated Timing messages, while performing Transparent Clock 757 functionality 759 o An LER receives MPLS encapsulated Timing messages from a Timing 760 LSP and terminates them, while performing the OC or BC 761 functionality 763 o An LSR receives MPLS encapsulated Timing messages from a Timing 764 LSP and forwards them to another MPLS interface, while performing 765 the TC functionality 767 This document also supports the case where not all LSRs are Timing- 768 capable/aware. It also supports the case where not all LER/LSR 769 interfaces are Timing-capable/aware. 771 19. Acknowledgements 773 The authors would like to thank Luca Martini, Ron Cohen, Yaakov 774 Stein, Tal Mizrahi, Stefano Ruffini, Peter Meyer and other members of 775 IETF for reviewing and providing feedback on this draft. 777 20. IANA Considerations 779 There are no IANA requirements in this specification. 781 21. References 783 21.1. Normative References 785 [IEEE-1588] 786 IEEE 1588-2008, "IEEE Standard for a Precision Clock 787 Synchronization Protocol for Networked Measurement and 788 Control Systems". 790 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 791 Requirement Levels", BCP 14, RFC 2119, March 1997. 793 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 794 Edge (PWE3) Architecture", RFC 3985, March 2005. 796 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 797 Proxies (ND Proxy)", RFC 4389, April 2006. 799 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 800 Heron, "Pseudowire Setup and Maintenance Using the Label 801 Distribution Protocol (LDP)", RFC 4447, April 2006. 803 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, 804 "Encapsulation Methods for Transport of Ethernet over MPLS 805 Networks", RFC 4448, April 2006. 807 [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire 808 Emulation Edge-to-Edge (PWE3) Frame Check Sequence 809 Retention", RFC 4720, November 2006. 811 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 812 Connectivity Verification (VCCV): A Control Channel for 813 Pseudowires", RFC 5085, December 2007. 815 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 816 (BFD)", RFC 5880, June 2010. 818 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 819 "Bidirectional Forwarding Detection (BFD) for MPLS Label 820 Switched Paths (LSPs)", RFC 5884, June 2010. 822 21.2. Informative References 824 [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate 825 system routeing information exchange protocol for use in 826 conjunction with the Protocol for providing the 827 Connectionless-mode Network Service (ISO 8473)". 829 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 830 dual environments", RFC 1195, December 1990. 832 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 834 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 835 Marker", RFC 2697, September 1999. 837 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 838 J., Courtney, W., Davari, S., Firoiu, V., and D. 839 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 840 Behavior)", RFC 3246, March 2002. 842 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 843 (TE) Extensions to OSPF Version 2", RFC 3630, 844 September 2003. 846 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 847 System (IS-IS) Extensions for Traffic Engineering (TE)", 848 RFC 3784, June 2004. 850 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 851 Shaffer, "Extensions to OSPF for Advertising Optional 852 Router Capabilities", RFC 4970, July 2007. 854 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 855 System to Intermediate System (IS-IS) Extensions for 856 Advertising Router Information", RFC 4971, July 2007. 858 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 859 Topology (MT) Routing in Intermediate System to 860 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 862 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 863 Engineering", RFC 5305, October 2008. 865 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, 866 "Traffic Engineering Extensions to OSPF Version 3", 867 RFC 5329, September 2008. 869 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 870 for IPv6", RFC 5340, July 2008. 872 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 873 Time Protocol Version 4: Protocol and Algorithms 874 Specification", RFC 5905, June 2010. 876 [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 877 J., and S. Amante, "Flow-Aware Transport of Pseudowires 878 over an MPLS Packet Switched Network", RFC 6391, 879 November 2011. 881 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 882 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 883 RFC 6790, November 2012. 885 1. Appendix 887 1.1. Routing extensions for Timing-aware Routers 889 MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and 890 IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE) 891 link information used for constraint-based routing. 893 Indeed, it is useful to advertise data plane TE router link 894 capabilities, such as the capability for a router to be Timing-aware. 895 This capability MUST then be taken into account during path 896 computation to prefer or even require links that advertise themselves 897 as Timing-aware. In this way the path can ensure the entry and exit 898 points into the LERs and, if desired, the links into the LSRs are 899 able to perform port based time-stamping thus minimizing their impact 900 on the performance of the slave clock. 902 extensions are required to OSPF and IS-IS in order to advertise 903 Timing-aware capabilities of a link. Such extensions are outside the 904 scope of this document; however such extension SHOULD be able to 905 signal the following information per Router Link: 907 o Capable of processing PTP, NTP or other Timing flows 909 o Capable of performing Transparent Clock operation 911 o Capable of performing Boundary Clock operation 913 1.2. Signaling Extensions for Creating Timing LSPs 915 RSVP-TE signaling MAY be used to setup the timing LSPs. When RSVP-TE 916 is used to setup Timing LSPs, some information that indicates that 917 the LSP is carrying Timing flows MUST be included in the new 918 Extensions to RSVP-TE: 920 The following information MAY also be included in the new Extensions 921 to RSVP-TE: 923 o Offset from Bottom of Stack (BoS) to the start of the Time-stamp 924 field 926 o Number of VLANs in case of PW encapsulation 928 o Timestamp field Type 930 * Correction Field, Timestamp 932 o Timestamp Field format 934 * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit 935 NTP, etc. 937 Note that in case the above optional information is signaled with 938 RSVP-TE for a Timing LSP, all the Timing packets carried in that LSP 939 must have the same signaled characteristics. For example if 940 Timestamp format is signaled as 64-bit PTPv1, then all Timing packets 941 must use 64-bit PTPv1 time-stamp. 943 Authors' Addresses 945 Shahram Davari 946 Broadcom Corp. 947 San Jose, CA 95134 948 USA 950 Email: davari@broadcom.com 952 Amit Oren 953 Broadcom Corp. 954 San Jose, CA 95134 955 USA 957 Email: amito@broadcom.com 959 Manav Bhatia 960 Alcatel-Lucent 961 Bangalore, 962 India 964 Email: manav.bhatia@alcatel-lucent.com 966 Peter Roberts 967 Alcatel-Lucent 968 Kanata, 969 Canada 971 Email: peter.roberts@alcatel-lucent.com 973 Laurent Montini 974 Cisco Systems 975 San Jose CA 976 USA 978 Email: lmontini@cisco.com