idnits 2.17.1 draft-ietf-tictoc-1588overmpls-01.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 == Line 853 has weird spacing: '...outeing infor...' == 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 the forward and reverse paths are the same PTP LSPs and PWs MUST not be subject to ECMP. == 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: Ethernet FCS of the outer encapsulation MUST be recalculated at every LSR that performs the TC processing and FCS retention for the payload Ethernet described in [RFC4720] MUST not be used. -- The document date (May 24, 2011) is 4722 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 870, but no explicit reference was found in the text == Unused Reference: 'RFC4971' is defined on line 874, 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) == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-fat-pw-06 -- 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 (~~), 7 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: November 25, 2011 M. Bhatia 6 P. Roberts 7 Alcatel-Lucent 8 L. Montini 9 Cisco Systems 10 May 24, 2011 12 Transporting PTP messages (1588) over MPLS Networks 13 draft-ietf-tictoc-1588overmpls-01 15 Abstract 17 This document defines the method for transporting PTP messages (PDUs) 18 over an MPLS network to enable a proper handling of these packets 19 (e.g. implementation of Transparent Clocks (TC)) in LSRs. 21 The basic idea is to transport PTP messages inside dedicated MPLS 22 LSPs. These LSPs only carry PTP messages and possibly Control and 23 Management packets, but they do not carry customer traffic. 25 Two methods for transporting 1588 over MPLS are defined. The first 26 method is to transport PTP messages directly over the dedicated MPLS 27 LSP via UDP/IP encapsulation, which is suitable for IP/MPLS networks. 28 The second method is to transport PTP messages inside a PW via 29 Ethernet encapsulation, which is more suitable for MPLS-TP networks. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on November 25, 2011. 48 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9 70 4. Dedicated LSPs for PTP messages . . . . . . . . . . . . . . . 10 72 5. 1588 over MPLS Encapsulation . . . . . . . . . . . . . . . . . 11 73 5.1. 1588 over LSP Encapsulation . . . . . . . . . . . . . . . 11 74 5.2. 1588 over PW Encapsulation . . . . . . . . . . . . . . . . 11 75 5.3. 1588 over pure MPLS mode . . . . . . . . . . . . . . . . . 13 77 6. 1588 Message Transport . . . . . . . . . . . . . . . . . . . . 14 79 7. Protection and Redundancy . . . . . . . . . . . . . . . . . . 16 81 8. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 9. OAM, Control and Management . . . . . . . . . . . . . . . . . 18 85 10. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 19 87 11. FCS Recalculation . . . . . . . . . . . . . . . . . . . . . . 20 89 12. UDP Checksum Correction . . . . . . . . . . . . . . . . . . . 21 91 13. Routing extensions for 1588aware LSRs . . . . . . . . . . . . 22 92 13.1. 1588aware Link Capability for OSPF . . . . . . . . . . . . 22 93 13.2. 1588aware Link Capability for IS-IS . . . . . . . . . . . 23 95 14. RSVP-TE Extensions for support of 1588 . . . . . . . . . . . . 25 97 15. Distributing PW labels . . . . . . . . . . . . . . . . . . . . 26 98 15.1. LDP extensions for distributing PW labels . . . . . . . . 26 99 15.2. BGP extensions for distributing PW labels . . . . . . . . 26 101 16. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 27 102 16.1. Behavior of 1588-aware LER . . . . . . . . . . . . . . . . 27 103 16.2. Behavior of 1588-aware LSR . . . . . . . . . . . . . . . . 27 104 16.3. Behavior of non-1588-aware LSR . . . . . . . . . . . . . . 27 106 17. Other considerations . . . . . . . . . . . . . . . . . . . . . 29 108 18. Security Considerations . . . . . . . . . . . . . . . . . . . 30 109 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 111 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 112 20.1. IANA Considerations for OSPF . . . . . . . . . . . . . . . 32 113 20.2. IANA Considerations for IS-IS . . . . . . . . . . . . . . 32 114 20.3. IANA Considerations for RSVP . . . . . . . . . . . . . . . 32 116 21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 117 21.1. Normative References . . . . . . . . . . . . . . . . . . . 33 118 21.2. Informative References . . . . . . . . . . . . . . . . . . 33 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 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 & E of [IEEE]) and 135 PTP PDUs over Ethernet (Annex F of [IEEE]). This document defines 136 mapping and transport of the PTP messages defined in [IEEE] over MPLS 137 networks. 139 PTP defines intermediate clock functions (called transparent clocks) 140 between the source of time (Master) and the Slave clocks. Boundary 141 Clocks (BC) form Master-Slave hierarchy with the Master clock as 142 root. The messages related to synchronization, establishing the 143 Master-Slave hierarchy, and signaling, terminate in the protocol 144 engine of a boundary clock and are not forwarded. Management 145 messages however, are forwarded to other ports on the boundary clock. 147 Transparent clocks modify a "correction field" (CF) within the 148 synchronization messages to compensate for residence and propagation 149 delays. Transparent clocks do not terminate synchronization, Master- 150 Slave hierarchy control messages or signaling messages. 152 There is a need to transport PTP messages over MPLS networks. The 153 MPLS network could be a transit network between 1588 Masters and 154 Slaves. The accuracy of the recovered clock improves and the Slave 155 logic simplifies when intermediate nodes (e.g. LSRs) properly handle 156 PTP messages (e.g. perform TC), otherwise the jitter at the 1588 157 Slave may be excessive and therefore the Slave may not be able to 158 properly recover the clock and time of day. 160 This document defines a "1588-aware LSR" that is able to identify 161 1588 timing flows carried over MPLS. 163 Transparent Clock (TC) function requires a 1588-aware LSR in the 164 middle of an LSP to identify the PTP messages and perform proper 165 update of the CF, via a 1-step or 2-step process. 167 More generally this document requires that an LSR should be able to 168 properly handle the PTP messages. For instance for those cases when 169 the TC function is not viable (e.g. due to layer violation) as an 170 alternative it should be possible to instead control the delay for 171 these messages on both directions across the node. 173 In the above cases it is beneficial that PTP packets can be easily 174 identified when carried over MPLS. 176 This document provides two methods for transporting PTP messages over 177 MPLS. The main objectives are for LSRs to be able to 178 deterministically detect and identify the PTP messages. 180 2. Terminology 182 1588: The timing and synchronization as defined by IEEE 1588 184 PTP: The timing and synchronization protocol used by 1588 186 Master: The Source of 1588 Timing and clock. This will be a port in 187 master state on a Grandmaster Clock or on a Boundary Clock. 189 Slave: The Destination of 1588 Timing and clock that tries to follow 190 the Master clock. This will be a port in slave state on a boundary 191 clock or on a Slave-Only Ordinary Clock. 193 OC: Ordinary Clock - a device with a single PTP port. 195 TC: Transparent Clock, a time stamping method applied by intermediate 196 nodes between Master and Slave 198 BC: Boundary Clock, is a node that recovers the Master clock via a 199 Slave function and uses that clock as the Master for other Slaves 201 PTP LSP: An LSP dedicated to carry PTP messages 203 PTP PW: A PW within a PTP LSP that is dedicated to carry PTP 204 messages. 206 CW: Pseudowire Control Word 208 LAG: Link Aggregation 210 ECMP: Equal Cost Multipath 212 CF: Correction Field, a field inside certain PTP messages (message 213 type 0-3)that holds the accumulative transit time inside intermediate 214 switches 216 3. Problem Statement 218 When PTP messages are transported over MPLS networks, there is a need 219 for intermediate LSRs to detect such messages and perform proper 220 processing (e.g. Transparent Clock (TC)). Note the TC processing 221 could be in the form of 1-Step or 2-Step time stamping. 223 PTP messages over Ethernet or IP can always be tunneled over MPLS. 224 However the 1588 over MPLS mapping defined in this document is 225 applicable whenever MPLS LSRs are 1588-aware and the intention is for 226 those LSRs to perform proper processing on these packets. 228 When 1588-awareness is needed, PTP messages should not be transported 229 over LSPs or PWs that are carrying customer traffic because LSRs 230 perform Label switching based on the top label in the stack. To 231 detect PTP messages inside such LSPs require special Hardware (HW) to 232 do deep packet inspection at line rate. Even if one assumes a deep 233 packet inspection HW at line rate exists, the payload can't be 234 deterministically identified by LSRs because the payload type is a 235 context of the PW label and the PW label and its context are only 236 known to the Edge routers (PEs) and LSRs don't know what is a PW's 237 payload (Ethernet, ATM, FR, CES, etc). Even if one assumes only 238 Ethernet PWs are permitted in an LSP, the LSRs don't have the 239 knowledge of whether PW Control Word (CW) is present or not and 240 therefore can't deterministically identify the payload. 242 Therefore a generic method is defined in this document that does not 243 require deep packet inspection at line rate, and can 244 deterministically identify PTP messages. The defined method is 245 applicable to both MPLS and MPLS-TP networks. 247 4. Dedicated LSPs for PTP messages 249 Many methods were considered for identifying the 1588 messages when 250 they are encapsulated in MPLS such as by using GAL/ACH or a new 251 reserved label. These methods were not attractive since they either 252 required deep packet inspection and snooping at line rate or they 253 required use of scarce new reserved label. Also one of the goals was 254 to reuse existing OAM and protection mechanisms. 256 The method defined in this document can be used by LSRs to identify 257 PTP messages in MPLS tunnels by using dedicated LSPs to carry PTP 258 messages. 260 Compliant implementations MUST use dedicated LSPs to carry PTP 261 messages over MPLS. Let's call these LSPs as the "PTP LSPs" and the 262 labels associated with these LSPs as "PTP labels". These LSPs could 263 be P2P or P2MP LSPs. The PTP LSP between Master and Slaves MAY be 264 P2MP or P2P LSP while the PTP LSP between each Slave and Master 265 SHOULD be P2P LSP. The PTP LSP between a Master and a Slave and the 266 PTP LSP between the same Slave and Master MUST be co-routed. 267 Alternatively, a single bidirectional co-routed LSP can be used. The 268 PTP LSP MAY be MPLS LSP or MPLS-TP LSP. 270 The PTP LSPs could be configured or signaled via RSVP-TE/GMPLS. New 271 RSVP-TE/GMPLS TLVs and objects are defined in this document to 272 indicate that these LSPs are PTP LSPs. 274 We should be selective about the kind of traffic that flows over PTP 275 LSPs as these will be handled as a special case by the LSR. The only 276 LSP user plane traffic MUST be PTP, but the LSP MAY also carry 277 essential MPLS/MPLS-TP control plane traffic such as BFD and LSP- 278 Ping. 280 5. 1588 over MPLS Encapsulation 282 This document defines two methods for carrying PTP messages over 283 MPLS. The first method is carrying IP encapsulated PTP messages over 284 PTP LSPs and the second method is to carry PTP messages over 285 dedicated Ethernet PWs (called PTP PWs) inside PTP LSPs. 287 5.1. 1588 over LSP Encapsulation 289 The simplest method of transporting PTP messages over MPLS is to 290 encapsulate PTP PDUs in UDP/IP and then encapsulate them in PTP LSP. 291 The 1588 over LSP format is shown in Figure 1. 293 +----------------------+ 294 | PTP Tunnel Label | 295 +----------------------+ 296 | IPv4/6 | 297 +----------------------+ 298 | UDP | 299 +----------------------+ 300 | PTP PDU | 301 +----------------------+ 303 Figure 1 - 1588 over LSP Encapsulation 305 This encapsulation is very simple and is useful when the networks 306 between 1588 Master and Slave are IP/MPLS networks. 308 In order for an LSR to process PTP messages, the PTP Label must be 309 the top label of the label stack. 311 The UDP/IP encapsulation of PTP MUST follow Annex D and E of [IEEE]. 313 5.2. 1588 over PW Encapsulation 315 Another method of transporting 1588 over MPLS networks is by 316 encapsulating PTP PDUs in Ethernet and then transporting them over 317 Ethernet PW (PTP PW) as defined in [RFC4448], which in turn is 318 transported over PTP LSPs. Alternatively PTP PDUs MAY be 319 encapsulated in UDP/IP/Ethernet and then transported over Ethernet 320 PW. 322 Both Raw and Tagged modes for Ethernet PW are permitted. The 1588 323 over PW format is shown in Figure 2. 325 +----------------+ 326 |PTP Tunnel Label| 327 +----------------+ 328 | PW Label | 329 +----------------+ 330 | Entropy Label | 331 | (optional) | 332 +----------------+ 333 | Control Word | 334 +----------------+ 335 | Ethernet | 336 | Header | 337 +----------------+ 338 | VLANs | 339 | (optional) | 340 +----------------+ 341 | IPV4/V6 | 342 | (optional) | 343 +----------------+ 344 | UDP | 345 | (optional) | 346 +----------------+ 347 | PTP PDU | 348 +----------------+ 350 Figure 2 - 1588 over PW Encapsulation 352 The Control Word (CW) as specified in [RFC4448] SHOULD be used to 353 ensure a more robust detection of PTP messages inside the MPLS 354 packet. If CW is used, the use of Sequence number is optional. 356 The use of VLAN and UDP/IP are optional. Note that 1 or 2 VLANs MAY 357 exist in the PW payload. 359 In order for an LSR to process PTP messages, the top label of the 360 label stack (the Tunnel Label) MUST be from PTP label range. However 361 in some applications the PW label may be the top label in the stack, 362 such as cases where there is only one-hop between PEs or in case of 363 PHP. In such cases, the PW label SHOULD be chosen from the PTP Label 364 range. 366 An Entropy label [I-D.ietf-pwe3-fat-pw] MAY be present at the bottom 367 of stack. 369 The Ethernet encapsulation of PTP MUST follow Annex F of [IEEE] and 370 the UDP/IP encapsulation of PTP MUST follow Annex D and E of [IEEE]. 372 For 1588 over MPLS encapsulations that are PW based, there are some 373 cases in which the PTP LSP label may not be present: 375 o When PHP is applied to the PTP LSP, and the packet is received 376 without PTP LSP label at PW termination point . 378 o When the PW is established between two routers directly connected 379 to each other and no PTP LSP is needed. 381 In such cases it is required for a router to identify these packets 382 as PTP packets. This would require the PW label to also be a label 383 that is distributed specifically for carrying PTP traffic (aka PTP PW 384 label). Therefore there is a need to add extension to LDP/BGP PW 385 label distribution protocol to indicate that a PW label is a PTP PW 386 labels. 388 5.3. 1588 over pure MPLS mode 390 Editor Note: The encapsulation is general enough and can support 391 transporting 1588 in a pure MPLS mode (i.e., without any IP/UDP or 392 Ethernet headers). Should the WG pursue this? 394 6. 1588 Message Transport 396 1588 protocol comprises of the following message types: 398 o Announce 400 o SYNC 402 o FOLLOW UP 404 o DELAY REQ (Delay Request) 406 o DELAY RESP (Delay Response) 408 o PDELAY REQ (Peer Delay Request) 410 o PDELAY RESP (Peer Delay Response) 412 o PDELAY RESP FOLLOW UP (Peer Delay Response Follow up) 414 o Management 416 o Signaling 418 A subset of PTP message types that require TC processing are called 419 Event messages: 421 o SYNC 423 o DELAY REQ (Delay Request) 425 o PDELAY REQ (Peer Delay Request) 427 o PDELAY RESP (Peer Delay Response) 429 SYNC and DELAY_REQ are exchanged between Master and Slave and MUST be 430 transported over PTP LSPs. PDELAY_REQ and PDELAY_RESP are exchanged 431 between adjacent routers and MAY be transported over single hop PTP 432 LSPs. If Two Step Transparent clocks are present, then the FOLLOW_UP 433 and DELAY_RESP messages must also be transported over the PTP LSPs. 435 For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be 436 transported over two PTP LSPs that are in opposite directions. These 437 PTP LSPs, which are in opposite directions MUST be congruent and co- 438 routed. Alternatively, a single bidirectional co-routed LSP can be 439 used. 441 Except as indicated above for the two-step Transparent clocks, Non- 442 Event PTP message types don't need to be processed by intermediate 443 routers. These message types MAY be carried in PTP Tunnel LSPs. 445 7. Protection and Redundancy 447 In order to ensure continuous uninterrupted operation of 1588 Slaves, 448 usually as a general practice, Redundant Masters are tracked by each 449 Slave. It is the responsibility of the network operator to ensure 450 that physically disjoint PTP tunnels that don't share any link are 451 used between the redundant Masters and a Slave. 453 When redundant Masters are tracked by a Slave, any PTP LSP or PTP PW 454 failure will trigger the slave to switch to the Redundant Master. 455 However LSP/PW protection such as Linear Protection Switching 456 (1:1,1+1), Ring protection switching or MPLS Fast Reroute (FRR) 457 SHOULD still be used to ensure the LSP/PW is ready for a future 458 failure. 460 Note that any protection or reroute mechanism that adds additional 461 label to the label stack, such as Facility Backup Fast Reroute, MUST 462 ensure that the pushed label is a PTP Label to ensure proper 463 processing of PTP messages by LSRs in the backup path. 465 8. ECMP 467 To ensure the proper operation of 1588 Slaves, the physical path for 468 PTP messages from Master to Slave and vice versa must be the same for 469 all PTP messages listed in section 7 and must not change even in the 470 presence of ECMP in the MPLS network. 472 To ensure the forward and reverse paths are the same PTP LSPs and PWs 473 MUST not be subject to ECMP. 475 9. OAM, Control and Management 477 In order to manage PTP LSPs and PTP PWs, they MAY carry OAM, Control 478 and Management messages. These control and management messages can 479 be differentiated from PTP messages via already defined IETF methods. 481 In particular BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389]MAY run 482 over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These 483 Management protocols are easily identified by the UDP Destination 484 Port number or by GAL/ACH respectively. 486 Also BFD, LSP-Ping and other Management messages MAY run over PTP PW 487 via one of the defined VCCVs (Type 1, 2 or 3) [RFC5085]. In this 488 case G-ACH, Router Alert Label (RAL), or PW label (TTL=1) are used to 489 identify such management messages. 491 10. QoS Considerations 493 The PTP messages are time critical and must be treated with the 494 highest priority. Therefore 1588 over MPLS messages must be treated 495 with the highest priority in the routers. This can be achieved by 496 proper setup of PTP tunnels. It is recommended that the PTP LSPs are 497 setup and marked properly to indicate EF-PHB for the CoS and Green 498 for drop eligibility. 500 11. FCS Recalculation 502 Ethernet FCS of the outer encapsulation MUST be recalculated at every 503 LSR that performs the TC processing and FCS retention for the payload 504 Ethernet described in [RFC4720] MUST not be used. 506 12. UDP Checksum Correction 508 For UDP/IP encapsulation mode of 1588 over MPLS, the UDP checksum is 509 optional when used for IPv4 encapsulation and mandatory in case of 510 IPv6. When IPv4/v6 UDP checksum is used each 1588-aware LSR must 511 either incrementally update the UDP checksum after the CF update or 512 should verify the UDP checksum on reception from upstream and 513 recalculate the checksum completely on transmission after CF update 514 to downstream node. 516 13. Routing extensions for 1588aware LSRs 518 MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and 519 IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE) 520 link information used for constraint-based routing. 522 Indeed, it is useful to advertise data plane TE router link 523 capabilities, such as the capability for a router to be 1588-aware. 524 This capability MUST then be taken into account during path 525 computation to prefer links that advertise themselves as 1588-aware, 526 so that the PTP LSPs can be properly handled. 528 For this purpose, the following sections specify extensions to OSPF 529 and IS-IS in order to advertise 1588 aware capabilities of a link. 531 13.1. 1588aware Link Capability for OSPF 533 OSPF uses the Link TLV (Type 2) that is itself carried within either 534 the Traffic Engineering LSA specified in [RFC3630] or the OSPFv3 535 Intra-Area-TE LSA (function code 10) defined in [RFC5329] to 536 advertise the TE related information for the locally attached router 537 links. For an LSA Type 10, one LSA can contain one Link TLV 538 information for a single link. This extension defines a new 1588- 539 aware capability sub-TLV that can be carried as part of the Link TLV. 541 The 1588-aware capability sub-TLV is OPTIONAL and MUST NOT appear 542 more than once within the Link TLV. If a second instance of the 543 1588-aware capability sub-TLV is present, the receiving system MUST 544 only process the first instance of the sub-TLV. It is defined as 545 follows: 547 0 1 2 3 548 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Type | Length | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Flags | 553 +-+-+-+-+-+-+-+-+ 555 Figure 3: 1588-aware Capability TLV 557 Where: 559 Type, 16 bits: 1588-aware Capability TLV where the value is TBD 561 Length, 16 bits: Gives the length of the flags field in octets, and 562 is currently set to 1 563 Flags, 8 bits: The bits are defined least-significant-bit (LSB) 564 first, so bit 7 is the least significant bit of the flags octet. 566 0 1 2 3 4 5 6 7 567 +-+-+-+-+-+-+-+-+ 568 | Reserved |C| 569 +-+-+-+-+-+-+-+-+ 571 Figure 4: Flags Format 573 Correction (C) field Update field, 1 bit: Setting the C bit to 1 574 indicates that the link is capable of recognizing the PTP event 575 packets and can compensate for residence time by updating the PTP 576 packet Correction Field. When this is set to 0, it means that this 577 link cannot perform the residence time correction but is capable of 578 performing MPLS frame forwarding of the frames with PTP labels using 579 a method that support the end to end delivery of accurate timing. 580 The exact method is not defined herein. 582 Reserved, 7 bits: Reserved for future use. The reserved bits must be 583 ignored by the receiver. 585 The 1588-aware Capability sub-TLV is applicable to both OSPFv2 and 586 OSPFv3. 588 13.2. 1588aware Link Capability for IS-IS 590 The IS-IS Traffic Engineering [RFC3784] defines the intra-area 591 traffic engineering enhancements and uses the Extended IS 592 Reachability TLV (Type 22) [RFC5305] to carry the per link TE-related 593 information. This extension defines a new 1588-aware capability sub- 594 TLV that can be carried as part of the Extended IS Reachability TLV. 596 The 1588-aware capability sub-TLV is OPTIONAL and MUST NOT appear 597 more than once within the Extended IS Reachability TLV or the Multi- 598 Topology (MT) Intermediate Systems TLV (type 222) specified in 599 [RFC5120]. If a second instance of the 1588-aware capability sub-TLV 600 is present, the receiving system MUST only process the first instance 601 of the sub-TLV. 603 The format of the IS-IS 1588-aware sub-TLV is identical to the TLV 604 format used by the Traffic Engineering Extensions to IS-IS [RFC3784]. 605 That is, the TLV is comprised of 1 octet for the type, 1 octet 606 specifying the TLV length, and a value field. The Length field 607 defines the length of the value portion in octets. 609 0 1 2 610 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Type | Length | Flags | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 Figure 5: 1588-aware Capability sub-TLV 617 Where: 619 Type, 8 bits: 1588-aware Capability sub-TLV where the value is TBD 621 Length, 8 bits: Gives the length of the flags field in octets, and is 622 currently set to 1 624 Flags, 8 bits: The bits are defined least-significant-bit (LSB) 625 first, so bit 7 is the least significant bit of the flags octet. 627 0 1 2 3 4 5 6 7 628 +-+-+-+-+-+-+-+-+ 629 | Reserved |C| 630 +-+-+-+-+-+-+-+-+ 632 Figure 6: Flags Format 634 Correction (C) field Update field, 1 bit: Setting the C bit to 1 635 indicates that the link is capable of recognizing the PTP event 636 packets and can compensate for residence time by updating the PTP 637 packet Correction Field. When this is set to 0, it means that this 638 link cannot perform the residence time correction but is capable of 639 performing MPLS frame forwarding of the frames with PTP labels using 640 a method that support the end to end delivery of accurate timing. 641 The exact method is not defined herein. 643 Reserved, 7 bits: Reserved for future use. The reserved bits must be 644 ignored by the receiver. 646 14. RSVP-TE Extensions for support of 1588 648 RSVP-TE signaling MAY be used to setup the PTP LSPs. A new RSVP 649 object is defined to signal that this is a PTP LSP. The OFFSET to 650 the start of the PTP message header MAY also be signaled. 651 Implementations can trivially locate the correctionField (CF) 652 location given this information. The OFFSET points to the start of 653 the PTP header as a node may want to check the PTP messageType before 654 it touches the correctionField (CF). 656 The LSRs that receive and process the RSVP-TE/GMPLS messages MAY use 657 the OFFSET to locate the start of the PTP message header. 659 Note that the new object/TLV Must be ignored by LSRs that are not 660 compliant to this specification. 662 The new RSVP 1588_PTP_LSP object should be included in signaling PTP 663 LSPs and is defined as follows: 665 0 1 2 3 666 +-------------+-------------+-------------+-------------+ 667 | Length (bytes) | Class-Num | C-Type | 668 +-------------+-------------+-------------+-------------+ 669 | Offset to locate the start of the PTP message header | 670 +-------------+-------------+-------------+-------------+ 672 Figure 7: RSVP 1588_PTP_LSP object 674 The ingress LSR MUST include this object in the RSVP PATH Message. 675 It is just a normal RSVP path that is exclusively set up for PTP 676 messages 678 15. Distributing PW labels 680 15.1. LDP extensions for distributing PW labels 682 TBD 684 15.2. BGP extensions for distributing PW labels 686 TBD 688 16. Behavior of LER/LSR 690 16.1. Behavior of 1588-aware LER 692 A 1588-aware LER advertises it's 1588-awareness via the OSPF 693 procedure explained in earlier section of this specification. The 694 1588-aware LER then signals PTP LSPs by including the 1588_PTP_LSP 695 object in the RSVP-TE signaling. 697 When a 1588 message is received from a non-MPLS interface, the LER 698 MUST redirect them to a previously established PTP LSP. When a 1588 699 over MPLS message is received from an MPLS interface, the processing 700 is similar to 1588-aware LSR processing. 702 16.2. Behavior of 1588-aware LSR 704 1588-aware LSRs are LSRs that understand the 1588_PTP_LSP RSVP object 705 and can perform 1588 processing (e.g. TC processing). 707 A 1588-aware LSR advertises it's 1588-awareness via the OSPF 708 procedure explained in earlier section of this specification. 710 When a 1588-aware LSR distributes a label for PTP LSP, it maintains 711 this information. When the 1588-aware LSR receives an MPLS packet, 712 it performs a label lookup and if the label lookup indicates it is a 713 PTP label then further parsing must be done to positively identify 714 that the payload is 1588 and not OAM, BFD or control and management. 715 Ruling out non-1588 messages can easily be done when parsing 716 indicates the presence of GAL, ACH or VCCV (Type 1, 2, 3) or when the 717 UDP port number does not match one of the 1588 UDP port numbers. 719 After a 1588 message is positively identified in a PTP LSP, the PTP 720 message type indicates what type of processing (TC) if any is 721 required. After 1588 processing the packet is forwarded as a normal 722 MPLS packet to downstream node. 724 16.3. Behavior of non-1588-aware LSR 726 It is most beneficial that all LSRs in the path of a PTP LSP be 1588- 727 aware LSRs. This would ensure the highest quality time and clock 728 synchronization by 1588 Slaves. However, this specification does not 729 mandate that all LSRs in path of a PTP LSP be 1588-aware. 731 Non-1588-aware LSRs are LSRs that either don't have the capability to 732 process 1588 packets (e.g. TC processing) or don't understand the 733 1588_PTP_LSP RSVP object. 735 Non-1588-aware LSRs ignore the RSVP 1588_PTP_LSP object and just 736 switch the MPLS packets carrying 1588 messages as data packets and 737 don't perform any TC processing. However as explained in QoS section 738 the 1588 over MPLS packets MUST be still be treated with the highest 739 priority. 741 17. Other considerations 743 The use of Explicit Null (Label= 0 or 2) is acceptable as long as 744 either the Explicit Null label is the bottom of stack label 745 (applicable only to UDP/IP encapsulation) or the label below the 746 Explicit Null label is a PTP label. 748 The use of Penultimate Hop Pop (PHP) is acceptable as long as either 749 the PHP label is the bottom of stack label (applicable only to UDP/IP 750 encapsulation) or the label below the PHP label is a PTP label. 752 18. Security Considerations 754 MPLS PW security considerations in general are discussed in [RFC3985] 755 and [RFC4447],and those considerations also apply to this document. 757 An experimental security protocol is defined in [IEEE]. The PTP 758 security extension and protocol provides group source authentication, 759 message integrity, and replay attack protection for PTP messages. 761 19. Acknowledgements 763 The authors would like to thank Luca Martini, Ron Cohen, Yaakov 764 Stein, Tal Mizrahi and other members of the TICTOC WG for reviewing 765 and providing feedback on this draft. 767 20. IANA Considerations 769 20.1. IANA Considerations for OSPF 771 IANA has defined a sub-registry for the sub-TLVs carried in an OSPF 772 TE Link TLV (type 2). IANA is requested to assign a new sub-TLV 773 codepoint for the 1588aware capability sub-TLV carried within the 774 Router Link TLV. 776 Value Sub-TLV References 777 ----- ---------------------- ---------- 778 TBD 1588aware node sub-TLV (this document) 780 20.2. IANA Considerations for IS-IS 782 IANA has defined a sub-registry for the sub-TLVs carried in the IS-IS 783 Extended IS Reacability TLV. IANA is requested to assign a new sub- 784 TLV code-point for the 1588aware capability sub-TLV carried within 785 the Extended IS Reacability TLV. 787 Value Sub-TLV References 788 ----- ---------------------- ---------- 789 TBD 1588aware node sub-TLV (this document) 791 20.3. IANA Considerations for RSVP 793 IANA is requested to assign a new Class Number for 1588 PTP LSP 794 object that is used to signal PTP LSPs. 796 1588 PTP LSP Object 798 Class-Num of type 11bbbbbb 800 Suggested value TBD 802 Defined CType: 1 (1588 PTP LSP) 804 21. References 806 21.1. Normative References 808 [IEEE] IEEE 1588-2008, "IEEE Standard for a Precision Clock 809 Synchronization Protocol for Networked Measurement and 810 Control Systems". 812 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 813 Requirement Levels", BCP 14, RFC 2119, March 1997. 815 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 816 Edge (PWE3) Architecture", RFC 3985, March 2005. 818 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 819 Proxies (ND Proxy)", RFC 4389, April 2006. 821 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 822 Heron, "Pseudowire Setup and Maintenance Using the Label 823 Distribution Protocol (LDP)", RFC 4447, April 2006. 825 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, 826 "Encapsulation Methods for Transport of Ethernet over MPLS 827 Networks", RFC 4448, April 2006. 829 [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire 830 Emulation Edge-to-Edge (PWE3) Frame Check Sequence 831 Retention", RFC 4720, November 2006. 833 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 834 Connectivity Verification (VCCV): A Control Channel for 835 Pseudowires", RFC 5085, December 2007. 837 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 838 (BFD)", RFC 5880, June 2010. 840 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 841 "Bidirectional Forwarding Detection (BFD) for MPLS Label 842 Switched Paths (LSPs)", RFC 5884, June 2010. 844 21.2. Informative References 846 [I-D.ietf-pwe3-fat-pw] 847 Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 848 J., and S. Amante, "Flow Aware Transport of Pseudowires 849 over an MPLS Packet Switched Network", 850 draft-ietf-pwe3-fat-pw-06 (work in progress), May 2011. 852 [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate 853 system routeing information exchange protocol for use in 854 conjunction with the Protocol for providing the 855 Connectionless-mode Network Service (ISO 8473)". 857 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 858 dual environments", RFC 1195, December 1990. 860 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 862 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 863 (TE) Extensions to OSPF Version 2", RFC 3630, 864 September 2003. 866 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 867 System (IS-IS) Extensions for Traffic Engineering (TE)", 868 RFC 3784, June 2004. 870 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 871 Shaffer, "Extensions to OSPF for Advertising Optional 872 Router Capabilities", RFC 4970, July 2007. 874 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 875 System to Intermediate System (IS-IS) Extensions for 876 Advertising Router Information", RFC 4971, July 2007. 878 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 879 Topology (MT) Routing in Intermediate System to 880 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 882 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 883 Engineering", RFC 5305, October 2008. 885 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, 886 "Traffic Engineering Extensions to OSPF Version 3", 887 RFC 5329, September 2008. 889 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 890 for IPv6", RFC 5340, July 2008. 892 Authors' Addresses 894 Shahram Davari 895 Broadcom Corp. 896 San Jose, CA 95134 897 USA 899 Email: davari@broadcom.com 901 Amit Oren 902 Broadcom Corp. 903 San Jose, CA 95134 904 USA 906 Email: amito@broadcom.com 908 Manav Bhatia 909 Alcatel-Lucent 910 Bangalore, 911 India 913 Email: manav.bhatia@alcatel-lucent.com 915 Peter Roberts 916 Alcatel-Lucent 917 Kanata, 918 Canada 920 Email: peter.roberts@alcatel-lucent.com 922 Laurent Montini 923 Cisco Systems 924 San Jose CA 925 USA 927 Email: lmontini@cisco.com