idnits 2.17.1 draft-ietf-tictoc-1588overmpls-00.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 862 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 MUST be recalculated at every LSR that performs the TC processing and FCS retention described in [RFC4720] MUST not be used. -- The document date (January 26, 2011) is 4839 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) -- 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-05 -- 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 (~~), 5 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: July 30, 2011 L. Martini 6 Cisco Systems 7 M. Bhatia 8 P. Roberts 9 Alcatel-Lucent 10 January 26, 2011 12 Transporting PTP messages (1588) over MPLS Networks 13 draft-ietf-tictoc-1588overmpls-00 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 July 30, 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 Node Capability for OSPF . . . . . . . . . . . . 22 93 13.2. 1588aware Node Capability for IS-IS . . . . . . . . . . . 23 95 14. RSVP-TE Extensions for support of 1588 . . . . . . . . . . . . 26 97 15. Distributing PW labels . . . . . . . . . . . . . . . . . . . . 27 98 15.1. LDP extensions for distributing PW labels . . . . . . . . 27 99 15.2. BGP extensions for distributing PW labels . . . . . . . . 27 101 16. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 28 102 16.1. Behavior of 1588-aware LER . . . . . . . . . . . . . . . . 28 103 16.2. Behavior of 1588-aware LSR . . . . . . . . . . . . . . . . 28 104 16.3. Behavior of non-1588-aware LSR . . . . . . . . . . . . . . 28 106 17. Other considerations . . . . . . . . . . . . . . . . . . . . . 30 108 18. Security Considerations . . . . . . . . . . . . . . . . . . . 31 109 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 110 19.1. IANA Considerations for OSPF . . . . . . . . . . . . . . . 32 111 19.2. IANA Considerations for IS-IS . . . . . . . . . . . . . . 32 112 19.3. IANA Considerations for RSVP . . . . . . . . . . . . . . . 32 114 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 115 20.1. Normative References . . . . . . . . . . . . . . . . . . . 33 116 20.2. Informative References . . . . . . . . . . . . . . . . . . 33 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC2119 [RFC2119]. 123 When used in lower case, these words convey their typical use in 124 common language, and are not to be interpreted as described in 125 RFC2119 [RFC2119]. 127 1. Introduction 129 The objective of Precision Time Protocol (PTP) is to synchronize 130 independent clocks running on separate nodes of a distributed system. 131 [IEEE] defines PTP messages for clock and time synchronization. The 132 PTP messages include PTP PDUs over UDP/IP (Annex D & E of [IEEE]) and 133 PTP PDUs over Ethernet (Annex F of [IEEE]). This document defines 134 mapping and transport of the PTP messages defined in [IEEE] over MPLS 135 networks. 137 PTP defines intermediate clock functions (called transparent clocks) 138 between the source of time (Master) and the Slave clocks. Boundary 139 Clocks (BC) form Master-Slave hierarchy with the Master clock as 140 root. The messages related to synchronization, establishing the 141 Master-Slave hierarchy, and signaling, terminate in the protocol 142 engine of a boundary clock and are not forwarded. Management 143 messages however, are forwarded to other ports on the boundary clock. 145 Transparent clocks modify a "correction field" (CF) within the 146 synchronization messages to compensate for residence and propagation 147 delays. Transparent clocks do not terminate synchronization, Master- 148 Slave hierarchy control messages or signaling messages. 150 There is a need to transport PTP messages over MPLS networks. The 151 MPLS network could be a transit network between 1588 Masters and 152 Slaves. The accuracy of the recovered clock improves and the Slave 153 logic simplifies when intermediate nodes (e.g. LSRs) properly handle 154 PTP messages (e.g. perform TC), otherwise the jitter at the 1588 155 Slave may be excessive and therefore the Slave may not be able to 156 properly recover the clock and time of day. 158 This document defines a "1588-aware LSR" that is able to identify 159 1588 timing flows carried over MPLS. 161 Transparent Clock (TC) function requires a 1588-aware LSR in the 162 middle of an LSP to identify the PTP messages and perform proper 163 update of the CF, via a 1-step or 2-step process. 165 More generally this document requires that an LSR should be able to 166 properly handle the PTP messages. For instance for those cases when 167 the TC function is not viable (e.g. due to layer violation) as an 168 alternative it should be possible to instead control the delay for 169 these messages on both directions across the node. 171 In the above cases it is beneficial that PTP packets can be easily 172 identified when carried over MPLS. 174 This document provides two methods for transporting PTP messages over 175 MPLS. The main objectives are for LSRs to be able to 176 deterministically detect and identify the PTP messages. 178 2. Terminology 180 1588: The timing and synchronization as defined by IEEE 1588 182 PTP: The timing and synchronization protocol used by 1588 184 Master: The Source of 1588 Timing and clock 186 Slave: The Destination of 1588 Timing and clock that tries to follow 187 the Master clock 189 OC: Ordinary Clock 191 TC: Transparent Clock, a time stamping method applied by intermediate 192 nodes between Master and Slave 194 BC: Boundary Clock, is a node that recovers the Master clock via a 195 Slave function and uses that clock as the Master for other Slaves 197 PTP LSP: An LSP dedicated to carry PTP messages 199 PTP PW: A PW within a PTP LSP that is dedicated to carry PTP 200 messages. 202 CW: Pseudowire Control Word 204 LAG: Link Aggregation 206 ECMP: Equal Cost Multipath 208 CF: Correction Field, a field inside certain PTP messages (message 209 type 0-3)that holds the accumulative transit time inside intermediate 210 switches 212 3. Problem Statement 214 When PTP messages are transported over MPLS networks, there is a need 215 for intermediate LSRs to detect such messages and perform proper 216 processing (e.g. Transparent Clock (TC)). Note the TC processing 217 could be in the form of 1-Step or 2-Step time stamping. 219 PTP messages over Ethernet or IP can always be tunneled over MPLS. 220 However the 1588 over MPLS mapping defined in this document is 221 applicable whenever MPLS LSRs are 1588-aware and the intention is for 222 those LSRs to perform proper processing on these packets. 224 When 1588-awareness is needed, PTP messages should not be transported 225 over LSPs or PWs that are carrying customer traffic because LSRs 226 perform Label switching based on the top label in the stack. To 227 detect PTP messages inside such LSPs require special Hardware (HW) to 228 do deep packet inspection at line rate. Even if one assumes a deep 229 packet inspection HW at line rate exists, the payload can't be 230 deterministically identified by LSRs because the payload type is a 231 context of the PW label and the PW label and its context are only 232 known to the Edge routers (PEs) and LSRs don't know what is a PW's 233 payload (Ethernet, ATM, FR, CES, etc). Even if one assumes only 234 Ethernet PWs are permitted in an LSP, the LSRs don't have the 235 knowledge of whether PW Control Word (CW) is present or not and 236 therefore can't deterministically identify the payload. 238 Therefore a generic method is defined in this document that does not 239 require deep packet inspection at line rate, and can 240 deterministically identify PTP messages. The defined method is 241 applicable to both MPLS and MPLS-TP networks. 243 4. Dedicated LSPs for PTP messages 245 Many methods were considered for identifying the 1588 messages when 246 they are encapsulated in MPLS such as by using GAL/ACH or a new 247 reserved label. These methods were not attractive since they either 248 required deep packet inspection and snooping at line rate or they 249 required use of scarce new reserved label. Also one of the goals was 250 to reuse existing OAM and protection mechanisms. 252 The method defined in this document can be used by LSRs to identify 253 PTP messages in MPLS tunnels by using dedicated LSPs to carry PTP 254 messages. 256 Compliant implementations MUST use dedicated LSPs to carry PTP 257 messages over MPLS. Let's call these LSPs as the "PTP LSPs" and the 258 labels associated with these LSPs as "PTP labels". These LSPs could 259 be P2P or P2MP LSPs. The PTP LSP between Master and Slaves MAY be 260 P2MP or P2P LSP while the PTP LSP between each Slave and Master 261 SHOULD be P2P LSP. The PTP LSP between a Master and a Slave and the 262 PTP LSP between the same Slave and Master MUST be co-routed. 263 Alternatively, a single bidirectional co-routed LSP can be used. The 264 PTP LSP MAY be MPLS LSP or MPLS-TP LSP. 266 The PTP LSPs could be configured or signaled via RSVP-TE/GMPLS. New 267 RSVP-TE/GMPLS TLVs and objects are defined in this document to 268 indicate that these LSPs are PTP LSPs. 270 We should be selective about the kind of traffic that flows over PTP 271 LSPs as these will be handled as a special case by the LSR. The only 272 LSP user plane traffic MUST be PTP, but the LSP MAY also carry 273 essential MPLS/MPLS-TP control plane traffic such as BFD and LSP- 274 Ping. 276 5. 1588 over MPLS Encapsulation 278 This document defines two methods for carrying PTP messages over 279 MPLS. The first method is carrying IP encapsulated PTP messages over 280 PTP LSPs and the second method is to carry PTP messages over 281 dedicated Ethernet PWs (called PTP PWs) inside PTP LSPs. 283 5.1. 1588 over LSP Encapsulation 285 The simplest method of transporting PTP messages over MPLS is to 286 encapsulate PTP PDUs in UDP/IP and then encapsulate them in PTP LSP. 287 The 1588 over LSP format is shown in Figure 1. 289 +----------------------+ 290 | PTP Tunnel Label | 291 +----------------------+ 292 | IPv4/6 | 293 +----------------------+ 294 | UDP | 295 +----------------------+ 296 | PTP PDU | 297 +----------------------+ 299 Figure 1 - 1588 over LSP Encapsulation 301 This encapsulation is very simple and is useful when the networks 302 between 1588 Master and Slave are IP/MPLS networks. 304 In order for an LSR to process PTP messages, the PTP Label must be 305 the top label of the label stack. 307 The UDP/IP encapsulation of PTP MUST follow Annex D and E of [IEEE]. 309 5.2. 1588 over PW Encapsulation 311 Another method of transporting 1588 over MPLS networks is by 312 encapsulating PTP PDUs in Ethernet and then transporting them over 313 Ethernet PW (PTP PW) as defined in [RFC4448], which in turn is 314 transported over PTP LSPs. Alternatively PTP PDUs MAY be 315 encapsulated in UDP/IP/Ethernet and then transported over Ethernet 316 PW. 318 Both Raw and Tagged modes for Ethernet PW are permitted. The 1588 319 over PW format is shown in Figure 2. 321 +----------------+ 322 |PTP Tunnel Label| 323 +----------------+ 324 | PW Label | 325 +----------------+ 326 | Entropy Label | 327 | (optional) | 328 +----------------+ 329 | Control Word | 330 +----------------+ 331 | Ethernet | 332 | Header | 333 +----------------+ 334 | VLANs | 335 | (optional) | 336 +----------------+ 337 | IPV4/V6 | 338 | (optional) | 339 +----------------+ 340 | UDP | 341 | (optional) | 342 +----------------+ 343 | PTP PDU | 344 +----------------+ 346 Figure 2 - 1588 over PW Encapsulation 348 The Control Word (CW) as specified in [RFC4448] SHOULD be used to 349 ensure a more robust detection of PTP messages inside the MPLS 350 packet. If CW is used, the use of Sequence number is optional. 352 The use of VLAN and UDP/IP are optional. Note that 1 or 2 VLANs MAY 353 exist in the PW payload. 355 In order for an LSR to process PTP messages, the top label of the 356 label stack (the Tunnel Label) MUST be from PTP label range. However 357 in some applications the PW label may be the top label in the stack, 358 such as cases where there is only one-hop between PEs or in case of 359 PHP. In such cases, the PW label SHOULD be chosen from the PTP Label 360 range. 362 An Entropy label [I-D.ietf-pwe3-fat-pw] MAY be present at the bottom 363 of stack. 365 The Ethernet encapsulation of PTP MUST follow Annex F of [IEEE] and 366 the UDP/IP encapsulation of PTP MUST follow Annex D and E of [IEEE]. 368 For 1588 over MPLS encapsulations that are PW based, there are some 369 cases in which the PTP LSP label may not be present: 371 o When PHP is applied to the PTP LSP, and the packet is received 372 without PTP LSP label at PW termination point . 374 o When the PW is established between two routers directly connected 375 to each other and no PTP LSP is needed. 377 In such cases it is required for a router to identify these packets 378 as PTP packets. This would require the PW label to also be a label 379 that is distributed specifically for carrying PTP traffic (aka PTP PW 380 label). Therefore there is a need to add extension to LDP/BGP PW 381 label distribution protocol to indicate that a PW label is a PTP PW 382 labels. 384 5.3. 1588 over pure MPLS mode 386 Editor Note: The encapsulation is general enough and can support 387 transporting 1588 in a pure MPLS mode (i.e., without any IP/UDP or 388 Ethernet headers). Should the WG pursue this? 390 6. 1588 Message Transport 392 1588 protocol comprises of the following message types: 394 o Announce 396 o SYNC 398 o FOLLOW UP 400 o DELAY REQ (Delay Request) 402 o DELAY RESP (Delay Response) 404 o PDELAY REQ (Peer Delay Request) 406 o PDELAY RESP (Peer Delay Response) 408 o PDELAY RESP FOLLOW UP (Peer Delay Response Follow up) 410 o Management 412 o Signaling 414 A subset of PTP message types that require TC processing are called 415 Event messages: 417 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 Master and Slave and MUST be 426 transported over PTP LSPs. PDELAY_REQ and PDELAY_RESP are exchanged 427 between adjacent routers and MAY be transported over single hop PTP 428 LSPs. If Two Step Transparent clocks are present, then the FOLLOW_UP 429 and DELAY_RESP messages must also be transported over the PTP LSPs. 431 For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be 432 transported over two PTP LSPs that are in opposite directions. These 433 PTP LSPs, which are in opposite directions MUST be congruent and co- 434 routed. Alternatively, a single bidirectional co-routed LSP can be 435 used. 437 Except as indicated above for the two-step Transparent clocks, Non- 438 Event PTP message types don't need to be processed by intermediate 439 routers. These message types MAY be carried in PTP Tunnel LSPs. 441 7. Protection and Redundancy 443 In order to ensure continuous uninterrupted operation of 1588 Slaves, 444 usually as a general practice, Redundant Masters are tracked by each 445 Slave. It is the responsibility of the network operator to ensure 446 that physically disjoint PTP tunnels that don't share any link are 447 used between the redundant Masters and a Slave. 449 When redundant Masters are tracked by a Slave, any PTP LSP or PTP PW 450 failure will trigger the slave to switch to the Redundant Master. 451 However LSP/PW protection such as Linear Protection Switching 452 (1:1,1+1), Ring protection switching or MPLS Fast Reroute (FRR) 453 SHOULD still be used to ensure the LSP/PW is ready for a future 454 failure. 456 Note that any protection or reroute mechanism that adds additional 457 label to the label stack, such as Facility Backup Fast Reroute, MUST 458 ensure that the pushed label is a PTP Label to ensure proper 459 processing of PTP messages by LSRs in the backup path. 461 8. ECMP 463 To ensure the proper operation of 1588 Slaves, the physical path for 464 PTP messages from Master to Slave and vice versa must be the same for 465 all PTP messages listed in section 7 and must not change even in the 466 presence of ECMP in the MPLS network. 468 To ensure the forward and reverse paths are the same PTP LSPs and PWs 469 MUST not be subject to ECMP. 471 9. OAM, Control and Management 473 In order to manage PTP LSPs and PTP PWs, they MAY carry OAM, Control 474 and Management messages. These control and management messages can 475 be differentiated from PTP messages via already defined IETF methods. 477 In particular BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389]MAY run 478 over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These 479 Management protocols are easily identified by the UDP Destination 480 Port number or by GAL/ACH respectively. 482 Also BFD, LSP-Ping and other Management messages MAY run over PTP PW 483 via one of the defined VCCVs (Type 1, 2 or 3) [RFC5085]. In this 484 case G-ACH, Router Alert Label (RAL), or PW label (TTL=1) are used to 485 identify such management messages. 487 10. QoS Considerations 489 The PTP messages are time critical and must be treated with the 490 highest priority. Therefore 1588 over MPLS messages must be treated 491 with the highest priority in the routers. This can be achieved by 492 proper setup of PTP tunnels. It is recommended that the PTP LSPs are 493 setup and marked properly to indicate EF-PHB for the CoS and Green 494 for drop eligibility. 496 11. FCS Recalculation 498 Ethernet FCS MUST be recalculated at every LSR that performs the TC 499 processing and FCS retention described in [RFC4720] MUST not be used. 501 12. UDP Checksum Correction 503 For UDP/IP encapsulation mode of 1588 over MPLS, the UDP checksum is 504 optional when used for IPv4 encapsulation and mandatory in case of 505 IPv6. When IPv4/v6 UDP checksum is used each 1588-aware LSR must 506 either incrementally update the UDP checksum after the CF update or 507 should verify the UDP checksum on reception from upstream and 508 recalculate the checksum completely on transmission after CF update 509 to downstream node. 511 13. Routing extensions for 1588aware LSRs 513 MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and 514 IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE) 515 link information used for constraint-based routing. 517 Indeed, it is useful to advertise data plane TE node capabilities, 518 such as the capability for a router to be 1588-aware. This 519 capability MUST then be taken into account during path computation to 520 prefer nodes that advertise themselves as 1588-aware, so that the PTP 521 LSPs can be properly handled. 523 For this purpose, the following sections specify extensions to OSPF 524 and IS-IS in order to advertise 1588 aware capabilities of a node. 526 Editor Note: There is an open issue on whether we must consider LSRs 527 that may not want to support PTP on all ports. An example could be 528 an LSR where a few blades have been upgraded to support PTP 529 timestamping in silicon. In such cases, routers must explicitly 530 indicate the ports that are 1588-aware. If the WG agrees about this 531 then we will need to change the subsequent OSPF and IS-IS sections to 532 advertise the 1588-aware capability on per port/interface basis, 533 rather than per node as is current described. 535 13.1. 1588aware Node Capability for OSPF 537 This extension makes use of the Router Information (RI) Opaque LSA 538 defined in [RFC4970]for both OSPFv2 and OSPFv3, by defining a new 539 OSPF Router Information (RI) TLV - The 1588-aware Capability TLV. 541 The 1588-aware Capability TLV is OPTIONAL and is defined as follows: 543 0 1 2 3 544 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 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Type | Length | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Flags | 549 +-+-+-+-+-+-+-+-+ 551 Figure 3: 1588-aware Capability TLV 553 Where: 555 Type, 16 bits: 1588-aware Capability TLV where the value is TBD 557 Length, 16 bits: Gives the length of the flags field in octets, and 558 is currently set to 1 560 Flags, 8 bits: The bits are defined least-significant-bit (LSB) 561 first, so bit 7 is the least significant bit of the flags octet. 563 0 1 2 3 4 5 6 7 564 +-+-+-+-+-+-+-+-+ 565 | Reserved |C| 566 +-+-+-+-+-+-+-+-+ 568 Figure 4: Flags Format 570 Correction (C) field Update field, 1 bit: Setting the C bit to 1 571 indicates that the node is capable of recognizing the PTP event 572 packets and can compensate for residence time by updating the PTP 573 packet Correction Field. When this is set to 0, it means that this 574 node cannot perform the residence time correction but is capable of 575 performing MPLS frame forwarding of the frames with PTP labels using 576 a method that support the end to end delivery of accurate timing. 577 The exact method is not defined herein. 579 Reserved, 7 bits: Reserved for future use. The reserved bits must be 580 ignored by the receiver. 582 The 1588-aware Capability TLV is applicable to both OSPFv2 and 583 OSPFv3. 585 The 1588-aware Capability TLV MAY be advertised within an area-local 586 or autonomous system (AS) scope Router Information (RI) LSA. But the 587 1588-aware Capability TLV SHOULD NOT be advertised into an area in 588 more than one RI LSA irrespective of the scope of the LSA. 590 The flooding scope is controlled by the Opaque LSA type in OSPFv2 and 591 by the S1 and S2 bits in OSPFv3. For area scope, the 1588-aware 592 Capability TLV MUST be carried within an OSPFv2 Type 10 RI LSA or an 593 OSPFv3 RI LSA with the S1 bit set and S2 bit clear. If the flooding 594 scope is the entire routing domain (AS scope), the 1588-aware 595 Capability TLV MUST be carried within an OSPFv2 Type 11 RI LSA or 596 OSPFv3 RI LSA with the S1 bit clear and the S2 bit set. 598 13.2. 1588aware Node Capability for IS-IS 600 Generic capability advertisement mechanisms for IS-IS are defined in 601 [RFC4971]. These allow a router to advertise its capabilities within 602 an IS-IS area or an entire IS-IS routing domain. This document 603 defines a new sub-TLV (named the 1588-aware Capability) to be carried 604 within the IS-IS Router Capability TLV. 606 The IS-IS extensions defined in this document allow for discovering 607 1588-aware nodes within an IS-IS routing domain. Solutions for 1588- 608 aware nodes discovery across AS boundaries are beyond the scope of 609 this document, and are for further study. 611 The format of the IS-IS 1588-aware sub-TLV is identical to the TLV 612 format used by the Traffic Engineering Extensions to IS-IS [RFC3784]. 613 That is, the TLV is comprised of 1 octet for the type, 1 octet 614 specifying the TLV length, and a value field. The Length field 615 defines the length of the value portion in octets. 617 0 1 2 618 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Type | Length | Flags | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 Figure 5: 1588-aware Capability sub-TLV 625 Where: 627 Type, 8 bits: 1588-aware Capability sub-TLV where the value is TBD 629 Length, 8 bits: Gives the length of the flags field in octets, and is 630 currently set to 1 632 Flags, 8 bits: The bits are defined least-significant-bit (LSB) 633 first, so bit 7 is the least significant bit of the flags octet. 635 0 1 2 3 4 5 6 7 636 +-+-+-+-+-+-+-+-+ 637 | Reserved |C| 638 +-+-+-+-+-+-+-+-+ 640 Figure 6: Flags Format 642 Correction (C) field Update field, 1 bit: Setting the C bit to 1 643 indicates that the node is capable of recognizing the PTP event 644 packets and can compensate for residence time by updating the PTP 645 packet Correction Field. When this is set to 0, it means that this 646 node cannot perform the residence time correction but is capable of 647 performing MPLS frame forwarding of the frames with PTP labels using 648 a method that support the end to end delivery of accurate timing. 649 The exact method is not defined herein. 651 Reserved, 7 bits: Reserved for future use. The reserved bits must be 652 ignored by the receiver. 654 The 1588-aware sub-TLV is optional and is carried within an IS-IS 655 Capability TLV [RFC4971] to facilitate selection of 1588-aware nodes. 657 The flooding scope for 1588-aware node information advertised through 658 IS-IS can be a single L1 area, an L1 area and the L2 sub-domain, or 659 the entire IS-IS routing domain. 661 14. RSVP-TE Extensions for support of 1588 663 RSVP-TE signaling MAY be used to setup the PTP LSPs. A new RSVP 664 object is defined to signal that this is a PTP LSP. The OFFSET to 665 the start of the PTP message header MAY also be signaled. 666 Implementations can trivially locate the correctionField (CF) 667 location given this information. The OFFSET points to the start of 668 the PTP header as a node may want to check the PTP messageType before 669 it touches the correctionField (CF). 671 The LSRs that receive and process the RSVP-TE/GMPLS messages MAY use 672 the OFFSET to locate the start of the PTP message header. 674 Note that the new object/TLV Must be ignored by LSRs that are not 675 compliant to this specification. 677 The new RSVP 1588_PTP_LSP object should be included in signaling PTP 678 LSPs and is defined as follows: 680 0 1 2 3 681 +-------------+-------------+-------------+-------------+ 682 | Length (bytes) | Class-Num | C-Type | 683 +-------------+-------------+-------------+-------------+ 684 | Offset to locate the start of the PTP message header | 685 +-------------+-------------+-------------+-------------+ 687 Figure 7: RSVP 1588_PTP_LSP object 689 The ingress LSR MUST include this object in the RSVP PATH Message. 690 It is just a normal RSVP path that is exclusively set up for PTP 691 messages 693 15. Distributing PW labels 695 15.1. LDP extensions for distributing PW labels 697 TBD 699 15.2. BGP extensions for distributing PW labels 701 TBD 703 16. Behavior of LER/LSR 705 16.1. Behavior of 1588-aware LER 707 A 1588-aware LER advertises it's 1588-awareness via the OSPF 708 procedure explained in earlier section of this specification. The 709 1588-aware LER then signals PTP LSPs by including the 1588_PTP_LSP 710 object in the RSVP-TE signaling. 712 When a 1588 message is received from a non-MPLS interface, the LER 713 MUST redirect them to a previously established PTP LSP. When a 1588 714 over MPLS message is received from an MPLS interface, the processing 715 is similar to 1588-aware LSR processing. 717 16.2. Behavior of 1588-aware LSR 719 1588-aware LSRs are LSRs that understand the 1588_PTP_LSP RSVP object 720 and can perform 1588 processing (e.g. TC processing). 722 A 1588-aware LSR advertises it's 1588-awareness via the OSPF 723 procedure explained in earlier section of this specification. 725 When a 1588-aware LSR distributes a label for PTP LSP, it maintains 726 this information. When the 1588-aware LSR receives an MPLS packet, 727 it performs a label lookup and if the label lookup indicates it is a 728 PTP label then further parsing must be done to positively identify 729 that the payload is 1588 and not OAM, BFD or control and management. 730 Ruling out non-1588 messages can easily be done when parsing 731 indicates the presence of GAL, ACH or VCCV (Type 1, 2, 3) or when the 732 UDP port number does not match one of the 1588 UDP port numbers. 734 After a 1588 message is positively identified in a PTP LSP, the PTP 735 message type indicates what type of processing (TC) if any is 736 required. After 1588 processing the packet is forwarded as a normal 737 MPLS packet to downstream node. 739 16.3. Behavior of non-1588-aware LSR 741 It is most beneficial that all LSRs in the path of a PTP LSP be 1588- 742 aware LSRs. This would ensure the highest quality time and clock 743 synchronization by 1588 Slaves. However, this specification does not 744 mandate that all LSRs in path of a PTP LSP be 1588-aware. 746 Non-1588-aware LSRs are LSRs that either don't have the capability to 747 process 1588 packets (e.g. TC processing) or don't understand the 748 1588_PTP_LSP RSVP object. 750 Non-1588-aware LSRs ignore the RSVP 1588_PTP_LSP object and just 751 switch the MPLS packets carrying 1588 messages as data packets and 752 don't perform any TC processing. However as explained in QoS section 753 the 1588 over MPLS packets MUST be still be treated with the highest 754 priority. 756 17. Other considerations 758 The use of Explicit Null (Label= 0 or 2) is acceptable as long as 759 either the Explicit Null label is the bottom of stack label 760 (applicable only to UDP/IP encapsulation) or the label below the 761 Explicit Null label is a PTP label. 763 The use of Penultimate Hop Pop (PHP) is acceptable as long as either 764 the PHP label is the bottom of stack label (applicable only to UDP/IP 765 encapsulation) or the label below the PHP label is a PTP label. 767 18. Security Considerations 769 MPLS PW security considerations in general are discussed in [RFC3985] 770 and [RFC4447],and those considerations also apply to this document. 772 An experimental security protocol is defined in [IEEE]. The PTP 773 security extension and protocol provides group source authentication, 774 message integrity, and replay attack protection for PTP messages. 776 19. IANA Considerations 778 19.1. IANA Considerations for OSPF 780 IANA has defined a registry for TLVs carried in the Router 781 Information LSA defined in [RFC4970]. IANA is requested to assign a 782 new TLV code-point for the PCED TLV carried within the Router 783 Information LSA. 785 Value Sub-TLV References 786 ----- ---------------------- ---------- 787 TBD 1588aware node sub-TLV (this document) 789 19.2. IANA Considerations for IS-IS 791 IANA has defined a registry for the sub-TLVs carried in the IS-IS 792 Router Capability sub-TLVs defined in [RFC4971]. IANA is requested 793 to assign a new sub-TLV code-point for the 1588aware node sub-TLV 794 carried within the Router Capability sub-TLV. 796 Value Sub-TLV References 797 ----- ---------------------- ---------- 798 TBD 1588aware node sub-TLV (this document) 800 19.3. IANA Considerations for RSVP 802 IANA is requested to assign a new Class Number for 1588 PTP LSP 803 object that is used to signal PTP LSPs. 805 1588 PTP LSP Object 807 Class-Num of type 11bbbbbb 809 Suggested value TBD 811 Defined CType: 1 (1588 PTP LSP) 813 20. References 815 20.1. Normative References 817 [IEEE] IEEE 1588-2008, "IEEE Standard for a Precision Clock 818 Synchronization Protocol for Networked Measurement and 819 Control Systems". 821 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 822 Requirement Levels", BCP 14, RFC 2119, March 1997. 824 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 825 Edge (PWE3) Architecture", RFC 3985, March 2005. 827 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 828 Proxies (ND Proxy)", RFC 4389, April 2006. 830 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 831 Heron, "Pseudowire Setup and Maintenance Using the Label 832 Distribution Protocol (LDP)", RFC 4447, April 2006. 834 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, 835 "Encapsulation Methods for Transport of Ethernet over MPLS 836 Networks", RFC 4448, April 2006. 838 [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire 839 Emulation Edge-to-Edge (PWE3) Frame Check Sequence 840 Retention", RFC 4720, November 2006. 842 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 843 Connectivity Verification (VCCV): A Control Channel for 844 Pseudowires", RFC 5085, December 2007. 846 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 847 (BFD)", RFC 5880, June 2010. 849 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 850 "Bidirectional Forwarding Detection (BFD) for MPLS Label 851 Switched Paths (LSPs)", RFC 5884, June 2010. 853 20.2. Informative References 855 [I-D.ietf-pwe3-fat-pw] 856 Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 857 J., and S. Amante, "Flow Aware Transport of Pseudowires 858 over an MPLS PSN", draft-ietf-pwe3-fat-pw-05 (work in 859 progress), October 2010. 861 [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate 862 system routeing information exchange protocol for use in 863 conjunction with the Protocol for providing the 864 Connectionless-mode Network Service (ISO 8473)". 866 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 867 dual environments", RFC 1195, December 1990. 869 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 871 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 872 System (IS-IS) Extensions for Traffic Engineering (TE)", 873 RFC 3784, June 2004. 875 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 876 Shaffer, "Extensions to OSPF for Advertising Optional 877 Router Capabilities", RFC 4970, July 2007. 879 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 880 System to Intermediate System (IS-IS) Extensions for 881 Advertising Router Information", RFC 4971, July 2007. 883 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 884 for IPv6", RFC 5340, July 2008. 886 Authors' Addresses 888 Shahram Davari 889 Broadcom Corp. 890 San Jose, CA 95134 891 USA 893 Email: davari@broadcom.com 895 Amit Oren 896 Broadcom Corp. 897 San Jose, CA 95134 898 USA 900 Email: amito@broadcom.com 902 Luca Martini 903 Cisco Systems 904 San Jose CA 905 USA 907 Email: lmartini@cisco.com 909 Manav Bhatia 910 Alcatel-Lucent 911 Bangalore, 912 India 914 Email: manav.bhatia@alcatel-lucent.com 916 Peter Roberts 917 Alcatel-Lucent 918 Kanata, 919 Canada 921 Email: peter.roberts@alcatel-lucent.com