draft-ietf-tictoc-1588overmpls-04.txt   draft-ietf-tictoc-1588overmpls-05.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: August 27, 2013 M. Bhatia Expires: December 17, 2013 M. Bhatia
P. Roberts P. Roberts
Alcatel-Lucent Alcatel-Lucent
L. Montini L. Montini
L. Martini
Cisco Systems Cisco Systems
February 23, 2013 June 15, 2013
Transporting Timing messages over MPLS Networks Transporting Timing messages over MPLS Networks
draft-ietf-tictoc-1588overmpls-04 draft-ietf-tictoc-1588overmpls-05
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
Management packets, but they do not carry customer traffic. Management packets, but they do not carry customer traffic.
Two methods for transporting Timing messages over MPLS are defined. Two methods for transporting Timing messages over MPLS are defined.
The first method is to transport Timing messages directly over the The first method is to transport Timing messages directly over the
dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for
MPLS networks. The second method is to transport Timing messages MPLS networks. The second method is to transport Timing messages
inside a PW via Ethernet encapsulation, which is suitable for both inside a PW via Ethernet encapsulation.
MPLS and MPLS-TP networks.
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 August 27, 2013. This Internet-Draft will expire on December 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8
4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . 10 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . 9
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
skipping to change at page 3, line 36 skipping to change at page 2, line 51
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
13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 21 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 21
14. FCS Recalculation . . . . . . . . . . . . . . . . . . . . . . 22 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . . 22
15. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 23
15. UDP Checksum Correction . . . . . . . . . . . . . . . . . . . 23 15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . . 23
15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . . 23
16. Routing extensions for Timing-aware Routers . . . . . . . . . 24 15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . . 24
17. Signaling Extensions for Creating Timing LSPs . . . . . . . . 25 16. Other considerations . . . . . . . . . . . . . . . . . . . . . 25
18. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 26 17. Security Considerations . . . . . . . . . . . . . . . . . . . 26
18.1. Behavior of Timing-capable/aware LER . . . . . . . . . . . 26
18.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . . 26
18.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . . 26
19. Other considerations . . . . . . . . . . . . . . . . . . . . . 28 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
20. Security Considerations . . . . . . . . . . . . . . . . . . . 29 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
21. Applicability Statement . . . . . . . . . . . . . . . . . . . 30
22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
20.1. Normative References . . . . . . . . . . . . . . . . . . . 29
20.2. Informative References . . . . . . . . . . . . . . . . . . 29
23. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 Appendix 1. Routing extensions for Timing-aware Routers . . . . . 32
24. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Appendix 2. Signaling Extensions for Creating Timing LSPs . . . . 33
24.1. Normative References . . . . . . . . . . . . . . . . . . . 33
24.2. Informative References . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
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 1. Introduction
The objective of Precision Time Protocol (PTP) and Network Timing The objective of Precision Time Protocol (PTP) and Network Timing
Protocol (NTP) are to synchronize independent clocks running on Protocol (NTP) are to synchronize independent clocks running on
separate nodes of a distributed system. separate nodes of a distributed system.
[IEEE] defines PTP messages for frequency, phase and time [IEEE-1588] defines PTP messages for frequency, phase and time
synchronization. The PTP messages include PTP PDUs over UDP/IP synchronization. The PTP messages include PTP PDUs over UDP/IP
(Annex D and E of [IEEE]) and PTP PDUs over Ethernet (Annex F of (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 [IEEE-1588]). This document defines mapping and transport of the PTP
PTP messages defined in [IEEE] over MPLS/MPLS-TP networks. PTP messages defined in [IEEE-1588] over MPLS/MPLS-TP networks. PTP
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.
skipping to change at page 6, line 52 skipping to change at page 5, line 52
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 Time-stamp. 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 MPLS/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 When signaling is used to setup the PTP LSP, Extensions to signaling
establishing PTP LSPs. However such extensions are outside the scope protocols (e.g., RSVP-TE) are required for establishing PTP LSPs.
of this document. However such extensions are outside the scope 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 At the time of publishing this specification, Transparent Clocking
(TC) is only defined for PTP. Therefore at this time any part of (TC) is only defined for PTP. Therefore at this time any part of
this specification that talks about Transparent Clocking applies only this specification that talks about Transparent Clocking applies only
to PTP. to PTP.
skipping to change at page 9, line 7 skipping to change at page 8, line 7
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 Timing messages: Timing Protocol messages that are exchanged between
routers in order to establish a synchronized clock. routers in order to establish a synchronized clock.
3. Problem Statement 3. Problem Statement
[IEEE] has defined methods for transporting PTP messages over [IEEE-1588] 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,
there is a requirement to limit the possible encapsulation options to there is a requirement to limit the possible encapsulation options to
simplify the Timing message identification and processing required at simplify the Timing message identification and processing required at
the port level. the port level.
When Timing-awareness is needed, Timing messages should not be When Timing-awareness is needed, Timing messages should not be
transported over LSPs or PWs that are carrying customer traffic transported over LSPs or PWs that are carrying customer traffic
because LSRs perform Label switching based on the top label in the because LSRs perform Label switching based on the top label in the
stack. To detect Timing messages inside such LSPs require special stack. To detect Timing messages inside such LSPs require special
hardware to do deep packet inspection at line rate. Even if such hardware to do deep packet inspection at line rate. Even if such
hardware exists, the payload cant be deterministically identified by hardware exists, the payload can't be deterministically identified by
LSRs because the payload type is a context of the PW label, and the 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/ 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, 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 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 LSRs dont have the knowledge of whether PW Control Word (CW) is
present or not and therefore can not deterministically identify the present or not and therefore can not deterministically identify the
payload. payload.
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. This method can be used to detect Timing
and MPLS-TP networks. Messages in both one-step and two-step clock implementations of
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 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. End-to- act as master for other boundary clocks or for slave clocks. End-to-
End Transparent clocks do not terminate the Timing messages but they End Transparent clocks do not terminate the Timing messages but they
do modify the contents of the Timing messages as they transit across do modify the contents of the Timing messages as they transit across
the transparent clock. the transparent clock.
Master/Slave clock could be integrated in the LERs. An example is Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent Clock
shown in Figure 1, where the LERs act as Ordinary Clock (OC) and are
the initiating/terminating point for Timing messages. The ingress (TC) could be implemented in either LERs or LSRs.
LER encapsulates the Timing messages in Timing LSP and the Egress LER
terminates the Timing LSP. The LSRs act as Transparent Clock (TC) An example is shown in Figure 1, where the LERs act as Ordinary Clock
and just update the Timing field in the Timing messages. (OC) and are the initiating/terminating point for Timing messages.
The ingress LER encapsulates the Timing messages in Timing LSP and
the Egress LER terminates the Timing LSP. The LSRs act as
Transparent Clock (TC) and just update the Timing field in the Timing
messages.
+--------+ +-------+ +-------+ +-------+ +--------+ +--------+ +-------+ +-------+ +-------+ +--------+
|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/MPLS-TP network Figure (1) - Deployment example 1 of timing over MPLS network
LERs could also act as Boundary Clock (BC). This is shown in Figure Another example is shown in Figure2, where LERs terminate the Timing
2, where LERs terminate the Timing messages received from switch/ messages received from switch/routers that are outside of the MPLS
routers that are outside of the MPLS network acting as OC or BC. In network acting as OC or BC. In this example LERs regenerate the
this example LERs regenerate the clock and initiate timing messages clock and initiate timing messages encapsulated in Timing LSP toward
encapsulated in Timing LSP toward the MPLS network, while the LSRs the MPLS network, while the LSRs act as Transparent Clock (TC) and
act as Transparent Clock (TC) and just update the Timing field in the just update the Timing field in the Timing messages, which are
Timing messages, which are already encapsulated in Timing LSPs. 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/MPLS-TP network Figure (2) - Deployment example 2 of timing over MPLS network
LERs could also act as Transparent Clock (TC). This is shown in Another example is shown in Figure 3, where LERs do not terminate the
Figure 3, where LERs do not terminate the Timing messages received Timing messages received from switch/routers that are outside of the
from switch/routers that are outside of the MPLS network acting as MPLS network acting as OC, TC or BC. The LERs act as TC and update
OC, TC or BC. The LERs act as TC and update the Timing field in the the Timing field in the Timing messages as they transit the LER,
Timing messages as they transit the LER, while encapsulating them in while encapsulating them in timing LSP. The LSRs also act as
timing LSP. The LSRs also act as Transparent Clock (TC) and just Transparent Clock (TC) and just update the Timing field in the Timing
update the Timing field in the Timing messages which are already messages which are already 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 network
An MPLS domain can serve multiple customers. This means that the Another example is shown in Figure 4, where LERs and LSRs support
MPLS domain (maintained by a service provider) may provide timing Boundary Clocks. A single-hop LSP is created between two adjacent
services to multiple customers, each having their own Timing domain. LSRs engaged in BC operation. Other methods such as PTP transport
Therefore LER BCs need to interact with multiple grandmasters, and over Ethernet MAY be used for transporting timing messages if the
consequently multiple time references. Also, LER/LSR TCs MUST be link between the two routers is Ethernet.
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. |Switch, | | | | | | | |Switch, |
| Router |-----| LER |-----| LSR |-----| LER |-----| Router |
| OC/BC | | BC | | BC | | BC | | OC/BC |
+--------+ +-------+ +-------+ +-------+ +--------+
Figure (4) - Deployment example 3 of timing over MPLS network
An MPLS domain MAY serve multiple customers. In these cases the MPLS
domain (maintained by a service provider) may provide timing services
to multiple customers, each having their own Timing domain.
The Timing over MPLS architecture assumes full mesh of Timing LSPs The Timing over MPLS architecture assumes full mesh of Timing LSPs
between all LERs supporting this specification. It supports between all LERs supporting this specification. It supports
Point-to- point (VPWS) and Multipoint (VPLS) services. This means Point-to- point (VPWS) and Multipoint (VPLS) services. This means
that a customer may purchase a Point-to-point Timing service between 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 or a Multipoint Timing service between more than
two customer sites. two 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
skipping to change at page 12, line 8 skipping to change at page 12, line 8
Field update MAY be transported over Timing LSPs to simplify hardware Field update MAY be transported over Timing LSPs to simplify hardware
and software. 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 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/G-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
identify Timing messages in MPLS tunnels by just looking at the top identify Timing messages in MPLS tunnels by just looking at the top
label in the MPLS label stack, which only carry Timing messages as label in the MPLS label stack, which only carry Timing messages as
well as OAM, but not data plane client traffic. well as OAM, but not data plane client traffic.
Compliant implementations MUST use dedicated LSPs to carry Timing Compliant implementations MUST use dedicated LSPs to carry Timing
messages over MPLS. These LSPs are herein referred to as "Timing messages over MPLS. These LSPs are herein referred to as "Timing
LSPs" and the labels associated with these LSPs as "Timing LSP LSPs" and the labels associated with these LSPs as "Timing LSP
labels". The Timing LSPs that runs between Ingress and Egress LERs labels". The Timing LSPs that runs between Ingress and Egress LERs
MUST be co-routed. Alternatively, a single bidirectional co-routed MUST be co-routed. Alternatively, a single bidirectional co-routed
LSP can be used. LSP can be used.
Co-routing of the two directions is required to limit the difference Co-routing of the two directions is required to limit the difference
in the delays in the Master clock to Slave clock direction compared 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 to the Slave clock to Master clock direction. The Timing LSP MAY be
MPLS LSP or MPLS-TP LSP. MPLS/MPLS-TP LSP.
The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS. The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS.
New Extensions to RSVP-TE/GMPLS TLVs are required; however they are New Extensions to RSVP-TE/GMPLS TLVs are required; however they are
outside the scope of this document. outside the scope of this document.
The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such as The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such as
BFD and LSP Ping but the LSP data plane client plane traffic MUST be BFD and LSP Ping but the LSP data plane client plane traffic MUST be
Timing packets only. Timing packets only.
6. Timing over LSP Encapsulation 6. Timing over LSP Encapsulation
This document defines two methods for carrying Timing messages over This document defines two methods for carrying Timing messages over
MPLS. The first method is carrying UDP/IP encapsulated Timing MPLS. The first method is carrying UDP/IP encapsulated Timing
messages over Timing LSPs, which is suitable for MPLS networks and messages over Timing LSPs, and the second method, is carrying
the second method, is carrying Ethernet encapsulated Timing messages Ethernet encapsulated Timing messages over Ethernet PWs inside Timing
over Ethernet PWs inside Timing LSPs, which is suitable for MPLS and LSPs.
MPLS-TP networks.
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 simplest method of transporting Timing messages over MPLS is to
encapsulate Timing PDUs in UDP/IP and then encapsulate them in Timing encapsulate Timing PDUs in UDP/IP and then encapsulate them in Timing
LSP. This format is shown in Figure 4. LSP. This format is shown in Figure 4.
+----------------------+ +----------------------+
| Timing LSP Label | | Timing LSP Label |
+----------------------+ +----------------------+
skipping to change at page 13, line 41 skipping to change at page 13, line 40
This encapsulation is very simple and is useful when the network This encapsulation is very simple and is useful when the network
between Timing Master Clock and Slave Clock is MPLS network. between Timing Master Clock and Slave Clock is MPLS network.
In order for an LER/LSR to process Timing messages, the Timing LSP In order for an LER/LSR to process Timing messages, the Timing LSP
Label must be at the top label of the label stack. The LER/LSR MUST 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. know that the Timing LSP Label is used for carrying Timing messages.
This can be accomplished via static configuration or via RSVP-TE This can be accomplished via static configuration or via RSVP-TE
signaling. signaling.
The UDP/IP encapsulation of PTP MUST follow Annex D and E of [IEEE]. The UDP/IP encapsulation of PTP MUST follow Annex D and E of
While the UDP/IP encapsulation of NTP MUST follow [RFC5905]. [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 by
encapsulating Timing PDUs in PW which in turn is transported over encapsulating Timing PDUs in PW which in turn is transported over
Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448], Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448],
shown in Fig 5(A) MUST be used and the Ethernet encapsulation of PTP shown in Fig 5(A) MUST be used and the Ethernet encapsulation of PTP
MUST follow Annex F of [IEEE]. MUST follow Annex F of [IEEE-1588].
The Tagged mode defined in [RFC-4448] MUST be used and the Payload The RAW mode or Tagged mode defined in [RFC4448] MAY be used and the
MUST have 2 VLAN tags (S-VLAN and C-VLAN). The Timing over PW Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The
encapsulation MUST use the Control Word (CW) as specified in Timing over PW encapsulation MUST use the Control Word (CW) as
[RFC4448] to ensure proper detection of PTP messages inside the MPLS specified in [RFC4448] to ensure proper detection of PTP messages
packets for Timing over LSP and Timing over PW encapsulation. The inside the MPLS packets for Timing over LSP and Timing over PW
use of Sequence Number in the CW is optional. 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 Timing over PW encapsulation for NTP MUST use NTP over UDP/IP over PW
(the IP PW discussed in [RFC4447]) shown in Fig 5(B). (the IP PW discussed in [RFC4447]) 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 PDU |
| S-VLAN | | | |S-VLAN(Optional)| | |
+----------------+ +----------------+ +----------------+ +----------------+
| C-VLAN | (B) |C-VLAN(Optional)| (B)
+----------------+ +----------------+
| Timing PDU | | Timing PDU |
| | | |
+----------------+ +----------------+
(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 In order for an LSR to process PTP messages, the top label of the
label stack (the Tunnel Label) MUST be a Timing label. label stack (the Tunnel Label) MUST be a Timing label.
The PW method of transporting Timing over MPLS is applicable to both
MPLS and MPLS-TP networks.
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.
are defined generically enough to accommodate any such new
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 or correction field
some dont. It is the job of the LER/LSR to parse the timing message update at port level and some dont. It is the job of the LER/LSR to
and find out the type of the Timing message and decide whether and parse the timing message and find out the type of the Timing message
how to Time- stamp it (e.g., BC) or modify existing time-stamp in it and decide whether and how to Time- stamp it (e.g., BC) or update
(e.g., TC). correction field(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 or correction field update:
time-stamping.
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 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, PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP,
DELAY_RESP, and PDELAY_RESP_FOLLOW_UP messages MUST also be and PDELAY_RESP_FOLLOW_UP messages MUST also be transported over the
transported over the PTP LSPs. 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.
These message types MAY be carried in PTP Tunnel LSPs. These message types MAY be carried in PTP Tunnel LSPs.
skipping to change at page 16, line 23 skipping to change at page 16, line 23
(or port) and redundant master clocks (or ports). (or port) and redundant master clocks (or ports).
When a slave clock (or port) listens to redundant master clocks or When a slave clock (or port) listens to redundant master clocks or
ports, any prolonged Timing LSP outage will trigger the slave clock ports, any prolonged Timing LSP outage will trigger the slave clock
or port to switch to a redundant master clock or port. or port to switch to a redundant master clock or port.
LSP/PW protection such as Linear protection Switching (1:1, 1+1), LSP/PW protection such as Linear protection Switching (1:1, 1+1),
Ring protection switching or MPLS Fast Reroute (FRR) generally switch Ring protection switching or MPLS Fast Reroute (FRR) generally switch
alternative path that usually cause a change in delay, which if alternative path that usually cause a change in delay, which if
undetected by slave clock can reduce accuracy of the slave clock. undetected by slave clock can reduce accuracy of the slave clock.
However it is expected that most Slave clocks could detect the change
in delay. Therefore this specification recommends that protection Therefore protection switching MAY be used, as long as phase jumps
switching SHOULD be used, unless the operator knows that the upon switchover due to differences in path latency are detected and
protection switching may have adverse effect on the slave clock. compensated for (such compensation not being required if BCs or peer-
peer TCs are used throughout).
Note that any protection or reroute mechanism that adds additional Note that any protection or reroute mechanism that adds additional
MPLS label to the label stack, such as Facility Backup Fast Reroute, MPLS label to the label stack, such as Facility Backup Fast Reroute,
MUST ensure that the pushed label is also a Timing Label to ensure MUST ensure that the pushed label is also a Timing Label to ensure
recognition of the MPLS frame as containing Timing messages, as it recognition of the MPLS frame as containing Timing messages, as it
transits the backup path. transits the backup path.
9. ECMP 9. ECMP
To ensure the optimal operation of slave clocks and avoid error To ensure the optimal operation of slave clocks and avoid error
skipping to change at page 19, line 8 skipping to change at page 19, line 8
Multipath). Multipath).
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 used.
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 Label MUST NOT be used for the Timing LSP[RFC6790] and
Entropy MSUT NOT be used for the PWs that are carried inside Timing Entropy Label MUST NOT be used for the PWs that are carried inside
LSP [RFC6391]. Timing LSP [RFC6391].
12. OAM, Control and Management 12. OAM, Control and Management
In order to monitor 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/G-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
encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3 or 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 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 to be deprecated by IETF). In this case G-ACH, PW label (TTL=1) or
GAL-ACH are used to identify such management messages. GAL-ACH are used to identify such management messages.
13. QoS Considerations 13. QoS Considerations
In network deployments where not every LSR/LER is Timing-aware, it is 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 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 the timing recovery in the slave clock. The Timing messages are time
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 and Checksum Recalculation
When time-stamp 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
For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum
may be required as per UDP transport standards. may be required as per UDP transport standards.
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 15. Behavior of LER/LSR
MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and
IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE)
link information used for constraint-based routing.
Indeed, it is useful to advertise data plane TE router link
capabilities, such as the capability for a router to be Timing-aware.
This capability MUST then be taken into account during path
computation to prefer or even require links that advertise themselves
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
able to perform port based time-stamping thus minimizing their impact
on the performance of the slave clock.
extensions are required to OSPF and IS-IS in order to advertise
Timing-aware capabilities of a link. Such extensions are outside the
scope of this document; however such extension SHOULD be able to
signal the following information per Router Link:
o Capable of processing PTP, NTP or other Timing flows
o Capable of performing Transparent Clock operation
o Capable of performing Boundary Clock operation
17. Signaling Extensions for Creating Timing LSPs
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
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
to RSVP-TE:
o Offset from Bottom of Stack (BoS) to the start of the Time-stamp
field
o Number of VLANs in case of PW encapsulation
o Timestamp field Type
* Correction Field, Timestamp
o Timestamp Field format
* 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit
NTP, etc.
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
must have the same signaled characteristics. For example if
Timestamp format is signaled as 64-bit PTPv1, then all Timing packets
must use 64-bit PTPv1 time-stamp.
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
controller and the Timing LSP may be setup using manual configuration controller and the Timing LSP may be setup using manual configuration
or other methods such as SDN. or other methods such as SDN.
18.1. Behavior of Timing-capable/aware LER 15.1. Behavior of Timing-capable/aware LER
When a Timing-capable/aware LER behaves as a Transparent clock and When a Timing-capable/aware LER behaves as a Transparent clock and
receives a Timing message from a Timing-capable/aware non-MPLS receives a Timing message from a Timing-capable/aware non-MPLS
interface, the LER updates the Correction Field (CF) and encapsulates interface, the LER updates the Correction Field (CF) and encapsulates
and forwards the timing message over previously established Timing and forwards the timing message over previously established Timing
LSP. Also when a Timing message is received from a Timing-capable/ LSP. Also when a Timing message is received from a Timing-capable/
aware MPLS interface, LER updates the Correction Filed (CF) and aware MPLS interface, LER updates the Correction Filed (CF) and
decapsulates the MPLS encapsulation and forwards the timing message decapsulates the MPLS encapsulation and forwards the timing message
to a non-MPLS interface. to a non-MPLS interface.
skipping to change at page 26, line 41 skipping to change at page 23, line 41
LERs Boundary clock processing module. Also when a Timing message is LERs Boundary clock processing module. Also when a Timing message is
received from a Timing- capable/aware MPLS interface, the LER received from a Timing- capable/aware MPLS interface, the LER
Timestamps the Timing packet and sends it to the LERs Boundary clock Timestamps the Timing packet and sends it to the LERs Boundary clock
processing module. processing module.
When a Timing-capable/aware LER behaves as an Ordinary Clock toward When a Timing-capable/aware LER behaves as an Ordinary Clock toward
the MPLS network, and receives a Timing message from a Timing- the MPLS network, and receives a Timing message from a Timing-
capable/aware MPLS interface, the LER Timestamps the Timing packet capable/aware MPLS interface, the LER Timestamps the Timing packet
and sends it to the LERs Ordinary clock processing module. and sends it to the LERs Ordinary clock processing module.
18.2. Behavior of Timing-capable/aware LSR 15.2. Behavior of Timing-capable/aware LSR
A Timing-capable/aware LSR behaves as a Transparent clock and When a Timing-capable/aware LSR behaves as a Transparent clock and
receives a Timing message from a Timing-capable/aware MPLS interface. receives a Timing message from a Timing-capable/aware MPLS interface,
The LSR updates the Correction Filed (CF) and forwards the timing The LSR updates the Correction Filed (CF) and forwards the timing
message over another MPLS interface. message over another MPLS interface.
18.3. Behavior of non-Timing-capable/aware LSR When a Timing-capable/aware LSR behaves as a Boundary clock and
receives a Timing message from a Timing-capable/aware MPLS interface.
The LSR performs the functions of a Boundary Clock in terminating the
received Timing message and re-generating a new timing message over
another (or the same) MPLS interface.
15.3. 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 Timing 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 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 or BC).
explained in QoS section the Timing8 over MPLS packets MUST be still However as explained in QoS section the Timing over MPLS packets MUST
be treated with the highest priority based on their Traffic Class be still be treated with the highest priority based on their Traffic
(TC) marking. Class (TC) marking.
19. Other considerations 16. Other considerations
[IEEE] defines an optional peer-to-peer Transparent clocking that [IEEE-1588] defines an optional peer-to-peer Transparent clocking
requires peer delay measurement between two adjacent Timing-capable/ that requires peer delay measurement between two adjacent Timing-
aware routers/switches. Peer delay measurement messages need to be capable/ aware routers/switches. Peer delay measurement messages
time stamped and terminated by the Timing-capable/aware routers/ need to be time stamped and terminated by the Timing-capable/aware
switches. This means that two adjacent LSRs may be engaged in a peer routers/ switches. This means that two adjacent LSRs may be engaged
delay measurement. in a peer delay measurement.
For transporting such peer delay measurement messages a single-hop For transporting such peer delay measurement messages a single-hop
LSP SHOULD to be created between the two adjacent LSRs engaged in LSP SHOULD to be created between the two adjacent LSRs engaged in
peer delay measurement to carry peer delay measurement messages. peer delay measurement to carry peer delay measurement messages.
Other methods such as PTP transport over Ethernet MAY be used for Other methods such as PTP transport over Ethernet MAY be used for
transporting peer delay measurement messages if the link between the transporting peer delay measurement messages if the link between the
two routers is Ethernet. two routers is Ethernet.
In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/ ware In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/ ware
routers/switches MUST maintain a list of all the neighbors it needs 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 to send a PDelay_Req to, where each neighbor corresponds to a timing
LSP. 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 17. 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-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 maintain and process each customers clock and
Timing messages separately from other customers to ensure there is no Timing messages separately from other customers to ensure there is no
cross- customer effect. For example if an LER BC is synchronized to cross- customer effect. For example if an LER BC is synchronized to
a specific grandmaster, belonging to customer A, then the LER MUST a specific grandmaster, belonging to customer A, then the LER MUST
use that BC clock only for customer A to ensure that customer A use that BC clock only for customer A to ensure that customer A
cannot attack other customers by manipulating its time. cannot attack other customers by manipulating its time.
Timing messages (as opposed to regular customer data) SHOULD not be Timing messages MAY be encrypted or authenticated, provided that the
encrypted or authenticated on an end-to-end basis. Alternatively, LERs/LSRs that are Timing capable/aware can authenticate/ decrypt the
authentication/integrity verification mechanism can be used by a timing messages.
shared secret between the customer and provider nodes.
21. Applicability Statement
The Timing over MPLS transport methods described in this document
apply to the following network Elements:
o An LER receives IP or Ethernet Encapsulated Timing messages from a
non-MPLS interface and forwards them as MPLS encapsulated Timing
messages over Timing LSP, while performing Transparent Clock
functionality
o An LER receives MPLS encapsulated Timing messages from a Timing
LSP and forwards them to non-MPLS interface as IP or Ethernet
Encapsulated Timing messages, while performing Transparent Clock
functionality
o An LER receives MPLS encapsulated Timing messages from a Timing
LSP and terminates them, while performing the OC or BC
functionality
o An LSR receives MPLS encapsulated Timing messages from a Timing
LSP and forwards them to another MPLS interface, while performing
the TC functionality
This document also supports the case where not all LSRs are Timing-
capable/aware. It also supports the case where not all LER/LSR
interfaces are Timing-capable/aware.
22. Acknowledgements 18. Acknowledgements
The authors would like to thank Luca Martini, Ron Cohen, Yaakov The authors would like to thank Ron Cohen, Yaakov Stein, Tal Mizrahi,
Stein, Tal Mizrahi, Stefano Ruffini, Luca Moniti and other members of Stefano Ruffini, Peter Meyer, and other members of IETF for reviewing
IETF for reviewing and providing feedback on this draft. and providing feedback on this draft.
23. IANA Considerations 19. IANA Considerations
There are no IANA requirements in this specification. There are no IANA requirements in this specification.
24. References 20. References
24.1. Normative References 20.1. Normative References
[IEEE] IEEE 1588-2008, "IEEE Standard for a Precision Clock [IEEE-1588]
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".
[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, March 1997.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005. Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
skipping to change at page 33, line 45 skipping to change at page 29, line 46
Connectivity Verification (VCCV): A Control Channel for Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007. Pseudowires", RFC 5085, December 2007.
[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, June 2010.
[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, June 2010.
24.2. Informative References 20.2. Informative References
[I-D.ietf-pwe3-fat-pw] [I-D.ietf-pwe3-fat-pw]
Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
J., and S. Amante, "Flow Aware Transport of Pseudowires J., and S. Amante, "Flow Aware Transport of Pseudowires
over an MPLS Packet Switched Network", over an MPLS Packet Switched Network",
draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011. draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011.
[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 routeing information exchange protocol for use in
conjunction with the Protocol for providing the conjunction with the Protocol for providing the
skipping to change at page 36, line 5 skipping to change at page 31, line 14
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
[RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
J., and S. Amante, "Flow-Aware Transport of Pseudowires J., and S. Amante, "Flow-Aware Transport of Pseudowires
over an MPLS Packet Switched Network", RFC 6391, over an MPLS Packet Switched Network", RFC 6391,
November 2011. November 2011.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, November 2012.
1. Routing extensions for Timing-aware Routers
MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and
IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE)
link information used for constraint-based routing.
Indeed, it is useful to advertise data plane TE router link
capabilities, such as the capability for a router to be Timing-aware.
This capability MUST then be taken into account during path
computation to prefer or even require links that advertise themselves
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
able to perform port based time-stamping thus minimizing their impact
on the performance of the slave clock.
extensions are required to OSPF and IS-IS in order to advertise
Timing-aware capabilities of a link. Such extensions are outside the
scope of this document; however such extension SHOULD be able to
signal the following information per Router Link:
o Capable of processing PTP, NTP or other Timing flows
o Capable of performing Transparent Clock operation
o Capable of performing Boundary Clock operation
2. Signaling Extensions for Creating Timing LSPs
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
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
to RSVP-TE:
o Offset from Bottom of Stack (BoS) to the start of the Time-stamp
field
o Number of VLANs in case of PW encapsulation
o Timestamp field Type
* Correction Field, Timestamp
o Timestamp Field format
* 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit
NTP, etc.
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
must have the same signaled characteristics. For example if
Timestamp format is signaled as 64-bit PTPv1, then all Timing packets
must use 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
skipping to change at line 984 skipping to change at page 35, line 4
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
Luca
Cisco Systems
San Jose CA
USA
Email: lmartini@cisco.com
 End of changes. 71 change blocks. 
249 lines changed or deleted 233 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/