idnits 2.17.1 draft-ietf-tictoc-1588overmpls-02.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 -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: In network deployments where every LSR/LER supports PTP LSPs, then it MAY NOT be required to apply the same level of prioritization as specified above. -- The document date (October 7, 2011) is 4582 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) == Unused Reference: 'RFC4970' is defined on line 887, but no explicit reference was found in the text == Unused Reference: 'RFC4971' is defined on line 891, 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: 3 errors (**), 0 flaws (~~), 4 warnings (==), 6 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 9, 2012 M. Bhatia 6 P. Roberts 7 Alcatel-Lucent 8 L. Montini 9 Cisco Systems 10 October 7, 2011 12 Transporting PTP messages (1588) over MPLS Networks 13 draft-ietf-tictoc-1588overmpls-02 15 Abstract 17 This document defines the method for transporting PTP messages (PDUs) 18 over an MPLS network. The method allows for the easy identification 19 of these PDUs at the port level to allow for port level processing of 20 these PDUs in both LERs and LSRs. 22 The basic idea is to transport PTP messages inside dedicated MPLS 23 LSPs. These LSPs only carry PTP messages and possibly Control and 24 Management packets, but they do not carry customer traffic. 26 Two methods for transporting 1588 over MPLS are defined. The first 27 method is to transport PTP messages directly over the dedicated MPLS 28 LSP via UDP/IP encapsulation, which is suitable for IP/MPLS networks. 29 The second method is to transport PTP messages inside a PW via 30 Ethernet encapsulation, which is more suitable for MPLS-TP networks. 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 April 9, 2012. 49 Copyright Notice 51 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 72 4. 1588 over MPLS Architecture . . . . . . . . . . . . . . . . . 9 74 5. Dedicated LSPs for PTP messages . . . . . . . . . . . . . . . 10 76 6. 1588 over MPLS Encapsulation . . . . . . . . . . . . . . . . . 11 77 6.1. 1588 over LSP Encapsulation . . . . . . . . . . . . . . . 11 78 6.2. 1588 over PW Encapsulation . . . . . . . . . . . . . . . . 11 80 7. 1588 Message Transport . . . . . . . . . . . . . . . . . . . . 14 82 8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 16 84 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 10. OAM, Control and Management . . . . . . . . . . . . . . . . . 18 88 11. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 19 90 12. FCS Recalculation . . . . . . . . . . . . . . . . . . . . . . 20 92 13. UDP Checksum Correction . . . . . . . . . . . . . . . . . . . 21 94 14. Routing extensions for 1588aware LSRs . . . . . . . . . . . . 22 95 14.1. 1588aware Link Capability for OSPF . . . . . . . . . . . . 22 96 14.2. 1588aware Link Capability for IS-IS . . . . . . . . . . . 23 98 15. RSVP-TE Extensions for support of 1588 . . . . . . . . . . . . 25 100 16. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 26 101 16.1. Behavior of 1588-aware LER . . . . . . . . . . . . . . . . 26 102 16.2. Behavior of 1588-aware LSR . . . . . . . . . . . . . . . . 26 103 16.3. Behavior of non-1588-aware LSR . . . . . . . . . . . . . . 26 105 17. Other considerations . . . . . . . . . . . . . . . . . . . . . 28 107 18. Security Considerations . . . . . . . . . . . . . . . . . . . 29 109 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 111 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 112 20.1. IANA Considerations for OSPF . . . . . . . . . . . . . . . 31 113 20.2. IANA Considerations for IS-IS . . . . . . . . . . . . . . 31 114 20.3. IANA Considerations for RSVP . . . . . . . . . . . . . . . 31 116 21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 117 21.1. Normative References . . . . . . . . . . . . . . . . . . . 32 118 21.2. Informative References . . . . . . . . . . . . . . . . . . 32 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC2119 [RFC2119]. 125 When used in lower case, these words convey their typical use in 126 common language, and are not to be interpreted as described in 127 RFC2119 [RFC2119]. 129 1. Introduction 131 The objective of Precision Time Protocol (PTP) is to synchronize 132 independent clocks running on separate nodes of a distributed system. 133 [IEEE] defines PTP messages for clock and time synchronization. The 134 PTP messages include PTP PDUs over UDP/IP (Annex D and E of [IEEE]) 135 and PTP PDUs over Ethernet (Annex F of [IEEE]). This document 136 defines mapping and transport of the PTP messages defined in [IEEE] 137 over MPLS networks. 139 PTP defines several clock types: ordinary clocks, boundary clocks, 140 end-to-end transparent clocks, and peer-to-peer transparent clocks. 141 One key attribute of all of these clocks is the recommendation for 142 PTP messages processing to occur as close as possible to the actual 143 transmission and reception at the physical port interface. This 144 targets optimal time and/or frequency recovery by avoiding variable 145 delay introduced by queues internal to the clocks. To facilitate the 146 fast and efficient recognition of PTP messages at the port level when 147 the PTP messages are carried over MPLS LSPs, this document defines 148 the specific encapsulations that should be used. In addition, it can 149 be expected that there will exist LSR/LERs where only a subset of the 150 physical ports will have the port based PTP message processing 151 capabilities. In order to ensure that the PTP carrying LSPs always 152 enter and exit ports with this capability, routing extensions are 153 defined to advertise this capability on a port basis and to allow for 154 the establishment of LSPs that only transit such ports. While this 155 path establishment restriction may be applied only at the LER 156 ingress/egress ports, it becomes more important when using 157 Transparent Clock capable LSRs in the path. 159 The port based PTP message processing involves PTP event message 160 recognition. Once the PTP event messages are recognized they can be 161 modified based on the reception or transmission timestamp. An 162 alternative technique to actual packet modification could include the 163 enforcement of a fixed delay time across the LSR to remove 164 variability in the transit delay. This latter would be applicable in 165 a LSR which does not contain a PTP transparent Clock function. 167 This document provides two methods for transporting PTP messages over 168 MPLS. One is principally focused on an IP/MPLS environment and the 169 second is focused on the MPLS-TP environment. 171 While the techniques included herein allow for the establishment of 172 paths optimized to include PTP Timestamping capable links, the 173 performance of the Slave clocks is outside the scope of this 174 document. 176 2. Terminology 178 1588: The timing and synchronization as defined by IEEE 1588 180 PTP: The timing and synchronization protocol used by 1588 182 Master Clock: The source of 1588 timing to a set of slave clocks. 184 Master Port: A port on a ordinary or boundary clock that is in Master 185 state. This is the source of timing toward slave ports. 187 Slave Clock: A receiver of 1588 timing from a master clock 189 Slave Port: A port on a boundary clock or ordinary clock that is 190 receiving timing from a master clock. 192 Ordinary Clock: A device with a single PTP port. 194 Transparent Clock. A device that measures the time taken for a PTP 195 event message to transit the device and then updates the 196 correctionField of the message with this transit time. 198 Boundary Clock: A device with more than one PTP port. Generally 199 boundary clocks will have one port in slave state to receive timing 200 and then other ports in master state to re-distribute the timing. 202 PTP LSP: An LSP dedicated to carry PTP messages 204 PTP PW: A PW within a PTP LSP that is dedicated to carry PTP 205 messages. 207 CW: Pseudowire Control Word 209 LAG: Link Aggregation 211 ECMP: Equal Cost Multipath 213 CF: Correction Field, a field inside certain PTP messages (message 214 type 0-3)that holds the accumulative transit time inside intermediate 215 switches 217 3. Problem Statement 219 When PTP messages are transported over MPLS networks, there is a need 220 for PTP message processing at the physical port level. This 221 requirement exists to minimum uncertainty in the transit delays. If 222 PTP message processing occurs interior to the MPLS routers, then the 223 variable delay introduced by queuing between the physical port and 224 the PTP processing will add noise to the timing distribution. Port 225 based processing applies at both the originating and terminating LERs 226 and also at the intermediate LSRs if they support transparent clock 227 functionality. 229 PTP messages over Ethernet or IP can always be tunneled over MPLS. 230 However there is a requirement to limit the possible encapsulation 231 options to simplify the PTP message processing required at the port 232 level. This applies to all 1588 clock types implemented in MPLS 233 routers. But this is particularly important in LSRs that provide 234 transparent clock functionality. 236 When 1588-awareness is needed, PTP messages should not be transported 237 over LSPs or PWs that are carrying customer traffic because LSRs 238 perform Label switching based on the top label in the stack. To 239 detect PTP messages inside such LSPs require special hardware to do 240 deep packet inspection at line rate. Even if such hardware exists, 241 the payload can't be deterministically identified by LSRs because the 242 payload type is a context of the PW label and the PW label and its 243 context are only known to the Edge routers (PEs); LSRs don't know 244 what is a PW's payload (Ethernet, ATM, FR, CES, etc). Even if one 245 restricts an LSP to only carry Etehrent PWs, the LSRs don't have the 246 knowledge of whether PW Control Word (CW) is present or not and 247 therefore can't deterministically identify the payload. 249 Therefore a generic method is defined in this document that does not 250 require deep packet inspection at line rate, and can 251 deterministically identify PTP messages. The defined method is 252 applicable to both MPLS and MPLS-TP networks. 254 4. 1588 over MPLS Architecture 256 1588 communication flows map onto MPLS nodes as follows: 1588 257 messages are exchange between PTP ports on Ordinary and boundary 258 clocks. Transparent clocks do not terminate the PTP messages but 259 they do modify the contents of the PTP messages as they transit 260 across the Transparent clock. SO Ordinary and boundary clocks would 261 exist within LERs as they are the termination points for the PTP 262 messages carried in MPLS. Transparent clocks would exist within LSRs 263 as they do not terminate the PTP message exchange. 265 Perhaps a picture would be good here. 267 5. Dedicated LSPs for PTP messages 269 Many methods were considered for identifying the 1588 messages when 270 they are encapsulated in MPLS such as by using GAL/ACH or a new 271 reserved label. These methods were not attractive since they either 272 required deep packet inspection and snooping at line rate or they 273 required use of a scarce new reserved label. Also one of the goals 274 was to reuse existing OAM and protection mechanisms. 276 The method defined in this document can be used by LER/LSRs to 277 identify PTP messages in MPLS tunnels by using dedicated LSPs to 278 carry PTP messages. 280 Compliant implementations MUST use dedicated LSPs to carry PTP 281 messages over MPLS. These LSPs are herein referred to as "PTP LSPs" 282 and the labels associated with these LSPs as "PTP labels". These 283 LSPs could be P2P or P2MP LSPs. The PTP LSP between Master Clocks 284 and Slave Clocks MAY be P2MP or P2P LSP while the PTP LSP between 285 each Slave Clock and Master Clock SHOULD be P2P LSP. The PTP LSP 286 between a Master Clock and a Slave Clock and the PTP LSP between the 287 same Slave Clock and Master Clock MUST be co-routed. Alternatively, 288 a single bidirectional co-routed LSP can be used. The PTP LSP MAY be 289 MPLS LSP or MPLS-TP LSP. This co-routing is required to limit 290 differences in the delays in the Master clock to Slave clock 291 direction compared to the Slave clock to Master clock direction. 293 The PTP LSPs could be configured or signaled via RSVP-TE/GMPLS. New 294 RSVP-TE/GMPLS TLVs and objects are defined in this document to 295 indicate that these LSPs are PTP LSPs. 297 The PTP LSPs MAY carry essential MPLS/MPLS-TP control plane traffic 298 such as BFD and LSP Ping but the LSP user plane traffic MUST be PTP 299 only. 301 6. 1588 over MPLS Encapsulation 303 This document defines two methods for carrying PTP messages over 304 MPLS. The first method is carrying IP encapsulated PTP messages over 305 PTP LSPs and the second method is to carry PTP messages over 306 dedicated Ethernet PWs (called PTP PWs) inside PTP LSPs. 308 6.1. 1588 over LSP Encapsulation 310 The simplest method of transporting PTP messages over MPLS is to 311 encapsulate PTP PDUs in UDP/IP and then encapsulate them in PTP LSP. 312 The 1588 over LSP format is shown in Figure 1. 314 +----------------------+ 315 | PTP Tunnel Label | 316 +----------------------+ 317 | IPv4/6 | 318 +----------------------+ 319 | UDP | 320 +----------------------+ 321 | PTP PDU | 322 +----------------------+ 324 Figure 1 - 1588 over LSP Encapsulation 326 This encapsulation is very simple and is useful when the networks 327 between 1588 Master Clock and Slave Clock are IP/MPLS networks. 329 In order for an LSR to process PTP messages, the PTP Label must be 330 the top label of the label stack. 332 The UDP/IP encapsulation of PTP MUST follow Annex D and E of [IEEE]. 334 6.2. 1588 over PW Encapsulation 336 Another method of transporting 1588 over MPLS networks is by 337 encapsulating PTP PDUs in Ethernet and then transporting them over 338 Ethernet PW (PTP PW) as defined in [RFC4448], which in turn is 339 transported over PTP LSPs. Alternatively PTP PDUs MAY be 340 encapsulated in UDP/IP/Ethernet and then transported over Ethernet 341 PW. 343 Both Raw and Tagged modes for Ethernet PW are permitted. The 1588 344 over PW format is shown in Figure 2. 346 +----------------+ 347 |PTP Tunnel Label| 348 +----------------+ 349 | PW Label | 350 +----------------+ 351 | Control Word | 352 +----------------+ 353 | Ethernet | 354 | Header | 355 +----------------+ 356 | VLANs | 357 | (optional) | 358 +----------------+ 359 | IPV4/V6 | 360 | (optional) | 361 +----------------+ 362 | UDP | 363 | (optional) | 364 +----------------+ 365 | PTP PDU | 366 +----------------+ 368 Figure 2 - 1588 over PW Encapsulation 370 The Control Word (CW) as specified in [RFC4448] SHOULD be used to 371 ensure a more robust detection of PTP messages inside the MPLS 372 packet. If CW is used, the use of Sequence number is optional. 374 The use of VLAN and UDP/IP are optional. Note that 1 or 2 VLANs MAY 375 exist in the PW payload. 377 In order for an LSR to process PTP messages, the top label of the 378 label stack (the Tunnel Label) MUST be from PTP label range. However 379 in some applications the PW label may be the top label in the stack, 380 such as cases where there is only one-hop between PEs or in case of 381 PHP. In such cases, the PW label SHOULD be chosen from the PTP Label 382 range. 384 In order to ensure congruency between the two directions of PTP 385 message flow, ECMP should not be used for the PTP LSPs. Therefore, 386 no Entropy label [I-D.ietf-pwe3-fat-pw] is necessary and it SHOULD 387 NOT be present in the stack. 389 The Ethernet encapsulation of PTP MUST follow Annex F of [IEEE] and 390 the UDP/IP encapsulation of PTP MUST follow Annex D and E of [IEEE]. 392 For 1588 over MPLS encapsulations that are PW based, there are some 393 cases in which the PTP LSP label may not be present: 395 o When PHP is applied to the PTP LSP, and the packet is received 396 without PTP LSP label at PW termination point . 398 o When the PW is established between two routers directly connected 399 to each other and no PTP LSP is needed. 401 In such cases it is required for a router to identify these packets 402 as PTP packets. This would require the PW label to also be a label 403 that is distributed specifically for carrying PTP traffic (aka PTP PW 404 label). Therefore there is a need to add extension to LDP/BGP PW 405 label distribution protocol to indicate that a PW label is a PTP PW 406 labels. 408 7. 1588 Message Transport 410 1588 protocol comprises of the following message types: 412 o Announce 414 o SYNC 416 o FOLLOW UP 418 o DELAY_REQ (Delay Request) 420 o DELAY_RESP (Delay Response) 422 o PDELAY_REQ (Peer Delay Request) 424 o PDELAY_RESP (Peer Delay Response) 426 o PDELAY_RESP_FOLLOW_UP (Peer Delay Response Follow up) 428 o Management 430 o Signaling 432 A subset of PTP message types that require timestamp processing are 433 called Event messages: 435 o SYNC 437 o DELAY_REQ (Delay Request) 439 o PDELAY_REQ (Peer Delay Request) 441 o PDELAY_RESP (Peer Delay Response) 443 SYNC and DELAY_REQ are exchanged between Master Clock and Slave Clock 444 and MUST be transported over PTP LSPs. PDELAY_REQ and PDELAY_RESP 445 are exchanged between adjacent PTP clocks (i.e. Master, Slave, 446 Boundary, or Transparent) and MAY be transported over single hop PTP 447 LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP, 448 DELAY_RESP, and PDELAY_RESP_FOLLOW_UP messages must also be 449 transported over the PTP LSPs. 451 For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be 452 transported over two PTP LSPs that are in opposite directions. These 453 PTP LSPs, which are in opposite directions MUST be congruent and co- 454 routed. Alternatively, a single bidirectional co-routed LSP can be 455 used. 457 Except as indicated above for the two-step PTP clocks, Non-Event PTP 458 message types don't need to be processed by intermediate routers. 459 These message types MAY be carried in PTP Tunnel LSPs. 461 8. Protection and Redundancy 463 In order to ensure continuous uninterrupted operation of 1588 Slaves, 464 usually as a general practice, Redundant Masters are tracked by each 465 Slave. It is the responsibility of the network operator to ensure 466 that physically disjoint PTP tunnels that don't share any link are 467 used between the redundant Masters and a Slave. 469 When redundant Masters are tracked by a Slave, any prolonged PTP LSP 470 or PTP PW outage will trigger the Slave Clock to switch to the 471 Redundant Master Clock. However LSP/PW protection such as Linear 472 Protection Switching (1:1,1+1), Ring protection switching or MPLS 473 Fast Reroute (FRR) SHOULD still be used to provide resiliency to 474 individual network segment failures.. 476 Note that any protection or reroute mechanism that adds additional 477 label to the label stack, such as Facility Backup Fast Reroute, MUST 478 ensure that the pushed label is a PTP Label to ensure recognition of 479 the MPLS frame as containing PTP messages as it transits the backup 480 path.. 482 9. ECMP 484 To ensure the optimal operation of 1588 Slave clocks and avoid errors 485 introduced by forward and reverse path delay asymmetry, the physical 486 path for PTP messages from Master Clock to Slave Clock and vice versa 487 must be the same for all PTP messages listed in section 7 and must 488 not change even in the presence of ECMP in the MPLS network. 490 To ensure the forward and reverse paths are the same PTP LSPs and PWs 491 MUST NOT be subject to ECMP. 493 10. OAM, Control and Management 495 In order to manage PTP LSPs and PTP PWs, they MAY carry OAM, Control 496 and Management messages. These control and management messages can 497 be differentiated from PTP messages via already defined IETF methods. 499 In particular BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389]MAY run 500 over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These 501 Management protocols are easily identified by the UDP Destination 502 Port number or by GAL/ACH respectively. 504 Also BFD, LSP-Ping and other Management messages MAY run over PTP PW 505 via one of the defined VCCVs (Type 1, 2 or 3) [RFC5085]. In this 506 case G-ACH, Router Alert Label (RAL), or PW label (TTL=1) are used to 507 identify such management messages. 509 11. QoS Considerations 511 In network deployments where not every LSR/LER is PTP-aware, then it 512 is important to reduce the impact of the non-PTP-aware LSR/LERs on 513 the timing recovery in the slave clock. The PTP messages are time 514 critical and must be treated with the highest priority. Therefore 515 1588 over MPLS messages must be treated with the highest priority in 516 the routers. This can be achieved by proper setup of PTP tunnels. 517 It is recommended that the PTP LSPs are setup and marked properly to 518 indicate EF-PHB for the CoS and Green for drop eligibility. 520 In network deployments where every LSR/LER supports PTP LSPs, then it 521 MAY NOT be required to apply the same level of prioritization as 522 specified above. 524 12. FCS Recalculation 526 Ethernet FCS of the outer encapsulation MUST be recalculated at every 527 LSR that performs the Transparent Clock processing and FCS retention 528 for the payload Ethernet described in [RFC4720] MUST NOT be used. 530 13. UDP Checksum Correction 532 For UDP/IP encapsulation mode of 1588 over MPLS, the UDP checksum is 533 optional when used for IPv4 encapsulation and mandatory in case of 534 IPv6. When IPv4/v6 UDP checksum is used each 1588-aware LSR must 535 either incrementally update the UDP checksum after the CF update or 536 should verify the UDP checksum on reception from upstream and 537 recalculate the checksum completely on transmission after CF update 538 to downstream node. 540 14. Routing extensions for 1588aware LSRs 542 MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and 543 IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE) 544 link information used for constraint-based routing. 546 Indeed, it is useful to advertise data plane TE router link 547 capabilities, such as the capability for a router to be 1588-aware. 548 This capability MUST then be taken into account during path 549 computation to prefer or even require links that advertise themselves 550 as 1588-aware. In this way the path can ensure the entry and exit 551 points into the LERs and, if desired, the links into the LSRs are 552 able to perform port based timestamping thus minimizing their impact 553 on the performance of the slave clock. 555 For this purpose, the following sections specify extensions to OSPF 556 and IS-IS in order to advertise 1588 aware capabilities of a link. 558 14.1. 1588aware Link Capability for OSPF 560 OSPF uses the Link TLV (Type 2) that is itself carried within either 561 the Traffic Engineering LSA specified in [RFC3630] or the OSPFv3 562 Intra-Area-TE LSA (function code 10) defined in [RFC5329] to 563 advertise the TE related information for the locally attached router 564 links. For an LSA Type 10, one LSA can contain one Link TLV 565 information for a single link. This extension defines a new 1588- 566 aware capability sub-TLV that can be carried as part of the Link TLV. 568 The 1588-aware capability sub-TLV is OPTIONAL and MUST NOT appear 569 more than once within the Link TLV. If a second instance of the 570 1588-aware capability sub-TLV is present, the receiving system MUST 571 only process the first instance of the sub-TLV. It is defined as 572 follows: 574 0 1 2 3 575 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Type | Length | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Flags | 580 +-+-+-+-+-+-+-+-+ 582 Figure 3: 1588-aware Capability TLV 584 Where: 586 Type, 16 bits: 1588-aware Capability TLV where the value is TBD 587 Length, 16 bits: Gives the length of the flags field in octets, and 588 is currently set to 1 590 Flags, 8 bits: The bits are defined least-significant-bit (LSB) 591 first, so bit 7 is the least significant bit of the flags octet. 593 0 1 2 3 4 5 6 7 594 +-+-+-+-+-+-+-+-+ 595 | Reserved |C| 596 +-+-+-+-+-+-+-+-+ 598 Figure 4: Flags Format 600 Correction (C) field Update field, 1 bit: Setting the C bit to 1 601 indicates that the link is capable of recognizing the PTP event 602 packets and can compensate for residence time by updating the PTP 603 packet Correction Field. When this is set to 0, it means that this 604 link cannot perform the residence time correction but is capable of 605 performing MPLS frame forwarding of the frames with PTP labels using 606 a method that support the end to end delivery of accurate timing. 607 The exact method is not defined herein. 609 Reserved, 7 bits: Reserved for future use. The reserved bits must be 610 ignored by the receiver. 612 The 1588-aware Capability sub-TLV is applicable to both OSPFv2 and 613 OSPFv3. 615 14.2. 1588aware Link Capability for IS-IS 617 The IS-IS Traffic Engineering [RFC3784] defines the intra-area 618 traffic engineering enhancements and uses the Extended IS 619 Reachability TLV (Type 22) [RFC5305] to carry the per link TE-related 620 information. This extension defines a new 1588-aware capability sub- 621 TLV that can be carried as part of the Extended IS Reachability TLV. 623 The 1588-aware capability sub-TLV is OPTIONAL and MUST NOT appear 624 more than once within the Extended IS Reachability TLV or the Multi- 625 Topology (MT) Intermediate Systems TLV (type 222) specified in 626 [RFC5120]. If a second instance of the 1588-aware capability sub-TLV 627 is present, the receiving system MUST only process the first instance 628 of the sub-TLV. 630 The format of the IS-IS 1588-aware sub-TLV is identical to the TLV 631 format used by the Traffic Engineering Extensions to IS-IS [RFC3784]. 632 That is, the TLV is comprised of 1 octet for the type, 1 octet 633 specifying the TLV length, and a value field. The Length field 634 defines the length of the value portion in octets. 636 0 1 2 637 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Type | Length | Flags | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 Figure 5: 1588-aware Capability sub-TLV 644 Where: 646 Type, 8 bits: 1588-aware Capability sub-TLV where the value is TBD 648 Length, 8 bits: Gives the length of the flags field in octets, and is 649 currently set to 1 651 Flags, 8 bits: The bits are defined least-significant-bit (LSB) 652 first, so bit 7 is the least significant bit of the flags octet. 654 0 1 2 3 4 5 6 7 655 +-+-+-+-+-+-+-+-+ 656 | Reserved |C| 657 +-+-+-+-+-+-+-+-+ 659 Figure 6: Flags Format 661 Correction (C) field Update field, 1 bit: Setting the C bit to 1 662 indicates that the link is capable of recognizing the PTP event 663 packets and can compensate for residence time by updating the PTP 664 packet Correction Field. When this is set to 0, it means that this 665 link cannot perform the residence time correction but is capable of 666 performing MPLS frame forwarding of the frames with PTP labels using 667 a method that support the end to end delivery of accurate timing. 668 The exact method is not defined herein. 670 Reserved, 7 bits: Reserved for future use. The reserved bits must be 671 ignored by the receiver. 673 15. RSVP-TE Extensions for support of 1588 675 RSVP-TE signaling MAY be used to setup the PTP LSPs. A new RSVP 676 object is defined to signal that this is a PTP LSP. The OFFSET to 677 the start of the PTP message header MAY also be signaled. 678 Implementations can trivially locate the correctionField (CF) 679 location given this information. The OFFSET points to the start of 680 the PTP header as a node may want to check the PTP messageType before 681 it touches the correctionField (CF). The OFFSET is counted from TBD 683 The LSRs that receive and process the RSVP-TE/GMPLS messages MAY use 684 the OFFSET to locate the start of the PTP message header. 686 Note that the new object/TLV Must be ignored by LSRs that are not 687 compliant to this specification. 689 The new RSVP 1588_PTP_LSP object should be included in signaling PTP 690 LSPs and is defined as follows: 692 0 1 2 3 693 +-------------+-------------+-------------+-------------+ 694 | Length (bytes) | Class-Num | C-Type | 695 +-------------+-------------+-------------+-------------+ 696 | Offset to locate the start of the PTP message header | 697 +-------------+-------------+-------------+-------------+ 699 Figure 7: RSVP 1588_PTP_LSP object 701 The ingress LSR MUST include this object in the RSVP PATH Message. 702 It is just a normal RSVP path that is exclusively set up for PTP 703 messages 705 16. Behavior of LER/LSR 707 16.1. Behavior of 1588-aware LER 709 A 1588-aware LER advertises it's 1588-awareness via the OSPF 710 procedure explained in earlier section of this specification. The 711 1588-aware LER then signals PTP LSPs by including the 1588_PTP_LSP 712 object in the RSVP-TE signaling. 714 When a 1588 message is received from a non-MPLS interface, the LER 715 MUST redirect them to a previously established PTP LSP. When a 1588 716 over MPLS message is received from an MPLS interface, the processing 717 is similar to 1588-aware LSR processing. 719 16.2. Behavior of 1588-aware LSR 721 1588-aware LSRs are LSRs that understand the 1588_PTP_LSP RSVP object 722 and can perform 1588 processing (e.g. Transparent Clock processing). 724 A 1588-aware LSR advertises it's 1588-awareness via the OSPF 725 procedure explained in earlier section of this specification. 727 When a 1588-aware LSR distributes a label for PTP LSP, it maintains 728 this information. When the 1588-aware LSR receives an MPLS packet, 729 it performs a label lookup and if the label lookup indicates it is a 730 PTP label then further parsing must be done to positively identify 731 that the payload is 1588 and not OAM, BFD or control and management. 732 Ruling out non-1588 messages can easily be done when parsing 733 indicates the presence of GAL, ACH or VCCV (Type 1, 2, 3) or when the 734 UDP port number does not match one of the 1588 UDP port numbers. 736 After a 1588 message is positively identified in a PTP LSP, the PTP 737 message type indicates whether any timestamp processing is required. 738 After 1588 processing the packet is forwarded as a normal MPLS packet 739 to downstream node. 741 16.3. Behavior of non-1588-aware LSR 743 It is most beneficial that all LSRs in the path of a PTP LSP be 1588- 744 aware LSRs. This would ensure the highest quality time and clock 745 synchronization by 1588 Slave Clocks. However, this specification 746 does not mandate that all LSRs in path of a PTP LSP be 1588-aware. 748 Non-1588-aware LSRs are LSRs that either don't have the capability to 749 process 1588 packets (e.g. perform Transparent Clock processing) or 750 don't understand the 1588_PTP_LSP RSVP object. 752 Non-1588-aware LSRs ignore the RSVP 1588_PTP_LSP object and just 753 switch the MPLS packets carrying 1588 messages as data packets and 754 don't perform any timestamp related processing. However as explained 755 in QoS section the 1588 over MPLS packets MUST be still be treated 756 with the highest priority. 758 17. Other considerations 760 The use of Explicit Null (Label= 0 or 2) is acceptable as long as 761 either the Explicit Null label is the bottom of stack label 762 (applicable only to UDP/IP encapsulation) or the label below the 763 Explicit Null label is a PTP label. 765 The use of Penultimate Hop Pop (PHP) is acceptable as long as either 766 the PHP label is the bottom of stack label (applicable only to UDP/IP 767 encapsulation) or the label below the PHP label is a PTP label. 769 18. Security Considerations 771 MPLS PW security considerations in general are discussed in [RFC3985] 772 and [RFC4447],and those considerations also apply to this document. 774 An experimental security protocol is defined in [IEEE]. The PTP 775 security extension and protocol provides group source authentication, 776 message integrity, and replay attack protection for PTP messages. 778 19. Acknowledgements 780 The authors would like to thank Luca Martini, Ron Cohen, Yaakov 781 Stein, Tal Mizrahi and other members of the TICTOC WG for reviewing 782 and providing feedback on this draft. 784 20. IANA Considerations 786 20.1. IANA Considerations for OSPF 788 IANA has defined a sub-registry for the sub-TLVs carried in an OSPF 789 TE Link TLV (type 2). IANA is requested to assign a new sub-TLV 790 codepoint for the 1588aware capability sub-TLV carried within the 791 Router Link TLV. 793 Value Sub-TLV References 794 ----- ---------------------- ---------- 795 TBD 1588aware node sub-TLV (this document) 797 20.2. IANA Considerations for IS-IS 799 IANA has defined a sub-registry for the sub-TLVs carried in the IS-IS 800 Extended IS Reacability TLV. IANA is requested to assign a new sub- 801 TLV code-point for the 1588aware capability sub-TLV carried within 802 the Extended IS Reacability TLV. 804 Value Sub-TLV References 805 ----- ---------------------- ---------- 806 TBD 1588aware node sub-TLV (this document) 808 20.3. IANA Considerations for RSVP 810 IANA is requested to assign a new Class Number for 1588 PTP LSP 811 object that is used to signal PTP LSPs. 813 1588 PTP LSP Object 815 Class-Num of type 11bbbbbb 817 Suggested value TBD 819 Defined CType: 1 (1588 PTP LSP) 821 21. References 823 21.1. Normative References 825 [IEEE] IEEE 1588-2008, "IEEE Standard for a Precision Clock 826 Synchronization Protocol for Networked Measurement and 827 Control Systems". 829 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 830 Requirement Levels", BCP 14, RFC 2119, March 1997. 832 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 833 Edge (PWE3) Architecture", RFC 3985, March 2005. 835 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 836 Proxies (ND Proxy)", RFC 4389, April 2006. 838 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 839 Heron, "Pseudowire Setup and Maintenance Using the Label 840 Distribution Protocol (LDP)", RFC 4447, April 2006. 842 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, 843 "Encapsulation Methods for Transport of Ethernet over MPLS 844 Networks", RFC 4448, April 2006. 846 [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire 847 Emulation Edge-to-Edge (PWE3) Frame Check Sequence 848 Retention", RFC 4720, November 2006. 850 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 851 Connectivity Verification (VCCV): A Control Channel for 852 Pseudowires", RFC 5085, December 2007. 854 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 855 (BFD)", RFC 5880, June 2010. 857 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 858 "Bidirectional Forwarding Detection (BFD) for MPLS Label 859 Switched Paths (LSPs)", RFC 5884, June 2010. 861 21.2. Informative References 863 [I-D.ietf-pwe3-fat-pw] 864 Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 865 J., and S. Amante, "Flow Aware Transport of Pseudowires 866 over an MPLS Packet Switched Network", 867 draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011. 869 [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate 870 system routeing information exchange protocol for use in 871 conjunction with the Protocol for providing the 872 Connectionless-mode Network Service (ISO 8473)". 874 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 875 dual environments", RFC 1195, December 1990. 877 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 879 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 880 (TE) Extensions to OSPF Version 2", RFC 3630, 881 September 2003. 883 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 884 System (IS-IS) Extensions for Traffic Engineering (TE)", 885 RFC 3784, June 2004. 887 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 888 Shaffer, "Extensions to OSPF for Advertising Optional 889 Router Capabilities", RFC 4970, July 2007. 891 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 892 System to Intermediate System (IS-IS) Extensions for 893 Advertising Router Information", RFC 4971, July 2007. 895 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 896 Topology (MT) Routing in Intermediate System to 897 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 899 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 900 Engineering", RFC 5305, October 2008. 902 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, 903 "Traffic Engineering Extensions to OSPF Version 3", 904 RFC 5329, September 2008. 906 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 907 for IPv6", RFC 5340, July 2008. 909 Authors' Addresses 911 Shahram Davari 912 Broadcom Corp. 913 San Jose, CA 95134 914 USA 916 Email: davari@broadcom.com 918 Amit Oren 919 Broadcom Corp. 920 San Jose, CA 95134 921 USA 923 Email: amito@broadcom.com 925 Manav Bhatia 926 Alcatel-Lucent 927 Bangalore, 928 India 930 Email: manav.bhatia@alcatel-lucent.com 932 Peter Roberts 933 Alcatel-Lucent 934 Kanata, 935 Canada 937 Email: peter.roberts@alcatel-lucent.com 939 Laurent Montini 940 Cisco Systems 941 San Jose CA 942 USA 944 Email: lmontini@cisco.com