idnits 2.17.1 draft-zhang-tictoc-pdv-lsp-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 664 has weird spacing: '...outeing infor...' -- The document date (Oct 20, 2011) is 4572 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) == Missing Reference: 'RFC2119' is mentioned on line 119, but not defined == Missing Reference: 'RFC5340' is mentioned on line 455, but not defined == Unused Reference: 'RFC3985' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'RFC4736' is defined on line 649, but no explicit reference was found in the text == Unused Reference: 'RFC5880' is defined on line 654, but no explicit reference was found in the text == Unused Reference: 'RFC5884' is defined on line 657, but no explicit reference was found in the text == Unused Reference: 'RFC4970' is defined on line 681, but no explicit reference was found in the text == Unused Reference: 'RFC4971' is defined on line 685, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-tictoc-1588overmpls-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-tictoc-1588overmpls (ref. 'I-D.ietf-tictoc-1588overmpls') -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE' ** Downref: Normative reference to an Informational RFC: RFC 3985 ** Downref: Normative reference to an Informational RFC: RFC 4736 -- 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 (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Zhang 3 Internet-Draft L. Xia 4 Intended status: Standards Track ZTE Corporation 5 Expires: April 22, 2012 Oct 20, 2011 7 PDV-based PTP LSP Setup,Reoptimization and Recovery 8 draft-zhang-tictoc-pdv-lsp-00 10 Abstract 12 This document defines a mechanism for the setup,reoptimization and 13 recovery of PTP LSP based on the PDV metrics between the 1588 Master 14 and the 1588 Slave. 16 When a PTP communication path goes through the third party networks 17 (e.g. the MPLS networks), the PDV noise caused by the third party 18 networks will have a significant impact on the synchronization 19 performance. So, the PDV metrics should be considered in the setup 20 of PTP LSP. 22 In addition, when the PDV noise exceeds to a certain degree, it is 23 necessary to notify the head-end LSR(i.e. the 1588 Master) to switch 24 to the backup PTP LSP and to reoptimize the primary PTP LSP in order 25 to improve the PTP reliability. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 22, 2012. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 65 4. PTP LSP setup and reoptimization . . . . . . . . . . . . . . . 5 66 4.1. Advertisement of the capability of reserving bandwidth . . 6 67 4.2. PTP LSP setup . . . . . . . . . . . . . . . . . . . . . . 6 68 4.3. Congestion detection . . . . . . . . . . . . . . . . . . . 7 69 4.4. PTP LSP reoptimization . . . . . . . . . . . . . . . . . . 7 70 5. PTP LSP recovery mechanisms . . . . . . . . . . . . . . . . . 8 71 5.1. PDV measurement and PDV network limits . . . . . . . . . . 8 72 5.2. PTP LSP recovery . . . . . . . . . . . . . . . . . . . . . 8 73 5.3. PTP Master recovery . . . . . . . . . . . . . . . . . . . 9 74 6. Protocal extensions . . . . . . . . . . . . . . . . . . . . . 11 75 6.1. IGP extensions . . . . . . . . . . . . . . . . . . . . . . 11 76 6.2. RSVP-TE extensions . . . . . . . . . . . . . . . . . . . . 13 77 7. Other considerations . . . . . . . . . . . . . . . . . . . . . 13 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 10.1. IANA Considerations for OSPF . . . . . . . . . . . . . . . 14 82 10.2. IANA Considerations for IS-IS . . . . . . . . . . . . . . 14 83 10.3. IANA Considerations for RSVP . . . . . . . . . . . . . . . 15 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 There are many applications that need frequency or phase/time 92 synchronization, and there is an emerging need to distribute highly 93 accurate time and frequency information over IP and over MPLS packet 94 switched networks (PSNs), especially with the development of the 95 telecom network. [IEEE] defines PTP for clock and time 96 synchronization. PTP version 2 contains three clock type, they are 97 Ordinary Clock(OC), Boundary Clock(BC) and Transparent Clock(TC). 98 Transparent Clocks modify a "correction field" (CF) within the 99 synchronization messages to compensate for residence and propagation 100 delays. So, Transparent Clock can eliminate the impact of the PDV 101 noise. 103 With the large-scale deployment of the MPLS networks and the 1588 104 networks, there is an increasing need to transport PTP messages over 105 the MPLS networks. The MPLS networks could be a transit network 106 between the 1588 Master and the 1588 Slave. But the PDV noise 107 between the 1588 Master and the 1588 Slave may be excessive and 108 therefore the 1588 Slave may not be able to properly recover the 109 clock and time of day. Therefore, it is necessary to setup PTP LSP 110 based on the PDV attributes, and when the PDV noise exceeds a certain 111 degree, the 1588 Master will switch to the backup PTP LSP and 112 reoptimize the primary PTP LSP. 114 1.1. Conventions Used in This Document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 2. Terminology 122 PTN: Packet Transport Network; 124 1588: The timing and synchronization as defined by IEEE 1588; 126 PTP: The timing and synchronization protocol used by 1588; 128 Master: The Source of 1588 Timing and clock. This will be a port in 129 master state on a Grandmaster Clock or on a Boundary Clock; 131 Slave: The Destination of 1588 Timing and clock that tries to follow 132 the Master clock. This will be a port in slave state on a boundary 133 clock or on a Slave-Only Ordinary Clock; 134 OC: Ordinary Clock - a device with a single PTP port; 136 TC: Transparent Clock, a time stamping method applied by intermediate 137 nodes between Master and Slave; 139 BC: Boundary Clock, is a node that recovers the Master clock via a 140 Slave function and uses that clock as the Master for other Slaves; 142 PDV: Packet Delay Variation; 144 PTP LSP: An LSP dedicated to carry PTP messages; 146 PDV PTP LSP: An PTP LSP based on the PDV attributes; 148 ACR: Adaptive Clock Recovery; 150 MBB: make-before-break; 152 LSR: Label Switch Router; 154 3. Problem Statement 156 With the development of telecom networks, there is an increasing need 157 to transport PTP or CES over the third part networks(e.g. MPLS 158 networks). Two main applications are addressed in ITU-T G.8261.1: 160 (1) the distribution of a synchronization network clock signal via 161 packet based method (e.g. using PTP); 163 (2) the distribution of a service clock signal over a packet network 164 according to the ACR method (e.g. clock recovery of CES using 165 Adaptive Method). The packet networks are Ethernet, MPLS, T-MPLS or 166 IP. For these applications, frequency synchronization information is 167 carried via packets and is recovered according to adaptive clock 168 recovery(ACR) method. But the third part networks(e.g. MPLS 169 networks) may introduce the PDV noise which will have a significant 170 impact on the ACR Methods and the synchronization performance. 172 The method for transporting PTP messages (PDUs) over an MPLS network 173 is defined in [I-D.ietf-tictoc-1588overmpls]. This document defines 174 a "1588-aware LSR" that is able to identify 1588 timing flows carried 175 over MPLS. Transparent Clock (TC) function requires a 1588-aware LSR 176 in the middle of an LSP to properly handle the PTP messages. 177 However, this specification does not mandate that all LSRs in path of 178 a PTP LSP be 1588-aware, Non-1588-aware LSRs don't perform any TC 179 processing. Therefore, these LSRs may introduce additional PDV 180 noise, although the PTP messages are treated with the highest 181 priority and Green for drop eligibility, because the other flows may 182 use the same queue. 184 Just as MPLS-TE setup a TE LSP based on TE metrics(e.g. bandwidth), 185 it is necessary to setup a PTP LSP based-on the PDV metrics, and if 186 the PDV noise between the 1588 Master and the 1588 Slave has 187 deteriorated into a certain degree, then the 1588 Master switchs to 188 the backup PTP LSP and reoptimizes the primary PTP LSP. So, it is 189 useful for clock recovery algorithms to improve the performance of 190 clock recovery. 192 4. PTP LSP setup and reoptimization 194 The PDV noise introduced by the MPLS networks is critical for the 195 clock recovery algorithm and the synchronization performance. The 196 main factor caused the PDV noise is congestion in the network nodes. 197 In order to minimize the PDV noise between the 1588 Master and the 198 1588 Slave, the 1588 Master SHOULD discover a PTP LSP along which the 199 number of the Non-1588-aware LSRs is minimum. 201 MPLS-TE support setting up TE-LSP based on the reserved bandwidth 202 which can prevent TE-flow from congestion. But due to the complexity 203 of implementation and the cost of HW, some of the network nodes don't 204 support the capability of reserving bandwidth. In this case, 205 congestion detection MUST be enabled on these nodes. If congestion 206 occurred on one of these nodes, then the node MUST notify the 1588 207 Master(i.e. the head-end node ), therefore the 1588 Master is able to 208 reoptimize the TE-LSP and to avoid the congested nodes so that the 209 PDV noise between the 1588 Master and the 1588 Slave can be 210 minimized. 212 It is possible that after a PTP LSP has been established, a more 213 efficient path for the PTP becomes available, perhaps because one or 214 more new 1588aware links have been advertised or because some other 215 services have been torn down causing resources in the network to be 216 released. When a better path can be found for one of the previously 217 computed paths, the node or component that originally requested the 218 path can be notified. In order to take advantage of the new path, 219 the ingress node must re-route the PTP onto the new path using the 220 reoptimization technique(e.g. make-before-break). 222 Mpls Network 223 head-end +--------------------------------+ tail-end 224 (the 1588 Master)| |(the 1588 Slave) 225 +------| PTP LSP |-------+ 226 ======> | | = = = = = = = = = = = = = = > | |======> 227 +------| |-------+ 228 | | 229 +--------------------------------+ 230 Figure 1. 1588 over MPLS Network 232 4.1. Advertisement of the capability of reserving bandwidth 234 Due to the complexity of implement and the cost of HW, some of the 235 network nodes don't support the capability of reserving bandwidth 236 based on the LSP , so that these network nodes may introduce 237 jitter(i.e. PDV). 239 Just as the capability of 1588-aware which can compensate for 240 residence time by updating the PTP packet Correction Field and 241 eliminate the delay and jitter, it is useful to advertise data plane 242 TE router link capabilities within the whole network, such as the 243 capability of reserving bandwidth. This capability MUST then be 244 taken into account during path computation to prefer links that 245 advertise themselves as reserving bandwidth , so that the PTP LSPs 246 can be properly handled. 248 For this purpose, the following sections specify extensions to OSPF 249 and IS-IS in order to advertise the capability of reserving 250 bandwidth. 252 4.2. PTP LSP setup 254 The Procedures for setting up LSP Tunnels are defined in [RFC3209]. 255 To setup PTP LSP, more constraints information MUST be taken into 256 account, for examples, 1588-aware, reserving bandwidth, and so on. . 258 After all TE information were advertised by link state protocol(e.g. 259 OSPF or IS-IS), the TE database at the head-end node contains all the 260 links and their characteristics or attributes and includes 1588-aware 261 and reserving bandwidth. From this MPLS TE database, path 262 calculation (PCALC) or constrained SPF (CSPF) calculates the shortest 263 route that still adheres to all the constraints from the head-end 264 LSR(i.e. the 1588 Master) to the tail-end LSR(i.e. the 1588 Slave). 266 4.3. Congestion detection 268 Quality of service (QoS) has become popular the past few years. Few 269 networks have unlimited bandwidth, so congestion is always a 270 possibility in the network. QoS is a means to prioritize important 271 traffic over less important traffic and make sure it is delivered. 272 Congestion may happen at different points within a network node. 273 Each congestion point represents a potential source of delay, jitter, 274 and loss for traffic streams. 276 If neither the capability of 1588-aware nor the capability of 277 reserving bandwidth is supported at a node, then this node may 278 introduce jitter(i.e. PDV), although the LSP tunnel is treated with 279 the highest priority. 281 So, after PTP LSP has been set up, the head-end node(i.e. the 1588 282 Master) MUST request those network nodes which support neither 1588- 283 aware nor reserving bandwidth to enable congestion detection. When 284 congestion occurs or disappears on the node, the node MUST send a 285 notification message to the head-end node, so that the head-end node 286 can reoptimizes the PTP LSP and sets up another new PTP LSP which 287 doesn't pass through these congested network nodes. 289 Because a PTP LSP is related to a special output port and a special 290 priority, the data plane can detect congestion based on the output 291 port and the corresponding queue. When congestion has occurred, the 292 data plane will notify the control plane which will sends a notify 293 message to the head-end. 295 4.4. PTP LSP reoptimization 297 As mentioned above, it is possible that a more efficient path for the 298 PTP becomes available, for example, the deployment of new 1588-aware 299 LSRs,and so on. In order to improve the synchronization performance, 300 the head-end MUST re-route the PTP onto the new path. It is assumed 301 that the head-end node has received the congestion notifications from 302 the congested nodes along the PTP LSP, and the PDV noise between the 303 1588 Master and the 1588 Slave exceeds a certain degree. At this 304 time, the tail-end node(e.g. the 1588 Slave) MUST send a 305 reoptimization notification message to the head-end node, the receipt 306 of such of message will then trigger a reoptimization on the head-end 307 node for the affected PTP LSP. Because the head-end node has learned 308 about which network nodes are 1588-aware and which network nodes has 309 occurred congestion, so it can reoptimize the affected PTP LSP and 310 avoid those congested nodes.. 312 There are several reoptimization triggers, including timer-based 313 reoptimization ,event-driven reoptimization and operator-driven 314 reoptimization. Note that reoptimization or recovery may also 315 introduce the PDV. Therefore, PTP LSP reoptimization MUST be 316 triggered by the PDV metrics. 318 5. PTP LSP recovery mechanisms 320 One kind of network fault is packets arriving at a network node which 321 the node has no forwarding information or incorrect forwarding 322 information. This problem can be detected by the control 323 information. Another kind of problem is the one in which the control 324 plane information is correct but the data plane fails. In this case, 325 LSP ping, LSP traceroute and Bidirectional Forwarding Detection (BFD) 326 are tools that can detect problems in the MPLS control and data 327 planes. 329 The above network problems are all due to connection failure. But 330 for the synchronization application(e.g. PTP), it is tolerant of an 331 occasional missed message, duplicated message, or message that 332 arrived out of order,which means that an occasional connection 333 failure is insignificant to the synchronization performance. 334 However, the PDV by the packet timing signal as it traverses the 335 network from the 1588 Master to the 1588 Slave is critical to the 336 synchronization performance. So, it is reasonable to recover the 337 synchronization application based on the PDV metrics. 339 5.1. PDV measurement and PDV network limits 341 ITU-T G.826x concerns frequency synchronization aspects in packet 342 networks. In particular it specifies the Hypothetical Reference 343 Model and the PDV network limits applicable when frequency 344 synchronization is carried via packets and is recovered according to 345 adaptive clock recovery method as defined in G.8261 and G.8260. It 346 specifies the minimum equipment tolerance to packet delay variation 347 in terms of the metrics defined in ITU-T G.8260 at boundary of these 348 packet networks. 350 PDV measurement is at the input of the 1588 Slave. If the PDV exceed 351 the network limits, then the 1588 Slave MUST send native indications 352 over the PTP LSP to notify the 1588 Master of the PDV fault condition 353 and to recover the synchronization application based on the PDV 354 metrics. 356 5.2. PTP LSP recovery 358 The three main components are the 1588 Master, the 1588 Slave and the 359 packet network. A packet timing signal generated by the 1588 Master 360 is transported over the packet network so that the 1588 Slave can 361 generate a clock frequency traceable to the input timing signal 362 available at the 1588 Master. 364 Mpls Network 365 head-end +---------------------------+ tail-end 366 (the 1588 Master)| primary PTP LSP |(the 1588 Slave) 367 +------| = = = = = = = = = = = = =>|-------+ 368 ======> | | | |======> 369 +------| = = = = = = = = = = = = =>|-------+ 370 | backup PTP LSP | 371 +---------------------------+ 372 Figure 2. PTP LSP recovery 374 In this case, there is only a 1588 Master to which the 1588 Slaves 375 are synchronized. It is REQUIRED to set up the primary and the 376 backup PTP LSP, because the PDV metrics is critical to the 377 synchronization performance. This document defines the following 378 functions: 380 1) The head-end node sets up dedicated bidirectional 1+1 path 381 protection which contain the primary and the backup PTP LSP; 383 2) The head-end node and the tail-end all send the Announce message 384 to each other and to establish the synchronization hierarchy. 386 3) The 1588 Master initiates simultaneously the synchronization 387 message exchange over the primary and the backup PTP LSPs. The 1588 388 Slave obtains the timestamp t1,t2,t3 and t4 which is used for PDV 389 measurement. 391 4) The 1588 Slave compares the PDV performance of primary path with 392 the PDV performance of backup path to determine which PTP LSP should 393 be selected, and the 1588 Slave synchronizes to the PTP LSP which the 394 PDV performance is better. 396 5) If the PDV perfermance of primary path is exceed the PDV network 397 limits, then the PTP LSP will switch to the backup path and 398 synchronize to it. At the same time, the 1588 Slave sends a notify 399 message to the 1588 Master to reoptimize the primary PTP LSP. 401 5.3. PTP Master recovery 403 In traditional synchronization networks, timing availability is 404 enhanced by the use of timing protection where by the timing to a 405 1588 Slave clock (e.g. SEC, or EEC) may be provided over one or more 406 alternative network paths. In the case of the packet based timing 407 architecture, the 1588 Slave may have visibility to two or more 1588 408 Masters. 1588 Master protection is stated in In ITU-T G.8265 section 409 7.2.1. 411 Mpls Network 412 head-end1 +-------------------------------+ 413 (the 1588 Master1) | | 414 +------| | tail-end 415 ======> | | PTP LSP1 |(the 1588 Slave) 416 +------| = = = = = = = = == = = = = => |-------+ 417 head-end2 | | |======> 418 (the 1588 Master2) | PTP LSP2 | | 419 +------| = = = = = = = = == = = = = = >|-------+ 420 ======>| | | 421 +------| | 422 +-------------------------------+ 423 Figure 3. PTP Master recovery 425 In this case, there are two 1588 Masters to which the 1588 Slave is 426 synchronized. The following details 1588 Master recovery process: 428 1) The primary Master and the backup Master are set up respectively a 429 bidirectional PTP LSP to the 1588 Slave. 431 2) The 1588 Masters and the 1588 Slave all send the Announce message 432 to each other and to establish the synchronization hierarchy. 434 3) The primary Master and the backup Master initiate respectively the 435 synchronization message exchange over the PTP LSP. The 1588 Slave 436 obtains the timestamp t1,t2,t3 and t4 which is used for PDV 437 measurement from the primary Master and the backup Master. 439 4) The 1588 Slave compares the PDV performance of the primary Master 440 with the PDV performance of the backup Master to determine which 1588 441 Master should be selected. According to ITU-T G.8265.1 6.7.3 "Master 442 selection process", the following parameters contribute to the 1588 443 Master selection process: (1)Quality Level(QL), (2)Packet Timing 444 Signal Fail(PTSF-lossSync,PTSF-lossAnnounce,PTSF-unusable) and 445 Priority. PTSF-unusable means that the PTP packet timing signal is 446 not usable for the 1588 Slave to achieve the performance target (e.g. 447 violates the 1588 Slave input tolerance because of excessive PDV 448 noise), then a PTSF-unusable associated to this 1588 Master must 449 occur. 451 6. Protocal extensions 453 6.1. IGP extensions 455 MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and 456 IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE) 457 link information used for constraint-based routing. Indeed, it is 458 useful to advertise data plane TE router link capabilities, such as 459 the capability for a router to be reserving-bandwidth. This 460 capability MUST then be taken into account during path computation to 461 prefer links that advertise themselves as reserving- bandwidth, so 462 that the PTP LSPs can be properly handled. For this purpose, the 463 following sections specify extensions to OSPF and IS-IS in order to 464 advertise reserving-bandwidth capabilities of a link. 466 1. reserving-bandwidth Capability for OSPF OSPF uses the Link TLV 467 (Type 2) that is itself carried within either the Traffic Engineering 468 LSA specified in [RFC3630] or the OSPFv3 Intra-Area-TE LSA (function 469 code 10) defined in [RFC5329] to advertise the TE related information 470 for the locally attached router links. For an LSA Type 10, one LSA 471 can contain one Link TLV information for a single link. This 472 extension defines a new reserving-bandwidth capability sub-TLV that 473 can be carried as part of the Link TLV. 475 The reserving-bandwidth capability sub-TLV is OPTIONAL and MUST NOT 476 appear more than once within the Link TLV. If a second instance of 477 the reserving-bandwidth capability sub-TLV is present, the receiving 478 system MUST only process the first instance of the sub-TLV. It is 479 defined as follows: 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Type | Length | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Flags | 487 +-+-+-+-+-+-+-+-+ 489 Figure 4: reserving-bandwidth Capability TLV 491 Where: 493 Type, 16 bits: reserving-bandwidth Capability TLV where the value is 494 TBD; 496 Length, 16 bits: Gives the length of the flags field in octets, and 497 is currently set to 1; 499 Flags, 8 bits: The bits are defined least-significant-bit (LSB) 500 first, so bit 7 is the least significant bit of the flags octet. 502 0 1 2 3 4 5 6 7 503 +-+-+-+-+-+-+-+-+ 504 | Reserved |R| 505 +-+-+-+-+-+-+-+-+ 506 Figure 5: Flags Format 508 Reserving bandwidth (R) field, 1 bit: Setting the R bit to 1 509 indicates that the node is capable of supporting reserving-bandwidth 510 capability. When this is set to 0, it means that this node cannot 511 reserve bandwidth for PTP LSP. 513 Reserved, 7 bits: Reserved for future use. The reserved bits must be 514 ignored by the receiver. The reserving-bandwidth Capability sub-TLV 515 is applicable to both OSPFv2 and OSPFv3. 2. reserving-bandwidth 516 Capability for IS-IS The IS-IS Traffic Engineering [RFC3784] defines 517 the intra-area traffic engineering enhancements and uses the Extended 518 IS Reachability TLV (Type 22) [RFC5305] to carry the per link TE- 519 related information. This extension defines a new reserving- 520 bandwidth capability sub-TLV that can be carried as part of the 521 Extended IS Reachability TLV. The reserving-bandwidth capability 522 sub-TLV is OPTIONAL and MUST NOT appear more than once within the 523 Extended IS Reachability TLV or the Multi-Topology (MT) Intermediate 524 Systems TLV (type 222) specified in [RFC5120]. If a second instance 525 of the reserving-bandwidth capability sub-TLV is present, the 526 receiving system MUST only process the first instance of the sub-TLV. 527 The format of the IS-IS reserving-bandwidth sub-TLV is identical to 528 the TLV format used by the Traffic Engineering Extensions to IS-IS 529 [RFC3784]. That is, the TLV is comprised of 1 octet for the type, 1 530 octet specifying the TLV length, and a value field. The Length field 531 defines the length of the value portion in octets. 533 0 1 2 534 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Type | Length | Flags | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 Figure 6: reserving-bandwidth Capability sub-TLV 540 Where: 542 Type, 8 bits: reserving-bandwidth Capability sub-TLV where the value 543 is TBD; 545 Length, 8 bits: Gives the length of the flags field in octets, and is 546 currently set to 1 Flags, 8 bits: The bits are defined least- 547 significant-bit (LSB) first, so bit 7 is the least significant bit of 548 the flags octet. 550 0 1 2 3 4 5 6 7 551 +-+-+-+-+-+-+-+-+ 552 | Reserved |R| 553 +-+-+-+-+-+-+-+-+ 554 Figure 7: Flags Format 556 Reserving bandwidth (R) field, 1 bit: Setting the R bit to 1 557 indicates that the node is capable of supporting reserving-bandwidth 558 capability. When this is set to 0, it means that this node cannot 559 reserve bandwidth for PTP LSP. 561 Reserved, 7 bits: Reserved for future use. The reserved bits must be 562 ignored by the receiver. 564 6.2. RSVP-TE extensions 566 A new flag in the SESSION ATTRIBUTE object and new Error Value sub- 567 codes in the ERROR SPEC object are proposed in this document. 569 1.PTP LSP Congestion Detection Request The following new flag of the 570 SESSION_ATTRIBUTE object (C-Type 1 and 7) is defined: Path congestion 571 detection request: 0x40 This flag indicates that a PTP LSP congestion 572 detection (of the current PTP LSP in use) is requested. 574 2.New Error Value Sub-Codes As defined in [RFC3209], the Error Code 575 25 in the ERROR SPEC object corresponds to a Notify Error. This 576 document adds a new Error Value sub-codes: 578 9,PDV degradation. 580 7. Other considerations 582 Network congestion may also led to PTP packets being dropped. So, in 583 addition to the PDV, the statistics for packet loss rate SHOULD be 584 collected by the 1588 Slave. When packet loss rate has going up a 585 certain threshold, the 1588 Slave send a notify message to the 1588 586 master that decides to reoptimize the PTP LSP or not. 588 8. Security Considerations 590 An experimental security protocol is defined in [IEEE]. The PTP 591 security extension and protocol provides group source authentication, 592 message integrity, and replay attack protection for PTP messages. 594 9. Acknowledgements 596 The authors would like to thank Li He, Liang Xia, Lizhong Jin,Zhitao 597 Fu,Weilian Jiang and other members for their suggestions and helpful 598 comments during the discussions of this document. 600 10. IANA Considerations 602 10.1. IANA Considerations for OSPF 604 IANA has defined a sub-registry for the sub-TLVs carried in an OSPF 605 TE Link TLV (type 2). IANA is requested to assign a new sub-TLV 606 codepoint for the reserving-bandwidth capability sub-TLV carried 607 within the Router Link TLV. 609 Value Sub-TLV References 610 ------ ------------------------------- ---------- 611 TBD reserving-bandwidth node sub-TLV (this document) 613 10.2. IANA Considerations for IS-IS 615 IANA has defined a sub-registry for the sub-TLVs carried in the IS-IS 616 Extended IS Reacability TLV. IANA is requested to assign a new. sub- 617 TLV code-point for the reserving-bandwidth capability sub-TLV carried 618 within the Extended IS Reacability TLV. 620 Value Sub-TLV References 621 ----- ------------------------------- ---------- 622 TBD reserving-bandwidth node sub-TLV (this document) 624 10.3. IANA Considerations for RSVP 626 IANA assigned three new error sub-code values for the RSVP PathErr 627 Notify message (Error code=25): 9, PDV degradation. 629 11. References 631 11.1. Normative References 633 [I-D.ietf-tictoc-1588overmpls] 634 S. Davari,A. Oren,M. Bhatia,P. Roberts,L. Montini, 635 "Transporting PTP messages (1588) over MPLS Networks", 636 draft-ietf-tictoc-1588overmpls-02 , October 2011. 638 [IEEE] "IEEE 1588-2008, "IEEE Standard for a Precision Clock 639 Synchronization Protocol for Networked Measurement and 640 Control Systems", , 2008. 642 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 643 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 644 Tunnels", RFC 3209, December 2001. 646 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 647 Edge (PWE3) Architecture", RFC 3985, March 2005. 649 [RFC4736] Vasseur, JP., Ikejiri, Y., and R. Zhang, "Reoptimization 650 of Multiprotocol Label Switching (MPLS) Traffic 651 Engineering (TE) Loosely Routed Label Switched Path 652 (LSP)", RFC 4736, November 2006. 654 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 655 (BFD)", RFC 5880, June 2010. 657 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 658 "Bidirectional Forwarding Detection (BFD) for MPLS Label 659 Switched Paths (LSPs)", RFC 5884, June 2010. 661 11.2. Informative References 663 [ISO] "ISO/IEC 10589:1992, "Intermediate system to Intermediate 664 system routeing information exchange protocol for use in 665 conjunction with the Protocol for providing the 666 Connectionless-mode Network Service (ISO 8473)", , 1992. 668 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 669 dual environments", RFC 1195, December 1990. 671 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 673 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 674 (TE) Extensions to OSPF Version 2", RFC 3630, 675 September 2003. 677 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 678 System (IS-IS) Extensions for Traffic Engineering (TE)", 679 RFC 3784, June 2004. 681 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 682 Shaffer, "Extensions to OSPF for Advertising Optional 683 Router Capabilities", RFC 4970, July 2007. 685 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 686 System to Intermediate System (IS-IS) Extensions for 687 Advertising Router Information", RFC 4971, July 2007. 689 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 690 Topology (MT) Routing in Intermediate System to 691 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 693 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 694 Engineering", RFC 5305, October 2008. 696 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, 697 "Traffic Engineering Extensions to OSPF Version 3", 698 RFC 5329, September 2008. 700 Authors' Addresses 702 Junhui Zhang 703 ZTE Corporation 704 No.50 Ruanjian Ave,Yuhuatai District 705 Nanjing 210012 706 P.R.China 708 Email: zhang.junhui1@zte.com.cn 709 URI: http://www.zte.com.cn/ 710 Liang Xia 711 ZTE Corporation 712 No.50 Ruanjian Ave,Yuhuatai District 713 Nanjing 210012 714 P.R.China 716 Email: xia.liang2@zte.com.cn 717 URI: http://www.zte.com.cn/