idnits 2.17.1 draft-ietf-tictoc-1588overmpls-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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). Entropy labels MUST NOT be used for the Timing LSP [RFC6790] and MUST NOT be used for PWs inside the Timing LSP [RFC6391]. == 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 employed. -- The document date (October 16, 2015) is 3114 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC-4448' is mentioned on line 377, but not defined ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: April 18, 2016 M. Bhatia 6 P. Roberts 7 Alcatel-Lucent 8 L. Montini 9 Cisco Systems 10 October 16, 2015 12 Transporting Timing messages over MPLS Networks 13 draft-ietf-tictoc-1588overmpls-07 15 Abstract 17 This document defines a method for transporting timing messages, such 18 as Precision Time Protocol (PTP) or Network Time Protocol (NTP), over 19 a Multiprotocol Label Switched (MPLS) network. The method 20 facilitates efficient recognition of timing packets to enable their 21 port level processing in both Label Edge Routers (LERs) and Label 22 Switched Routers (LSRs). 24 The basic mechanism is to transport timing messages inside "Timing 25 LSPs", which are dedicated MPLS Label Switched Paths (LSPs) that 26 carry only timing, and possibly related Operations, Administration 27 and Maintenance (OAM) or management packets, but do not carry 28 customer traffic. 30 Two encapsulations methods are defined. The first transports UDP/IP 31 encapsulated timing messages directly over the dedicated LSP. The 32 second transports Ethernet encapsuled timing messages inside an 33 Ethernet pseudowire. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 18, 2016. 51 Copyright Notice 53 Copyright (c) 2015 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 71 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . 5 72 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . 7 73 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . 8 74 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . 8 75 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . 8 76 7. Timing message Processing . . . . . . . . . . . . . . . . . . 9 77 8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 10 78 9. ECMP and Entropy . . . . . . . . . . . . . . . . . . . . . . 10 79 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 11. OAM, Control and Management . . . . . . . . . . . . . . . . . 11 81 12. QoS Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 13. FCS and Checksum Recalculation . . . . . . . . . . . . . . . 11 83 14. Behavior of LER/LSRs . . . . . . . . . . . . . . . . . . . . 12 84 14.1. Behavior of Timing-capable/aware LERs/LSRs . . . . . . . 12 85 14.2. Behavior of non-Timing-capable/aware LSR . . . . . . . . 12 86 15. Other considerations . . . . . . . . . . . . . . . . . . . . 13 87 16. Security Considerations . . . . . . . . . . . . . . . . . . . 13 88 17. Applicability Statement . . . . . . . . . . . . . . . . . . . 14 89 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 90 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 91 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 20.1. Normative References . . . . . . . . . . . . . . . . . . 15 93 20.2. Informative References . . . . . . . . . . . . . . . . . 16 94 Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 17 95 A.1. Routing extensions for Timing-aware Routers . . . . . . . 17 96 A.2. Signaling Extensions for Creating Timing LSPs . . . . . . 17 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 100 1. Introduction 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC2119 [RFC2119]. 106 When used in lower case, these words convey their typical use in 107 common language, and are not to be interpreted as described in 108 RFC2119 [RFC2119]. 110 The objective of timing distribution protocols, such as Precision 111 Time Protocol (PTP) and Network Timing Protocol (NTP), is to 112 synchronize clocks running on nodes of a distributed system. 114 Timing distribution protocols are presently transported over IP or 115 Ethernet. The present document presents a mechanism for transport 116 over Multiprotocol Label Switched (MPLS) networks. Our solution 117 involves transporting timing messages over dedicated "Timing Label 118 Switched Paths (LSPs)". These are ordinary LSPs that carry timing 119 messages and MAY carry Operations, Administration and Maintenance 120 (OAM) or management messages, but do not carry any other traffic. 122 Timing LSPs may be established statically or via signaling. When 123 using signaling, extensions to routing protocols (e.g., OSPF, ISIS) 124 are required to enable routers to distribute their timing processing 125 capabilities, and extensions to path set up protocols (e.g., RSVP-TE) 126 are required for establishing the LSPs. All such extensions are 127 beyond the scope of this document. 129 High accuracy timing distribution requires on-path support, e.g., 130 Transparent Clocks (TCs) or Boundary Clocks (BCs), at intermediate 131 nodes. These intermediate nodes need to recognize and appropriately 132 process timing distribution packets. To facilitate efficient 133 recognition of timing messages transported over MPLS, this document 134 restricts the specific encapsulations to be used. 136 [IEEE-1588] defines PTP messages for frequency, phase and time 137 synchronization. PTP messages may be transported over UDP/IP (Annex 138 D and E of [IEEE-1588]) or over Ethernet (Annex F of [IEEE-1588]). 139 This document defines two methods to transport PTP messages over MPLS 140 networks. 142 PTP defines several clock types, including ordinary clocks, boundary 143 clocks, end-to-end transparent clocks, and peer-to-peer transparent 144 clocks. Transparent clocks are situated at intermediate nodes and 145 update the Correction Field inside PTP messages in order to reflect 146 the time required to transit the node. 148 [RFC5905] defines NTP messages for clock and time synchronization. 149 NTP messages are transported over UDP/IP. This document defines a 150 method to transport NTP messages over MPLS networks. 152 It can be expected that only a subset of LSR ports will be capable of 153 processing timing messages. Timing LSPs MUST be set up (either by 154 manual provisioing or via signaling) to traverse these ports. While 155 Timing LSPs are designed to optimize timing distribution, the 156 performance of slave clocks is beyond the scope of this document. 158 Presently on-path support is only defined for PTP, and therefore much 159 of our discussion will focus on PTP. NTP timing distribution may 160 benefit from transport in a Timing LSP due to prioritorization or 161 selection of ports or nodes with minimal delay or delay asymmetry. 163 2. Terminology 165 1588: The timing distribution protocol defined in IEEE 1588. 167 Boundary Clock: A device with one timing port to receive timing 168 messages and at least one port to re-distribute timing messages. 170 CF: Correction Field, a field inside certain PTP messages that holds 171 the accumulated transit time. 173 Master Clock: The source of 1588 timing messages to a set of slave 174 clocks. 176 NTP: The timing distribution protocol defined in RFC 5905. 178 Ordinary Clock: A master or slave clock. Note that ordinary clocks 179 have only a single PTP port. 181 PTP: Precision Time Protocol. See 1588. 183 Slave Clock: A receiver of 1588 timing messages from a master clock. 185 Timing LSP: An MPLS LSP dedicated to carry timing messages. 187 Timing messages: Timing distribution protocol messages that are 188 exchanged between clocks. 190 Timing port: A port on a (master, slave, transparent, or boundary) 191 clock. 193 Timing PW: A PW within a Timing LSP that is dedicated to carry timing 194 messages. 196 Transparent Clock: An intermediate node that forwards timing messages 197 while updating their CF. 199 3. Problem Statement 201 [IEEE-1588] defines methods for transporting PTP messages over 202 Ethernet and IP networks. [RFC5905] defines a method of transporting 203 NTP messages over IP networks. There is a need to transport timing 204 messages over MPLS networks while supporting the Transparent Clock 205 (TC), Boundary Clock (BC) and Ordinary Clock (OC) functionalities in 206 LER and LSRs of the MPLS network. 208 There are potentially many ways of transporting timing packets over 209 MPLS. However, it is advisable to limit the number of possible 210 encapsulation options to simplify recognition and processing of 211 timing packets. 213 The solution herein desscribed transports timing messages over 214 dedicated "Timing Label Switched Paths (LSPs)". Were timing packets 215 to share LSPs with other traffic, intermediate LSRs would be required 216 to perform some deeper inspection to differentiate between timing 217 packets and other packets. The method herein proposed avoids this 218 complexity, and can readily detect all PTP messages (one-step or two- 219 step), and supports ordinary, boundary and transparent clocks. 221 4. Timing over MPLS Architecture 223 Timing messages are exchanged between timing ports on ordinary and 224 boundary clocks. Boundary clocks terminate the timing messages and 225 act as master clock for other boundary clocks or slave clocks. End- 226 to-End transparent clocks do not terminate the timing messages but do 227 modify the contents of the timing messages in transit. 229 OC, BC and TC functionality may be implemented in either LERs or 230 LSRs. 232 An example is shown in Figure 1, where the LERs act as OCs and are 233 the initiating/terminating points for timing messages. The ingress 234 LER encapsulates timing messages in a Timing LSP and the egress LER 235 terminates this Timing LSP. Intermediate LSRs (only one is shown 236 here) act as TCs, updating the CF of transiting timing messages, as 237 well as performing label switching operations. 239 +--------+ +-------+ +-------+ +-------+ +--------+ 240 |Switch, | | | | | | | |Switch, | 241 | Router |-----| LER |-----| LSR |-----| LER |-----| Router | 242 | | | OC | | TC | | OC | | | 243 +--------+ +-------+ +-------+ +-------+ +--------+ 244 / \ 245 +-------+ / \ +-------+ 246 | LER | / \ | LER | 247 | Master|---/ \---| Slave | 248 | Clock | | Clock | 249 +-------+ +-------+ 251 Figure (1) - Deployment example 1 of timing over MPLS network 253 Another example is shown in Figure 2, where LERs act as BCs, and 254 switches/routers outside of the MPLS network, act as OCs or BCs. The 255 ingress LER BC recovers timing and initiates timing messages 256 encapsulated in the Timing LSP toward the MPLS network, an 257 intermediate LSR acts as a TC, and the egress LER acts as a BC 258 sending timing messages to equipment outside the MPLS network. 260 +--------+ +-------+ +-------+ +-------+ +--------+ 261 |Switch, | | | | | | | |Switch, | 262 | Router |-----| LER |-----| LSR |-----| LER |-----| Router | 263 | OC/BC | | BC | | TC | | BC | | OC/BC | 264 +--------+ +-------+ +-------+ +-------+ +--------+ 266 Figure (2) - Deployment example 2 of timing over MPLS network 268 Yet another example is shown in Figure 3, where both LERs and LSRs 269 act as TCs. The ingress LER updates the CF and encapsulates the 270 timing message in an MPLS packet, intermediate LSRs update the CF and 271 perform label switching, and the egress LER updates the CF and sends 272 the timing messages to equipment outside the MPLS network. 274 +--------+ +-------+ +-------+ +-------+ +--------+ 275 |Switch, | | | | | | | |Switch, | 276 | Router |-----| LER |-----| LSR |-----| LER |-----| Router | 277 |OC/TC/BC| | TC | | TC | | TC | |OC/TC/BC| 278 +--------+ +-------+ +-------+ +-------+ +--------+ 280 Figure (3) - Deployment example 3 of timing over MPLS network 281 A final example is shown in Figure 4, where all nodes act as BCs. 282 Single-hop LSPs are created between every two adjacent LSRs. Of 283 course, PTP transport over Ethernet MAY be used between two network 284 elements. 286 +--------+ +-------+ +-------+ +-------+ +--------+ 287 |Switch, | | | | | | | |Switch, | 288 | Router |-----| LER |-----| LSR |-----| LER |-----| Router | 289 | OC/BC | | BC | | BC | | BC | | OC/BC | 290 +--------+ +-------+ +-------+ +-------+ +--------+ 292 Figure (4) - Deployment example 3 of timing over MPLS network 294 An MPLS domain MAY serve multiple customers, each having its own 295 Timing domain. In these cases the MPLS domain (maintained by a 296 service provider) MUST provide dedicated timing services to each 297 customer. 299 The timing over MPLS architecture assumes a full mesh of Timing LSPs 300 between all LERs supporting this specification. It supports point- 301 to- point (VPWS) and Multipoint (VPLS) services. This means that a 302 customer may purchase a point-to-point timing service between two 303 customer sites or a multipoint timing service between more than two 304 customer sites. 306 The Timing over MPLS architecture supports P2P or P2MP Timing LSPs. 307 This means that the Timing Multicast messages such as PTP Multicast 308 event messages MAY be transported over P2MP Timing LSPs or MAY be 309 replicated and transported over multiple P2P Timing LSPs. 311 Timing LSPs, as defined by this specification, MAY be used for timing 312 messages that do not require time-stamping or CF updating. 314 PTP Announce messages that determine the Timing LSP terminating point 315 behavior such as BC/OC/TC SHOULD be transported over the Timing LSP 316 to simplify hardware and software. 318 5. Dedicated LSPs for Timing messages 320 The method defined in this document is used by LER and LSRs to 321 identify timing messages by observing the top label of the MPLS label 322 stack. Compliant implementations MUST use dedicated LSPs to carry 323 timing messages over MPLS. Such LSPs are herein referred to as 324 "Timing LSPs" and the labels associated with these LSPs as "Timing 325 LSP labels". 327 Timing distribution requires symmetrical bidirectional 328 communications. Co-routing of the two directions is required to 329 limit delay asymmetry. Thus timing messages MUST be transported 330 either over two co-routed unidirectional Timing LSPs, or a single 331 bidirectional co-routed Timing LSP. 333 Timing LSPs MAY be configured using RSVP-TE. Extensions to RSVP-TE 334 are required for this purpose, but are beyond the scope of this 335 document. 337 6. Timing over LSP Encapsulation 339 We define two methods for carrying timing messages over MPLS. The 340 first method transports UDP/IP-encapsulated timing messages over 341 Timing LSPs, and the second method transports Ethernet encapsulated 342 timing messages over Ethernet PWs placed in Timing LSPs. 344 6.1. Timing over UDP/IP over MPLS Encapsulation 346 The first method directly encapsulates UDP/IP timing messages in a 347 Timing LSP. The UDP/IP encapsulation of PTP messages MUST comply to 348 Annex D and E of [IEEE-1588], and the UDP/IP encapsulation of NTP 349 messages MUST comply to [RFC5905]. This format is shown in Figure 4. 351 +----------------------+ 352 | Timing LSP Label | 353 +----------------------+ 354 | IPv4/6 | 355 +----------------------+ 356 | UDP | 357 +----------------------+ 358 | timing message | 359 +----------------------+ 361 Figure (4) - Timing over UDP/IP over MPLS Encapsulation 363 In order for an LER/LSR to process timing messages, the Timing LSP 364 Label must be the top label of the label stack. The LER/LSR MUST 365 know that this label is a Timing LSP Label. It can learn this by 366 static configuration or via RSVP-TE signaling. 368 6.2. Timing over PW Encapsulation 370 Another method of transporting timing over MPLS networks is to use 371 Ethernet encapsulated timing messages, and to transport these in an 372 Ethernet PW which in turn is transported over a Timing LSP. In the 373 case of PTP, the Ethernet encapsulation MUST comply to Annex F of 374 [IEEE-1588] and the Ethernet PW encapsulation to [RFC4448], resulting 375 in the format shown in Figure 5(A). 377 Either the Raw mode or Tagged mode defined in [RFC-4448] MAY be used 378 and the payload MAY have 0, 1, or 2 VLAN tags. The Timing over PW 379 encapsulation MUST use the Control Word (CW) as specified in 380 [RFC4448]. The use of Sequence Number in the CW is optional. 382 NTP MAY be transported using an IP PW (as defined in [RFC4447]) as 383 shown in Fig 5(B). 385 +-----------------+ +----------------+ 386 |Timing LSP Label | |Timing LSP Label| 387 +-----------------+ +----------------+ 388 | PW Label | | PW Label | 389 +-----------------+ +----------------+ 390 | Control Word | | IP | 391 +-----------------+ +----------------+ 392 | Ethernet | | UDP | 393 | Header | +----------------+ 394 +-----------------+ | Timing message | 395 |S-VLAN (Optional)| | | 396 +-----------------+ +----------------+ 397 |C-VLAN (Optional)| (B) 398 +-----------------+ 399 | Timing message | 400 | | 401 +-----------------+ 402 (A) 404 Figure (5) - Timing over PW Encapsulations 406 7. Timing message Processing 408 Each Timing protocol such as PTP and NTP, defines a set of timing 409 messages. PTP defines SYNC, DELAY_REQ, DELAY_RESP, FOLLOW_UP, etc. 411 Some timing messages require per-packet processing, such as time- 412 stamping or CF updating. A compliant LER/LSR parses each timing 413 message to determine the required processing. 415 For example, the following PTP messages (event messages) require 416 time-stamping or CF updating: 418 o SYNC 419 o DELAY_REQ (Delay Request) 421 o PDELAY_REQ (Peer Delay Request) 423 o PDELAY_RESP (Peer Delay Response) 425 SYNC and DELAY_REQ are exchanged between a Master Clock and a Slave 426 Clock and MUST be transported over Timing LSPs. PDELAY_REQ and 427 PDELAY_RESP are exchanged between adjacent PTP clocks (master, slave, 428 boundary, or transparent) and SHOULD be transported over single hop 429 Timing LSPs. If two-Step PTP clocks are present, then the FOLLOW_UP, 430 and PDELAY_RESP_FOLLOW_UP messages MUST also be transported over 431 Timing LSPs. 433 For a given instance of the 1588 protocol, SYNC and DELAY_REQ MUST be 434 transported in opposite directions. As aforementioned, two co-routed 435 unidirectional LSPs or a single bidirectional co-routed LSP MAY be 436 used. 438 Except as indicated above for two-step PTP clocks, PTP messages that 439 are not "event messages" need not be processed by intermediate 440 routers. These message types MAY be carried in PTP Tunnel LSPs. 442 8. Protection and Redundancy 444 In order to ensure continuous uninterrupted operation of timing 445 distribution, slave clocks often track redundant master clocks. 446 Prolonged outages of Timing LSPs trigger switching to a redundant 447 master clock It is the responsibility of the network operator to 448 ensure that physically disjoint Timing LSPs are established between a 449 slave clock and redundant master clocks. 451 LSP or PW layer protection, such as linear protection Switching, ring 452 protection switching or MPLS Fast Reroute (FRR), will lead to changes 453 in propagation delay between master and slave clocks. Such a change, 454 if undetected by the slave clock, would negatively impact timing 455 performance. While it is expected that slave clocks will often be 456 able to detect such delay changes, this specification RECOMMENDS that 457 automatic protection switching NOT be used for Timing LSPs, unless 458 the operator can ensure that it will not negatively impact timing 459 performance. 461 9. ECMP and Entropy 463 To ensure the correct operation of slave clocks and avoid error 464 introduced by forward and reverse path delay asymmetry, the physical 465 path taken by timing messages MUST be the same for all timing 466 messages. In particular, the PTP event messages listed in section 7 467 MUST be routed in the same way. 469 Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost 470 Multipath). Entropy labels MUST NOT be used for the Timing LSP 471 [RFC6790] and MUST NOT be used for PWs inside the Timing LSP 472 [RFC6391]. 474 10. PHP 476 To ensure that the label on the top of the label stack is the Timing 477 LSP Label, PHP MUST not be employed. 479 11. OAM, Control and Management 481 In order to monitor Timing LSPs or PWs, it is necessary to enable 482 them to carry OAM messages. OAM packets MUST be differentiated from 483 timing messages by already defined IETF methods. 485 For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY run 486 over Timing LSPs via UDP/IP encapsulation or via GAL/G-ACh. These 487 protocols can easily be identified by the UDP Destination port number 488 or by GAL/G-ACh respectively. 490 Also BFD, LSP-Ping and other messages MAY run over Timing PWs via 491 VCCV [RFC5085]. In this case these messages are recognized according 492 to the VCCV type. 494 12. QoS Considerations 496 There may be deployments where timing messages traverse LSR/LERs that 497 are not capable of the required processing. In order to minimize the 498 negative impact on the timing performance of the slave clock timing 499 messages MUST be treated with the highest priority. This can be 500 achieved by proper setup of Timing LSPs. 502 It is recommended that Timing LSPs be configured to indicate EF-PHB 503 [RFC3246] for the CoS and "green" [RFC2697] for drop eligibility. 505 13. FCS and Checksum Recalculation 507 Since Boundary and Transparent Clocks modify packets, when the MPLS 508 packets are transported over Ethernet the processing MUST include 509 recalculation of the Ethernet FCS. FCS retention as described in 510 [RFC4720] MUST NOT be used. 512 For the UDP/IP encapsulation mode, calculation of the UDP checksum 513 will generally be required. After updating the CF a Transparent 514 Clock MUST either incrementally update the UDP checksum or completely 515 recalculate the checksum before transmission to downstream node. 517 14. Behavior of LER/LSRs 519 Timing-aware LERs or LSRs are MPLS routers that are able to recognize 520 timing packets. Timing-capable LERs and LSRs further have one or 521 more interfaces that can perform timing processing (OC/BC/TC) on 522 timing packets. Timing-capable/aware LERs and LSRs MAY advertise the 523 timing capabilities of their interfaces via control plane protocols 524 such as OSPF or IS-IS, and timing-aware LERs can then be set up 525 Timing LSPs via RSVP-TE signaling. Alternatively the timing 526 capabilities of LERs and LSRs may be known by a centralized 527 controller or management system, and Timing LSPs may be manually 528 configured, or set up by a management platform or a Software Defined 529 Networking (SDN) controller. 531 14.1. Behavior of Timing-capable/aware LERs/LSRs 533 When a timing-capable ingress LER acting as a TC receives a timing 534 message packet from a timing-capable non-MPLS interface, the LER 535 updates the CF, encapsulates and forwards the packet over a 536 previously established Timing LSP. When a timing-capable egress LER 537 acting as a TC receives a timing message packet on timing-capable 538 MPLS interface, the LER updates the CF, decapsulates the MPLS 539 encapsulation, and forwards the packet via a non-MPLS interface. 540 When a timing-capable LSR acting as a TC receives a timing message 541 from a timing-capable MPLS interface, the LSR updates the CF and 542 forwards the timing message over another MPLS interface. 544 When a timing-capable LER acting as a BC receives a timing message 545 packet from a timing-capable interface, the LER time-stamps the 546 packet and sends it to the BC processing module. 548 When a timing-capable LER acting as an OC receives a timing message 549 from a timing-capable MPLS interface, the LER time-stamps the packet 550 and sends it to the OC processing module. 552 14.2. Behavior of non-Timing-capable/aware LSR 554 It is most beneficial when all LSRs in the path of a Timing LSP be 555 timing-Capable/aware LSRs. This would ensure the highest quality 556 time and clock synchronization by slave clocks. However, this 557 specification does not mandate that all LSRs in path of a Timing LSP 558 be timing-capable/aware. 560 Non-timing-capable/aware LSRs just perform label switching on the 561 packets encapsulated in Timing LSPs and don't perform any timing 562 related processing. However, as explained in QoS section, timing 563 packets MUST be still be treated with the highest priority based on 564 their Traffic Class marking. 566 15. Other considerations 568 [IEEE-1588] defines an optional peer-to-peer transparent clocking 569 (P2P TC) mode that compensates both for residence time in the network 570 node and for propagation time on the link between modes. To support 571 P2P TC, delay measurement must be performed between two adjacent 572 timing-capable/aware LSRs. Thus, in addition to the TC functionality 573 detailed above on transit PTP timing messages, adjacent peer to peer 574 TCs MUST engage in single-hop peer delay measurement. 576 For single hop peer delay measurement a single-hop LSP SHOULD be 577 created between the two adjacent LSRs. Other methods MAY be used; 578 for example, if the link between the two adjacent routers is 579 Ethernet, PTP transport over Ethernet MAY be used. 581 To support P2P TC, a timing-capable/ware LSR MUST maintain a list of 582 all neighbors to which it needs to send a PDelay_Req, and maintain a 583 single-hop timing LSP to each. 585 The use of Explicit Null Label (label 0 or 2) is acceptable as long 586 as either the Explicit Null label is the bottom of stack label (for 587 the UDP/IP encapsulation) or the label below the Explicit Null label 588 (for the PW case). 590 16. Security Considerations 592 Security considerations for MPLS and pseudowires are discussed in 593 [RFC3985] and [RFC4447]. Security considerations for timing are 594 discussed in [RFC7384]. Everything discussed in those documents 595 applies to the Timing LSP of this document. 597 An experimental security protocol is defined in [IEEE-1588]. The PTP 598 security extension and protocol provides group source authentication, 599 message integrity, and replay attack protection for PTP messages. 601 When the MPLS network (provider network) serves multiple customers, 602 it is important to distinguish between timing messages belonging to 603 different customers. For example if an LER BC is synchronized to a 604 grandmaster belonging to customer A, then the LER MUST only use that 605 BC for slaves of customer A, to ensure that customer A cannot 606 adversely affect the timing distribution of other customers. 608 Timing messages MAY be encrypted or authenticated, provided that the 609 timing-capable LERs/LSRs can authenticate/ decrypt the timing 610 messages. 612 17. Applicability Statement 614 The Timing over MPLS transport methods described in this document 615 apply to the following network Elements: 617 o An ingress LER that receives IP or Ethernet encapsulated timing 618 messages from a non-MPLS interface and forwards them as MPLS 619 encapsulated timing messages over Timing LSP, optionally 620 performing TC functionality. 622 o An egress LER that receives MPLS encapsulated timing messages from 623 a Timing LSP and forwards them to non-MPLS interface as IP or 624 Ethernet encapsulated timing messages, optionally performing TC 625 functionality. 627 o An ingress LER that receives MPLS encapsulated timing messages 628 from a non-MPLS interface, performs BC functionality, and sends 629 timing messages over a Timing LSP. 631 o An egress LER that receives MPLS encapsulated timing messages from 632 a Timing LSP, performs BC functionality, and sends timing messages 633 over a non-MPLS interface. 635 o An LSR on a Timing LSP that receives MPLS encapsulated timing 636 messages from one MPLS interface and forwards them to another MPLS 637 interface, optionally performing TC functionality. 639 This document also supports the case where not all LSRs are timing- 640 capable/aware, or not all LER/LSR interfaces are timing-capable/ 641 aware. 643 18. Acknowledgements 645 The authors would like to thank Yaakov Stein, Luca Martini, Ron 646 Cohen, Tal Mizrahi, Stefano Ruffini, Peter Meyer and other IETF 647 participants for reviewing and providing feedback on this draft. 649 19. IANA Considerations 651 There are no IANA requirements in this specification. 653 20. References 655 20.1. Normative References 657 [IEEE-1588] 658 IEEE 1588-2008, "IEEE Standard for a Precision Clock 659 Synchronization Protocol for Networked Measurement and 660 Control Systems", July 2008. 662 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 663 Requirement Levels", BCP 14, RFC 2119, 664 DOI 10.17487/RFC2119, March 1997, 665 . 667 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 668 Edge-to-Edge (PWE3) Architecture", RFC 3985, 669 DOI 10.17487/RFC3985, March 2005, 670 . 672 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 673 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 674 2006, . 676 [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 677 G. Heron, "Pseudowire Setup and Maintenance Using the 678 Label Distribution Protocol (LDP)", RFC 4447, 679 DOI 10.17487/RFC4447, April 2006, 680 . 682 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 683 "Encapsulation Methods for Transport of Ethernet over MPLS 684 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 685 . 687 [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire 688 Emulation Edge-to-Edge (PWE3) Frame Check Sequence 689 Retention", RFC 4720, DOI 10.17487/RFC4720, November 2006, 690 . 692 [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual 693 Circuit Connectivity Verification (VCCV): A Control 694 Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, 695 December 2007, . 697 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 698 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 699 . 701 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 702 "Bidirectional Forwarding Detection (BFD) for MPLS Label 703 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 704 June 2010, . 706 20.2. Informative References 708 [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate 709 system routing information exchange protocol for use in 710 conjunction with the Protocol for providing the 711 Connectionless-mode Network Service (ISO 8473)", April 712 1992. 714 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 715 dual environments", RFC 1195, DOI 10.17487/RFC1195, 716 December 1990, . 718 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 719 DOI 10.17487/RFC2328, April 1998, 720 . 722 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 723 Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999, 724 . 726 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 727 J., Courtney, W., Davari, S., Firoiu, V., and D. 728 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 729 Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, 730 . 732 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 733 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 734 . 736 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 737 "Network Time Protocol Version 4: Protocol and Algorithms 738 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 739 . 741 [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 742 Regan, J., and S. Amante, "Flow-Aware Transport of 743 Pseudowires over an MPLS Packet Switched Network", 744 RFC 6391, DOI 10.17487/RFC6391, November 2011, 745 . 747 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 748 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 749 RFC 6790, DOI 10.17487/RFC6790, November 2012, 750 . 752 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 753 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 754 October 2014, . 756 Appendix A. Appendix 758 A.1. Routing extensions for Timing-aware Routers 760 MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and 761 IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE) 762 link information used for constraint-based routing. 764 Timing related capabilities, such as the capability for a router to 765 perform time-stamping, and OC, TC or BC processing, need to be 766 advertised in order for them to be taken into account during path 767 computation. A management system or SDN controller cognizant of 768 timing related capabilities, can prefer or even require a Timing LSP 769 to traverse links or nodes or intefaces with the required 770 capabilities. The optimal path will optimize the performance of the 771 slave clock. 773 Extensions are required to OSPF and IS-IS in order to advertise 774 timing related capabilities of a link. Such extensions are outside 775 the scope of this document; however such extensions SHOULD be able to 776 signal the following information per Router Link: 778 o Capable of processing PTP, NTP or other timing flows 780 o Capable of performing TC operation 782 o Capable of performing BC operation 784 A.2. Signaling Extensions for Creating Timing LSPs 786 RSVP-TE signaling MAY be used to set up Timing LSPs. Extensions are 787 required to RSVP-TE for this purpose. Such extensions are outside 788 the scope of this document; however, the following information MAY be 789 included in such extensions: 791 o Offset from Bottom of Stack (BoS) to the start of the Time-stamp 792 field 794 o Number of VLANs in case of PW encapsulation 795 o Time-stamp field Type 797 * Correction Field, time-stamp 799 o Time-stamp Field format 801 * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit 802 NTP, etc. 804 Note that when the above optional information is signaled with RSVP- 805 TE for a Timing LSP, all the timing packets carried in that LSP must 806 have the same signaled characteristics. For example if time-stamp 807 format is signaled as 64-bit PTPv1, then all timing packets must use 808 64-bit PTPv1 time-stamp. 810 Authors' Addresses 812 Shahram Davari 813 Broadcom Corp. 814 San Jose, CA 95134 815 USA 817 Email: davari@broadcom.com 819 Amit Oren 820 Broadcom Corp. 821 San Jose, CA 95134 822 USA 824 Email: amito@broadcom.com 826 Manav Bhatia 827 Alcatel-Lucent 828 Bangalore 829 India 831 Email: manav.bhatia@alcatel-lucent.com 833 Peter Roberts 834 Alcatel-Lucent 835 Kanata 836 Canada 838 Email: peter.roberts@alcatel-lucent.com 839 Laurent Montini 840 Cisco Systems 841 San Jose CA 842 USA 844 Email: lmontini@cisco.com