[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/