idnits 2.17.1 draft-davari-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 == 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 proper operation of 1588 Slaves, the physical path for PTP messages from Master to Slave and vice versa MUST be the same for all PTP messages listed in section 7 and MUST not change even in the presence of ECMP in the MPLS network. == 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 15, 2011) is 4848 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) -- Looks like a reference, but probably isn't: '1' on line 646 == Unused Reference: 'RFC4970' is defined on line 708, 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-05 -- Obsolete informational reference (is this intentional?): RFC 4970 (Obsoleted by RFC 7770) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 4 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 19, 2011 L. Martini 6 Cisco Systems 7 M. Bhatia 8 P. Roberts 9 Alcatel-Lucent 10 January 15, 2011 12 Transporting PTP messages (1588) over MPLS Networks 13 draft-davari-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 July 19, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 70 4. Dedicated LSPs for PTP messages . . . . . . . . . . . . . . . 9 72 5. 1588 over MPLS Encapsulation . . . . . . . . . . . . . . . . . 10 73 5.1. 1588 over LSP Encapsulation . . . . . . . . . . . . . . . 10 74 5.2. 1588 over PW Encapsulation . . . . . . . . . . . . . . . . 10 76 6. 1588 Message Transport . . . . . . . . . . . . . . . . . . . . 12 78 7. Protection and Redundancy . . . . . . . . . . . . . . . . . . 14 80 8. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 9. OAM, Control and Management . . . . . . . . . . . . . . . . . 16 84 10. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 17 86 11. FCS Recalculation . . . . . . . . . . . . . . . . . . . . . . 18 88 12. OSPF extensions for 1588aware LSRs . . . . . . . . . . . . . . 19 89 12.1. 1588aware Node Capability for OSPF . . . . . . . . . . . . 19 91 13. RSVP-TE Extensions for support of 1588 . . . . . . . . . . . . 21 93 14. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 22 94 14.1. Behavior of 1588-aware LER . . . . . . . . . . . . . . . . 22 95 14.2. Behavior of 1588-aware LSR . . . . . . . . . . . . . . . . 22 96 14.3. Behavior of non-1588-aware LSR . . . . . . . . . . . . . . 22 98 15. Other considerations . . . . . . . . . . . . . . . . . . . . . 24 100 16. Security Considerations . . . . . . . . . . . . . . . . . . . 25 102 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 104 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 105 18.1. Normative References . . . . . . . . . . . . . . . . . . . 27 106 18.2. Informative References . . . . . . . . . . . . . . . . . . 27 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC2119 [RFC2119]. 113 When used in lower case, these words convey their typical use in 114 common language, and are not to be interpreted as described in 115 RFC2119 [RFC2119]. 117 1. Introduction 119 The objective of Precision Time Protocol (PTP) is to synchronize 120 independent clocks running on separate nodes of a distributed system. 121 [IEEE] defines PTP messages for clock and time synchronization. The 122 PTP messages include PTP PDUs over UDP/IP (Annex D & E of [IEEE]) and 123 PTP PDUs over Ethernet (Annex F of [IEEE]). This document defines 124 mapping and transport of the PTP messages defined in [IEEE] over MPLS 125 networks. 127 PTP defines intermediate clock functions (called transparent clocks) 128 between the source of time (Master) and the Slave clocks. Boundary 129 Clocks (BC) form Master-Slave hierarchy with the Master clock as 130 root. The messages related to synchronization, establishing the 131 Master-Slave hierarchy, and signaling, terminate in the protocol 132 engine of a boundary clock and are not forwarded. Management 133 messages however, are forwarded to other ports on the boundary clock. 135 Transparent clocks modify a "correction field" (CF) within the 136 synchronization messages to compensate for residence and propagation 137 delays. Transparent clocks do not terminate synchronization, Master- 138 Slave hierarchy control messages or signaling messages. 140 There is a need to transport PTP messages over MPLS networks. The 141 MPLS network could be a transit network between 1588 Masters and 142 Slaves. The accuracy of the recovered clock improves and the Slave 143 logic simplifies when intermediate nodes (e.g. LSRs) properly handle 144 PTP messages (e.g. perform TC), otherwise the jitter at the 1588 145 Slave may be excessive and therefore the Slave may not be able to 146 properly recover the clock and time of day. 148 This document requires that MPLS nodes (LSRs) SHOULD be able to 149 support the Transparent Clock (TC) function, meaning that they should 150 be able to modify the CF of the proper PTP messages, via a 1-step or 151 2-step process. Such an LSR is referred to as a "1588-aware LSR" in 152 this document. 154 TC requires a 1588-aware LSR in the middle of an LSP to identify the 155 PTP messages and perform proper update of the CF. 157 More generally this document requires that an LSR SHOULD be able to 158 properly handle the PTP messages. For instance for those cases when 159 the TC function is not viable (e.g. due to layer violation) as an 160 alternative it should be possible to instead control the delay for 161 these messages on both directions across the node. 163 In the above cases it is beneficial that PTP packets can be easily 164 identified when carried over MPLS. 166 This document provides two methods for transporting PTP messages over 167 MPLS. The main objectives are for LSRs to be able to 168 deterministically detect and identify the PTP messages. 170 2. Terminology 172 1588: The timing and synchronization as defined by IEEE 1588 174 PTP: The timing and synchronization protocol used by 1588 176 Master: The Source of 1588 Timing and clock 178 Slave: The Destination of 1588 Timing and clock that tries to follow 179 the Master clock 181 OC: Ordinary Clock 183 TC: Transparent Clocking, a time stamping method applied by 184 intermediate nodes between Master and Slave 186 BC: Border Clock, is a node that recovers the Master clock via a 187 Slave function and uses that clock as the Master for other Slaves 189 PTP LSP: An LSP dedicated to carry PTP messages 191 PTP PW: A PW within a PTP LSP that MAY correspond to a Master/Slave 192 flow. 194 CW: Pseudo wire Control Word 196 CW: Pseudo wire Control Word 198 LAG: Link Aggregation 200 ECMP: Equal Cost Multipath 202 CF: Correction Field, a field inside certain PTP messages (message 203 type 0-3)that holds the accumulative transit time inside intermediate 204 switches 206 3. Problem Statement 208 When PTP messages are transported over MPLS networks, there is a need 209 for intermediate LSRs to detect such messages and perform proper 210 processing (e.g. Transparent Clock (TC)). Note the TC processing 211 could be in the form of 1-Step or 2-Step time stamping. 213 PTP messages over Ethernet or IP can always be tunneled over MPLS. 214 However the 1588 over MPLS mapping defined in this document is 215 applicable whenever MPLS LSRs are 1588-aware and the intention is for 216 those LSRs to perform proper processing on these packets. 218 When 1588-awareness is needed, PTP messages should not be transported 219 over LSPs or PWs that are carrying customer traffic because LSRs 220 perform Label switching based on the top label in the stack. To 221 detect PTP messages inside such LSPs require special Hardware (HW) to 222 do deep packet inspection at line rate. Even if one assumes a deep 223 packet inspection HW at line rate exists, the payload can't be 224 deterministically identified by LSRs because the payload type is a 225 context of the PW label and the PW label and its context are only 226 known to the Edge routers (PEs) and LSRs don't know what is a PW's 227 payload (Ethernet, ATM, FR, CES, etc). Even if one assumes only 228 Ethernet PWs are permitted in an LSP, the LSRs don't have the 229 knowledge of whether PW Control Word (CW) is present or not and 230 therefore can't deterministically identify the payload. 232 Therefore a generic method is defined in this document that does not 233 require deep packet inspection at line rate, and can 234 deterministically identify PTP messages. The defined method is 235 applicable to both MPLS and MPLS-TP networks. 237 4. Dedicated LSPs for PTP messages 239 Many methods were considered for identifying the 1588 messages when 240 they are encapsulated in MPLS such as by using GAL/ACH or a new 241 reserved label. These methods were not attractive since they either 242 required deep packet inspection and snooping at line rate or they 243 required use of scarce new reserved label. Also one of the goals was 244 to reuse existing OAM and protection mechanisms. 246 The method defined in this document can be used by LSRs to identify 247 PTP messages in MPLS tunnels by using dedicated LSPs to carry PTP 248 messages. 250 Compliant implementations MUST use dedicated LSPs to carry PTP 251 messages over MPLS. Let's call these LSPs as the "PTP LSPs" and the 252 labels associated with these LSPs as "PTP labels". These LSPs could 253 be P2P or P2MP LSPs. The PTP LSP between Master and Slaves MAY be 254 P2MP or P2P LSP while the PTP LSP between each Slave and Master 255 SHOULD be P2P LSP. The PTP LSP between a Master and a Slave and the 256 PTP LSP between the same Slave and Master MUST be co-routed. 257 Alternatively, a single bidirectional co-routed LSP can be used. The 258 PTP LSP MAY be MPLS LSP or MPLS-TP LSP. 260 The PTP LSPs could be configured or signaled via RSVP-TE/GMPLS. New 261 RSVP-TE/GMPLS TLVs and objects are defined in this document to 262 indicate that these LSPs are PTP LSPs. 264 Note that the PTP LSPs MUST only carry PTP messages and MAY carry 265 MPLS/MPLS-TP control and management messages such as BFD and LSP- 266 Ping. 268 5. 1588 over MPLS Encapsulation 270 This document defines two methods for carrying PTP messages over 271 MPLS. The first method is carrying IP encapsulated PTP messages over 272 PTP LSPs and the second method is to carry PTP messages over 273 dedicated Ethernet PWs (called PTP PWs) inside PTP LSPs. 275 5.1. 1588 over LSP Encapsulation 277 The simplest method of transporting PTP messages over MPLS is to 278 encapsulate PTP PDUs in UDP/IP and then encapsulate them in PTP LSP. 279 The 1588 over LSP format is shown in Figure 1. 281 +----------------------+ 282 | PTP Tunnel Label | 283 +----------------------+ 284 | IPv4/6 | 285 +----------------------+ 286 | UDP | 287 +----------------------+ 288 | PTP PDU | 289 +----------------------+ 291 Figure 1 - 1588 over LSP Encapsulation 293 This encapsulation is very simple and is useful when the networks 294 between 1588 Master and Slave are IP/MPLS networks. 296 In order for an LSR to process PTP messages, the PTP Label MUST be 297 the top label of the label stack. 299 The UDP/IP encapsulation of PTP MUST follow Annex D and E of [IEEE]. 301 5.2. 1588 over PW Encapsulation 303 Another method of transporting 1588 over MPLS networks is by 304 encapsulating PTP PDUs in Ethernet and then transporting them over 305 Ethernet PW (PTP PW) as defined in [RFC4448], which in turn is 306 transported over PTP LSPs. Alternatively PTP PDUs MAY be 307 encapsulated in UDP/IP/Ethernet and then transported over Ethernet 308 PW. 310 Both Raw and Tagged modes for Ethernet PW are permitted. The 1588 311 over PW format is shown in Figure 2. 313 +----------------+ 314 |PTP Tunnel Label| 315 +----------------+ 316 | PW Label | 317 +----------------+ 318 | Entropy Label | 319 | (optional) | 320 +----------------+ 321 | Control Word | 322 +----------------+ 323 | Ethernet | 324 | Header | 325 +----------------+ 326 | VLANs | 327 | (optional) | 328 +----------------+ 329 | IPV4/V6 | 330 | (optional) | 331 +----------------+ 332 | UDP | 333 | (optional) | 334 +----------------+ 335 | PTP PDU | 336 +----------------+ 337 Figure 2 - 1588 over PW Encapsulation 339 The Control Word (CW) as specified in [RFC4448] SHOULD be used to 340 ensure a more robust detection of PTP messages inside the MPLS 341 packet. If CW is used, the use of Sequence number is optional. 343 The use of VLAN and UDP/IP are optional. Note that 1 or 2 VLANs MAY 344 exist in the PW payload. 346 In order for an LSR to process PTP messages, the top label of the 347 label stack (the Tunnel Label) MUST be from PTP label range. However 348 in some applications the PW label may be the top label in the stack, 349 such as cases where there is only one-hop between PEs or in case of 350 PHP. In such cases, the PW label SHOULD be chosen from the PTP Label 351 range. 353 An Entropy label [I-D.ietf-pwe3-fat-pw] MAY be present at the bottom 354 of stack. 356 The Ethernet encapsulation of PTP MUST follow Annex F of [IEEE] and 357 the UDP/IP encapsulation of PTP MUST follow Annex D and E of [IEEE]. 359 6. 1588 Message Transport 361 1588 protocol comprises of the following message types: 363 o Announce 365 o SYNC 367 o FOLLOW UP 369 o DELAY REQ (Delay Request) 371 o DELAY RESP (Delay Response) 373 o PDELAY REQ (Peer Delay Request) 375 o PDELAY RESP (Peer Delay Response) 377 o PDELAY RESP FOLLOW UP (Peer Delay Response Follow up) 379 o Management 381 o Signaling 383 A subset of PTP message types that require TC processing are called 384 Event messages: 386 o SYNC 388 o DELAY REQ (Delay Request) 390 o PDELAY REQ (Peer Delay Request) 392 o PDELAY RESP (Peer Delay Response) 394 SYNC and DELAY_REQ are exchanged between Master and Slave and MUST be 395 transported over PTP LSPs. PDELAY_REQ and PDELAY_RESP are exchanged 396 between adjacent routers and MAY be transported over single hop PTP 397 LSPs. If Two Step Transparent clocks are present, then the FOLLOW_UP 398 and DELAY_RESP messages must also be transported over the PTP LSPs. 400 For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be 401 transported over two PTP LSPs that are in opposite directions. These 402 PTP LSPs, which are in opposite directions MUST be congruent and co- 403 routed. Alternatively, a single bidirectional co-routed LSP can be 404 used. 406 Except as indicated above for the two-step Transparent clocks, Non- 407 Event PTP message types don't need to be processed by intermediate 408 routers. These message types MAY be carried in PTP Tunnel LSPs. 410 7. Protection and Redundancy 412 In order to ensure continuous uninterrupted operation of 1588 Slaves, 413 usually as a general practice, Redundant Masters are tracked by each 414 Slave. It is the responsibility of the network operator to ensure 415 that physically disjoint PTP tunnels that don't share any link are 416 used between the redundant Masters and a Slave. 418 When redundant Masters are tracked by a Slave, any PTP LSP or PTP PW 419 failure will trigger the slave to switch to the Redundant Master. 420 However LSP/PW protection such as Linear Protection Switching 421 (1:1,1+1), Ring protection switching or MPLS Fast Reroute (FRR) 422 SHOULD still be used to ensure the LSP/PW is ready for a future 423 failure. 425 Note that any protection or reroute mechanism that adds additional 426 label to the label stack, such as Facility Backup Fast Reroute, MUST 427 ensure that the pushed label is a PTP Label to ensure proper 428 processing of PTP messages by LSRs in the backup path. 430 8. ECMP 432 To ensure the proper operation of 1588 Slaves, the physical path for 433 PTP messages from Master to Slave and vice versa MUST be the same for 434 all PTP messages listed in section 7 and MUST not change even in the 435 presence of ECMP in the MPLS network. 437 To ensure the forward and reverse paths are the same PTP LSPs and PWs 438 MUST NOT be subject to ECMP. 440 9. OAM, Control and Management 442 In order to manage PTP LSPs and PTP PWs, they MAY carry OAM, Control 443 and Management messages. These control and management messages can 444 be differentiated from PTP messages via already defined IETF methods. 446 In particular BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389]MAY run 447 over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These 448 Management protocols are easily identified by the UDP Destination 449 Port number or by GAL/ACH respectively. 451 Also BFD, LSP-Ping and other Management messages MAY run over PTP PW 452 via one of the defined VCCVs (Type 1, 2 or 3) [RFC5085]. In this 453 case G-ACH, Router Alert Label (RAL), or PW label (TTL=1) are used to 454 identify such management messages. 456 10. QoS Considerations 458 The PTP messages are time critical and must be treated with the 459 highest priority. Therefore 1588 over MPLS messages must be treated 460 with the highest priority in the routers. This can be achieved by 461 proper setup of PTP tunnels. The PTP LSPs MUST be setup and marked 462 properly to indicate EF-PHB for the CoS and Green for drop 463 eligibility 465 11. FCS Recalculation 467 Ethernet FCS MUST be recalculated at every LSR that performs the TC 468 processing and FCS retention described in [RFC4720] MUST not be used. 470 12. OSPF extensions for 1588aware LSRs 472 MPLS-TE routing relies on extensions to OSPF [RFC2328] in order to 473 advertise Traffic Engineering (TE) link information used for 474 constraint-based routing. 476 Indeed, it is useful to advertise data plane TE node capabilities, 477 such as the capability for a router to be 1588-aware. This 478 capability MUST then be taken into account during path computation to 479 prefer nodes that advertise themselves as 1588-aware, so that the PTP 480 LSPs can be properly handled. 482 For this purpose, the following sections specify OSPF extensions in 483 order to advertise 1588 aware capabilities of a node. 485 12.1. 1588aware Node Capability for OSPF 487 This extension makes use of the Router Information (RI) Opaque LSA 488 defined in [RFC4970]for both OSPFv2 and OSPFv3, by defining a new 489 OSPF Router Information (RI) TLV - The 1588-aware Capability TLV. 491 The 1588-aware Capability TLV is OPTIONAL and is defined as follows: 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Type | Length | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Flags | 499 +-+-+-+-+-+-+-+-+ 501 Figure 3: 1588-aware Capability TLV 503 Where: 505 Type, 16 bits: 1588-aware Capability TLV where the value is TBD 507 Length, 16 bits: Gives the length of the flags field in octets, and 508 is currently set to 1 510 Flags, 8 bits: The bits are defined least-significant-bit (LSB) 511 first, so bit 7 is the least significant bit of the flags octet. 513 +-+-+-+-+-+-+-+-+ 514 | Reserved |C| 515 +-+-+-+-+-+-+-+-+ 516 Figure 4: Flags Format 518 Correction (C) field Update field, 1 bit: Setting the C bit to 1 519 indicates that the node is capable of recognizing the PTP event 520 packets and can compensate for residence time by updating the PTP 521 packet Correction Field. When this is set to 0, it means that this 522 node cannot perform the residence time correction but is capable of 523 performing MPLS frame forwarding of the frames with PTP labels using 524 a method that support the end to end delivery of accurate timing. 525 The exact method is not defined herein. 527 Reserved, 7 bits: Reserved for future use. The reserved bits must be 528 ignored by the receiver. 530 The 1588-aware Capability TLV is applicable to both OSPFv2 and 531 OSPFv3. 533 The 1588-aware Capability TLV MAY be advertised within an area-local 534 or autonomous system (AS) scope Router Information (RI) LSA. But the 535 1588-aware Capability TLV SHOULD NOT be advertised into an area in 536 more than one RI LSA irrespective of the scope of the LSA. 538 The flooding scope is controlled by the Opaque LSA type in OSPFv2 and 539 by the S1 and S2 bits in OSPFv3. For area scope, the 1588-aware 540 Capability TLV MUST be carried within an OSPFv2 Type 10 RI LSA or an 541 OSPFv3 RI LSA with the S1 bit set and S2 bit clear. If the flooding 542 scope is the entire routing domain (AS scope), the 1588-aware 543 Capability TLV MUST be carried within an OSPFv2 Type 11 RI LSA or 544 OSPFv3 RI LSA with the S1 bit clear and the S2 bit set. 546 13. RSVP-TE Extensions for support of 1588 548 RSVP-TE signaling MAY be used to setup the PTP LSPs. A new RSVP 549 object is defined to signal that this is a PTP LSP. The OFFSET to 550 the start of the PTP message header MAY also be signaled. 551 Implementations can trivially locate the correctionField (CF) 552 location given this information. The OFFSET points to the start of 553 the PTP header as a node may want to check the PTP messageType before 554 it touches the correctionField (CF). 556 The LSRs that receive and process the RSVP-TE/GMPLS messages MAY use 557 the OFFSET to locate the start of the PTP message header. 559 Note that the new object/TLV Must be ignored by LSRs that are not 560 compliant to this specification. 562 The new RSVP 1588_PTP_LSP object should be included in signaling PTP 563 LSPs and is defined as follows: 565 0 1 2 3 566 +-------------+-------------+-------------+-------------+ 567 | Length (bytes) | Class-Num | C-Type | 568 +-------------+-------------+-------------+-------------+ 569 | Offset to locate the start of the PTP message header | 570 +-------------+-------------+-------------+-------------+ 571 Figure 5: RSVP 1588_PTP_LSP object 573 The ingress LSR MUST include this object in the RSVP PATH Message. 574 It is just a normal RSVP path that is exclusively set up for PTP 575 messages 577 14. Behavior of LER/LSR 579 14.1. Behavior of 1588-aware LER 581 A 1588-aware LER advertises it's 1588-awareness via the OSPF 582 procedure explained in earlier section of this specification. The 583 1588-aware LER then signals PTP LSPs by including the 1588_PTP_LSP 584 object in the RSVP-TE signaling. 586 When a 1588 message is received from a non-MPLS interface, the LER 587 MUST redirect them to a previously established PTP LSP. When a 1588 588 over MPLS message is received from an MPLS interface, the processing 589 is similar to 1588-aware LSR processing. 591 14.2. Behavior of 1588-aware LSR 593 1588-aware LSRs are LSRs that understand the 1588_PTP_LSP RSVP object 594 and can perform 1588 processing (e.g. TC processing). 596 A 1588-aware LSR advertises it's 1588-awareness via the OSPF 597 procedure explained in earlier section of this specification. 599 When a 1588-aware LSR distributes a label for PTP LSP, it maintains 600 this information. When the 1588-aware LSR receives an MPLS packet, 601 it performs a label lookup and if the label lookup indicates it is a 602 PTP label then further parsing must be done to positively identify 603 that the payload is 1588 and not OAM, BFD or control and management. 604 Ruling out non-1588 messages can easily be done when parsing 605 indicates the presence of GAL, ACH or VCCV (Type 1, 2, 3) or when the 606 UDP port number does not match one of the 1588 UDP port numbers. 608 After a 1588 message is positively identified in a PTP LSP, the PTP 609 message type indicates what type of processing (TC) if any is 610 required. After 1588 processing the packet is forwarded as a normal 611 MPLS packet to downstream node. 613 14.3. Behavior of non-1588-aware LSR 615 It is most beneficial that all LSRs in the path of a PTP LSP be 1588- 616 aware LSRs. This would ensure the highest quality time and clock 617 synchronization by 1588 Slaves. However, this specification does not 618 mandate that all LSRs in path of a PTP LSP be 1588-aware. 620 Non-1588-aware LSRs are LSRs that either don't have the capability to 621 process 1588 packets (e.g. TC processing) or don't understand the 622 1588_PTP_LSP RSVP object. 624 Non-155-aware LSRs ignore the RSVP 1588_PTP_LSP object and just 625 switch the MPLS packets carrying 1588 messages as data packets and 626 don't perform any TC processing. However as explained in QoS section 627 the 1588 over MPLS packets MUST be still be treated with the highest 628 priority. 630 15. Other considerations 632 The use of Explicit Null (Label= 0 or 2) is acceptable as long as 633 either the Explicit Null label is the bottom of stack label 634 (applicable only to UDP/IP encapsulation) or the label below the 635 Explicit Null label is a PTP label. 637 The use of Penultimate Hop Pop (PHP) is acceptable as long as either 638 the PHP label is the bottom of stack label (applicable only to UDP/IP 639 encapsulation) or the label below the PHP label is a PTP label. 641 16. Security Considerations 643 MPLS PW security considerations in general are discussed in [RFC3985] 644 and [RFC4447],and those considerations also apply to this document. 646 An experimental security protocol is defined in [1]. The PTP 647 security extension and protocol provide group source authentication, 648 message integrity, and replay attack protection for PTP messages. 650 17. IANA Considerations 652 A new 1588-aware Capability TLV is required to signal 1588-awreness 653 via OSPF. IANA needs to assign a new Type for such TLV. 655 Also a 1588_PTP_LSP RSVP object is required to signal PTP LSP. IANA 656 needs to assign a new CLASS-Num and C-Type for 1588_PTP_LSP object. 658 18. References 660 18.1. Normative References 662 [IEEE] "IEEE Standard for a Precision Clock Synchronization 663 Protocol for Networked Measurement and Control Systems", 664 2008. 666 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 667 Requirement Levels", BCP 14, RFC 2119, March 1997. 669 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 670 Edge (PWE3) Architecture", RFC 3985, March 2005. 672 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 673 Proxies (ND Proxy)", RFC 4389, April 2006. 675 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 676 Heron, "Pseudowire Setup and Maintenance Using the Label 677 Distribution Protocol (LDP)", RFC 4447, April 2006. 679 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, 680 "Encapsulation Methods for Transport of Ethernet over MPLS 681 Networks", RFC 4448, April 2006. 683 [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire 684 Emulation Edge-to-Edge (PWE3) Frame Check Sequence 685 Retention", RFC 4720, November 2006. 687 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 688 Connectivity Verification (VCCV): A Control Channel for 689 Pseudowires", RFC 5085, December 2007. 691 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 692 (BFD)", RFC 5880, June 2010. 694 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 695 "Bidirectional Forwarding Detection (BFD) for MPLS Label 696 Switched Paths (LSPs)", RFC 5884, June 2010. 698 18.2. Informative References 700 [I-D.ietf-pwe3-fat-pw] 701 Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 702 J., and S. Amante, "Flow Aware Transport of Pseudowires 703 over an MPLS PSN", draft-ietf-pwe3-fat-pw-05 (work in 704 progress), October 2010. 706 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 708 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 709 Shaffer, "Extensions to OSPF for Advertising Optional 710 Router Capabilities", RFC 4970, July 2007. 712 Authors' Addresses 714 Shahram Davari 715 Broadcom Corp. 716 San Jose, CA 95134 717 USA 719 Email: davari@broadcom.com 721 Amit Oren 722 Broadcom Corp. 723 San Jose, CA 95134 724 USA 726 Email: amito@broadcom.com 728 Luca Martini 729 Cisco Systems 730 San Jose CA 731 USA 733 Email: lmartini@cisco.com 735 Manav Bhatia 736 Alcatel-Lucent 737 Bangalore, 738 India 740 Email: manav.bhatia@alcatel-lucent.com 742 Peter Roberts 743 Alcatel-Lucent 744 Kanata, 745 Canada 747 Email: peter.roberts@alcatel-lucent.com