draft-ietf-tictoc-1588overmpls-03.txt   draft-ietf-tictoc-1588overmpls-04.txt 
TICTOC Working Group S. Davari TICTOC Working Group S. Davari
Internet-Draft A. Oren Internet-Draft A. Oren
Intended status: Standards Track Broadcom Corp. Intended status: Standards Track Broadcom Corp.
Expires: April 25, 2013 M. Bhatia Expires: August 27, 2013 M. Bhatia
P. Roberts P. Roberts
Alcatel-Lucent Alcatel-Lucent
L. Montini L. Montini
Cisco Systems Cisco Systems
October 22, 2012 February 23, 2013
Transporting Timing messages over MPLS Networks Transporting Timing messages over MPLS Networks
draft-ietf-tictoc-1588overmpls-03 draft-ietf-tictoc-1588overmpls-04
Abstract Abstract
This document defines the method for transporting Timing messages This document defines the method for transporting Timing messages
such as PTP and NTP over an MPLS network. The method allows for the such as PTP and NTP over an MPLS network. The method allows for the
easy identification of these PDUs at the port level to allow for port easy identification of these PDUs at the port level to allow for port
level processing of these PDUs in both LERs and LSRs. level processing of these PDUs in both LERs and LSRs.
The basic idea is to transport Timing messages inside dedicated MPLS The basic idea is to transport Timing messages inside dedicated MPLS
LSPs. These LSPs only carry timing messages and possibly Control and LSPs. These LSPs only carry timing messages and possibly Control and
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2013. This Internet-Draft will expire on August 27, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 22 skipping to change at page 3, line 22
4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . 10 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . 10
5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . . 12 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . . 12
6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . 13 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . 13
6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . . 13 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . . 13
6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . . 13 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . . 13
6.3. Other Timing Encapsulation methods . . . . . . . . . . . . 14 6.3. Other Timing Encapsulation methods . . . . . . . . . . . . 14
7. Timing Message Processing . . . . . . . . . . . . . . . . . . 15 7. Timing message Processing . . . . . . . . . . . . . . . . . . 15
8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 16 8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 16
9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12. OAM, Control and Management . . . . . . . . . . . . . . . . . 20 12. OAM, Control and Management . . . . . . . . . . . . . . . . . 20
skipping to change at page 6, line 26 skipping to change at page 6, line 26
defines several clock types: ordinary clocks, boundary clocks, end- defines several clock types: ordinary clocks, boundary clocks, end-
to-end transparent clocks, and peer-to-peer transparent clocks. to-end transparent clocks, and peer-to-peer transparent clocks.
Transparent clocks require intermediate nodes to update correction Transparent clocks require intermediate nodes to update correction
field inside PTP message that reflects the transit time in the node. field inside PTP message that reflects the transit time in the node.
[RFC5905] defines NTP messages for clock and time synchronization. [RFC5905] defines NTP messages for clock and time synchronization.
The PTP messages (PDUs) are transported over UDP/IP. This document The PTP messages (PDUs) are transported over UDP/IP. This document
defines mapping and transport of the NTP messages defined in defines mapping and transport of the NTP messages defined in
[RFC5905] over MPLS networks. [RFC5905] over MPLS networks.
One key attribute of all of these Timing messages is that the One key attribute of all of these Timing messages is that the Time
Timestamp processing should occur as close as possible to the actual stamp processing should occur as close as possible to the actual
transmission and reception at the physical port interface. This transmission and reception at the physical port interface. This
targets optimal time and/or frequency recovery by avoiding variable targets optimal time and/or frequency recovery by avoiding variable
delay introduced by queues internal to the clocks. delay introduced by queues internal to the clocks.
To facilitate the fast and efficient recognition of Timing messages To facilitate the fast and efficient recognition of Timing messages
at the port level when the Timing messages are carried over MPLS at the port level when the Timing messages are carried over MPLS
LSPs, this document defines the specific encapsulations that should LSPs, this document defines the specific encapsulations that should
be used. In addition, it can be expected that there will exist LSR/ be used. In addition, it can be expected that there will exist LSR/
LERs where only a subset of the physical ports will have the port- LERs where only a subset of the physical ports will have the port-
based Timing message processing capabilities. In order to ensure based Timing message processing capabilities. In order to ensure
that the LSPs carrying Timing packets always enter and exit ports that the LSPs carrying Timing packets always enter and exit ports
with this capability, routing extensions are defined to advertise with this capability, routing extensions are defined to advertise
this capability on a port basis and to allow for the establishment of this capability on a port basis and to allow for the establishment of
LSPs that only transit such ports. While this path establishment LSPs that only transit such ports. While this path establishment
restriction may be applied only at the LER Ingress and/or egress restriction may be applied only at the LER Ingress and/or egress
ports, it becomes more important when using transparent clock capable ports, it becomes more important when using transparent clock capable
LSRs in the path. LSRs in the path.
Port based Timing message processing involves Timing message Port based Timing message processing involves Timing message
recognition. Once the Timing messages are recognized they can be recognition. Once the Timing messages are recognized they can be
modified based on the reception or transmission timestamp. modified based on the reception or transmission Time-stamp.
This document provides two methods for transporting Timing messages This document provides two methods for transporting Timing messages
over MPLS. One is applicable to MPLS environment and the other one over MPLS. One is applicable to MPLS environment and the other one
is applicable to both MPLS and MPLS-TP environment. is applicable to both MPLS and MPLS-TP environment.
The solution involves transporting Timing messages over dedicated The solution involves transporting Timing messages over dedicated
LSPs called Timing LSPs. These LSPs carry Timing messages and MAY LSPs called Timing LSPs. These LSPs carry Timing messages and MAY
carry Management and control messages, but not data plane client carry Management and control messages, but not data plane client
traffic. Timing LSPs can be established statically or via signaling. traffic. Timing LSPs can be established statically or via signaling.
Extensions to control plane (OSPF, ISIS, etc) is required to enable Extensions to control plane (OSPF, ISIS, etc.) is required to enable
routers to distribute their Timing processing capabilities over MPLS routers to distribute their Timing processing capabilities over MPLS
to other routers. However such extensions are outside the scope of to other routers. However such extensions are outside the scope of
this document. this document.
Extensions to signaling protocols (e.g., RSVP-TE) are required for Extensions to signaling protocols (e.g., RSVP-TE) are required for
establishing PTP LSPs. However such extensions are outside the scope establishing PTP LSPs. However such extensions are outside the scope
of this document. of this document.
While the techniques included herein allow for the establishment of While the techniques included herein allow for the establishment of
paths optimized to include Time-stamping capable links, the paths optimized to include Time-stamping capable links, the
performance of the Slave clocks is outside the scope of this performance of the Slave clocks is outside the scope of this
document. document.
At the time of publishing this specification, Transparent Clocking
(TC) is only defined for PTP. Therefore at this time any part of
this specification that talks about Transparent Clocking applies only
to PTP.
2. Terminology 2. Terminology
1588: The timing and synchronization as defined by IEEE 1588. 1588: The timing and synchronization as defined by IEEE 1588.
NTP: The timing and synchronization protocol defined by IETF RFC-1305 NTP: The timing and synchronization protocol defined by IETF RFC-1305
and RFC-5905. and RFC-5905.
PTP: The timing and synchronization protocol used by 1588. PTP: The timing and synchronization protocol used by 1588.
Master Clock: The source of 1588 timing to a set of slave clocks. Master Clock: The source of 1588 timing to a set of slave clocks.
skipping to change at page 9, line 5 skipping to change at page 8, line 49
CW: Pseudowire Control Word CW: Pseudowire Control Word
LAG: Link Aggregation LAG: Link Aggregation
ECMP: Equal Cost Multipath ECMP: Equal Cost Multipath
CF: Correction Field, a field inside certain PTP messages (message CF: Correction Field, a field inside certain PTP messages (message
type 0-3)that holds the accumulative transit time inside intermediate type 0-3)that holds the accumulative transit time inside intermediate
switches switches
Timing messages: Timing Protocol messages that are exchanged between
routers in order to establish a synchronized clock.
3. Problem Statement 3. Problem Statement
[IEEE] has defined methods for transporting PTP messages over [IEEE] has defined methods for transporting PTP messages over
Ethernet and IP networks. [RFC5905] has defined the method of Ethernet and IP networks. [RFC5905] has defined the method of
transporting NTP messages over IP networks. There is a need to transporting NTP messages over IP networks. There is a need to
transport Timing messages over MPLS networks while supporting the transport Timing messages over MPLS networks while supporting the
Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (OC) Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (OC)
functionality in the LER and LSRs in the MPLS network. functionality in the LER and LSRs in the MPLS network.
There are multiple ways of transporting Timing over MPLS. However, There are multiple ways of transporting Timing over MPLS. However,
skipping to change at page 10, line 9 skipping to change at page 10, line 9
A generic method is defined in this document that does not require A generic method is defined in this document that does not require
deep packet inspection at line rate, and can deterministically deep packet inspection at line rate, and can deterministically
identify Timing messages. The generic method is applicable to MPLS identify Timing messages. The generic method is applicable to MPLS
and MPLS-TP networks. and MPLS-TP networks.
4. Timing over MPLS Architecture 4. Timing over MPLS Architecture
Timing messages are exchange between Timing ports on ordinary and Timing messages are exchange between Timing ports on ordinary and
boundary clocks. Boundary clocks terminate the Timing messages and boundary clocks. Boundary clocks terminate the Timing messages and
act as master for other boundary clocks or for slave clocks. act as master for other boundary clocks or for slave clocks. End-to-
Transparent clocks do not terminate the Timing messages but they do End Transparent clocks do not terminate the Timing messages but they
modify the contents of the Timing messages as they transit across the do modify the contents of the Timing messages as they transit across
transparent clock. the transparent clock.
Master/Slave clock could be integrated in the LERs. An example is Master/Slave clock could be integrated in the LERs. An example is
shown in Figure 1, where the LERs act as Ordinary Clock (OC) and are shown in Figure 1, where the LERs act as Ordinary Clock (OC) and are
the initiating/terminating point for Timing messages. The ingress the initiating/terminating point for Timing messages. The ingress
LER encapsulates the Timing messages in Timing LSP and the Egress LER LER encapsulates the Timing messages in Timing LSP and the Egress LER
terminates the Timing LSP. The LSRs act as Transparent Clock (TC) terminates the Timing LSP. The LSRs act as Transparent Clock (TC)
and just update the Timing field in the Timing messages. and just update the Timing field in the Timing messages.
+--------+ +-------+ +-------+ +-------+ +--------+ +--------+ +-------+ +-------+ +-------+ +--------+
|Switch, | | | | | | | |Switch, | |Switch, | | | | | | | |Switch, |
skipping to change at page 12, line 5 skipping to change at page 11, line 22
encapsulated in Timing LSPs. encapsulated in Timing LSPs.
+--------+ +-------+ +-------+ +-------+ +--------+ +--------+ +-------+ +-------+ +-------+ +--------+
|Switch, | | | | | | | |Switch, | |Switch, | | | | | | | |Switch, |
| Router |-----| LER |-----| LSR |-----| LER |-----| Router | | Router |-----| LER |-----| LSR |-----| LER |-----| Router |
|OC/TC/BC| | TC | | TC | | TC | |OC/TC/BC| |OC/TC/BC| | TC | | TC | | TC | |OC/TC/BC|
+--------+ +-------+ +-------+ +-------+ +--------+ +--------+ +-------+ +-------+ +-------+ +--------+
Figure (3) - Deployment example 3 of timing over MPLS/MPLS-TP network Figure (3) - Deployment example 3 of timing over MPLS/MPLS-TP network
An MPLS domain can serve multiple customers. This means that the
MPLS domain (maintained by a service provider) may provide timing
services to multiple customers, each having their own Timing domain.
Therefore LER BCs need to interact with multiple grandmasters, and
consequently multiple time references. Also, LER/LSR TCs MUST be
synchronized to the same master clock (which is the service provider
Master clock), which implies that they need to choose one master to
synchronize to.
The Timing over MPLS architecture assumes full mesh of Timing LSPs
between all LERs supporting this specification. It supports
Point-to- point (VPWS) and Multipoint (VPLS) services. This means
that a customer may purchase a Point-to-point Timing service between
two customer sites or a Multipoint Timing service between more than
two customer sites.
The Timing over MPLS architecture supports P2P or P2MP Timing LSPs.
This means that the Timing Multicast messages such as PTP Multicast
event messages can be transported over P2MP Timing LSP or be
replicated and transported over many P2P Timing LSPs.
Timing messages, that do not require Time stamping or Correction
Field update MAY be transported over Timing LSPs to simplify hardware
and software.
PTP Announce messages that determine the Timing LSP terminating point
behavior such as BC/OC/TC SHOULD be transported over the Timing LSP
to simplify hardware and software.
5. Dedicated LSPs for Timing messages 5. Dedicated LSPs for Timing messages
Many methods have been considered for identifying the Timing messages Many methods have been considered for identifying the Timing messages
when they are encapsulated in MPLS such as using GAL/ACH or a new when they are encapsulated in MPLS such as using GAL/ACH or a new
reserved label. These methods were not attractive since they either reserved label. These methods were not attractive since they either
required deep packet inspection at line rate in the intermediate LSRs required deep packet inspection at line rate in the intermediate LSRs
or they required use of a scarce new reserved label. Also one of the or they required use of a scarce new reserved label. Also one of the
goals was to reuse existing OAM mechanisms. goals was to reuse existing OAM mechanisms.
The method defined in this document can be used by LER and LSRs to The method defined in this document can be used by LER and LSRs to
skipping to change at page 15, line 5 skipping to change at page 15, line 5
6.3. Other Timing Encapsulation methods 6.3. Other Timing Encapsulation methods
In future other timing encapsulation methods may be introduced, such In future other timing encapsulation methods may be introduced, such
as a new shim header after the Bottom of Stack to carry the Timing as a new shim header after the Bottom of Stack to carry the Timing
information. Such new encapsulations are outside the scope of this information. Such new encapsulations are outside the scope of this
document. The control and signaling requirements in this document document. The control and signaling requirements in this document
are defined generically enough to accommodate any such new are defined generically enough to accommodate any such new
encapsulations. encapsulations.
7. Timing Message Processing 7. Timing message Processing
Each Timing protocol such as PTP and NTP, define their set of Timing Each Timing protocol such as PTP and NTP, define their set of Timing
messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP,
FOLLOW_UP, etc messages. FOLLOW_UP, etc messages.
Some of the Timing messages require time stamping at port level and Some of the Timing messages require time stamping at port level and
some dont. It is the job of the LER/LSR to parse the timing message some dont. It is the job of the LER/LSR to parse the timing message
and find out the type of the Timing message and decide whether and and find out the type of the Timing message and decide whether and
how to Time- stamp it (e.g., BC) or modify existing timestamp in it how to Time- stamp it (e.g., BC) or modify existing time-stamp in it
(e.g., TC). (e.g., TC).
For example the following PTP messages (called Event messages) For example the following PTP messages (called Event messages)
require time-stamping, while other Non-Event PTP messages do not need require time-stamping, while other Non-Event PTP messages do not need
time-stamping. time-stamping.
o Announce
o SYNC o SYNC
o DELAY_REQ (Delay Request) o DELAY_REQ (Delay Request)
o PDELAY_REQ (Peer Delay Request) o PDELAY_REQ (Peer Delay Request)
o PDELAY_RESP (Peer Delay Response) o PDELAY_RESP (Peer Delay Response)
SYNC and DELAY_REQ are exchanged between Master Clock and Slave Clock SYNC and DELAY_REQ are exchanged between Master Clock and Slave Clock
and MUST be transported over PTP LSPs. PDELAY_REQ and PDELAY_RESP and MUST be transported over PTP LSPs. PDELAY_REQ and PDELAY_RESP
are exchanged between adjacent PTP clocks (i.e. Master, Slave, are exchanged between adjacent PTP clocks (i.e. Master, Slave,
Boundary, or Transparent) and MAY be transported over single hop PTP Boundary, or Transparent) and SHOULD be transported over single hop
LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP, PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP,
DELAY_RESP, and PDELAY_RESP_FOLLOW_UP messages must also be DELAY_RESP, and PDELAY_RESP_FOLLOW_UP messages MUST also be
transported over the PTP LSPs. transported over the PTP LSPs.
For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be
transported over two PTP LSPs that are in opposite directions. These transported over two PTP LSPs that are in opposite directions. These
PTP LSPs, which are in opposite directions MUST be congruent and co- PTP LSPs, which are in opposite directions MUST be congruent and co-
routed. Alternatively, a single bidirectional co-routed LSP can be routed. Alternatively, a single bidirectional co-routed LSP can be
used. used.
Except as indicated above for the two-step PTP clocks, Non-Event PTP Except as indicated above for the two-step PTP clocks, Non-Event PTP
message types do not need to be processed by intermediate routers. message types do not need to be processed by intermediate routers.
skipping to change at page 20, line 7 skipping to change at page 20, line 7
11. Entropy 11. Entropy
To ensure all Timing messages in a Timing LSP take the same path, To ensure all Timing messages in a Timing LSP take the same path,
Entropy MUST NOT be used for the Timing LSP [mpls-entropy] and Entropy MUST NOT be used for the Timing LSP [mpls-entropy] and
Entropy MSUT NOT be used for the PWs that are carried inside Timing Entropy MSUT NOT be used for the PWs that are carried inside Timing
LSP [RFC6391]. LSP [RFC6391].
12. OAM, Control and Management 12. OAM, Control and Management
IIn order to manage Timing LSPs and their encapsulated PWs, they MUST In order to monitor Timing LSPs and their encapsulated PWs, they MUST
be able to carry OAM and management messages. These management be able to carry OAM and management messages. These management
messages MUST be differentiated from Timing messages via already messages MUST be differentiated from Timing messages via already
defined IETF methods. defined IETF methods.
For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY run For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY run
over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These
Management protocols can easily be identified by the UDP Destination Management protocols can easily be identified by the UDP Destination
Port number or by GAL/ACH respectively. Port number or by GAL/ACH respectively.
Also BFD, LSP-Ping and other management messages MAY run over the PWs Also BFD, LSP-Ping and other management messages MAY run over the PWs
skipping to change at page 22, line 7 skipping to change at page 22, line 7
critical and must be treated with the highest priority. Therefore critical and must be treated with the highest priority. Therefore
Timing over MPLS messages must be treated with the highest priority Timing over MPLS messages must be treated with the highest priority
in the routers. This can be achieved by proper setup of Timing LSPs. in the routers. This can be achieved by proper setup of Timing LSPs.
It is recommended that the Timing LSPs are setup or configured It is recommended that the Timing LSPs are setup or configured
properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC2697] properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC2697]
for drop eligibility. for drop eligibility.
14. FCS Recalculation 14. FCS Recalculation
When timestamp generation and timing packet adjustment is performed When time-stamp generation and timing packet adjustment is performed
near the physical port hardware, the process MUST include near the physical port hardware, the process MUST include
recalculation of the Ethernet FCS. Also FCS retention for the recalculation of the Ethernet FCS. Also FCS retention for the
payload Ethernet described in [RFC4720] MUST NOT be used. payload Ethernet described in [RFC4720] MUST NOT be used.
15. UDP Checksum Correction 15. UDP Checksum Correction
For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum
is optional when used for IPv4 encapsulation and mandatory in case of may be required as per UDP transport standards.
IPv6.
When UDP checksum is used, each Timing-aware LER/LSR must either When UDP checksum is used, each Timing-aware LER/LSR must either
incrementally update the UDP checksum after Time stamping or incrementally update the UDP checksum after Time stamping or
Correction Field update or verify the UDP checksum on reception from Correction Field update or verify the UDP checksum on reception from
upstream and recalculate the checksum completely on transmission to upstream and recalculate the checksum completely on transmission to
downstream node after Time stamping or Correction Field update. downstream node after Time stamping or Correction Field update.
16. Routing extensions for Timing-aware Routers 16. Routing extensions for Timing-aware Routers
MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and
IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE) IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE)
link information used for constraint-based routing. link information used for constraint-based routing.
Indeed, it is useful to advertise data plane TE router link Indeed, it is useful to advertise data plane TE router link
capabilities, such as the capability for a router to be Timing-aware. capabilities, such as the capability for a router to be Timing-aware.
This capability MUST then be taken into account during path This capability MUST then be taken into account during path
computation to prefer or even require links that advertise themselves computation to prefer or even require links that advertise themselves
as Timing-aware. In this way the path can ensure the entry and exit as Timing-aware. In this way the path can ensure the entry and exit
points into the LERs and, if desired, the links into the LSRs are points into the LERs and, if desired, the links into the LSRs are
able to perform port based timestamping thus minimizing their impact able to perform port based time-stamping thus minimizing their impact
on the performance of the slave clock. on the performance of the slave clock.
extensions are required to OSPF and IS-IS in order to advertise extensions are required to OSPF and IS-IS in order to advertise
Timing-aware capabilities of a link. Such extensions are outside the Timing-aware capabilities of a link. Such extensions are outside the
scope of this document; however such extension SHOULD be able to scope of this document; however such extension SHOULD be able to
signal the following information per Router Link: signal the following information per Router Link:
o Capable of processing PTP, NTP or other Timing flows o Capable of processing PTP, NTP or other Timing flows
o Capable of performing Transparent Clock operation o Capable of performing Transparent Clock operation
skipping to change at page 25, line 15 skipping to change at page 25, line 15
17. Signaling Extensions for Creating Timing LSPs 17. Signaling Extensions for Creating Timing LSPs
RSVP-TE signaling MAY be used to setup the timing LSPs. When RSVP-TE RSVP-TE signaling MAY be used to setup the timing LSPs. When RSVP-TE
is used to setup Timing LSPs, some information that indicates that is used to setup Timing LSPs, some information that indicates that
the LSP is carrying Timing flows MUST be included in the new the LSP is carrying Timing flows MUST be included in the new
Extensions to RSVP-TE: Extensions to RSVP-TE:
The following information MAY also be included in the new Extensions The following information MAY also be included in the new Extensions
to RSVP-TE: to RSVP-TE:
o Offset from Bottom of Stack (BoS) to the start of the Timestamp o Offset from Bottom of Stack (BoS) to the start of the Time-stamp
field field
o Number of VLANs in case of PW encapsulation o Number of VLANs in case of PW encapsulation
o Timestamp field Type o Timestamp field Type
* Correction Field, Timestamp * Correction Field, Timestamp
o Timestamp Field format o Timestamp Field format
* 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit
NTP, etc. NTP, etc.
Note that in case the above optional information is signaled with Note that in case the above optional information is signaled with
RSVP-TE for a Timing LSP, all the Timing packets carried in that LSP RSVP-TE for a Timing LSP, all the Timing packets carried in that LSP
must have the same signaled characteristics. For example if must have the same signaled characteristics. For example if
Timestamp format is signaled as 64-bit PTPv1, then all Timing packets Timestamp format is signaled as 64-bit PTPv1, then all Timing packets
must use 64-bit PTPv1 timestamp. must use 64-bit PTPv1 time-stamp.
18. Behavior of LER/LSR 18. Behavior of LER/LSR
Timing-capable/aware LERs and LSRs are routers that have one or more Timing-capable/aware LERs and LSRs are routers that have one or more
interfaces that can perform Timing operations (OC/BC/TC) on Timing interfaces that can perform Timing operations (OC/BC/TC) on Timing
packets and are configured to do so. Timing-capable/aware LERs and packets and are configured to do so. Timing-capable/aware LERs and
LSRs can advertise their Timing-capability per-interface via control LSRs can advertise their Timing-capability per-interface via control
plane such as OSPF or IS-IS. The Timing-capable/aware LERs can then plane such as OSPF or IS-IS. The Timing-capable/aware LERs can then
signals Timing LSPs via RSVP-TE signaling. Alternatively the Timing signals Timing LSPs via RSVP-TE signaling. Alternatively the Timing
capability of LER and LSRs may be configured in a centralized capability of LER and LSRs may be configured in a centralized
skipping to change at page 28, line 7 skipping to change at page 28, line 7
be Timing- capable/aware. be Timing- capable/aware.
Non-Timing-capable/aware LSRs just switch the packets encapsulated in Non-Timing-capable/aware LSRs just switch the packets encapsulated in
Timing LSPs and dont perform any Timing operation (TC). However as Timing LSPs and dont perform any Timing operation (TC). However as
explained in QoS section the Timing8 over MPLS packets MUST be still explained in QoS section the Timing8 over MPLS packets MUST be still
be treated with the highest priority based on their Traffic Class be treated with the highest priority based on their Traffic Class
(TC) marking. (TC) marking.
19. Other considerations 19. Other considerations
[IEEE] Tdefines an optional peer-to-peer Transparent clocking that [IEEE] defines an optional peer-to-peer Transparent clocking that
requires peer delay measurement between two adjacent Timing-capable/ requires peer delay measurement between two adjacent Timing-capable/
ware routers/switches. Peer delay measurement messages need to be aware routers/switches. Peer delay measurement messages need to be
time stamped and terminated by the Timing-capable/aware routers/ time stamped and terminated by the Timing-capable/aware routers/
switches. This means that two adjacent LSRs may be engaged in a peer switches. This means that two adjacent LSRs may be engaged in a peer
delay measurement. Such peer delay measurement messages SHALL NOT delay measurement.
use the Timing LSP that runs between two LERs. For transporting such
peer delay measurement messages there are two options. Either a For transporting such peer delay measurement messages a single-hop
single-hop LSP needs to be created between the two adjacent LSRs LSP SHOULD to be created between the two adjacent LSRs engaged in
engaged in peer delay measurement to carry peer delay measurement peer delay measurement to carry peer delay measurement messages.
messages, or other methods such as PTP transport over Ethernet may be Other methods such as PTP transport over Ethernet MAY be used for
used for transporting peer delay measurement messages if the link transporting peer delay measurement messages if the link between the
between the two routers is Ethernet. two routers is Ethernet.
In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/ ware
routers/switches MUST maintain a list of all the neighbors it needs
to send a PDelay_Req to, where each neighbor corresponds to a timing
LSP.
The use of Explicit Null Label (Label= 0 or 2) is acceptable as long The use of Explicit Null Label (Label= 0 or 2) is acceptable as long
as either the Explicit Null label is the bottom of stack label as either the Explicit Null label is the bottom of stack label
(applicable only to UDP/IP encapsulation) or the label below the (applicable only to UDP/IP encapsulation) or the label below the
Explicit Null label is a PTP label. Explicit Null label is a PTP label.
20. Security Considerations 20. Security Considerations
MPLS PW security considerations in general are discussed in [RFC3985] MPLS PW security considerations in general are discussed in [RFC3985]
and [RFC4447],and those considerations also apply to this document. and [RFC4447],and those considerations also apply to this document.
An experimental security protocol is defined in [IEEE].The PTP An experimental security protocol is defined in [IEEE].The PTP
security extension and protocol provides group source authentication, security extension and protocol provides group source authentication,
message integrity, and replay attack protection for PTP messages. message integrity, and replay attack protection for PTP messages.
When the MPLS network (provider network) serves multiple customers,
it is important to maintain and process each customers clock and
Timing messages separately from other customers to ensure there is no
cross- customer effect. For example if an LER BC is synchronized to
a specific grandmaster, belonging to customer A, then the LER MUST
use that BC clock only for customer A to ensure that customer A
cannot attack other customers by manipulating its time.
Timing messages (as opposed to regular customer data) SHOULD not be
encrypted or authenticated on an end-to-end basis. Alternatively,
authentication/integrity verification mechanism can be used by a
shared secret between the customer and provider nodes.
21. Applicability Statement 21. Applicability Statement
The Timing over MPLS transport methods described in this document The Timing over MPLS transport methods described in this document
apply to the following network Elements: apply to the following network Elements:
o An LER receives IP or Ethernet Encapsulated Timing messages from a o An LER receives IP or Ethernet Encapsulated Timing messages from a
non-MPLS interface and forwards them as MPLS encapsulated Timing non-MPLS interface and forwards them as MPLS encapsulated Timing
messages over Timing LSP, while performing Transparent Clock messages over Timing LSP, while performing Transparent Clock
functionality functionality
 End of changes. 27 change blocks. 
38 lines changed or deleted 90 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/