idnits 2.17.1 draft-ietf-tictoc-1588overmpls-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 13 instances of too long lines in the document, the longest one being 2 characters 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 (October 22, 2012) is 4176 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) == Missing Reference: 'IEEE- 1588' is mentioned on line 140, but not defined == Missing Reference: 'RFC-4448' is mentioned on line 419, but not defined == Unused Reference: 'I-D.ietf-pwe3-fat-pw' is defined on line 833, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 857, but no explicit reference was found in the text == Unused Reference: 'RFC3784' is defined on line 861, but no explicit reference was found in the text == Unused Reference: 'RFC4970' is defined on line 865, but no explicit reference was found in the text == Unused Reference: 'RFC4971' is defined on line 869, but no explicit reference was found in the text == Unused Reference: 'RFC5120' is defined on line 873, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 877, but no explicit reference was found in the text == Unused Reference: 'RFC5329' is defined on line 880, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE' ** Downref: Normative reference to an Informational RFC: RFC 3985 ** Downref: Normative reference to an Experimental RFC: RFC 4389 ** 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: 4 errors (**), 0 flaws (~~), 13 warnings (==), 5 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: Standards Track Broadcom Corp. 5 Expires: April 25, 2013 M. Bhatia 6 P. Roberts 7 Alcatel-Lucent 8 L. Montini 9 Cisco Systems 10 October 22, 2012 12 Transporting Timing messages over MPLS Networks 13 draft-ietf-tictoc-1588overmpls-03 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, which is suitable for both 31 MPLS and MPLS-TP networks. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 25, 2013. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9 73 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . 10 75 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . . 12 77 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . 13 78 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . . 13 79 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . . 13 80 6.3. Other Timing Encapsulation methods . . . . . . . . . . . . 14 82 7. Timing Message Processing . . . . . . . . . . . . . . . . . . 15 84 8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 16 86 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 12. OAM, Control and Management . . . . . . . . . . . . . . . . . 20 94 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 21 96 14. FCS Recalculation . . . . . . . . . . . . . . . . . . . . . . 22 98 15. UDP Checksum Correction . . . . . . . . . . . . . . . . . . . 23 100 16. Routing extensions for Timing-aware Routers . . . . . . . . . 24 102 17. Signaling Extensions for Creating Timing LSPs . . . . . . . . 25 104 18. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 26 105 18.1. Behavior of Timing-capable/aware LER . . . . . . . . . . . 26 106 18.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . . 26 107 18.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . . 26 109 19. Other considerations . . . . . . . . . . . . . . . . . . . . . 28 111 20. Security Considerations . . . . . . . . . . . . . . . . . . . 29 112 21. Applicability Statement . . . . . . . . . . . . . . . . . . . 30 114 22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 116 23. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 118 24. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 119 24.1. Normative References . . . . . . . . . . . . . . . . . . . 33 120 24.2. Informative References . . . . . . . . . . . . . . . . . . 33 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC2119 [RFC2119]. 127 When used in lower case, these words convey their typical use in 128 common language, and are not to be interpreted as described in 129 RFC2119 [RFC2119]. 131 1. Introduction 133 The objective of Precision Time Protocol (PTP) and Network Timing 134 Protocol (NTP) are to synchronize independent clocks running on 135 separate nodes of a distributed system. 137 [IEEE] defines PTP messages for frequency, phase and time 138 synchronization. The PTP messages include PTP PDUs over UDP/IP 139 (Annex D and E of [IEEE]) and PTP PDUs over Ethernet (Annex F of 140 [IEEE- 1588]). This document defines mapping and transport of the 141 PTP messages defined in [IEEE] over MPLS/MPLS-TP networks. PTP 142 defines several clock types: ordinary clocks, boundary clocks, end- 143 to-end transparent clocks, and peer-to-peer transparent clocks. 144 Transparent clocks require intermediate nodes to update correction 145 field inside PTP message that reflects the transit time in the node. 147 [RFC5905] defines NTP messages for clock and time synchronization. 148 The PTP messages (PDUs) are transported over UDP/IP. This document 149 defines mapping and transport of the NTP messages defined in 150 [RFC5905] over MPLS networks. 152 One key attribute of all of these Timing messages is that the 153 Timestamp processing should occur as close as possible to the actual 154 transmission and reception at the physical port interface. This 155 targets optimal time and/or frequency recovery by avoiding variable 156 delay introduced by queues internal to the clocks. 158 To facilitate the fast and efficient recognition of Timing messages 159 at the port level when the Timing messages are carried over MPLS 160 LSPs, this document defines the specific encapsulations that should 161 be used. In addition, it can be expected that there will exist LSR/ 162 LERs where only a subset of the physical ports will have the port- 163 based Timing message processing capabilities. In order to ensure 164 that the LSPs carrying Timing packets always enter and exit ports 165 with this capability, routing extensions are defined to advertise 166 this capability on a port basis and to allow for the establishment of 167 LSPs that only transit such ports. While this path establishment 168 restriction may be applied only at the LER Ingress and/or egress 169 ports, it becomes more important when using transparent clock capable 170 LSRs in the path. 172 Port based Timing message processing involves Timing message 173 recognition. Once the Timing messages are recognized they can be 174 modified based on the reception or transmission timestamp. 176 This document provides two methods for transporting Timing messages 177 over MPLS. One is applicable to MPLS environment and the other one 178 is applicable to both MPLS and MPLS-TP environment. 180 The solution involves transporting Timing messages over dedicated 181 LSPs called Timing LSPs. These LSPs carry Timing messages and MAY 182 carry Management and control messages, but not data plane client 183 traffic. Timing LSPs can be established statically or via signaling. 184 Extensions to control plane (OSPF, ISIS, etc) is required to enable 185 routers to distribute their Timing processing capabilities over MPLS 186 to other routers. However such extensions are outside the scope of 187 this document. 189 Extensions to signaling protocols (e.g., RSVP-TE) are required for 190 establishing PTP LSPs. However such extensions are outside the scope 191 of this document. 193 While the techniques included herein allow for the establishment of 194 paths optimized to include Time-stamping capable links, the 195 performance of the Slave clocks is outside the scope of this 196 document. 198 2. Terminology 200 1588: The timing and synchronization as defined by IEEE 1588. 202 NTP: The timing and synchronization protocol defined by IETF RFC-1305 203 and RFC-5905. 205 PTP: The timing and synchronization protocol used by 1588. 207 Master Clock: The source of 1588 timing to a set of slave clocks. 209 Master Port: A port on a ordinary or boundary clock that is in Master 210 state. This is the source of timing toward slave ports. 212 Slave Clock: A receiver of 1588 timing from a master clock. 214 Slave Port: A port on a boundary clock or ordinary clock that is 215 receiving timing from a master clock. 217 Ordinary Clock: A device with a single PTP port. 219 Transparent Clock. A device that measures the time taken for a PTP 220 event message to transit the device and then updates the 221 correctionField of the message with this transit time. 223 Boundary Clock: A device with more than one PTP port. Generally 224 boundary clocks will have one port in slave state to receive timing 225 and then other ports in master state to re-distribute the timing. 227 PTP LSP: An LSP dedicated to carry PTP messages 229 PTP PW: A PW within a PTP LSP that is dedicated to carry PTP 230 messages. 232 CW: Pseudowire Control Word 234 LAG: Link Aggregation 236 ECMP: Equal Cost Multipath 238 CF: Correction Field, a field inside certain PTP messages (message 239 type 0-3)that holds the accumulative transit time inside intermediate 240 switches 242 3. Problem Statement 244 [IEEE] has defined methods for transporting PTP messages over 245 Ethernet and IP networks. [RFC5905] has defined the method of 246 transporting NTP messages over IP networks. There is a need to 247 transport Timing messages over MPLS networks while supporting the 248 Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (OC) 249 functionality in the LER and LSRs in the MPLS network. 251 There are multiple ways of transporting Timing over MPLS. However, 252 there is a requirement to limit the possible encapsulation options to 253 simplify the Timing message identification and processing required at 254 the port level. 256 When Timing-awareness is needed, Timing messages should not be 257 transported over LSPs or PWs that are carrying customer traffic 258 because LSRs perform Label switching based on the top label in the 259 stack. To detect Timing messages inside such LSPs require special 260 hardware to do deep packet inspection at line rate. Even if such 261 hardware exists, the payload cant be deterministically identified by 262 LSRs because the payload type is a context of the PW label, and the 263 PW label and its context are only known to the Edge routers (PEs/ 264 LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, CES, 265 etc). Even if one restricts an LSP to only carry Ethernet PWs, the 266 LSRs dont have the knowledge of whether PW Control Word (CW) is 267 present or not and therefore can not deterministically identify the 268 payload. 270 A generic method is defined in this document that does not require 271 deep packet inspection at line rate, and can deterministically 272 identify Timing messages. The generic method is applicable to MPLS 273 and MPLS-TP networks. 275 4. Timing over MPLS Architecture 277 Timing messages are exchange between Timing ports on ordinary and 278 boundary clocks. Boundary clocks terminate the Timing messages and 279 act as master for other boundary clocks or for slave clocks. 280 Transparent clocks do not terminate the Timing messages but they do 281 modify the contents of the Timing messages as they transit across the 282 transparent clock. 284 Master/Slave clock could be integrated in the LERs. An example is 285 shown in Figure 1, where the LERs act as Ordinary Clock (OC) and are 286 the initiating/terminating point for Timing messages. The ingress 287 LER encapsulates the Timing messages in Timing LSP and the Egress LER 288 terminates the Timing LSP. The LSRs act as Transparent Clock (TC) 289 and just update the Timing field in the Timing messages. 291 +--------+ +-------+ +-------+ +-------+ +--------+ 292 |Switch, | | | | | | | |Switch, | 293 | Router |-----| LER |-----| LSR |-----| LER |-----| Router | 294 | | | OC | | TC | | OC | | | 295 +--------+ +-------+ +-------+ +-------+ +--------+ 296 / \ 297 +-------+ / \ +-------+ 298 | LER | / \ | LER | 299 | Master|---/ \---| Slave | 300 | Clock | | Clock | 301 +-------+ +-------+ 303 Figure (1) - Deployment example 1 of timing over MPLS/MPLS-TP network 305 LERs could also act as Boundary Clock (BC). This is shown in Figure 306 2, where LERs terminate the Timing messages received from switch/ 307 routers that are outside of the MPLS network acting as OC or BC. In 308 this example LERs regenerate the clock and initiate timing messages 309 encapsulated in Timing LSP toward the MPLS network, while the LSRs 310 act as Transparent Clock (TC) and just update the Timing field in the 311 Timing messages, which are already encapsulated in Timing LSPs. 313 +--------+ +-------+ +-------+ +-------+ +--------+ 314 |Switch, | | | | | | | |Switch, | 315 | Router |-----| LER |-----| LSR |-----| LER |-----| Router | 316 | OC/BC | | BC | | TC | | BC | | OC/BC | 317 +--------+ +-------+ +-------+ +-------+ +--------+ 319 Figure (2) - Deployment example 2 of timing over MPLS/MPLS-TP network 321 LERs could also act as Transparent Clock (TC). This is shown in 322 Figure 3, where LERs do not terminate the Timing messages received 323 from switch/routers that are outside of the MPLS network acting as 324 OC, TC or BC. The LERs act as TC and update the Timing field in the 325 Timing messages as they transit the LER, while encapsulating them in 326 timing LSP. The LSRs also act as Transparent Clock (TC) and just 327 update the Timing field in the Timing messages which are already 328 encapsulated in Timing LSPs. 330 +--------+ +-------+ +-------+ +-------+ +--------+ 331 |Switch, | | | | | | | |Switch, | 332 | Router |-----| LER |-----| LSR |-----| LER |-----| Router | 333 |OC/TC/BC| | TC | | TC | | TC | |OC/TC/BC| 334 +--------+ +-------+ +-------+ +-------+ +--------+ 336 Figure (3) - Deployment example 3 of timing over MPLS/MPLS-TP network 338 5. Dedicated LSPs for Timing messages 340 Many methods have been considered for identifying the Timing messages 341 when they are encapsulated in MPLS such as using GAL/ACH or a new 342 reserved label. These methods were not attractive since they either 343 required deep packet inspection at line rate in the intermediate LSRs 344 or they required use of a scarce new reserved label. Also one of the 345 goals was to reuse existing OAM mechanisms. 347 The method defined in this document can be used by LER and LSRs to 348 identify Timing messages in MPLS tunnels by just looking at the top 349 label in the MPLS label stack, which only carry Timing messages as 350 well as OAM, but not data plane client traffic. 352 Compliant implementations MUST use dedicated LSPs to carry Timing 353 messages over MPLS. These LSPs are herein referred to as "Timing 354 LSPs" and the labels associated with these LSPs as "Timing LSP 355 labels". The Timing LSPs that runs between Ingress and Egress LERs 356 MUST be co-routed. Alternatively, a single bidirectional co-routed 357 LSP can be used. 359 Co-routing of the two directions is required to limit the difference 360 in the delays in the Master clock to Slave clock direction compared 361 to the Slave clock to Master clock direction. The Timing LSP MAY be 362 MPLS LSP or MPLS-TP LSP. 364 The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS. 365 New Extensions to RSVP-TE/GMPLS TLVs are required; however they are 366 outside the scope of this document. 368 The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such as 369 BFD and LSP Ping but the LSP data plane client plane traffic MUST be 370 Timing packets only. 372 6. Timing over LSP Encapsulation 374 This document defines two methods for carrying Timing messages over 375 MPLS. The first method is carrying UDP/IP encapsulated Timing 376 messages over Timing LSPs, which is suitable for MPLS networks and 377 the second method, is carrying Ethernet encapsulated Timing messages 378 over Ethernet PWs inside Timing LSPs, which is suitable for MPLS and 379 MPLS-TP networks. 381 6.1. Timing over UDP/IP over MPLS Encapsulation 383 The simplest method of transporting Timing messages over MPLS is to 384 encapsulate Timing PDUs in UDP/IP and then encapsulate them in Timing 385 LSP. This format is shown in Figure 4. 387 +----------------------+ 388 | Timing LSP Label | 389 +----------------------+ 390 | IPv4/6 | 391 +----------------------+ 392 | UDP | 393 +----------------------+ 394 | Timing PDU | 395 +----------------------+ 397 Figure (4) - Timing over UDP/IP over MPLS Encapsulation 399 This encapsulation is very simple and is useful when the network 400 between Timing Master Clock and Slave Clock is MPLS network. 402 In order for an LER/LSR to process Timing messages, the Timing LSP 403 Label must be at the top label of the label stack. The LER/LSR MUST 404 know that the Timing LSP Label is used for carrying Timing messages. 405 This can be accomplished via static configuration or via RSVP-TE 406 signaling. 408 The UDP/IP encapsulation of PTP MUST follow Annex D and E of [IEEE]. 409 While the UDP/IP encapsulation of NTP MUST follow [RFC5905]. 411 6.2. Timing over PW Encapsulation 413 Another method of transporting Timing over MPLS networks is by 414 encapsulating Timing PDUs in PW which in turn is transported over 415 Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448], 416 shown in Fig 5(A) MUST be used and the Ethernet encapsulation of PTP 417 MUST follow Annex F of [IEEE]. 419 The Tagged mode defined in [RFC-4448] MUST be used and the Payload 420 MUST have 2 VLAN tags (S-VLAN and C-VLAN). The Timing over PW 421 encapsulation MUST use the Control Word (CW) as specified in 422 [RFC4448] to ensure proper detection of PTP messages inside the MPLS 423 packets for Timing over LSP and Timing over PW encapsulation. The 424 use of Sequence Number in the CW is optional. 426 Timing over PW encapsulation for NTP MUST use NTP over UDP/IP over PW 427 (the IP PW discussed in [RFC4447]) shown in Fig 5(B). 429 +----------------+ +----------------+ 430 |Timing LSP Label| |Timing LSP Label| 431 +----------------+ +----------------+ 432 | PW Label | | PW Label | 433 +----------------+ +----------------+ 434 | Control Word | | IP | 435 +----------------+ +----------------+ 436 | Ethernet | | UDP | 437 | Header | +----------------+ 438 +----------------+ | Timing PDU | 439 | S-VLAN | | | 440 +----------------+ +----------------+ 441 | C-VLAN | (B) 442 +----------------+ 443 | Timing PDU | 444 | | 445 +----------------+ 446 (A) 448 Figure (5) - Timing over PW Encapsulations 450 In order for an LSR to process PTP messages, the top label of the 451 label stack (the Tunnel Label) MUST be a Timing label. 453 The PW method of transporting Timing over MPLS is applicable to both 454 MPLS and MPLS-TP networks. 456 6.3. Other Timing Encapsulation methods 458 In future other timing encapsulation methods may be introduced, such 459 as a new shim header after the Bottom of Stack to carry the Timing 460 information. Such new encapsulations are outside the scope of this 461 document. The control and signaling requirements in this document 462 are defined generically enough to accommodate any such new 463 encapsulations. 465 7. Timing Message Processing 467 Each Timing protocol such as PTP and NTP, define their set of Timing 468 messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, 469 FOLLOW_UP, etc messages. 471 Some of the Timing messages require time stamping at port level and 472 some dont. It is the job of the LER/LSR to parse the timing message 473 and find out the type of the Timing message and decide whether and 474 how to Time- stamp it (e.g., BC) or modify existing timestamp in it 475 (e.g., TC). 477 For example the following PTP messages (called Event messages) 478 require time-stamping, while other Non-Event PTP messages do not need 479 time-stamping. 481 o Announce 483 o SYNC 485 o DELAY_REQ (Delay Request) 487 o PDELAY_REQ (Peer Delay Request) 489 o PDELAY_RESP (Peer Delay Response) 491 SYNC and DELAY_REQ are exchanged between Master Clock and Slave Clock 492 and MUST be transported over PTP LSPs. PDELAY_REQ and PDELAY_RESP 493 are exchanged between adjacent PTP clocks (i.e. Master, Slave, 494 Boundary, or Transparent) and MAY be transported over single hop PTP 495 LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP, 496 DELAY_RESP, and PDELAY_RESP_FOLLOW_UP messages must also be 497 transported over the PTP LSPs. 499 For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be 500 transported over two PTP LSPs that are in opposite directions. These 501 PTP LSPs, which are in opposite directions MUST be congruent and co- 502 routed. Alternatively, a single bidirectional co-routed LSP can be 503 used. 505 Except as indicated above for the two-step PTP clocks, Non-Event PTP 506 message types do not need to be processed by intermediate routers. 507 These message types MAY be carried in PTP Tunnel LSPs. 509 8. Protection and Redundancy 511 In order to ensure continuous uninterrupted operation of slave 512 clocks, usually as a general practice, slave clocks (or ports) track 513 redundant master clocks. 515 It is the responsibility of the network operator to ensure that 516 physically disjoint Timing LSPs are established between a slave clock 517 (or port) and redundant master clocks (or ports). 519 When a slave clock (or port) listens to redundant master clocks or 520 ports, any prolonged Timing LSP outage will trigger the slave clock 521 or port to switch to a redundant master clock or port. 523 LSP/PW protection such as Linear protection Switching (1:1, 1+1), 524 Ring protection switching or MPLS Fast Reroute (FRR) generally switch 525 alternative path that usually cause a change in delay, which if 526 undetected by slave clock can reduce accuracy of the slave clock. 527 However it is expected that most Slave clocks could detect the change 528 in delay. Therefore this specification recommends that protection 529 switching SHOULD be used, unless the operator knows that the 530 protection switching may have adverse effect on the slave clock. 532 Note that any protection or reroute mechanism that adds additional 533 MPLS label to the label stack, such as Facility Backup Fast Reroute, 534 MUST ensure that the pushed label is also a Timing Label to ensure 535 recognition of the MPLS frame as containing Timing messages, as it 536 transits the backup path. 538 9. ECMP 540 To ensure the optimal operation of slave clocks and avoid error 541 introduced by forward and reverse path delay asymmetry, the physical 542 path for Timing messages from master clock to slave Clock and vice 543 versa must be the same for all Event Timing messages listed in 544 section 7. 546 Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost 547 Multipath). 549 10. PHP 551 To ensure that the label on the top of the label stack is the Timing 552 LSP Label, PHP MUST not be used. 554 11. Entropy 556 To ensure all Timing messages in a Timing LSP take the same path, 557 Entropy MUST NOT be used for the Timing LSP [mpls-entropy] and 558 Entropy MSUT NOT be used for the PWs that are carried inside Timing 559 LSP [RFC6391]. 561 12. OAM, Control and Management 563 IIn order to manage Timing LSPs and their encapsulated PWs, they MUST 564 be able to carry OAM and management messages. These management 565 messages MUST be differentiated from Timing messages via already 566 defined IETF methods. 568 For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY run 569 over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These 570 Management protocols can easily be identified by the UDP Destination 571 Port number or by GAL/ACH respectively. 573 Also BFD, LSP-Ping and other management messages MAY run over the PWs 574 encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3 or 575 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is going 576 to be deprecated by IETF). In this case G-ACH, PW label (TTL=1) or 577 GAL-ACH are used to identify such management messages. 579 13. QoS Considerations 581 In network deployments where not every LSR/LER is Timing-aware, it is 582 important to reduce the impact of the non-Timing-aware LSR/LERs on 583 the timing recovery in the slave clock. The Timing messages are time 584 critical and must be treated with the highest priority. Therefore 585 Timing over MPLS messages must be treated with the highest priority 586 in the routers. This can be achieved by proper setup of Timing LSPs. 588 It is recommended that the Timing LSPs are setup or configured 589 properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC2697] 590 for drop eligibility. 592 14. FCS Recalculation 594 When timestamp generation and timing packet adjustment is performed 595 near the physical port hardware, the process MUST include 596 recalculation of the Ethernet FCS. Also FCS retention for the 597 payload Ethernet described in [RFC4720] MUST NOT be used. 599 15. UDP Checksum Correction 601 For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum 602 is optional when used for IPv4 encapsulation and mandatory in case of 603 IPv6. 605 When UDP checksum is used, each Timing-aware LER/LSR must either 606 incrementally update the UDP checksum after Time stamping or 607 Correction Field update or verify the UDP checksum on reception from 608 upstream and recalculate the checksum completely on transmission to 609 downstream node after Time stamping or Correction Field update. 611 16. Routing extensions for Timing-aware Routers 613 MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and 614 IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE) 615 link information used for constraint-based routing. 617 Indeed, it is useful to advertise data plane TE router link 618 capabilities, such as the capability for a router to be Timing-aware. 619 This capability MUST then be taken into account during path 620 computation to prefer or even require links that advertise themselves 621 as Timing-aware. In this way the path can ensure the entry and exit 622 points into the LERs and, if desired, the links into the LSRs are 623 able to perform port based timestamping thus minimizing their impact 624 on the performance of the slave clock. 626 extensions are required to OSPF and IS-IS in order to advertise 627 Timing-aware capabilities of a link. Such extensions are outside the 628 scope of this document; however such extension SHOULD be able to 629 signal the following information per Router Link: 631 o Capable of processing PTP, NTP or other Timing flows 633 o Capable of performing Transparent Clock operation 635 o Capable of performing Boundary Clock operation 637 17. Signaling Extensions for Creating Timing LSPs 639 RSVP-TE signaling MAY be used to setup the timing LSPs. When RSVP-TE 640 is used to setup Timing LSPs, some information that indicates that 641 the LSP is carrying Timing flows MUST be included in the new 642 Extensions to RSVP-TE: 644 The following information MAY also be included in the new Extensions 645 to RSVP-TE: 647 o Offset from Bottom of Stack (BoS) to the start of the Timestamp 648 field 650 o Number of VLANs in case of PW encapsulation 652 o Timestamp field Type 654 * Correction Field, Timestamp 656 o Timestamp Field format 658 * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit 659 NTP, etc. 661 Note that in case the above optional information is signaled with 662 RSVP-TE for a Timing LSP, all the Timing packets carried in that LSP 663 must have the same signaled characteristics. For example if 664 Timestamp format is signaled as 64-bit PTPv1, then all Timing packets 665 must use 64-bit PTPv1 timestamp. 667 18. Behavior of LER/LSR 669 Timing-capable/aware LERs and LSRs are routers that have one or more 670 interfaces that can perform Timing operations (OC/BC/TC) on Timing 671 packets and are configured to do so. Timing-capable/aware LERs and 672 LSRs can advertise their Timing-capability per-interface via control 673 plane such as OSPF or IS-IS. The Timing-capable/aware LERs can then 674 signals Timing LSPs via RSVP-TE signaling. Alternatively the Timing 675 capability of LER and LSRs may be configured in a centralized 676 controller and the Timing LSP may be setup using manual configuration 677 or other methods such as SDN. 679 18.1. Behavior of Timing-capable/aware LER 681 When a Timing-capable/aware LER behaves as a Transparent clock and 682 receives a Timing message from a Timing-capable/aware non-MPLS 683 interface, the LER updates the Correction Field (CF) and encapsulates 684 and forwards the timing message over previously established Timing 685 LSP. Also when a Timing message is received from a Timing-capable/ 686 aware MPLS interface, LER updates the Correction Filed (CF) and 687 decapsulates the MPLS encapsulation and forwards the timing message 688 to a non-MPLS interface. 690 When a Timing-capable/aware LER behaves as a Boundary clock and 691 receives a Timing message from a Timing-capable/aware non MPLS 692 interface, the LER Timestamps the Timing packet and sends it to the 693 LERs Boundary clock processing module. Also when a Timing message is 694 received from a Timing- capable/aware MPLS interface, the LER 695 Timestamps the Timing packet and sends it to the LERs Boundary clock 696 processing module. 698 When a Timing-capable/aware LER behaves as an Ordinary Clock toward 699 the MPLS network, and receives a Timing message from a Timing- 700 capable/aware MPLS interface, the LER Timestamps the Timing packet 701 and sends it to the LERs Ordinary clock processing module. 703 18.2. Behavior of Timing-capable/aware LSR 705 A Timing-capable/aware LSR behaves as a Transparent clock and 706 receives a Timing message from a Timing-capable/aware MPLS interface. 707 The LSR updates the Correction Filed (CF) and forwards the timing 708 message over another MPLS interface. 710 18.3. Behavior of non-Timing-capable/aware LSR 712 It is most beneficial when all LSRs in the path of a Timing LSP be 713 timing-Capable/aware LSRs. This would ensure the highest quality 714 time and clock synchronization by Timing Slave Clocks. However, this 715 specification does not mandate that all LSRs in path of a Timing LSP 716 be Timing- capable/aware. 718 Non-Timing-capable/aware LSRs just switch the packets encapsulated in 719 Timing LSPs and dont perform any Timing operation (TC). However as 720 explained in QoS section the Timing8 over MPLS packets MUST be still 721 be treated with the highest priority based on their Traffic Class 722 (TC) marking. 724 19. Other considerations 726 [IEEE] Tdefines an optional peer-to-peer Transparent clocking that 727 requires peer delay measurement between two adjacent Timing-capable/ 728 ware routers/switches. Peer delay measurement messages need to be 729 time stamped and terminated by the Timing-capable/aware routers/ 730 switches. This means that two adjacent LSRs may be engaged in a peer 731 delay measurement. Such peer delay measurement messages SHALL NOT 732 use the Timing LSP that runs between two LERs. For transporting such 733 peer delay measurement messages there are two options. Either a 734 single-hop LSP needs to be created between the two adjacent LSRs 735 engaged in peer delay measurement to carry peer delay measurement 736 messages, or other methods such as PTP transport over Ethernet may be 737 used for transporting peer delay measurement messages if the link 738 between the two routers is Ethernet. 740 The use of Explicit Null Label (Label= 0 or 2) is acceptable as long 741 as either the Explicit Null label is the bottom of stack label 742 (applicable only to UDP/IP encapsulation) or the label below the 743 Explicit Null label is a PTP label. 745 20. Security Considerations 747 MPLS PW security considerations in general are discussed in [RFC3985] 748 and [RFC4447],and those considerations also apply to this document. 750 An experimental security protocol is defined in [IEEE].The PTP 751 security extension and protocol provides group source authentication, 752 message integrity, and replay attack protection for PTP messages. 754 21. Applicability Statement 756 The Timing over MPLS transport methods described in this document 757 apply to the following network Elements: 759 o An LER receives IP or Ethernet Encapsulated Timing messages from a 760 non-MPLS interface and forwards them as MPLS encapsulated Timing 761 messages over Timing LSP, while performing Transparent Clock 762 functionality 764 o An LER receives MPLS encapsulated Timing messages from a Timing 765 LSP and forwards them to non-MPLS interface as IP or Ethernet 766 Encapsulated Timing messages, while performing Transparent Clock 767 functionality 769 o An LER receives MPLS encapsulated Timing messages from a Timing 770 LSP and terminates them, while performing the OC or BC 771 functionality 773 o An LSR receives MPLS encapsulated Timing messages from a Timing 774 LSP and forwards them to another MPLS interface, while performing 775 the TC functionality 777 This document also supports the case where not all LSRs are Timing- 778 capable/aware. It also supports the case where not all LER/LSR 779 interfaces are Timing-capable/aware. 781 22. Acknowledgements 783 The authors would like to thank Luca Martini, Ron Cohen, Yaakov 784 Stein, Tal Mizrahi, Stefano Ruffini, Luca Moniti and other members of 785 IETF for reviewing and providing feedback on this draft. 787 23. IANA Considerations 789 There are no IANA requirements in this specification. 791 24. References 793 24.1. Normative References 795 [IEEE] IEEE 1588-2008, "IEEE Standard for a Precision Clock 796 Synchronization Protocol for Networked Measurement and 797 Control Systems". 799 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 800 Requirement Levels", BCP 14, RFC 2119, March 1997. 802 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 803 Edge (PWE3) Architecture", RFC 3985, March 2005. 805 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 806 Proxies (ND Proxy)", RFC 4389, April 2006. 808 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 809 Heron, "Pseudowire Setup and Maintenance Using the Label 810 Distribution Protocol (LDP)", RFC 4447, April 2006. 812 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, 813 "Encapsulation Methods for Transport of Ethernet over MPLS 814 Networks", RFC 4448, April 2006. 816 [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire 817 Emulation Edge-to-Edge (PWE3) Frame Check Sequence 818 Retention", RFC 4720, November 2006. 820 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 821 Connectivity Verification (VCCV): A Control Channel for 822 Pseudowires", RFC 5085, December 2007. 824 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 825 (BFD)", RFC 5880, June 2010. 827 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 828 "Bidirectional Forwarding Detection (BFD) for MPLS Label 829 Switched Paths (LSPs)", RFC 5884, June 2010. 831 24.2. Informative References 833 [I-D.ietf-pwe3-fat-pw] 834 Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 835 J., and S. Amante, "Flow Aware Transport of Pseudowires 836 over an MPLS Packet Switched Network", 837 draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011. 839 [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate 840 system routeing information exchange protocol for use in 841 conjunction with the Protocol for providing the 842 Connectionless-mode Network Service (ISO 8473)". 844 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 845 dual environments", RFC 1195, December 1990. 847 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 849 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 850 Marker", RFC 2697, September 1999. 852 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 853 J., Courtney, W., Davari, S., Firoiu, V., and D. 854 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 855 Behavior)", RFC 3246, March 2002. 857 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 858 (TE) Extensions to OSPF Version 2", RFC 3630, 859 September 2003. 861 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 862 System (IS-IS) Extensions for Traffic Engineering (TE)", 863 RFC 3784, June 2004. 865 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 866 Shaffer, "Extensions to OSPF for Advertising Optional 867 Router Capabilities", RFC 4970, July 2007. 869 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 870 System to Intermediate System (IS-IS) Extensions for 871 Advertising Router Information", RFC 4971, July 2007. 873 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 874 Topology (MT) Routing in Intermediate System to 875 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 877 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 878 Engineering", RFC 5305, October 2008. 880 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, 881 "Traffic Engineering Extensions to OSPF Version 3", 882 RFC 5329, September 2008. 884 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 885 for IPv6", RFC 5340, July 2008. 887 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 888 Time Protocol Version 4: Protocol and Algorithms 889 Specification", RFC 5905, June 2010. 891 [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 892 J., and S. Amante, "Flow-Aware Transport of Pseudowires 893 over an MPLS Packet Switched Network", RFC 6391, 894 November 2011. 896 Authors' Addresses 898 Shahram Davari 899 Broadcom Corp. 900 San Jose, CA 95134 901 USA 903 Email: davari@broadcom.com 905 Amit Oren 906 Broadcom Corp. 907 San Jose, CA 95134 908 USA 910 Email: amito@broadcom.com 912 Manav Bhatia 913 Alcatel-Lucent 914 Bangalore, 915 India 917 Email: manav.bhatia@alcatel-lucent.com 919 Peter Roberts 920 Alcatel-Lucent 921 Kanata, 922 Canada 924 Email: peter.roberts@alcatel-lucent.com 926 Laurent Montini 927 Cisco Systems 928 San Jose CA 929 USA 931 Email: lmontini@cisco.com