draft-ietf-tictoc-1588overmpls-06.txt   draft-ietf-tictoc-1588overmpls-07.txt 
TICTOC Working Group S. Davari TICTOC Working Group S. Davari
Internet-Draft A. Oren Internet-Draft A. Oren
Intended status: Experimental Broadcom Corp. Intended status: Experimental Broadcom Corp.
Expires: October 30, 2014 M. Bhatia Expires: April 18, 2016 M. Bhatia
P. Roberts P. Roberts
Alcatel-Lucent Alcatel-Lucent
L. Montini L. Montini
Cisco Systems Cisco Systems
April 28, 2014 October 16, 2015
Transporting Timing messages over MPLS Networks Transporting Timing messages over MPLS Networks
draft-ietf-tictoc-1588overmpls-06 draft-ietf-tictoc-1588overmpls-07
Abstract Abstract
This document defines the method for transporting Timing messages This document defines a method for transporting timing messages, such
such as PTP and NTP over an MPLS network. The method allows for the as Precision Time Protocol (PTP) or Network Time Protocol (NTP), over
easy identification of these PDUs at the port level to allow for port a Multiprotocol Label Switched (MPLS) network. The method
level processing of these PDUs in both LERs and LSRs. facilitates efficient recognition of timing packets to enable their
port level processing in both Label Edge Routers (LERs) and Label
Switched Routers (LSRs).
The basic idea is to transport Timing messages inside dedicated MPLS The basic mechanism is to transport timing messages inside "Timing
LSPs. These LSPs only carry Timing messages and possibly Control and LSPs", which are dedicated MPLS Label Switched Paths (LSPs) that
Management packets, but they do not carry customer traffic. carry only timing, and possibly related Operations, Administration
and Maintenance (OAM) or management packets, but do not carry
customer traffic.
Two methods for transporting Timing messages over MPLS are defined. Two encapsulations methods are defined. The first transports UDP/IP
The first method is to transport Timing messages directly over the encapsulated timing messages directly over the dedicated LSP. The
dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for second transports Ethernet encapsuled timing messages inside an
MPLS networks. The second method is to transport Timing messages Ethernet pseudowire.
inside a PW via Ethernet encapsulation.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 18, 2016.
This Internet-Draft will expire on October 30, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . 7
6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . 8
4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . 10 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . 8
6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . 8
5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . . 13 7. Timing message Processing . . . . . . . . . . . . . . . . . . 9
8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 10
6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . 14 9. ECMP and Entropy . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . . 14 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . . 14 11. OAM, Control and Management . . . . . . . . . . . . . . . . . 11
6.3. Other Timing Encapsulation methods . . . . . . . . . . . . 15 12. QoS Considerations . . . . . . . . . . . . . . . . . . . . . 11
13. FCS and Checksum Recalculation . . . . . . . . . . . . . . . 11
7. Timing message Processing . . . . . . . . . . . . . . . . . . 16 14. Behavior of LER/LSRs . . . . . . . . . . . . . . . . . . . . 12
14.1. Behavior of Timing-capable/aware LERs/LSRs . . . . . . . 12
8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 17 14.2. Behavior of non-Timing-capable/aware LSR . . . . . . . . 12
15. Other considerations . . . . . . . . . . . . . . . . . . . . 13
9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 16. Security Considerations . . . . . . . . . . . . . . . . . . . 13
17. Applicability Statement . . . . . . . . . . . . . . . . . . . 14
10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
20.1. Normative References . . . . . . . . . . . . . . . . . . 15
12. OAM, Control and Management . . . . . . . . . . . . . . . . . 21 20.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 17
13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 22 A.1. Routing extensions for Timing-aware Routers . . . . . . . 17
A.2. Signaling Extensions for Creating Timing LSPs . . . . . . 17
14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . . 23
15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 24
15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . . 24
15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . . 24
15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . . 24
16. Other considerations . . . . . . . . . . . . . . . . . . . . . 26
17. Security Considerations . . . . . . . . . . . . . . . . . . . 27
18. Applicability Statement . . . . . . . . . . . . . . . . . . . 28
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
21.1. Normative References . . . . . . . . . . . . . . . . . . . 31
21.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix 1. Appendix . . . . . . . . . . . . . . . . . . . . . . 34 1. Introduction
1.1. Routing extensions for Timing-aware Routers . . . . . . . 34
1.2. Signaling Extensions for Creating Timing LSPs . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
When used in lower case, these words convey their typical use in When used in lower case, these words convey their typical use in
common language, and are not to be interpreted as described in common language, and are not to be interpreted as described in
RFC2119 [RFC2119]. RFC2119 [RFC2119].
1. Introduction The objective of timing distribution protocols, such as Precision
Time Protocol (PTP) and Network Timing Protocol (NTP), is to
The objective of Precision Time Protocol (PTP) and Network Timing synchronize clocks running on nodes of a distributed system.
Protocol (NTP) are to synchronize independent clocks running on
separate nodes of a distributed system.
[IEEE-1588] defines PTP messages for frequency, phase and time
synchronization. The PTP messages include PTP PDUs over UDP/IP
(Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Annex F of
[IEEE-1588]). This document defines mapping and transport of the PTP
messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PTP
defines several clock types: ordinary clocks, boundary clocks, end-
to-end transparent clocks, and peer-to-peer transparent clocks.
Transparent clocks require intermediate nodes to update correction
field inside PTP message that reflects the transit time in the node.
[RFC5905] defines NTP messages for clock and time synchronization.
The PTP messages (PDUs) are transported over UDP/IP. This document
defines mapping and transport of the NTP messages defined in
[RFC5905] over MPLS networks.
One key attribute of all of these Timing messages is that the Time Timing distribution protocols are presently transported over IP or
stamp processing should occur as close as possible to the actual Ethernet. The present document presents a mechanism for transport
transmission and reception at the physical port interface. This over Multiprotocol Label Switched (MPLS) networks. Our solution
targets optimal time and/or frequency recovery by avoiding variable involves transporting timing messages over dedicated "Timing Label
delay introduced by queues internal to the clocks. Switched Paths (LSPs)". These are ordinary LSPs that carry timing
messages and MAY carry Operations, Administration and Maintenance
(OAM) or management messages, but do not carry any other traffic.
To facilitate the fast and efficient recognition of Timing messages Timing LSPs may be established statically or via signaling. When
at the port level when the Timing messages are carried over MPLS using signaling, extensions to routing protocols (e.g., OSPF, ISIS)
LSPs, this document defines the specific encapsulations that should are required to enable routers to distribute their timing processing
be used. In addition, it can be expected that there will exist LSR/ capabilities, and extensions to path set up protocols (e.g., RSVP-TE)
LERs where only a subset of the physical ports will have the port- are required for establishing the LSPs. All such extensions are
based Timing message processing capabilities. In order to ensure beyond the scope of this document.
that the LSPs carrying Timing packets always enter and exit ports
with this capability, routing extensions can be defined to advertise
this capability on a port basis and to allow for the establishment of
LSPs that only transit such ports. While this path establishment
restriction may be applied only at the LER Ingress and/or egress
ports, it becomes more important when using transparent clock capable
LSRs in the path.
Port based Timing message processing involves Timing message High accuracy timing distribution requires on-path support, e.g.,
recognition. Once the Timing messages are recognized they can be Transparent Clocks (TCs) or Boundary Clocks (BCs), at intermediate
modified based on the reception or transmission Time-stamp. nodes. These intermediate nodes need to recognize and appropriately
process timing distribution packets. To facilitate efficient
recognition of timing messages transported over MPLS, this document
restricts the specific encapsulations to be used.
This document provides two methods for transporting Timing messages [IEEE-1588] defines PTP messages for frequency, phase and time
over MPLS. One is applicable to MPLS environment and the other one synchronization. PTP messages may be transported over UDP/IP (Annex
is applicable to MPLS/MPLS-TP environment. D and E of [IEEE-1588]) or over Ethernet (Annex F of [IEEE-1588]).
This document defines two methods to transport PTP messages over MPLS
networks.
The solution involves transporting Timing messages over dedicated PTP defines several clock types, including ordinary clocks, boundary
LSPs called Timing LSPs. These LSPs carry Timing messages and MAY clocks, end-to-end transparent clocks, and peer-to-peer transparent
carry Management and control messages, but not data plane client clocks. Transparent clocks are situated at intermediate nodes and
traffic. Timing LSPs can be established statically or via signaling. update the Correction Field inside PTP messages in order to reflect
Extensions to control plane (OSPF, ISIS, etc.) is required to enable the time required to transit the node.
routers to distribute their Timing processing capabilities over MPLS
to other routers. However such extensions are outside the scope of
this document.
When signaling is used to setup the PTP LSP, extensions to signaling [RFC5905] defines NTP messages for clock and time synchronization.
protocols (e.g., RSVP-TE) are required for establishing PTP LSPs. NTP messages are transported over UDP/IP. This document defines a
However such extensions are outside the scope of this document. method to transport NTP messages over MPLS networks.
While the techniques included herein allow for the establishment of It can be expected that only a subset of LSR ports will be capable of
paths optimized to include Time-stamping capable links, the processing timing messages. Timing LSPs MUST be set up (either by
performance of the Slave clocks is outside the scope of this manual provisioing or via signaling) to traverse these ports. While
document. Timing LSPs are designed to optimize timing distribution, the
performance of slave clocks is beyond the scope of this document.
At the time of publishing this specification, Transparent Clocking Presently on-path support is only defined for PTP, and therefore much
(TC) is only defined for PTP. Therefore at this time any part of of our discussion will focus on PTP. NTP timing distribution may
this specification that talks about Transparent Clocking applies only benefit from transport in a Timing LSP due to prioritorization or
to PTP. selection of ports or nodes with minimal delay or delay asymmetry.
2. Terminology 2. Terminology
1588: The timing and synchronization as defined by IEEE 1588. 1588: The timing distribution protocol defined in IEEE 1588.
NTP: The timing and synchronization protocol defined by IETF RFC-1305 Boundary Clock: A device with one timing port to receive timing
and RFC-5905. messages and at least one port to re-distribute timing messages.
PTP: The timing and synchronization protocol used by 1588. CF: Correction Field, a field inside certain PTP messages that holds
the accumulated transit time.
Master Clock: The source of 1588 timing to a set of slave clocks. Master Clock: The source of 1588 timing messages to a set of slave
clocks.
Master Port: A port on a ordinary or boundary clock that is in Master NTP: The timing distribution protocol defined in RFC 5905.
state. This is the source of timing toward slave ports.
Slave Clock: A receiver of 1588 timing from a master clock. Ordinary Clock: A master or slave clock. Note that ordinary clocks
have only a single PTP port.
Slave Port: A port on a boundary clock or ordinary clock that is PTP: Precision Time Protocol. See 1588.
receiving timing from a master clock.
Ordinary Clock: A device with a single PTP port. Slave Clock: A receiver of 1588 timing messages from a master clock.
Transparent Clock. A device that measures the time taken for a PTP Timing LSP: An MPLS LSP dedicated to carry timing messages.
event message to transit the device and then updates the
correctionField of the message with this transit time.
Boundary Clock: A device with more than one PTP port. Generally Timing messages: Timing distribution protocol messages that are
boundary clocks will have one port in slave state to receive timing exchanged between clocks.
and then other ports in master state to re-distribute the timing.
PTP LSP: An LSP dedicated to carry PTP messages Timing port: A port on a (master, slave, transparent, or boundary)
clock.
PTP PW: A PW within a PTP LSP that is dedicated to carry PTP Timing PW: A PW within a Timing LSP that is dedicated to carry timing
messages. messages.
CW: Pseudowire Control Word Transparent Clock: An intermediate node that forwards timing messages
while updating their CF.
LAG: Link Aggregation
ECMP: Equal Cost Multipath
CF: Correction Field, a field inside certain PTP messages (message
type 0-3)that holds the accumulative transit time inside intermediate
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-1588] has defined methods for transporting PTP messages over [IEEE-1588] defines methods for transporting PTP messages over
Ethernet and IP networks. [RFC5905] has defined the method of Ethernet and IP networks. [RFC5905] defines a method of transporting
transporting NTP messages over IP networks. There is a need to NTP messages over IP networks. There is a need to transport timing
transport Timing messages over MPLS networks while supporting the messages over MPLS networks while supporting the Transparent Clock
Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (OC) (TC), Boundary Clock (BC) and Ordinary Clock (OC) functionalities in
functionality in the LER and LSRs in the MPLS network. LER and LSRs of the MPLS network.
There are multiple ways of transporting Timing over MPLS. However,
there is a requirement to limit the possible encapsulation options to
simplify the Timing message identification and processing required at
the port level.
When Timing-awareness is needed, Timing messages should not be There are potentially many ways of transporting timing packets over
transported over LSPs or PWs that are carrying customer traffic MPLS. However, it is advisable to limit the number of possible
because LSRs perform Label switching based on the top label in the encapsulation options to simplify recognition and processing of
stack. To detect Timing messages inside such LSPs require special timing packets.
hardware to do deep packet inspection at line rate. Even if such
hardware exists, the payload cant be deterministically identified by
LSRs because the payload type is a context of the PW label, and the
PW label and its context are only known to the Edge routers (PEs/
LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, CES,
etc). Even if one restricts an LSP to only carry Ethernet PWs, the
LSRs dont have the knowledge of whether PW Control Word (CW) is
present or not and therefore can not deterministically identify the
payload.
A generic method is defined in this document that does not require The solution herein desscribed transports timing messages over
deep packet inspection at line rate, and can deterministically dedicated "Timing Label Switched Paths (LSPs)". Were timing packets
identify Timing messages. This method can be used to detect Timing to share LSPs with other traffic, intermediate LSRs would be required
Messages in both one-step and two-step clock implementations of to perform some deeper inspection to differentiate between timing
ordinary, boundary and transparent clocks. packets and other packets. The method herein proposed avoids this
complexity, and can readily detect all PTP messages (one-step or two-
step), and supports ordinary, boundary and transparent clocks.
4. Timing over MPLS Architecture 4. Timing over MPLS Architecture
Timing messages are exchange between Timing ports on ordinary and Timing messages are exchanged 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. End-to- act as master clock for other boundary clocks or slave clocks. End-
End Transparent clocks do not terminate the Timing messages but they to-End transparent clocks do not terminate the timing messages but do
do modify the contents of the Timing messages as they transit across modify the contents of the timing messages in transit.
the transparent clock.
Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent Clock OC, BC and TC functionality may be implemented in either LERs or
(TC) could be implemented in either LERs or LSRs. LSRs.
An example is shown in Figure 1, where the LERs act as Ordinary Clock An example is shown in Figure 1, where the LERs act as OCs and are
(OC) and are the initiating/terminating point for Timing messages. the initiating/terminating points for timing messages. The ingress
The ingress LER encapsulates the Timing messages in Timing LSP and LER encapsulates timing messages in a Timing LSP and the egress LER
the Egress LER terminates the Timing LSP. The LSRs act as terminates this Timing LSP. Intermediate LSRs (only one is shown
Transparent Clock (TC) and just update the Timing field in the Timing here) act as TCs, updating the CF of transiting timing messages, as
messages. well as performing label switching operations.
+--------+ +-------+ +-------+ +-------+ +--------+ +--------+ +-------+ +-------+ +-------+ +--------+
|Switch, | | | | | | | |Switch, | |Switch, | | | | | | | |Switch, |
| Router |-----| LER |-----| LSR |-----| LER |-----| Router | | Router |-----| LER |-----| LSR |-----| LER |-----| Router |
| | | OC | | TC | | OC | | | | | | OC | | TC | | OC | | |
+--------+ +-------+ +-------+ +-------+ +--------+ +--------+ +-------+ +-------+ +-------+ +--------+
/ \ / \
+-------+ / \ +-------+ +-------+ / \ +-------+
| LER | / \ | LER | | LER | / \ | LER |
| Master|---/ \---| Slave | | Master|---/ \---| Slave |
| Clock | | Clock | | Clock | | Clock |
+-------+ +-------+ +-------+ +-------+
Figure (1) - Deployment example 1 of timing over MPLS network Figure (1) - Deployment example 1 of timing over MPLS network
Another example is shown in Figure 2, where LERs terminate the Timing Another example is shown in Figure 2, where LERs act as BCs, and
messages received from switch/routers that are outside of the MPLS switches/routers outside of the MPLS network, act as OCs or BCs. The
network acting as OC or BC. In this example LERs regenerate the ingress LER BC recovers timing and initiates timing messages
clock and initiate timing messages encapsulated in Timing LSP toward encapsulated in the Timing LSP toward the MPLS network, an
the MPLS network, while the LSRs act as Transparent Clock (TC) and intermediate LSR acts as a TC, and the egress LER acts as a BC
just update the Timing field in the Timing messages, which are sending timing messages to equipment outside the MPLS network.
already encapsulated in Timing LSPs.
+--------+ +-------+ +-------+ +-------+ +--------+ +--------+ +-------+ +-------+ +-------+ +--------+
|Switch, | | | | | | | |Switch, | |Switch, | | | | | | | |Switch, |
| Router |-----| LER |-----| LSR |-----| LER |-----| Router | | Router |-----| LER |-----| LSR |-----| LER |-----| Router |
| OC/BC | | BC | | TC | | BC | | OC/BC | | OC/BC | | BC | | TC | | BC | | OC/BC |
+--------+ +-------+ +-------+ +-------+ +--------+ +--------+ +-------+ +-------+ +-------+ +--------+
Figure (2) - Deployment example 2 of timing over MPLS network
Another example is shown in Figure 3, where LERs do not terminate the Figure (2) - Deployment example 2 of timing over MPLS network
Timing messages received from switch/routers that are outside of the
MPLS network acting as OC, TC or BC. The LERs act as TC and update
the Timing field in the Timing messages as they transit the LER,
while encapsulating them in timing LSP. The LSRs also act as
Transparent Clock (TC) and just update the Timing field in the Timing
messages which are already encapsulated in Timing LSPs.
+--------+ +-------+ +-------+ +-------+ +--------+ Yet another example is shown in Figure 3, where both LERs and LSRs
|Switch, | | | | | | | |Switch, | act as TCs. The ingress LER updates the CF and encapsulates the
| Router |-----| LER |-----| LSR |-----| LER |-----| Router | timing message in an MPLS packet, intermediate LSRs update the CF and
|OC/TC/BC| | TC | | TC | | TC | |OC/TC/BC| perform label switching, and the egress LER updates the CF and sends
+--------+ +-------+ +-------+ +-------+ +--------+ the timing messages to equipment outside the MPLS network.
Figure (3) - Deployment example 3 of timing over MPLS network +--------+ +-------+ +-------+ +-------+ +--------+
|Switch, | | | | | | | |Switch, |
| Router |-----| LER |-----| LSR |-----| LER |-----| Router |
|OC/TC/BC| | TC | | TC | | TC | |OC/TC/BC|
+--------+ +-------+ +-------+ +-------+ +--------+
Another example is shown in Figure 4, where LERs and LSRs support Figure (3) - Deployment example 3 of timing over MPLS network
Boundary Clocks. A single-hop LSP is created between two adjacent A final example is shown in Figure 4, where all nodes act as BCs.
LSRs engaged in BC operation. Other methods such as PTP transport Single-hop LSPs are created between every two adjacent LSRs. Of
over Ethernet MAY be used for transporting timing messages if the course, PTP transport over Ethernet MAY be used between two network
link between the two routers is Ethernet. elements.
+--------+ +-------+ +-------+ +-------+ +--------+ +--------+ +-------+ +-------+ +-------+ +--------+
|Switch, | | | | | | | |Switch, | |Switch, | | | | | | | |Switch, |
| Router |-----| LER |-----| LSR |-----| LER |-----| Router | | Router |-----| LER |-----| LSR |-----| LER |-----| Router |
| OC/BC | | BC | | BC | | BC | | OC/BC | | OC/BC | | BC | | BC | | BC | | OC/BC |
+--------+ +-------+ +-------+ +-------+ +--------+ +--------+ +-------+ +-------+ +-------+ +--------+
Figure (4) - Deployment example 3 of timing over MPLS network Figure (4) - Deployment example 3 of timing over MPLS network
An MPLS domain MAY serve multiple customers. In these cases the MPLS An MPLS domain MAY serve multiple customers, each having its own
domain (maintained by a service provider) may provide timing services Timing domain. In these cases the MPLS domain (maintained by a
to multiple customers, each having their own Timing domain. service provider) MUST provide dedicated timing services to each
customer.
The Timing over MPLS architecture assumes full mesh of Timing LSPs The timing over MPLS architecture assumes a full mesh of Timing LSPs
between all LERs supporting this specification. It supports between all LERs supporting this specification. It supports point-
Point-to- point (VPWS) and Multipoint (VPLS) services. This means to- point (VPWS) and Multipoint (VPLS) services. This means that a
that a customer may purchase a Point-to-point Timing service between customer may purchase a point-to-point timing service between two
two customer sites or a Multipoint Timing service between more than customer sites or a multipoint timing service between more than two
two customer sites. customer sites.
The Timing over MPLS architecture supports P2P or P2MP Timing LSPs. The Timing over MPLS architecture supports P2P or P2MP Timing LSPs.
This means that the Timing Multicast messages such as PTP Multicast This means that the Timing Multicast messages such as PTP Multicast
event messages can be transported over P2MP Timing LSP or be event messages MAY be transported over P2MP Timing LSPs or MAY be
replicated and transported over many P2P Timing LSPs. replicated and transported over multiple P2P Timing LSPs.
Timing messages, that do not require Time stamping or Correction Timing LSPs, as defined by this specification, MAY be used for timing
Field update MAY be transported over Timing LSPs to simplify hardware messages that do not require time-stamping or CF updating.
and software.
PTP Announce messages that determine the Timing LSP terminating point PTP Announce messages that determine the Timing LSP terminating point
behavior such as BC/OC/TC SHOULD be transported over the Timing LSP behavior such as BC/OC/TC SHOULD be transported over the Timing LSP
to simplify hardware and software. 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 The method defined in this document is used by LER and LSRs to
when they are encapsulated in MPLS such as using GAL/G-ACH or a new identify timing messages by observing the top label of the MPLS label
reserved label. These methods were not attractive since they either stack. Compliant implementations MUST use dedicated LSPs to carry
required deep packet inspection at line rate in the intermediate LSRs timing messages over MPLS. Such LSPs are herein referred to as
or they required use of a scarce new reserved label. Also one of the "Timing LSPs" and the labels associated with these LSPs as "Timing
goals was to reuse existing OAM mechanisms. LSP labels".
The method defined in this document can be used by LER and LSRs to
identify Timing messages in MPLS tunnels by just looking at the top
label in the MPLS label stack, which only carry Timing messages as
well as OAM, but not data plane client traffic.
Compliant implementations MUST use dedicated LSPs to carry Timing
messages over MPLS. These LSPs are herein referred to as "Timing
LSPs" and the labels associated with these LSPs as "Timing LSP
labels". The Timing LSPs that runs between Ingress and Egress LERs
MUST be co-routed. Alternatively, a single bidirectional co-routed
LSP can be used.
Co-routing of the two directions is required to limit the difference
in the delays in the Master clock to Slave clock direction compared
to the Slave clock to Master clock direction. The Timing LSP MAY be
MPLS LSP/MPLS-TP LSP.
The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS. Timing distribution requires symmetrical bidirectional
New Extensions to RSVP-TE/GMPLS TLVs are required; however they are communications. Co-routing of the two directions is required to
outside the scope of this document. limit delay asymmetry. Thus timing messages MUST be transported
either over two co-routed unidirectional Timing LSPs, or a single
bidirectional co-routed Timing LSP.
The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such as Timing LSPs MAY be configured using RSVP-TE. Extensions to RSVP-TE
BFD and LSP Ping but the LSP data plane client plane traffic MUST be are required for this purpose, but are beyond the scope of this
Timing packets only. document.
6. Timing over LSP Encapsulation 6. Timing over LSP Encapsulation
This standard defines two methods for carrying Timing messages over We define two methods for carrying timing messages over MPLS. The
MPLS. The first method is carrying UDP/IP encapsulated Timing first method transports UDP/IP-encapsulated timing messages over
messages over Timing LSPs, and the second method, is carrying Timing LSPs, and the second method transports Ethernet encapsulated
Ethernet encapsulated Timing messages over Ethernet PWs inside Timing timing messages over Ethernet PWs placed in Timing LSPs.
LSPs.
6.1. Timing over UDP/IP over MPLS Encapsulation 6.1. Timing over UDP/IP over MPLS Encapsulation
The simplest method of transporting Timing messages over MPLS is to The first method directly encapsulates UDP/IP timing messages in a
encapsulate Timing PDUs in UDP/IP and then encapsulate them in Timing Timing LSP. The UDP/IP encapsulation of PTP messages MUST comply to
LSP. This format is shown in Figure 4. Annex D and E of [IEEE-1588], and the UDP/IP encapsulation of NTP
messages MUST comply to [RFC5905]. This format is shown in Figure 4.
+----------------------+ +----------------------+
| Timing LSP Label | | Timing LSP Label |
+----------------------+ +----------------------+
| IPv4/6 | | IPv4/6 |
+----------------------+ +----------------------+
| UDP | | UDP |
+----------------------+ +----------------------+
| Timing PDU | | timing message |
+----------------------+ +----------------------+
Figure (4) - Timing over UDP/IP over MPLS Encapsulation Figure (4) - Timing over UDP/IP over MPLS Encapsulation
This encapsulation is very simple and is useful when the network In order for an LER/LSR to process timing messages, the Timing LSP
between Timing Master Clock and Slave Clock is MPLS network. Label must be the top label of the label stack. The LER/LSR MUST
know that this label is a Timing LSP Label. It can learn this by
In order for an LER/LSR to process Timing messages, the Timing LSP static configuration or via RSVP-TE signaling.
Label must be at the top label of the label stack. The LER/LSR MUST
know that the Timing LSP Label is used for carrying Timing messages.
This can be accomplished via static configuration or via RSVP-TE
signaling.
The UDP/IP encapsulation of PTP MUST follow Annex D and E of
[IEEE-1588]. While the UDP/IP encapsulation of NTP MUST follow
[RFC5905].
6.2. Timing over PW Encapsulation 6.2. Timing over PW Encapsulation
Another method of transporting Timing over MPLS networks is by Another method of transporting timing over MPLS networks is to use
encapsulating Timing PDUs in PW which in turn is transported over Ethernet encapsulated timing messages, and to transport these in an
Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448], Ethernet PW which in turn is transported over a Timing LSP. In the
shown in Fig 5(A) MUST be used and the Ethernet encapsulation of PTP case of PTP, the Ethernet encapsulation MUST comply to Annex F of
MUST follow Annex F of [IEEE-1588]. [IEEE-1588] and the Ethernet PW encapsulation to [RFC4448], resulting
in the format shown in Figure 5(A).
The RAW mode or Tagged mode defined in [RFC-4448] MAY be used and the Either the Raw mode or Tagged mode defined in [RFC-4448] MAY be used
Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The and the payload MAY have 0, 1, or 2 VLAN tags. The Timing over PW
Timing over PW encapsulation MUST use the Control Word (CW) as encapsulation MUST use the Control Word (CW) as specified in
specified in [RFC4448] to ensure proper detection of PTP messages [RFC4448]. The use of Sequence Number in the CW is optional.
inside the MPLS packets for Timing over LSP and Timing over PW
encapsulation. The use of Sequence Number in the CW is optional.
Timing over PW encapsulation for NTP MUST use NTP over UDP/IP over PW NTP MAY be transported using an IP PW (as defined in [RFC4447]) as
(the IP PW discussed in [RFC4447]) shown in Fig 5(B). shown in Fig 5(B).
+-----------------+ +----------------+ +-----------------+ +----------------+
|Timing LSP Label | |Timing LSP Label| |Timing LSP Label | |Timing LSP Label|
+-----------------+ +----------------+ +-----------------+ +----------------+
| PW Label | | PW Label | | PW Label | | PW Label |
+-----------------+ +----------------+ +-----------------+ +----------------+
| Control Word | | IP | | Control Word | | IP |
+-----------------+ +----------------+ +-----------------+ +----------------+
| Ethernet | | UDP | | Ethernet | | UDP |
| Header | +----------------+ | Header | +----------------+
+-----------------+ | Timing PDU | +-----------------+ | Timing message |
|S-VLAN (Optional)| | | |S-VLAN (Optional)| | |
+-----------------+ +----------------+ +-----------------+ +----------------+
|C-VLAN (Optional)| (B) |C-VLAN (Optional)| (B)
+-----------------+ +-----------------+
| Timing PDU | | Timing message |
| | | |
+-----------------+ +-----------------+
(A) (A)
Figure (5) - Timing over PW Encapsulations Figure (5) - Timing over PW Encapsulations
In order for an LSR to process PTP messages, the top label of the
label stack (the Tunnel Label) MUST be a Timing label.
6.3. Other Timing Encapsulation methods
In future other timing encapsulation methods may be introduced, such
as a new shim header after the Bottom of Stack to carry the Timing
information. Such new encapsulations are outside the scope of this
document.
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, defines a set of timing
messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, messages. PTP defines SYNC, DELAY_REQ, DELAY_RESP, FOLLOW_UP, etc.
FOLLOW_UP, etc messages.
Some of the Timing messages require time stamping or correction field Some timing messages require per-packet processing, such as time-
update at port level and some dont. It is the job of the LER/LSR to stamping or CF updating. A compliant LER/LSR parses each timing
parse the timing message and find out the type of the Timing message message to determine the required processing.
and decide whether and how to Time- stamp it (e.g., BC) or update
correction field(e.g., TC).
For example the following PTP messages (called Event messages) For example, the following PTP messages (event messages) require
require time-stamping or correction field update: time-stamping or CF updating:
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 a Master Clock and a Slave
and MUST be transported over PTP LSPs. PDELAY_REQ and PDELAY_RESP Clock and MUST be transported over Timing LSPs. PDELAY_REQ and
are exchanged between adjacent PTP clocks (i.e. Master, Slave, PDELAY_RESP are exchanged between adjacent PTP clocks (master, slave,
Boundary, or Transparent) and SHOULD be transported over single hop boundary, or transparent) and SHOULD be transported over single hop
PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP, Timing LSPs. If two-Step PTP clocks are present, then the FOLLOW_UP,
and PDELAY_RESP_FOLLOW_UP messages MUST also be transported over the and PDELAY_RESP_FOLLOW_UP messages MUST also be transported over
PTP LSPs. Timing LSPs.
For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be For a given instance of the 1588 protocol, SYNC and DELAY_REQ MUST be
transported over two PTP LSPs that are in opposite directions. These transported in opposite directions. As aforementioned, two co-routed
PTP LSPs, which are in opposite directions MUST be congruent and co- unidirectional LSPs or a single bidirectional co-routed LSP MAY 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 two-step PTP clocks, PTP messages that
message types do not need to be processed by intermediate routers. are not "event messages" need not be processed by intermediate
These message types MAY be carried in PTP Tunnel LSPs. routers. These message types MAY be carried in PTP Tunnel LSPs.
8. Protection and Redundancy 8. Protection and Redundancy
In order to ensure continuous uninterrupted operation of slave In order to ensure continuous uninterrupted operation of timing
clocks, usually as a general practice, slave clocks (or ports) track distribution, slave clocks often track redundant master clocks.
redundant master clocks. Prolonged outages of Timing LSPs trigger switching to a redundant
master clock It is the responsibility of the network operator to
It is the responsibility of the network operator to ensure that ensure that physically disjoint Timing LSPs are established between a
physically disjoint Timing LSPs are established between a slave clock slave clock and redundant master clocks.
(or port) and redundant master clocks (or ports).
When a slave clock (or port) listens to redundant master clocks or
ports, any prolonged Timing LSP outage will trigger the slave clock
or port to switch to a redundant master clock or port.
LSP/PW protection such as Linear protection Switching (1:1, 1+1), LSP or PW layer protection, such as linear protection Switching, ring
Ring protection switching or MPLS Fast Reroute (FRR) can switch to an protection switching or MPLS Fast Reroute (FRR), will lead to changes
alternative path that can cause a change in delay, which if in propagation delay between master and slave clocks. Such a change,
undetected by the slave clock, can reduce accuracy of the slave if undetected by the slave clock, would negatively impact timing
clock. While it is expected that most Slave clocks will be able to performance. While it is expected that slave clocks will often be
detect the change in delay, this specification still recommends that able to detect such delay changes, this specification RECOMMENDS that
protection switching MUST NOT be used, unless the operator knows that automatic protection switching NOT be used for Timing LSPs, unless
the protection switching will not have any adverse effect on the the operator can ensure that it will not negatively impact timing
slave clock. performance.
9. ECMP 9. ECMP and Entropy
To ensure the optimal operation of slave clocks and avoid error To ensure the correct operation of slave clocks and avoid error
introduced by forward and reverse path delay asymmetry, the physical introduced by forward and reverse path delay asymmetry, the physical
path for Timing messages from master clock to slave Clock and vice path taken by timing messages MUST be the same for all timing
versa must be the same for all Event Timing messages listed in messages. In particular, the PTP event messages listed in section 7
section 7. MUST be routed in the same way.
Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost
Multipath). Multipath). Entropy labels MUST NOT be used for the Timing LSP
[RFC6790] and MUST NOT be used for PWs inside the Timing LSP
[RFC6391].
10. PHP 10. PHP
To ensure that the label on the top of the label stack is the Timing To ensure that the label on the top of the label stack is the Timing
LSP Label, PHP MUST not be used. LSP Label, PHP MUST not be employed.
11. Entropy
To ensure all Timing messages in a Timing LSP take the same path,
Entropy Label MUST NOT be used for the Timing LSP [RFC6790] and
Entropy Label MUST NOT be used for the PWs that are carried inside
Timing LSP [RFC6391].
12. OAM, Control and Management 11. OAM, Control and Management
In order to monitor Timing LSPs and their encapsulated PWs, they MUST In order to monitor Timing LSPs or PWs, it is necessary to enable
be able to carry OAM and management messages. These management them to carry OAM messages. OAM packets MUST be differentiated from
messages MUST be differentiated from Timing messages via already timing messages by 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 Timing LSPs via UDP/IP encapsulation or via GAL/G-ACh. These
Management protocols can easily be identified by the UDP Destination protocols can easily be identified by the UDP Destination port number
Port number or by GAL/G-ACH respectively. or by GAL/G-ACh respectively.
Also BFD, LSP-Ping and other management messages MAY run over the PWs
encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3 or
4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is going
to be deprecated by IETF). In this case G-ACH, PW label (TTL=1) or
GAL-ACH are used to identify such management messages.
13. QoS Considerations
In network deployments where not every LSR/LER is Timing-aware, it is
important to reduce the impact of the non-Timing-aware LSR/LERs on
the timing recovery in the slave clock. The Timing messages are time
critical and must be treated with the highest priority. Therefore
Timing over MPLS messages must be treated with the highest priority
in the routers. This can be achieved by proper setup of Timing LSPs.
It is recommended that the Timing LSPs are setup or configured Also BFD, LSP-Ping and other messages MAY run over Timing PWs via
properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC2697] VCCV [RFC5085]. In this case these messages are recognized according
for drop eligibility. to the VCCV type.
14. FCS and Checksum Recalculation 12. QoS Considerations
When time-stamp generation and timing packet adjustment is performed There may be deployments where timing messages traverse LSR/LERs that
near the physical port hardware, the process MUST include are not capable of the required processing. In order to minimize the
recalculation of the Ethernet FCS. Also FCS retention for the negative impact on the timing performance of the slave clock timing
payload Ethernet described in [RFC4720] MUST NOT be used. messages MUST be treated with the highest priority. This can be
achieved by proper setup of Timing LSPs.
For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum It is recommended that Timing LSPs be configured to indicate EF-PHB
may be required as per UDP transport standards. [RFC3246] for the CoS and "green" [RFC2697] for drop eligibility.
When UDP checksum is used, each Timing-aware LER/LSR must either 13. FCS and Checksum Recalculation
incrementally update the UDP checksum after Time stamping or
Correction Field update or verify the UDP checksum on reception from
upstream and recalculate the checksum completely on transmission to
downstream node after Time stamping or Correction Field update.
15. Behavior of LER/LSR Since Boundary and Transparent Clocks modify packets, when the MPLS
packets are transported over Ethernet the processing MUST include
recalculation of the Ethernet FCS. FCS retention as described in
[RFC4720] MUST NOT be used.
Timing-capable/aware LERs and LSRs are routers that have one or more For the UDP/IP encapsulation mode, calculation of the UDP checksum
interfaces that can perform Timing operations (OC/BC/TC) on Timing will generally be required. After updating the CF a Transparent
packets and are configured to do so. Timing-capable/aware LERs and Clock MUST either incrementally update the UDP checksum or completely
LSRs can advertise their Timing-capability per-interface via control recalculate the checksum before transmission to downstream node.
plane such as OSPF or IS-IS. The Timing-capable/aware LERs can then
signals Timing LSPs via RSVP-TE signaling. Alternatively the Timing
capability of LER and LSRs may be configured in a centralized
controller and the Timing LSP may be setup using manual configuration
or other methods such as SDN.
15.1. Behavior of Timing-capable/aware LER 14. Behavior of LER/LSRs
When a Timing-capable/aware LER behaves as a Transparent clock and Timing-aware LERs or LSRs are MPLS routers that are able to recognize
receives a Timing message from a Timing-capable/aware non-MPLS timing packets. Timing-capable LERs and LSRs further have one or
interface, the LER updates the Correction Field (CF) and encapsulates more interfaces that can perform timing processing (OC/BC/TC) on
and forwards the timing message over previously established Timing timing packets. Timing-capable/aware LERs and LSRs MAY advertise the
LSP. Also when a Timing message is received from a Timing-capable/ timing capabilities of their interfaces via control plane protocols
aware MPLS interface, LER updates the Correction Filed (CF) and such as OSPF or IS-IS, and timing-aware LERs can then be set up
decapsulates the MPLS encapsulation and forwards the timing message Timing LSPs via RSVP-TE signaling. Alternatively the timing
to a non-MPLS interface. capabilities of LERs and LSRs may be known by a centralized
controller or management system, and Timing LSPs may be manually
configured, or set up by a management platform or a Software Defined
Networking (SDN) controller.
When a Timing-capable/aware LER behaves as a Boundary clock and 14.1. Behavior of Timing-capable/aware LERs/LSRs
receives a Timing message from a Timing-capable/aware non MPLS
interface, the LER Timestamps the Timing packet and sends it to the
LERs Boundary clock processing module. Also when a Timing message is
received from a Timing- capable/aware MPLS interface, the LER
Timestamps the Timing packet and sends it to the LERs Boundary clock
processing module.
When a Timing-capable/aware LER behaves as an Ordinary Clock toward When a timing-capable ingress LER acting as a TC receives a timing
the MPLS network, and receives a Timing message from a Timing- message packet from a timing-capable non-MPLS interface, the LER
capable/aware MPLS interface, the LER Timestamps the Timing packet updates the CF, encapsulates and forwards the packet over a
and sends it to the LERs Ordinary clock processing module. previously established Timing LSP. When a timing-capable egress LER
acting as a TC receives a timing message packet on timing-capable
MPLS interface, the LER updates the CF, decapsulates the MPLS
encapsulation, and forwards the packet via a non-MPLS interface.
When a timing-capable LSR acting as a TC receives a timing message
from a timing-capable MPLS interface, the LSR updates the CF and
forwards the timing message over another MPLS interface.
15.2. Behavior of Timing-capable/aware LSR When a timing-capable LER acting as a BC receives a timing message
packet from a timing-capable interface, the LER time-stamps the
packet and sends it to the BC processing module.
A Timing-capable/aware LSR behaves as a Transparent clock and When a timing-capable LER acting as an OC receives a timing message
receives a Timing message from a Timing-capable/aware MPLS interface. from a timing-capable MPLS interface, the LER time-stamps the packet
The LSR updates the Correction Filed (CF) and forwards the timing and sends it to the OC processing module.
message over another MPLS interface.
15.3. Behavior of non-Timing-capable/aware LSR 14.2. Behavior of non-Timing-capable/aware LSR
It is most beneficial when all LSRs in the path of a Timing LSP be It is most beneficial when all LSRs in the path of a Timing LSP be
timing-Capable/aware LSRs. This would ensure the highest quality timing-Capable/aware LSRs. This would ensure the highest quality
time and clock synchronization by Timing Slave Clocks. However, this time and clock synchronization by slave clocks. However, this
specification does not mandate that all LSRs in path of a Timing LSP specification does not mandate that all LSRs in path of a Timing LSP
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 perform label switching on the
Timing LSPs and dont perform any Timing operation (TC). However as packets encapsulated in Timing LSPs and don't perform any timing
explained in QoS section the Timing over MPLS packets MUST be still related processing. However, as explained in QoS section, timing
be treated with the highest priority based on their Traffic Class packets MUST be still be treated with the highest priority based on
(TC) marking. their Traffic Class marking.
16. Other considerations 15. Other considerations
[IEEE-1588] defines an optional peer-to-peer Transparent clocking [IEEE-1588] defines an optional peer-to-peer transparent clocking
that requires peer delay measurement between two adjacent Timing- (P2P TC) mode that compensates both for residence time in the network
capable/ aware routers/switches. Peer delay measurement messages node and for propagation time on the link between modes. To support
need to be time stamped and terminated by the Timing-capable/aware P2P TC, delay measurement must be performed between two adjacent
routers/ switches. This means that two adjacent LSRs may be engaged timing-capable/aware LSRs. Thus, in addition to the TC functionality
in a peer delay measurement. detailed above on transit PTP timing messages, adjacent peer to peer
TCs MUST engage in single-hop peer delay measurement.
For transporting such peer delay measurement messages a single-hop For single hop peer delay measurement a single-hop LSP SHOULD be
LSP SHOULD to be created between the two adjacent LSRs engaged in created between the two adjacent LSRs. Other methods MAY be used;
peer delay measurement to carry peer delay measurement messages. for example, if the link between the two adjacent routers is
Other methods such as PTP transport over Ethernet MAY be used for Ethernet, PTP transport over Ethernet MAY be used.
transporting peer delay measurement messages if the link between the
two routers is Ethernet.
In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/ ware To support P2P TC, a timing-capable/ware LSR MUST maintain a list of
routers/switches MUST maintain a list of all the neighbors it needs all neighbors to which it needs to send a PDelay_Req, and maintain a
to send a PDelay_Req to, where each neighbor corresponds to a timing single-hop timing LSP to each.
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 (for
(applicable only to UDP/IP encapsulation) or the label below the the UDP/IP encapsulation) or the label below the Explicit Null label
Explicit Null label is a PTP label. (for the PW case).
17. Security Considerations 16. Security Considerations
MPLS PW security considerations in general are discussed in [RFC3985] Security considerations for MPLS and pseudowires are discussed in
and [RFC4447],and those considerations also apply to this document. [RFC3985] and [RFC4447]. Security considerations for timing are
discussed in [RFC7384]. Everything discussed in those documents
applies to the Timing LSP of this document.
An experimental security protocol is defined in [IEEE-1588].The PTP An experimental security protocol is defined in [IEEE-1588]. 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, When the MPLS network (provider network) serves multiple customers,
it is important to maintain and process each customers clock and it is important to distinguish between timing messages belonging to
Timing messages separately from other customers to ensure there is no different customers. For example if an LER BC is synchronized to a
cross- customer effect. For example if an LER BC is synchronized to grandmaster belonging to customer A, then the LER MUST only use that
a specific grandmaster, belonging to customer A, then the LER MUST BC for slaves of customer A, to ensure that customer A cannot
use that BC clock only for customer A to ensure that customer A adversely affect the timing distribution of other customers.
cannot attack other customers by manipulating its time.
Timing messages MAY be encrypted or authenticated, provided that the Timing messages MAY be encrypted or authenticated, provided that the
LERs/LSRs that are Timing capable/aware can authenticate/ decrypt the timing-capable LERs/LSRs can authenticate/ decrypt the timing
timing messages. messages.
18. Applicability Statement 17. 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 ingress LER that receives IP or Ethernet encapsulated timing
non-MPLS interface and forwards them as MPLS encapsulated Timing messages from a non-MPLS interface and forwards them as MPLS
messages over Timing LSP, while performing Transparent Clock encapsulated timing messages over Timing LSP, optionally
functionality performing TC functionality.
o An LER receives MPLS encapsulated Timing messages from a Timing o An egress LER that receives MPLS encapsulated timing messages from
LSP and forwards them to non-MPLS interface as IP or Ethernet a Timing LSP and forwards them to non-MPLS interface as IP or
Encapsulated Timing messages, while performing Transparent Clock Ethernet encapsulated timing messages, optionally performing TC
functionality functionality.
o An LER receives MPLS encapsulated Timing messages from a Timing o An ingress LER that receives MPLS encapsulated timing messages
LSP and terminates them, while performing the OC or BC from a non-MPLS interface, performs BC functionality, and sends
functionality timing messages over a Timing LSP.
o An LSR receives MPLS encapsulated Timing messages from a Timing o An egress LER that receives MPLS encapsulated timing messages from
LSP and forwards them to another MPLS interface, while performing a Timing LSP, performs BC functionality, and sends timing messages
the TC functionality over a non-MPLS interface.
This document also supports the case where not all LSRs are Timing- o An LSR on a Timing LSP that receives MPLS encapsulated timing
capable/aware. It also supports the case where not all LER/LSR messages from one MPLS interface and forwards them to another MPLS
interfaces are Timing-capable/aware. interface, optionally performing TC functionality.
19. Acknowledgements This document also supports the case where not all LSRs are timing-
capable/aware, or not all LER/LSR interfaces are timing-capable/
aware.
The authors would like to thank Luca Martini, Ron Cohen, Yaakov 18. Acknowledgements
Stein, Tal Mizrahi, Stefano Ruffini, Peter Meyer and other members of
IETF for reviewing and providing feedback on this draft.
20. IANA Considerations The authors would like to thank Yaakov Stein, Luca Martini, Ron
Cohen, Tal Mizrahi, Stefano Ruffini, Peter Meyer and other IETF
participants for reviewing and providing feedback on this draft.
19. IANA Considerations
There are no IANA requirements in this specification. There are no IANA requirements in this specification.
21. References 20. References
21.1. Normative References 20.1. Normative References
[IEEE-1588] [IEEE-1588]
IEEE 1588-2008, "IEEE Standard for a Precision Clock IEEE 1588-2008, "IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
Control Systems". Control Systems", July 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge (PWE3) Architecture", RFC 3985, March 2005. Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005,
<http://www.rfc-editor.org/info/rfc3985>.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006. Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April
2006, <http://www.rfc-editor.org/info/rfc4389>.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
Heron, "Pseudowire Setup and Maintenance Using the Label G. Heron, "Pseudowire Setup and Maintenance Using the
Distribution Protocol (LDP)", RFC 4447, April 2006. Label Distribution Protocol (LDP)", RFC 4447,
DOI 10.17487/RFC4447, April 2006,
<http://www.rfc-editor.org/info/rfc4447>.
[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS "Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, April 2006. Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,
<http://www.rfc-editor.org/info/rfc4448>.
[RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire
Emulation Edge-to-Edge (PWE3) Frame Check Sequence Emulation Edge-to-Edge (PWE3) Frame Check Sequence
Retention", RFC 4720, November 2006. Retention", RFC 4720, DOI 10.17487/RFC4720, November 2006,
<http://www.rfc-editor.org/info/rfc4720>.
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual
Connectivity Verification (VCCV): A Control Channel for Circuit Connectivity Verification (VCCV): A Control
Pseudowires", RFC 5085, December 2007. Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085,
December 2007, <http://www.rfc-editor.org/info/rfc5085>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010. (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<http://www.rfc-editor.org/info/rfc5880>.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label "Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010. Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
June 2010, <http://www.rfc-editor.org/info/rfc5884>.
21.2. Informative References 20.2. Informative References
[ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermediate
system routeing information exchange protocol for use in system routing information exchange protocol for use in
conjunction with the Protocol for providing the conjunction with the Protocol for providing the
Connectionless-mode Network Service (ISO 8473)". Connectionless-mode Network Service (ISO 8473)", April
1992.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990. dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <http://www.rfc-editor.org/info/rfc1195>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>.
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color
Marker", RFC 2697, September 1999. Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999,
<http://www.rfc-editor.org/info/rfc2697>.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D. J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002. Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
<http://www.rfc-editor.org/info/rfc3246>.
[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.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<http://www.rfc-editor.org/info/rfc5340>.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>.
[RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V.,
J., and S. Amante, "Flow-Aware Transport of Pseudowires Regan, J., and S. Amante, "Flow-Aware Transport of
over an MPLS Packet Switched Network", RFC 6391, Pseudowires over an MPLS Packet Switched Network",
November 2011. RFC 6391, DOI 10.17487/RFC6391, November 2011,
<http://www.rfc-editor.org/info/rfc6391>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, November 2012. RFC 6790, DOI 10.17487/RFC6790, November 2012,
<http://www.rfc-editor.org/info/rfc6790>.
1. Appendix [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <http://www.rfc-editor.org/info/rfc7384>.
1.1. Routing extensions for Timing-aware Routers Appendix A. Appendix
A.1. 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 Timing related capabilities, such as the capability for a router to
capabilities, such as the capability for a router to be Timing-aware. perform time-stamping, and OC, TC or BC processing, need to be
This capability MUST then be taken into account during path advertised in order for them to be taken into account during path
computation to prefer or even require links that advertise themselves computation. A management system or SDN controller cognizant of
as Timing-aware. In this way the path can ensure the entry and exit timing related capabilities, can prefer or even require a Timing LSP
points into the LERs and, if desired, the links into the LSRs are to traverse links or nodes or intefaces with the required
able to perform port based time-stamping thus minimizing their impact capabilities. The optimal path will optimize the performance of the
on the performance of the slave clock. 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 related capabilities of a link. Such extensions are outside
scope of this document; however such extension SHOULD be able to the scope of this document; however such extensions 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 Boundary Clock operation o Capable of performing TC operation
1.2. Signaling Extensions for Creating Timing LSPs o Capable of performing BC operation
RSVP-TE signaling MAY be used to setup the timing LSPs. When RSVP-TE A.2. Signaling Extensions for Creating Timing LSPs
is used to setup Timing LSPs, some information that indicates that
the LSP is carrying Timing flows MUST be included in the new
Extensions to RSVP-TE:
The following information MAY also be included in the new Extensions RSVP-TE signaling MAY be used to set up Timing LSPs. Extensions are
to RSVP-TE: required to RSVP-TE for this purpose. Such extensions are outside
the scope of this document; however, the following information MAY be
included in such extensions:
o Offset from Bottom of Stack (BoS) to the start of the Time-stamp 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 Time-stamp field Type
o Timestamp field Type * Correction Field, time-stamp
* Correction Field, Timestamp
o Timestamp Field format o Time-stamp 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 when the above optional information is signaled with RSVP-
RSVP-TE for a Timing LSP, all the Timing packets carried in that LSP TE for a Timing LSP, all the timing packets carried in that LSP must
must have the same signaled characteristics. For example if have the same signaled characteristics. For example if time-stamp
Timestamp format is signaled as 64-bit PTPv1, then all Timing packets format is signaled as 64-bit PTPv1, then all timing packets must use
must use 64-bit PTPv1 time-stamp. 64-bit PTPv1 time-stamp.
Authors' Addresses Authors' Addresses
Shahram Davari Shahram Davari
Broadcom Corp. Broadcom Corp.
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: davari@broadcom.com Email: davari@broadcom.com
Amit Oren Amit Oren
Broadcom Corp. Broadcom Corp.
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: amito@broadcom.com Email: amito@broadcom.com
Manav Bhatia Manav Bhatia
Alcatel-Lucent Alcatel-Lucent
Bangalore, Bangalore
India India
Email: manav.bhatia@alcatel-lucent.com Email: manav.bhatia@alcatel-lucent.com
Peter Roberts Peter Roberts
Alcatel-Lucent Alcatel-Lucent
Kanata, Kanata
Canada Canada
Email: peter.roberts@alcatel-lucent.com Email: peter.roberts@alcatel-lucent.com
Laurent Montini Laurent Montini
Cisco Systems Cisco Systems
San Jose CA San Jose CA
USA USA
Email: lmontini@cisco.com Email: lmontini@cisco.com
 End of changes. 160 change blocks. 
637 lines changed or deleted 503 lines changed or added

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