Internet DRAFT - draft-zhang-tictoc-pdv-lsp
draft-zhang-tictoc-pdv-lsp
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]
