Network Working Group J. Zhang Internet-Draft L. Xia Intended status: Standards Track ZTE Corporation Expires: April 22, 2012 Oct 20, 2011 PDV-based PTP LSP Setup,Reoptimization and Recovery draft-zhang-tictoc-pdv-lsp-00 Abstract This document defines a mechanism for the setup,reoptimization and recovery of PTP LSP based on the PDV metrics between the 1588 Master and the 1588 Slave. When a PTP communication path goes through the third party networks (e.g. the MPLS networks), the PDV noise caused by the third party networks will have a significant impact on the synchronization performance. So, the PDV metrics should be considered in the setup of PTP LSP. In addition, when the PDV noise exceeds to a certain degree, it is necessary to notify the head-end LSR(i.e. the 1588 Master) to switch to the backup PTP LSP and to reoptimize the primary PTP LSP in order to improve the PTP reliability. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 22, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Zhang & Xia Expires April 22, 2012 [Page 1] Internet-Draft PDV-based PTP LSP Oct 2011 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. PTP LSP setup and reoptimization . . . . . . . . . . . . . . . 5 4.1. Advertisement of the capability of reserving bandwidth . . 6 4.2. PTP LSP setup . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Congestion detection . . . . . . . . . . . . . . . . . . . 7 4.4. PTP LSP reoptimization . . . . . . . . . . . . . . . . . . 7 5. PTP LSP recovery mechanisms . . . . . . . . . . . . . . . . . 8 5.1. PDV measurement and PDV network limits . . . . . . . . . . 8 5.2. PTP LSP recovery . . . . . . . . . . . . . . . . . . . . . 8 5.3. PTP Master recovery . . . . . . . . . . . . . . . . . . . 9 6. Protocal extensions . . . . . . . . . . . . . . . . . . . . . 11 6.1. IGP extensions . . . . . . . . . . . . . . . . . . . . . . 11 6.2. RSVP-TE extensions . . . . . . . . . . . . . . . . . . . . 13 7. Other considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10.1. IANA Considerations for OSPF . . . . . . . . . . . . . . . 14 10.2. IANA Considerations for IS-IS . . . . . . . . . . . . . . 14 10.3. IANA Considerations for RSVP . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Zhang & Xia Expires April 22, 2012 [Page 2] Internet-Draft PDV-based PTP LSP Oct 2011 1. Introduction There are many applications that need frequency or phase/time synchronization, and there is an emerging need to distribute highly accurate time and frequency information over IP and over MPLS packet switched networks (PSNs), especially with the development of the telecom network. [IEEE] defines PTP for clock and time synchronization. PTP version 2 contains three clock type, they are Ordinary Clock(OC), Boundary Clock(BC) and Transparent Clock(TC). Transparent Clocks modify a "correction field" (CF) within the synchronization messages to compensate for residence and propagation delays. So, Transparent Clock can eliminate the impact of the PDV noise. With the large-scale deployment of the MPLS networks and the 1588 networks, there is an increasing need to transport PTP messages over the MPLS networks. The MPLS networks could be a transit network between the 1588 Master and the 1588 Slave. But the PDV noise between the 1588 Master and the 1588 Slave may be excessive and therefore the 1588 Slave may not be able to properly recover the clock and time of day. Therefore, it is necessary to setup PTP LSP based on the PDV attributes, and when the PDV noise exceeds a certain degree, the 1588 Master will switch to the backup PTP LSP and reoptimize the primary PTP LSP. 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Terminology PTN: Packet Transport Network; 1588: The timing and synchronization as defined by IEEE 1588; PTP: The timing and synchronization protocol used by 1588; Master: The Source of 1588 Timing and clock. This will be a port in master state on a Grandmaster Clock or on a Boundary Clock; Slave: The Destination of 1588 Timing and clock that tries to follow the Master clock. This will be a port in slave state on a boundary clock or on a Slave-Only Ordinary Clock; Zhang & Xia Expires April 22, 2012 [Page 3] Internet-Draft PDV-based PTP LSP Oct 2011 OC: Ordinary Clock - a device with a single PTP port; TC: Transparent Clock, a time stamping method applied by intermediate nodes between Master and Slave; BC: Boundary Clock, is a node that recovers the Master clock via a Slave function and uses that clock as the Master for other Slaves; PDV: Packet Delay Variation; PTP LSP: An LSP dedicated to carry PTP messages; PDV PTP LSP: An PTP LSP based on the PDV attributes; ACR: Adaptive Clock Recovery; MBB: make-before-break; LSR: Label Switch Router; 3. Problem Statement With the development of telecom networks, there is an increasing need to transport PTP or CES over the third part networks(e.g. MPLS networks). Two main applications are addressed in ITU-T G.8261.1: (1) the distribution of a synchronization network clock signal via packet based method (e.g. using PTP); (2) the distribution of a service clock signal over a packet network according to the ACR method (e.g. clock recovery of CES using Adaptive Method). The packet networks are Ethernet, MPLS, T-MPLS or IP. For these applications, frequency synchronization information is carried via packets and is recovered according to adaptive clock recovery(ACR) method. But the third part networks(e.g. MPLS networks) may introduce the PDV noise which will have a significant impact on the ACR Methods and the synchronization performance. The method for transporting PTP messages (PDUs) over an MPLS network is defined in [I-D.ietf-tictoc-1588overmpls]. This document defines a "1588-aware LSR" that is able to identify 1588 timing flows carried over MPLS. Transparent Clock (TC) function requires a 1588-aware LSR in the middle of an LSP to properly handle the PTP messages. However, this specification does not mandate that all LSRs in path of a PTP LSP be 1588-aware, Non-1588-aware LSRs don't perform any TC processing. Therefore, these LSRs may introduce additional PDV Zhang & Xia Expires April 22, 2012 [Page 4] Internet-Draft PDV-based PTP LSP Oct 2011 noise, although the PTP messages are treated with the highest priority and Green for drop eligibility, because the other flows may use the same queue. Just as MPLS-TE setup a TE LSP based on TE metrics(e.g. bandwidth), it is necessary to setup a PTP LSP based-on the PDV metrics, and if the PDV noise between the 1588 Master and the 1588 Slave has deteriorated into a certain degree, then the 1588 Master switchs to the backup PTP LSP and reoptimizes the primary PTP LSP. So, it is useful for clock recovery algorithms to improve the performance of clock recovery. 4. PTP LSP setup and reoptimization The PDV noise introduced by the MPLS networks is critical for the clock recovery algorithm and the synchronization performance. The main factor caused the PDV noise is congestion in the network nodes. In order to minimize the PDV noise between the 1588 Master and the 1588 Slave, the 1588 Master SHOULD discover a PTP LSP along which the number of the Non-1588-aware LSRs is minimum. MPLS-TE support setting up TE-LSP based on the reserved bandwidth which can prevent TE-flow from congestion. But due to the complexity of implementation and the cost of HW, some of the network nodes don't support the capability of reserving bandwidth. In this case, congestion detection MUST be enabled on these nodes. If congestion occurred on one of these nodes, then the node MUST notify the 1588 Master(i.e. the head-end node ), therefore the 1588 Master is able to reoptimize the TE-LSP and to avoid the congested nodes so that the PDV noise between the 1588 Master and the 1588 Slave can be minimized. It is possible that after a PTP LSP has been established, a more efficient path for the PTP becomes available, perhaps because one or more new 1588aware links have been advertised or because some other services have been torn down causing resources in the network to be released. When a better path can be found for one of the previously computed paths, the node or component that originally requested the path can be notified. In order to take advantage of the new path, the ingress node must re-route the PTP onto the new path using the reoptimization technique(e.g. make-before-break). Zhang & Xia Expires April 22, 2012 [Page 5] Internet-Draft PDV-based PTP LSP Oct 2011 Mpls Network head-end +--------------------------------+ tail-end (the 1588 Master)| |(the 1588 Slave) +------| PTP LSP |-------+ ======> | | = = = = = = = = = = = = = = > | |======> +------| |-------+ | | +--------------------------------+ Figure 1. 1588 over MPLS Network 4.1. Advertisement of the capability of reserving bandwidth Due to the complexity of implement and the cost of HW, some of the network nodes don't support the capability of reserving bandwidth based on the LSP , so that these network nodes may introduce jitter(i.e. PDV). Just as the capability of 1588-aware which can compensate for residence time by updating the PTP packet Correction Field and eliminate the delay and jitter, it is useful to advertise data plane TE router link capabilities within the whole network, such as the capability of reserving bandwidth. This capability MUST then be taken into account during path computation to prefer links that advertise themselves as reserving bandwidth , so that the PTP LSPs can be properly handled. For this purpose, the following sections specify extensions to OSPF and IS-IS in order to advertise the capability of reserving bandwidth. 4.2. PTP LSP setup The Procedures for setting up LSP Tunnels are defined in [RFC3209]. To setup PTP LSP, more constraints information MUST be taken into account, for examples, 1588-aware, reserving bandwidth, and so on. . After all TE information were advertised by link state protocol(e.g. OSPF or IS-IS), the TE database at the head-end node contains all the links and their characteristics or attributes and includes 1588-aware and reserving bandwidth. From this MPLS TE database, path calculation (PCALC) or constrained SPF (CSPF) calculates the shortest route that still adheres to all the constraints from the head-end LSR(i.e. the 1588 Master) to the tail-end LSR(i.e. the 1588 Slave). Zhang & Xia Expires April 22, 2012 [Page 6] Internet-Draft PDV-based PTP LSP Oct 2011 4.3. Congestion detection Quality of service (QoS) has become popular the past few years. Few networks have unlimited bandwidth, so congestion is always a possibility in the network. QoS is a means to prioritize important traffic over less important traffic and make sure it is delivered. Congestion may happen at different points within a network node. Each congestion point represents a potential source of delay, jitter, and loss for traffic streams. If neither the capability of 1588-aware nor the capability of reserving bandwidth is supported at a node, then this node may introduce jitter(i.e. PDV), although the LSP tunnel is treated with the highest priority. So, after PTP LSP has been set up, the head-end node(i.e. the 1588 Master) MUST request those network nodes which support neither 1588- aware nor reserving bandwidth to enable congestion detection. When congestion occurs or disappears on the node, the node MUST send a notification message to the head-end node, so that the head-end node can reoptimizes the PTP LSP and sets up another new PTP LSP which doesn't pass through these congested network nodes. Because a PTP LSP is related to a special output port and a special priority, the data plane can detect congestion based on the output port and the corresponding queue. When congestion has occurred, the data plane will notify the control plane which will sends a notify message to the head-end. 4.4. PTP LSP reoptimization As mentioned above, it is possible that a more efficient path for the PTP becomes available, for example, the deployment of new 1588-aware LSRs,and so on. In order to improve the synchronization performance, the head-end MUST re-route the PTP onto the new path. It is assumed that the head-end node has received the congestion notifications from the congested nodes along the PTP LSP, and the PDV noise between the 1588 Master and the 1588 Slave exceeds a certain degree. At this time, the tail-end node(e.g. the 1588 Slave) MUST send a reoptimization notification message to the head-end node, the receipt of such of message will then trigger a reoptimization on the head-end node for the affected PTP LSP. Because the head-end node has learned about which network nodes are 1588-aware and which network nodes has occurred congestion, so it can reoptimize the affected PTP LSP and avoid those congested nodes.. There are several reoptimization triggers, including timer-based reoptimization ,event-driven reoptimization and operator-driven Zhang & Xia Expires April 22, 2012 [Page 7] Internet-Draft PDV-based PTP LSP Oct 2011 reoptimization. Note that reoptimization or recovery may also introduce the PDV. Therefore, PTP LSP reoptimization MUST be triggered by the PDV metrics. 5. PTP LSP recovery mechanisms One kind of network fault is packets arriving at a network node which the node has no forwarding information or incorrect forwarding information. This problem can be detected by the control information. Another kind of problem is the one in which the control plane information is correct but the data plane fails. In this case, LSP ping, LSP traceroute and Bidirectional Forwarding Detection (BFD) are tools that can detect problems in the MPLS control and data planes. The above network problems are all due to connection failure. But for the synchronization application(e.g. PTP), it is tolerant of an occasional missed message, duplicated message, or message that arrived out of order,which means that an occasional connection failure is insignificant to the synchronization performance. However, the PDV by the packet timing signal as it traverses the network from the 1588 Master to the 1588 Slave is critical to the synchronization performance. So, it is reasonable to recover the synchronization application based on the PDV metrics. 5.1. PDV measurement and PDV network limits ITU-T G.826x concerns frequency synchronization aspects in packet networks. In particular it specifies the Hypothetical Reference Model and the PDV network limits applicable when frequency synchronization is carried via packets and is recovered according to adaptive clock recovery method as defined in G.8261 and G.8260. It specifies the minimum equipment tolerance to packet delay variation in terms of the metrics defined in ITU-T G.8260 at boundary of these packet networks. PDV measurement is at the input of the 1588 Slave. If the PDV exceed the network limits, then the 1588 Slave MUST send native indications over the PTP LSP to notify the 1588 Master of the PDV fault condition and to recover the synchronization application based on the PDV metrics. 5.2. PTP LSP recovery The three main components are the 1588 Master, the 1588 Slave and the packet network. A packet timing signal generated by the 1588 Master is transported over the packet network so that the 1588 Slave can Zhang & Xia Expires April 22, 2012 [Page 8] Internet-Draft PDV-based PTP LSP Oct 2011 generate a clock frequency traceable to the input timing signal available at the 1588 Master. Mpls Network head-end +---------------------------+ tail-end (the 1588 Master)| primary PTP LSP |(the 1588 Slave) +------| = = = = = = = = = = = = =>|-------+ ======> | | | |======> +------| = = = = = = = = = = = = =>|-------+ | backup PTP LSP | +---------------------------+ Figure 2. PTP LSP recovery In this case, there is only a 1588 Master to which the 1588 Slaves are synchronized. It is REQUIRED to set up the primary and the backup PTP LSP, because the PDV metrics is critical to the synchronization performance. This document defines the following functions: 1) The head-end node sets up dedicated bidirectional 1+1 path protection which contain the primary and the backup PTP LSP; 2) The head-end node and the tail-end all send the Announce message to each other and to establish the synchronization hierarchy. 3) The 1588 Master initiates simultaneously the synchronization message exchange over the primary and the backup PTP LSPs. The 1588 Slave obtains the timestamp t1,t2,t3 and t4 which is used for PDV measurement. 4) The 1588 Slave compares the PDV performance of primary path with the PDV performance of backup path to determine which PTP LSP should be selected, and the 1588 Slave synchronizes to the PTP LSP which the PDV performance is better. 5) If the PDV perfermance of primary path is exceed the PDV network limits, then the PTP LSP will switch to the backup path and synchronize to it. At the same time, the 1588 Slave sends a notify message to the 1588 Master to reoptimize the primary PTP LSP. 5.3. PTP Master recovery In traditional synchronization networks, timing availability is enhanced by the use of timing protection where by the timing to a Zhang & Xia Expires April 22, 2012 [Page 9] Internet-Draft PDV-based PTP LSP Oct 2011 1588 Slave clock (e.g. SEC, or EEC) may be provided over one or more alternative network paths. In the case of the packet based timing architecture, the 1588 Slave may have visibility to two or more 1588 Masters. 1588 Master protection is stated in In ITU-T G.8265 section 7.2.1. Mpls Network head-end1 +-------------------------------+ (the 1588 Master1) | | +------| | tail-end ======> | | PTP LSP1 |(the 1588 Slave) +------| = = = = = = = = == = = = = => |-------+ head-end2 | | |======> (the 1588 Master2) | PTP LSP2 | | +------| = = = = = = = = == = = = = = >|-------+ ======>| | | +------| | +-------------------------------+ Figure 3. PTP Master recovery In this case, there are two 1588 Masters to which the 1588 Slave is synchronized. The following details 1588 Master recovery process: 1) The primary Master and the backup Master are set up respectively a bidirectional PTP LSP to the 1588 Slave. 2) The 1588 Masters and the 1588 Slave all send the Announce message to each other and to establish the synchronization hierarchy. 3) The primary Master and the backup Master initiate respectively the synchronization message exchange over the PTP LSP. The 1588 Slave obtains the timestamp t1,t2,t3 and t4 which is used for PDV measurement from the primary Master and the backup Master. 4) The 1588 Slave compares the PDV performance of the primary Master with the PDV performance of the backup Master to determine which 1588 Master should be selected. According to ITU-T G.8265.1 6.7.3 "Master selection process", the following parameters contribute to the 1588 Master selection process: (1)Quality Level(QL), (2)Packet Timing Signal Fail(PTSF-lossSync,PTSF-lossAnnounce,PTSF-unusable) and Priority. PTSF-unusable means that the PTP packet timing signal is not usable for the 1588 Slave to achieve the performance target (e.g. violates the 1588 Slave input tolerance because of excessive PDV noise), then a PTSF-unusable associated to this 1588 Master must occur. Zhang & Xia Expires April 22, 2012 [Page 10] Internet-Draft PDV-based PTP LSP Oct 2011 6. Protocal extensions 6.1. IGP extensions MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE) link information used for constraint-based routing. Indeed, it is useful to advertise data plane TE router link capabilities, such as the capability for a router to be reserving-bandwidth. This capability MUST then be taken into account during path computation to prefer links that advertise themselves as reserving- bandwidth, so that the PTP LSPs can be properly handled. For this purpose, the following sections specify extensions to OSPF and IS-IS in order to advertise reserving-bandwidth capabilities of a link. 1. reserving-bandwidth Capability for OSPF OSPF uses the Link TLV (Type 2) that is itself carried within either the Traffic Engineering LSA specified in [RFC3630] or the OSPFv3 Intra-Area-TE LSA (function code 10) defined in [RFC5329] to advertise the TE related information for the locally attached router links. For an LSA Type 10, one LSA can contain one Link TLV information for a single link. This extension defines a new reserving-bandwidth capability sub-TLV that can be carried as part of the Link TLV. The reserving-bandwidth capability sub-TLV is OPTIONAL and MUST NOT appear more than once within the Link TLV. If a second instance of the reserving-bandwidth capability sub-TLV is present, the receiving system MUST only process the first instance of the sub-TLV. It is defined as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | +-+-+-+-+-+-+-+-+ Figure 4: reserving-bandwidth Capability TLV Where: Type, 16 bits: reserving-bandwidth Capability TLV where the value is TBD; Length, 16 bits: Gives the length of the flags field in octets, and Zhang & Xia Expires April 22, 2012 [Page 11] Internet-Draft PDV-based PTP LSP Oct 2011 is currently set to 1; Flags, 8 bits: The bits are defined least-significant-bit (LSB) first, so bit 7 is the least significant bit of the flags octet. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Reserved |R| +-+-+-+-+-+-+-+-+ Figure 5: Flags Format Reserving bandwidth (R) field, 1 bit: Setting the R bit to 1 indicates that the node is capable of supporting reserving-bandwidth capability. When this is set to 0, it means that this node cannot reserve bandwidth for PTP LSP. Reserved, 7 bits: Reserved for future use. The reserved bits must be ignored by the receiver. The reserving-bandwidth Capability sub-TLV is applicable to both OSPFv2 and OSPFv3. 2. reserving-bandwidth Capability for IS-IS The IS-IS Traffic Engineering [RFC3784] defines the intra-area traffic engineering enhancements and uses the Extended IS Reachability TLV (Type 22) [RFC5305] to carry the per link TE- related information. This extension defines a new reserving- bandwidth capability sub-TLV that can be carried as part of the Extended IS Reachability TLV. The reserving-bandwidth capability sub-TLV is OPTIONAL and MUST NOT appear more than once within the Extended IS Reachability TLV or the Multi-Topology (MT) Intermediate Systems TLV (type 222) specified in [RFC5120]. If a second instance of the reserving-bandwidth capability sub-TLV is present, the receiving system MUST only process the first instance of the sub-TLV. The format of the IS-IS reserving-bandwidth sub-TLV is identical to the TLV format used by the Traffic Engineering Extensions to IS-IS [RFC3784]. That is, the TLV is comprised of 1 octet for the type, 1 octet specifying the TLV length, and a value field. The Length field defines the length of the value portion in octets. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: reserving-bandwidth Capability sub-TLV Where: Zhang & Xia Expires April 22, 2012 [Page 12] Internet-Draft PDV-based PTP LSP Oct 2011 Type, 8 bits: reserving-bandwidth Capability sub-TLV where the value is TBD; Length, 8 bits: Gives the length of the flags field in octets, and is currently set to 1 Flags, 8 bits: The bits are defined least- significant-bit (LSB) first, so bit 7 is the least significant bit of the flags octet. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Reserved |R| +-+-+-+-+-+-+-+-+ Figure 7: Flags Format Reserving bandwidth (R) field, 1 bit: Setting the R bit to 1 indicates that the node is capable of supporting reserving-bandwidth capability. When this is set to 0, it means that this node cannot reserve bandwidth for PTP LSP. Reserved, 7 bits: Reserved for future use. The reserved bits must be ignored by the receiver. 6.2. RSVP-TE extensions A new flag in the SESSION ATTRIBUTE object and new Error Value sub- codes in the ERROR SPEC object are proposed in this document. 1.PTP LSP Congestion Detection Request The following new flag of the SESSION_ATTRIBUTE object (C-Type 1 and 7) is defined: Path congestion detection request: 0x40 This flag indicates that a PTP LSP congestion detection (of the current PTP LSP in use) is requested. 2.New Error Value Sub-Codes As defined in [RFC3209], the Error Code 25 in the ERROR SPEC object corresponds to a Notify Error. This document adds a new Error Value sub-codes: 9,PDV degradation. 7. Other considerations Network congestion may also led to PTP packets being dropped. So, in addition to the PDV, the statistics for packet loss rate SHOULD be collected by the 1588 Slave. When packet loss rate has going up a Zhang & Xia Expires April 22, 2012 [Page 13] Internet-Draft PDV-based PTP LSP Oct 2011 certain threshold, the 1588 Slave send a notify message to the 1588 master that decides to reoptimize the PTP LSP or not. 8. Security Considerations An experimental security protocol is defined in [IEEE]. The PTP security extension and protocol provides group source authentication, message integrity, and replay attack protection for PTP messages. 9. Acknowledgements The authors would like to thank Li He, Liang Xia, Lizhong Jin,Zhitao Fu,Weilian Jiang and other members for their suggestions and helpful comments during the discussions of this document. 10. IANA Considerations 10.1. IANA Considerations for OSPF IANA has defined a sub-registry for the sub-TLVs carried in an OSPF TE Link TLV (type 2). IANA is requested to assign a new sub-TLV codepoint for the reserving-bandwidth capability sub-TLV carried within the Router Link TLV. Value Sub-TLV References ------ ------------------------------- ---------- TBD reserving-bandwidth node sub-TLV (this document) 10.2. IANA Considerations for IS-IS IANA has defined a sub-registry for the sub-TLVs carried in the IS-IS Extended IS Reacability TLV. IANA is requested to assign a new. sub- TLV code-point for the reserving-bandwidth capability sub-TLV carried within the Extended IS Reacability TLV. Value Sub-TLV References ----- ------------------------------- ---------- TBD reserving-bandwidth node sub-TLV (this document) Zhang & Xia Expires April 22, 2012 [Page 14] Internet-Draft PDV-based PTP LSP Oct 2011 10.3. IANA Considerations for RSVP IANA assigned three new error sub-code values for the RSVP PathErr Notify message (Error code=25): 9, PDV degradation. 11. References 11.1. Normative References [I-D.ietf-tictoc-1588overmpls] S. Davari,A. Oren,M. Bhatia,P. Roberts,L. Montini, "Transporting PTP messages (1588) over MPLS Networks", draft-ietf-tictoc-1588overmpls-02 , October 2011. [IEEE] "IEEE 1588-2008, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", , 2008. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture", RFC 3985, March 2005. [RFC4736] Vasseur, JP., Ikejiri, Y., and R. Zhang, "Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, November 2006. [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010. 11.2. Informative References [ISO] "ISO/IEC 10589:1992, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)", , 1992. [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. Zhang & Xia Expires April 22, 2012 [Page 15] Internet-Draft PDV-based PTP LSP Oct 2011 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004. [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 4970, July 2007. [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", RFC 4971, July 2007. [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008. [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008. [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, September 2008. Authors' Addresses Junhui Zhang ZTE Corporation No.50 Ruanjian Ave,Yuhuatai District Nanjing 210012 P.R.China Email: zhang.junhui1@zte.com.cn URI: http://www.zte.com.cn/ Zhang & Xia Expires April 22, 2012 [Page 16] Internet-Draft PDV-based PTP LSP Oct 2011 Liang Xia ZTE Corporation No.50 Ruanjian Ave,Yuhuatai District Nanjing 210012 P.R.China Email: xia.liang2@zte.com.cn URI: http://www.zte.com.cn/ Zhang & Xia Expires April 22, 2012 [Page 17]