draft-ietf-tictoc-1588overmpls-02.txt   draft-ietf-tictoc-1588overmpls-03.txt 
TICTOC Working Group S. Davari TICTOC Working Group S. Davari
Internet-Draft A. Oren Internet-Draft A. Oren
Intended status: Standards Track Broadcom Corp. Intended status: Standards Track Broadcom Corp.
Expires: April 9, 2012 M. Bhatia Expires: April 25, 2013 M. Bhatia
P. Roberts P. Roberts
Alcatel-Lucent Alcatel-Lucent
L. Montini L. Montini
Cisco Systems Cisco Systems
October 7, 2011 October 22, 2012
Transporting PTP messages (1588) over MPLS Networks Transporting Timing messages over MPLS Networks
draft-ietf-tictoc-1588overmpls-02 draft-ietf-tictoc-1588overmpls-03
Abstract Abstract
This document defines the method for transporting PTP messages (PDUs) This document defines the method for transporting Timing messages
over an MPLS network. The method allows for the easy identification such as PTP and NTP over an MPLS network. The method allows for the
of these PDUs at the port level to allow for port level processing of easy identification of these PDUs at the port level to allow for port
these PDUs in both LERs and LSRs. level processing of these PDUs in both LERs and LSRs.
The basic idea is to transport PTP messages inside dedicated MPLS The basic idea is to transport Timing messages inside dedicated MPLS
LSPs. These LSPs only carry PTP 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 1588 over MPLS are defined. The first Two methods for transporting Timing messages over MPLS are defined.
method is to transport PTP messages directly over the dedicated MPLS The first method is to transport Timing messages directly over the
LSP via UDP/IP encapsulation, which is suitable for IP/MPLS networks. dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for
The second method is to transport PTP messages inside a PW via MPLS networks. The second method is to transport Timing messages
Ethernet encapsulation, which is more suitable for MPLS-TP networks. inside a PW via Ethernet encapsulation, which is suitable for both
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 April 9, 2012. This Internet-Draft will expire on April 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9
4. 1588 over MPLS Architecture . . . . . . . . . . . . . . . . . 9 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . 10
5. Dedicated LSPs for PTP messages . . . . . . . . . . . . . . . 10 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . . 12
6. 1588 over MPLS Encapsulation . . . . . . . . . . . . . . . . . 11 6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . 13
6.1. 1588 over LSP Encapsulation . . . . . . . . . . . . . . . 11 6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . . 13
6.2. 1588 over PW Encapsulation . . . . . . . . . . . . . . . . 11 6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . . 13
6.3. Other Timing Encapsulation methods . . . . . . . . . . . . 14
7. 1588 Message Transport . . . . . . . . . . . . . . . . . . . . 14 7. Timing Message Processing . . . . . . . . . . . . . . . . . . 15
8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 16 8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 16
9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10. OAM, Control and Management . . . . . . . . . . . . . . . . . 18 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 19 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12. FCS Recalculation . . . . . . . . . . . . . . . . . . . . . . 20 12. OAM, Control and Management . . . . . . . . . . . . . . . . . 20
13. UDP Checksum Correction . . . . . . . . . . . . . . . . . . . 21 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 21
14. Routing extensions for 1588aware LSRs . . . . . . . . . . . . 22 14. FCS Recalculation . . . . . . . . . . . . . . . . . . . . . . 22
14.1. 1588aware Link Capability for OSPF . . . . . . . . . . . . 22
14.2. 1588aware Link Capability for IS-IS . . . . . . . . . . . 23
15. RSVP-TE Extensions for support of 1588 . . . . . . . . . . . . 25 15. UDP Checksum Correction . . . . . . . . . . . . . . . . . . . 23
16. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 26 16. Routing extensions for Timing-aware Routers . . . . . . . . . 24
16.1. Behavior of 1588-aware LER . . . . . . . . . . . . . . . . 26
16.2. Behavior of 1588-aware LSR . . . . . . . . . . . . . . . . 26
16.3. Behavior of non-1588-aware LSR . . . . . . . . . . . . . . 26
17. Other considerations . . . . . . . . . . . . . . . . . . . . . 28 17. Signaling Extensions for Creating Timing LSPs . . . . . . . . 25
18. Security Considerations . . . . . . . . . . . . . . . . . . . 29 18. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 19. Other considerations . . . . . . . . . . . . . . . . . . . . . 28
20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 20. Security Considerations . . . . . . . . . . . . . . . . . . . 29
20.1. IANA Considerations for OSPF . . . . . . . . . . . . . . . 31 21. Applicability Statement . . . . . . . . . . . . . . . . . . . 30
20.2. IANA Considerations for IS-IS . . . . . . . . . . . . . . 31
20.3. IANA Considerations for RSVP . . . . . . . . . . . . . . . 31
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
21.1. Normative References . . . . . . . . . . . . . . . . . . . 32
21.2. Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 23. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
24. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
24.1. Normative References . . . . . . . . . . . . . . . . . . . 33
24.2. Informative References . . . . . . . . . . . . . . . . . . 33
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 1. Introduction
The objective of Precision Time Protocol (PTP) is to synchronize The objective of Precision Time Protocol (PTP) and Network Timing
independent clocks running on separate nodes of a distributed system. Protocol (NTP) are to synchronize independent clocks running on
[IEEE] defines PTP messages for clock and time synchronization. The separate nodes of a distributed system.
PTP messages include PTP PDUs over UDP/IP (Annex D and E of [IEEE])
and PTP PDUs over Ethernet (Annex F of [IEEE]). This document
defines mapping and transport of the PTP messages defined in [IEEE]
over MPLS networks.
PTP defines several clock types: ordinary clocks, boundary clocks, [IEEE] defines PTP messages for frequency, phase and time
end-to-end transparent clocks, and peer-to-peer transparent clocks. synchronization. The PTP messages include PTP PDUs over UDP/IP
One key attribute of all of these clocks is the recommendation for (Annex D and E of [IEEE]) and PTP PDUs over Ethernet (Annex F of
PTP messages processing to occur as close as possible to the actual [IEEE- 1588]). This document defines mapping and transport of the
PTP messages defined in [IEEE] 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
Timestamp processing should occur as close as possible to the actual
transmission and reception at the physical port interface. This transmission and reception at the physical port interface. This
targets optimal time and/or frequency recovery by avoiding variable targets optimal time and/or frequency recovery by avoiding variable
delay introduced by queues internal to the clocks. To facilitate the delay introduced by queues internal to the clocks.
fast and efficient recognition of PTP messages at the port level when
the PTP messages are carried over MPLS LSPs, this document defines
the specific encapsulations that should be used. In addition, it can
be expected that there will exist LSR/LERs where only a subset of the
physical ports will have the port based PTP message processing
capabilities. In order to ensure that the PTP carrying LSPs always
enter and exit ports with this capability, routing extensions are
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/egress ports, it becomes more important when using
Transparent Clock capable LSRs in the path.
The port based PTP message processing involves PTP event message To facilitate the fast and efficient recognition of Timing messages
recognition. Once the PTP event messages are recognized they can be at the port level when the Timing messages are carried over MPLS
modified based on the reception or transmission timestamp. An LSPs, this document defines the specific encapsulations that should
alternative technique to actual packet modification could include the be used. In addition, it can be expected that there will exist LSR/
enforcement of a fixed delay time across the LSR to remove LERs where only a subset of the physical ports will have the port-
variability in the transit delay. This latter would be applicable in based Timing message processing capabilities. In order to ensure
a LSR which does not contain a PTP transparent Clock function. that the LSPs carrying Timing packets always enter and exit ports
with this capability, routing extensions are 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.
This document provides two methods for transporting PTP messages over Port based Timing message processing involves Timing message
MPLS. One is principally focused on an IP/MPLS environment and the recognition. Once the Timing messages are recognized they can be
second is focused on the MPLS-TP environment. modified based on the reception or transmission timestamp.
This document provides two methods for transporting Timing messages
over MPLS. One is applicable to MPLS environment and the other one
is applicable to both MPLS and MPLS-TP environment.
The solution involves transporting Timing messages over dedicated
LSPs called Timing LSPs. These LSPs carry Timing messages and MAY
carry Management and control messages, but not data plane client
traffic. Timing LSPs can be established statically or via signaling.
Extensions to control plane (OSPF, ISIS, etc) is required to enable
routers to distribute their Timing processing capabilities over MPLS
to other routers. However such extensions are outside the scope of
this document.
Extensions to signaling protocols (e.g., RSVP-TE) are required for
establishing PTP LSPs. 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 PTP Timestamping 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.
2. Terminology 2. Terminology
1588: The timing and synchronization as defined by IEEE 1588 1588: The timing and synchronization as defined by IEEE 1588.
PTP: The timing and synchronization protocol used by 1588 NTP: The timing and synchronization protocol defined by IETF RFC-1305
and RFC-5905.
PTP: The timing and synchronization protocol used by 1588.
Master Clock: The source of 1588 timing to a set of slave clocks. Master Clock: The source of 1588 timing to a set of slave clocks.
Master Port: A port on a ordinary or boundary clock that is in Master Master Port: A port on a ordinary or boundary clock that is in Master
state. This is the source of timing toward slave ports. state. This is the source of timing toward slave ports.
Slave Clock: A receiver of 1588 timing from a master clock Slave Clock: A receiver of 1588 timing from a master clock.
Slave Port: A port on a boundary clock or ordinary clock that is Slave Port: A port on a boundary clock or ordinary clock that is
receiving timing from a master clock. receiving timing from a master clock.
Ordinary Clock: A device with a single PTP port. Ordinary Clock: A device with a single PTP port.
Transparent Clock. A device that measures the time taken for a PTP Transparent Clock. A device that measures the time taken for a PTP
event message to transit the device and then updates the event message to transit the device and then updates the
correctionField of the message with this transit time. correctionField of the message with this transit time.
skipping to change at page 8, line 7 skipping to change at page 9, line 7
LAG: Link Aggregation LAG: Link Aggregation
ECMP: Equal Cost Multipath ECMP: Equal Cost Multipath
CF: Correction Field, a field inside certain PTP messages (message CF: Correction Field, a field inside certain PTP messages (message
type 0-3)that holds the accumulative transit time inside intermediate type 0-3)that holds the accumulative transit time inside intermediate
switches switches
3. Problem Statement 3. Problem Statement
When PTP messages are transported over MPLS networks, there is a need [IEEE] has defined methods for transporting PTP messages over
for PTP message processing at the physical port level. This Ethernet and IP networks. [RFC5905] has defined the method of
requirement exists to minimum uncertainty in the transit delays. If transporting NTP messages over IP networks. There is a need to
PTP message processing occurs interior to the MPLS routers, then the transport Timing messages over MPLS networks while supporting the
variable delay introduced by queuing between the physical port and Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (OC)
the PTP processing will add noise to the timing distribution. Port functionality in the LER and LSRs in the MPLS network.
based processing applies at both the originating and terminating LERs
and also at the intermediate LSRs if they support transparent clock
functionality.
PTP messages over Ethernet or IP can always be tunneled over MPLS.
However there is a requirement to limit the possible encapsulation
options to simplify the PTP message processing required at the port
level. This applies to all 1588 clock types implemented in MPLS
routers. But this is particularly important in LSRs that provide
transparent clock functionality.
When 1588-awareness is needed, PTP messages should not be transported
over LSPs or PWs that are carrying customer traffic because LSRs
perform Label switching based on the top label in the stack. To
detect PTP messages inside such LSPs require special hardware to do
deep packet inspection at line rate. Even if such hardware exists,
the payload can't 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); LSRs don't know
what is a PW's payload (Ethernet, ATM, FR, CES, etc). Even if one
restricts an LSP to only carry Etehrent PWs, the LSRs don't have the
knowledge of whether PW Control Word (CW) is present or not and
therefore can't deterministically identify the payload.
Therefore a generic method is defined in this document that does not
require deep packet inspection at line rate, and can
deterministically identify PTP messages. The defined method is
applicable to both MPLS and MPLS-TP networks.
4. 1588 over MPLS Architecture 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.
1588 communication flows map onto MPLS nodes as follows: 1588 When Timing-awareness is needed, Timing messages should not be
messages are exchange between PTP ports on Ordinary and boundary transported over LSPs or PWs that are carrying customer traffic
clocks. Transparent clocks do not terminate the PTP messages but because LSRs perform Label switching based on the top label in the
they do modify the contents of the PTP messages as they transit stack. To detect Timing messages inside such LSPs require special
across the Transparent clock. SO Ordinary and boundary clocks would hardware to do deep packet inspection at line rate. Even if such
exist within LERs as they are the termination points for the PTP hardware exists, the payload cant be deterministically identified by
messages carried in MPLS. Transparent clocks would exist within LSRs LSRs because the payload type is a context of the PW label, and the
as they do not terminate the PTP message exchange. 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.
Perhaps a picture would be good here. A generic method is defined in this document that does not require
deep packet inspection at line rate, and can deterministically
identify Timing messages. The generic method is applicable to MPLS
and MPLS-TP networks.
5. Dedicated LSPs for PTP messages 4. Timing over MPLS Architecture
Many methods were considered for identifying the 1588 messages when Timing messages are exchange between Timing ports on ordinary and
they are encapsulated in MPLS such as by using GAL/ACH or a new boundary clocks. Boundary clocks terminate the Timing messages and
reserved label. These methods were not attractive since they either act as master for other boundary clocks or for slave clocks.
required deep packet inspection and snooping at line rate or they Transparent clocks do not terminate the Timing messages but they do
required use of a scarce new reserved label. Also one of the goals modify the contents of the Timing messages as they transit across the
was to reuse existing OAM and protection mechanisms. transparent clock.
The method defined in this document can be used by LER/LSRs to Master/Slave clock could be integrated in the LERs. An example is
identify PTP messages in MPLS tunnels by using dedicated LSPs to shown in Figure 1, where the LERs act as Ordinary Clock (OC) and are
carry PTP messages. 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.
Compliant implementations MUST use dedicated LSPs to carry PTP +--------+ +-------+ +-------+ +-------+ +--------+
messages over MPLS. These LSPs are herein referred to as "PTP LSPs" |Switch, | | | | | | | |Switch, |
and the labels associated with these LSPs as "PTP labels". These | Router |-----| LER |-----| LSR |-----| LER |-----| Router |
LSPs could be P2P or P2MP LSPs. The PTP LSP between Master Clocks | | | OC | | TC | | OC | | |
and Slave Clocks MAY be P2MP or P2P LSP while the PTP LSP between +--------+ +-------+ +-------+ +-------+ +--------+
each Slave Clock and Master Clock SHOULD be P2P LSP. The PTP LSP / \
between a Master Clock and a Slave Clock and the PTP LSP between the +-------+ / \ +-------+
same Slave Clock and Master Clock MUST be co-routed. Alternatively, | LER | / \ | LER |
a single bidirectional co-routed LSP can be used. The PTP LSP MAY be | Master|---/ \---| Slave |
MPLS LSP or MPLS-TP LSP. This co-routing is required to limit | Clock | | Clock |
differences in the delays in the Master clock to Slave clock +-------+ +-------+
direction compared to the Slave clock to Master clock direction.
The PTP LSPs could be configured or signaled via RSVP-TE/GMPLS. New Figure (1) - Deployment example 1 of timing over MPLS/MPLS-TP network
RSVP-TE/GMPLS TLVs and objects are defined in this document to
indicate that these LSPs are PTP LSPs.
The PTP LSPs MAY carry essential MPLS/MPLS-TP control plane traffic LERs could also act as Boundary Clock (BC). This is shown in Figure
such as BFD and LSP Ping but the LSP user plane traffic MUST be PTP 2, where LERs terminate the Timing messages received from switch/
only. routers that are outside of the MPLS network acting as OC or BC. In
this example LERs regenerate the clock and initiate timing messages
encapsulated in Timing LSP toward the MPLS network, while the LSRs
act as Transparent Clock (TC) and just update the Timing field in the
Timing messages, which are already encapsulated in Timing LSPs.
6. 1588 over MPLS Encapsulation +--------+ +-------+ +-------+ +-------+ +--------+
|Switch, | | | | | | | |Switch, |
| Router |-----| LER |-----| LSR |-----| LER |-----| Router |
| OC/BC | | BC | | TC | | BC | | OC/BC |
+--------+ +-------+ +-------+ +-------+ +--------+
This document defines two methods for carrying PTP messages over Figure (2) - Deployment example 2 of timing over MPLS/MPLS-TP network
MPLS. The first method is carrying IP encapsulated PTP messages over
PTP LSPs and the second method is to carry PTP messages over
dedicated Ethernet PWs (called PTP PWs) inside PTP LSPs.
6.1. 1588 over LSP Encapsulation LERs could also act as Transparent Clock (TC). This is shown in
Figure 3, where LERs do not terminate the 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.
The simplest method of transporting PTP messages over MPLS is to +--------+ +-------+ +-------+ +-------+ +--------+
encapsulate PTP PDUs in UDP/IP and then encapsulate them in PTP LSP. |Switch, | | | | | | | |Switch, |
The 1588 over LSP format is shown in Figure 1. | Router |-----| LER |-----| LSR |-----| LER |-----| Router |
|OC/TC/BC| | TC | | TC | | TC | |OC/TC/BC|
+--------+ +-------+ +-------+ +-------+ +--------+
+----------------------+ Figure (3) - Deployment example 3 of timing over MPLS/MPLS-TP network
| PTP Tunnel Label |
+----------------------+
| IPv4/6 |
+----------------------+
| UDP |
+----------------------+
| PTP PDU |
+----------------------+
Figure 1 - 1588 over LSP Encapsulation 5. Dedicated LSPs for Timing messages
This encapsulation is very simple and is useful when the networks Many methods have been considered for identifying the Timing messages
between 1588 Master Clock and Slave Clock are IP/MPLS networks. when they are encapsulated in MPLS such as using GAL/ACH or a new
reserved label. These methods were not attractive since they either
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
goals was to reuse existing OAM mechanisms.
In order for an LSR to process PTP messages, the PTP Label must be The method defined in this document can be used by LER and LSRs to
the top label of the label stack. 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.
The UDP/IP encapsulation of PTP MUST follow Annex D and E of [IEEE]. 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.
6.2. 1588 over PW Encapsulation 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 or MPLS-TP LSP.
Another method of transporting 1588 over MPLS networks is by The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS.
encapsulating PTP PDUs in Ethernet and then transporting them over New Extensions to RSVP-TE/GMPLS TLVs are required; however they are
Ethernet PW (PTP PW) as defined in [RFC4448], which in turn is outside the scope of this document.
transported over PTP LSPs. Alternatively PTP PDUs MAY be
encapsulated in UDP/IP/Ethernet and then transported over Ethernet
PW.
Both Raw and Tagged modes for Ethernet PW are permitted. The 1588 The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such as
over PW format is shown in Figure 2. BFD and LSP Ping but the LSP data plane client plane traffic MUST be
Timing packets only.
+----------------+ 6. Timing over LSP Encapsulation
|PTP Tunnel Label|
+----------------+
| PW Label |
+----------------+
| Control Word |
+----------------+
| Ethernet |
| Header |
+----------------+
| VLANs |
| (optional) |
+----------------+
| IPV4/V6 |
| (optional) |
+----------------+
| UDP |
| (optional) |
+----------------+
| PTP PDU |
+----------------+
Figure 2 - 1588 over PW Encapsulation This document defines two methods for carrying Timing messages over
MPLS. The first method is carrying UDP/IP encapsulated Timing
messages over Timing LSPs, which is suitable for MPLS networks and
the second method, is carrying Ethernet encapsulated Timing messages
over Ethernet PWs inside Timing LSPs, which is suitable for MPLS and
MPLS-TP networks.
The Control Word (CW) as specified in [RFC4448] SHOULD be used to 6.1. Timing over UDP/IP over MPLS Encapsulation
ensure a more robust detection of PTP messages inside the MPLS
packet. If CW is used, the use of Sequence number is optional.
The use of VLAN and UDP/IP are optional. Note that 1 or 2 VLANs MAY The simplest method of transporting Timing messages over MPLS is to
exist in the PW payload. encapsulate Timing PDUs in UDP/IP and then encapsulate them in Timing
LSP. This format is shown in Figure 4.
In order for an LSR to process PTP messages, the top label of the +----------------------+
label stack (the Tunnel Label) MUST be from PTP label range. However | Timing LSP Label |
in some applications the PW label may be the top label in the stack, +----------------------+
such as cases where there is only one-hop between PEs or in case of | IPv4/6 |
PHP. In such cases, the PW label SHOULD be chosen from the PTP Label +----------------------+
range. | UDP |
+----------------------+
| Timing PDU |
+----------------------+
In order to ensure congruency between the two directions of PTP Figure (4) - Timing over UDP/IP over MPLS Encapsulation
message flow, ECMP should not be used for the PTP LSPs. Therefore,
no Entropy label [I-D.ietf-pwe3-fat-pw] is necessary and it SHOULD
NOT be present in the stack.
The Ethernet encapsulation of PTP MUST follow Annex F of [IEEE] and This encapsulation is very simple and is useful when the network
the UDP/IP encapsulation of PTP MUST follow Annex D and E of [IEEE]. between Timing Master Clock and Slave Clock is MPLS network.
For 1588 over MPLS encapsulations that are PW based, there are some In order for an LER/LSR to process Timing messages, the Timing LSP
cases in which the PTP LSP label may not be present: 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.
o When PHP is applied to the PTP LSP, and the packet is received The UDP/IP encapsulation of PTP MUST follow Annex D and E of [IEEE].
without PTP LSP label at PW termination point . While the UDP/IP encapsulation of NTP MUST follow [RFC5905].
o When the PW is established between two routers directly connected 6.2. Timing over PW Encapsulation
to each other and no PTP LSP is needed.
In such cases it is required for a router to identify these packets Another method of transporting Timing over MPLS networks is by
as PTP packets. This would require the PW label to also be a label encapsulating Timing PDUs in PW which in turn is transported over
that is distributed specifically for carrying PTP traffic (aka PTP PW Timing LSPs. In case of PTP, Ethernet PW encapsulation [RFC4448],
label). Therefore there is a need to add extension to LDP/BGP PW shown in Fig 5(A) MUST be used and the Ethernet encapsulation of PTP
label distribution protocol to indicate that a PW label is a PTP PW MUST follow Annex F of [IEEE].
labels.
7. 1588 Message Transport The Tagged mode defined in [RFC-4448] MUST be used and the Payload
MUST have 2 VLAN tags (S-VLAN and C-VLAN). The Timing over PW
encapsulation MUST use the Control Word (CW) as specified in
[RFC4448] to ensure proper detection of PTP messages inside the MPLS
packets for Timing over LSP and Timing over PW encapsulation. The
use of Sequence Number in the CW is optional.
1588 protocol comprises of the following message types: 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).
o Announce +----------------+ +----------------+
|Timing LSP Label| |Timing LSP Label|
+----------------+ +----------------+
| PW Label | | PW Label |
+----------------+ +----------------+
| Control Word | | IP |
+----------------+ +----------------+
| Ethernet | | UDP |
| Header | +----------------+
+----------------+ | Timing PDU |
| S-VLAN | | |
+----------------+ +----------------+
| C-VLAN | (B)
+----------------+
| Timing PDU |
| |
+----------------+
(A)
o SYNC Figure (5) - Timing over PW Encapsulations
o FOLLOW UP In order for an LSR to process PTP messages, the top label of the
label stack (the Tunnel Label) MUST be a Timing label.
o DELAY_REQ (Delay Request) The PW method of transporting Timing over MPLS is applicable to both
MPLS and MPLS-TP networks.
o DELAY_RESP (Delay Response) 6.3. Other Timing Encapsulation methods
o PDELAY_REQ (Peer Delay Request) 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. The control and signaling requirements in this document
are defined generically enough to accommodate any such new
encapsulations.
o PDELAY_RESP (Peer Delay Response) 7. Timing Message Processing
o PDELAY_RESP_FOLLOW_UP (Peer Delay Response Follow up) Each Timing protocol such as PTP and NTP, define their set of Timing
messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP,
FOLLOW_UP, etc messages.
o Management Some of the Timing messages require time stamping at port level and
some dont. It is the job of the LER/LSR to parse the timing message
and find out the type of the Timing message and decide whether and
how to Time- stamp it (e.g., BC) or modify existing timestamp in it
(e.g., TC).
o Signaling For example the following PTP messages (called Event messages)
require time-stamping, while other Non-Event PTP messages do not need
time-stamping.
A subset of PTP message types that require timestamp processing are o Announce
called Event messages:
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
skipping to change at page 15, line 6 skipping to change at page 15, line 46
DELAY_RESP, and PDELAY_RESP_FOLLOW_UP messages must also be DELAY_RESP, and PDELAY_RESP_FOLLOW_UP messages must also be
transported over the PTP LSPs. transported over the PTP LSPs.
For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be
transported over two PTP LSPs that are in opposite directions. These transported over two PTP LSPs that are in opposite directions. These
PTP LSPs, which are in opposite directions MUST be congruent and co- PTP LSPs, which are in opposite directions MUST be congruent and co-
routed. Alternatively, a single bidirectional co-routed LSP can be routed. Alternatively, a single bidirectional co-routed LSP can be
used. used.
Except as indicated above for the two-step PTP clocks, Non-Event PTP Except as indicated above for the two-step PTP clocks, Non-Event PTP
message types don't 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.
8. Protection and Redundancy 8. Protection and Redundancy
In order to ensure continuous uninterrupted operation of 1588 Slaves, In order to ensure continuous uninterrupted operation of slave
usually as a general practice, Redundant Masters are tracked by each clocks, usually as a general practice, slave clocks (or ports) track
Slave. It is the responsibility of the network operator to ensure redundant master clocks.
that physically disjoint PTP tunnels that don't share any link are
used between the redundant Masters and a Slave.
When redundant Masters are tracked by a Slave, any prolonged PTP LSP It is the responsibility of the network operator to ensure that
or PTP PW outage will trigger the Slave Clock to switch to the physically disjoint Timing LSPs are established between a slave clock
Redundant Master Clock. However LSP/PW protection such as Linear (or port) and redundant master clocks (or ports).
Protection Switching (1:1,1+1), Ring protection switching or MPLS
Fast Reroute (FRR) SHOULD still be used to provide resiliency to When a slave clock (or port) listens to redundant master clocks or
individual network segment failures.. 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),
Ring protection switching or MPLS Fast Reroute (FRR) generally switch
alternative path that usually cause a change in delay, which if
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
switching SHOULD be used, unless the operator knows that the
protection switching may have adverse effect on the slave clock.
Note that any protection or reroute mechanism that adds additional Note that any protection or reroute mechanism that adds additional
label to the label stack, such as Facility Backup Fast Reroute, MUST MPLS label to the label stack, such as Facility Backup Fast Reroute,
ensure that the pushed label is a PTP Label to ensure recognition of MUST ensure that the pushed label is also a Timing Label to ensure
the MPLS frame as containing PTP messages as it transits the backup recognition of the MPLS frame as containing Timing messages, as it
path.. transits the backup path.
9. ECMP 9. ECMP
To ensure the optimal operation of 1588 Slave clocks and avoid errors To ensure the optimal 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 PTP messages from Master Clock to Slave Clock and vice versa path for Timing messages from master clock to slave Clock and vice
must be the same for all PTP messages listed in section 7 and must versa must be the same for all Event Timing messages listed in
not change even in the presence of ECMP in the MPLS network. section 7.
To ensure the forward and reverse paths are the same PTP LSPs and PWs Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost
MUST NOT be subject to ECMP. Multipath).
10. OAM, Control and Management 10. PHP
In order to manage PTP LSPs and PTP PWs, they MAY carry OAM, Control To ensure that the label on the top of the label stack is the Timing
and Management messages. These control and management messages can LSP Label, PHP MUST not be used.
be differentiated from PTP messages via already defined IETF methods.
In particular BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389]MAY run 11. Entropy
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 MSUT NOT be used for the PWs that are carried inside Timing
LSP [RFC6391].
12. OAM, Control and Management
IIn order to manage Timing LSPs and their encapsulated PWs, they MUST
be able to carry OAM and management messages. These management
messages MUST be differentiated from Timing messages via already
defined IETF methods.
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 are easily identified by the UDP Destination Management protocols can easily be identified by the UDP Destination
Port number or by GAL/ACH respectively. Port number or by GAL/ACH respectively.
Also BFD, LSP-Ping and other Management messages MAY run over PTP PW Also BFD, LSP-Ping and other management messages MAY run over the PWs
via one of the defined VCCVs (Type 1, 2 or 3) [RFC5085]. In this encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3 or
case G-ACH, Router Alert Label (RAL), or PW label (TTL=1) are used to 4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is going
identify such management messages. to be deprecated by IETF). In this case G-ACH, PW label (TTL=1) or
GAL-ACH are used to identify such management messages.
11. QoS Considerations 13. QoS Considerations
In network deployments where not every LSR/LER is PTP-aware, then it In network deployments where not every LSR/LER is Timing-aware, it is
is important to reduce the impact of the non-PTP-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 PTP 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
1588 over MPLS messages must be treated with the highest priority in Timing over MPLS messages must be treated with the highest priority
the routers. This can be achieved by proper setup of PTP tunnels. in the routers. This can be achieved by proper setup of Timing LSPs.
It is recommended that the PTP LSPs are setup and marked properly to
indicate EF-PHB for the CoS and Green for drop eligibility.
In network deployments where every LSR/LER supports PTP LSPs, then it It is recommended that the Timing LSPs are setup or configured
MAY NOT be required to apply the same level of prioritization as properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC2697]
specified above. for drop eligibility.
12. FCS Recalculation 14. FCS Recalculation
Ethernet FCS of the outer encapsulation MUST be recalculated at every When timestamp generation and timing packet adjustment is performed
LSR that performs the Transparent Clock processing and FCS retention near the physical port hardware, the process MUST include
for the payload Ethernet described in [RFC4720] MUST NOT be used. recalculation of the Ethernet FCS. Also FCS retention for the
payload Ethernet described in [RFC4720] MUST NOT be used.
13. UDP Checksum Correction 15. UDP Checksum Correction
For UDP/IP encapsulation mode of 1588 over MPLS, the UDP checksum is For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum
optional when used for IPv4 encapsulation and mandatory in case of is optional when used for IPv4 encapsulation and mandatory in case of
IPv6. When IPv4/v6 UDP checksum is used each 1588-aware LSR must IPv6.
either incrementally update the UDP checksum after the CF update or
should verify the UDP checksum on reception from upstream and
recalculate the checksum completely on transmission after CF update
to downstream node.
14. Routing extensions for 1588aware LSRs When UDP checksum is used, each Timing-aware LER/LSR must either
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.
16. Routing extensions for Timing-aware Routers
MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and
IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE) IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE)
link information used for constraint-based routing. link information used for constraint-based routing.
Indeed, it is useful to advertise data plane TE router link Indeed, it is useful to advertise data plane TE router link
capabilities, such as the capability for a router to be 1588-aware. capabilities, such as the capability for a router to be Timing-aware.
This capability MUST then be taken into account during path This capability MUST then be taken into account during path
computation to prefer or even require links that advertise themselves computation to prefer or even require links that advertise themselves
as 1588-aware. In this way the path can ensure the entry and exit as Timing-aware. In this way the path can ensure the entry and exit
points into the LERs and, if desired, the links into the LSRs are points into the LERs and, if desired, the links into the LSRs are
able to perform port based timestamping thus minimizing their impact able to perform port based timestamping thus minimizing their impact
on the performance of the slave clock. on the performance of the slave clock.
For this purpose, the following sections specify extensions to OSPF extensions are required to OSPF and IS-IS in order to advertise
and IS-IS in order to advertise 1588 aware capabilities of a link. Timing-aware capabilities of a link. Such extensions are outside the
scope of this document; however such extension SHOULD be able to
14.1. 1588aware Link Capability for OSPF signal the following information per Router Link:
OSPF uses the Link TLV (Type 2) that is itself carried within either
the Traffic Engineering LSA specified in [RFC3630] or the OSPFv3
Intra-Area-TE LSA (function code 10) defined in [RFC5329] to
advertise the TE related information for the locally attached router
links. For an LSA Type 10, one LSA can contain one Link TLV
information for a single link. This extension defines a new 1588-
aware capability sub-TLV that can be carried as part of the Link TLV.
The 1588-aware capability sub-TLV is OPTIONAL and MUST NOT appear
more than once within the Link TLV. If a second instance of the
1588-aware capability sub-TLV is present, the receiving system MUST
only process the first instance of the sub-TLV. It is defined as
follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+
Figure 3: 1588-aware Capability TLV
Where:
Type, 16 bits: 1588-aware Capability TLV where the value is TBD
Length, 16 bits: Gives the length of the flags field in octets, and
is currently set to 1
Flags, 8 bits: The bits are defined least-significant-bit (LSB)
first, so bit 7 is the least significant bit of the flags octet.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |C|
+-+-+-+-+-+-+-+-+
Figure 4: Flags Format
Correction (C) field Update field, 1 bit: Setting the C bit to 1
indicates that the link is capable of recognizing the PTP event
packets and can compensate for residence time by updating the PTP
packet Correction Field. When this is set to 0, it means that this
link cannot perform the residence time correction but is capable of
performing MPLS frame forwarding of the frames with PTP labels using
a method that support the end to end delivery of accurate timing.
The exact method is not defined herein.
Reserved, 7 bits: Reserved for future use. The reserved bits must be
ignored by the receiver.
The 1588-aware Capability sub-TLV is applicable to both OSPFv2 and
OSPFv3.
14.2. 1588aware Link Capability for IS-IS
The IS-IS Traffic Engineering [RFC3784] defines the intra-area
traffic engineering enhancements and uses the Extended IS
Reachability TLV (Type 22) [RFC5305] to carry the per link TE-related
information. This extension defines a new 1588-aware capability sub-
TLV that can be carried as part of the Extended IS Reachability TLV.
The 1588-aware capability sub-TLV is OPTIONAL and MUST NOT appear
more than once within the Extended IS Reachability TLV or the Multi-
Topology (MT) Intermediate Systems TLV (type 222) specified in
[RFC5120]. If a second instance of the 1588-aware capability sub-TLV
is present, the receiving system MUST only process the first instance
of the sub-TLV.
The format of the IS-IS 1588-aware sub-TLV is identical to the TLV
format used by the Traffic Engineering Extensions to IS-IS [RFC3784].
That is, the TLV is comprised of 1 octet for the type, 1 octet
specifying the TLV length, and a value field. The Length field
defines the length of the value portion in octets.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: 1588-aware Capability sub-TLV
Where:
Type, 8 bits: 1588-aware Capability sub-TLV where the value is TBD
Length, 8 bits: Gives the length of the flags field in octets, and is
currently set to 1
Flags, 8 bits: The bits are defined least-significant-bit (LSB)
first, so bit 7 is the least significant bit of the flags octet.
0 1 2 3 4 5 6 7 o Capable of processing PTP, NTP or other Timing flows
+-+-+-+-+-+-+-+-+
| Reserved |C|
+-+-+-+-+-+-+-+-+
Figure 6: Flags Format o Capable of performing Transparent Clock operation
Correction (C) field Update field, 1 bit: Setting the C bit to 1 o Capable of performing Boundary Clock operation
indicates that the link is capable of recognizing the PTP event
packets and can compensate for residence time by updating the PTP
packet Correction Field. When this is set to 0, it means that this
link cannot perform the residence time correction but is capable of
performing MPLS frame forwarding of the frames with PTP labels using
a method that support the end to end delivery of accurate timing.
The exact method is not defined herein.
Reserved, 7 bits: Reserved for future use. The reserved bits must be 17. Signaling Extensions for Creating Timing LSPs
ignored by the receiver.
15. RSVP-TE Extensions for support of 1588 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:
RSVP-TE signaling MAY be used to setup the PTP LSPs. A new RSVP The following information MAY also be included in the new Extensions
object is defined to signal that this is a PTP LSP. The OFFSET to to RSVP-TE:
the start of the PTP message header MAY also be signaled.
Implementations can trivially locate the correctionField (CF)
location given this information. The OFFSET points to the start of
the PTP header as a node may want to check the PTP messageType before
it touches the correctionField (CF). The OFFSET is counted from TBD
The LSRs that receive and process the RSVP-TE/GMPLS messages MAY use o Offset from Bottom of Stack (BoS) to the start of the Timestamp
the OFFSET to locate the start of the PTP message header. field
Note that the new object/TLV Must be ignored by LSRs that are not o Number of VLANs in case of PW encapsulation
compliant to this specification.
The new RSVP 1588_PTP_LSP object should be included in signaling PTP o Timestamp field Type
LSPs and is defined as follows:
0 1 2 3 * Correction Field, Timestamp
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| Offset to locate the start of the PTP message header |
+-------------+-------------+-------------+-------------+
Figure 7: RSVP 1588_PTP_LSP object o Timestamp Field format
The ingress LSR MUST include this object in the RSVP PATH Message. * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit
It is just a normal RSVP path that is exclusively set up for PTP NTP, etc.
messages
16. Behavior of LER/LSR 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 timestamp.
16.1. Behavior of 1588-aware LER 18. Behavior of LER/LSR
A 1588-aware LER advertises it's 1588-awareness via the OSPF Timing-capable/aware LERs and LSRs are routers that have one or more
procedure explained in earlier section of this specification. The interfaces that can perform Timing operations (OC/BC/TC) on Timing
1588-aware LER then signals PTP LSPs by including the 1588_PTP_LSP packets and are configured to do so. Timing-capable/aware LERs and
object in the RSVP-TE signaling. LSRs can advertise their Timing-capability per-interface via control
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.
When a 1588 message is received from a non-MPLS interface, the LER 18.1. Behavior of Timing-capable/aware LER
MUST redirect them to a previously established PTP LSP. When a 1588
over MPLS message is received from an MPLS interface, the processing
is similar to 1588-aware LSR processing.
16.2. Behavior of 1588-aware LSR When a Timing-capable/aware LER behaves as a Transparent clock and
receives a Timing message from a Timing-capable/aware non-MPLS
interface, the LER updates the Correction Field (CF) and encapsulates
and forwards the timing message over previously established Timing
LSP. Also when a Timing message is received from a Timing-capable/
aware MPLS interface, LER updates the Correction Filed (CF) and
decapsulates the MPLS encapsulation and forwards the timing message
to a non-MPLS interface.
1588-aware LSRs are LSRs that understand the 1588_PTP_LSP RSVP object When a Timing-capable/aware LER behaves as a Boundary clock and
and can perform 1588 processing (e.g. Transparent Clock processing). 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.
A 1588-aware LSR advertises it's 1588-awareness via the OSPF When a Timing-capable/aware LER behaves as an Ordinary Clock toward
procedure explained in earlier section of this specification. the MPLS network, and receives a Timing message from a Timing-
capable/aware MPLS interface, the LER Timestamps the Timing packet
and sends it to the LERs Ordinary clock processing module.
When a 1588-aware LSR distributes a label for PTP LSP, it maintains 18.2. Behavior of Timing-capable/aware LSR
this information. When the 1588-aware LSR receives an MPLS packet,
it performs a label lookup and if the label lookup indicates it is a
PTP label then further parsing must be done to positively identify
that the payload is 1588 and not OAM, BFD or control and management.
Ruling out non-1588 messages can easily be done when parsing
indicates the presence of GAL, ACH or VCCV (Type 1, 2, 3) or when the
UDP port number does not match one of the 1588 UDP port numbers.
After a 1588 message is positively identified in a PTP LSP, the PTP A Timing-capable/aware LSR behaves as a Transparent clock and
message type indicates whether any timestamp processing is required. receives a Timing message from a Timing-capable/aware MPLS interface.
After 1588 processing the packet is forwarded as a normal MPLS packet The LSR updates the Correction Filed (CF) and forwards the timing
to downstream node. message over another MPLS interface.
16.3. Behavior of non-1588-aware LSR 18.3. Behavior of non-Timing-capable/aware LSR
It is most beneficial that all LSRs in the path of a PTP LSP be 1588- It is most beneficial when all LSRs in the path of a Timing LSP be
aware LSRs. This would ensure the highest quality time and clock timing-Capable/aware LSRs. This would ensure the highest quality
synchronization by 1588 Slave Clocks. However, this specification time and clock synchronization by Timing Slave Clocks. However, this
does not mandate that all LSRs in path of a PTP LSP be 1588-aware. specification does not mandate that all LSRs in path of a Timing LSP
be Timing- capable/aware.
Non-1588-aware LSRs are LSRs that either don't have the capability to Non-Timing-capable/aware LSRs just switch the packets encapsulated in
process 1588 packets (e.g. perform Transparent Clock processing) or Timing LSPs and dont perform any Timing operation (TC). However as
don't understand the 1588_PTP_LSP RSVP object. explained in QoS section the Timing8 over MPLS packets MUST be still
be treated with the highest priority based on their Traffic Class
(TC) marking.
Non-1588-aware LSRs ignore the RSVP 1588_PTP_LSP object and just 19. Other considerations
switch the MPLS packets carrying 1588 messages as data packets and
don't perform any timestamp related processing. However as explained
in QoS section the 1588 over MPLS packets MUST be still be treated
with the highest priority.
17. Other considerations [IEEE] Tdefines an optional peer-to-peer Transparent clocking that
requires peer delay measurement between two adjacent Timing-capable/
ware routers/switches. Peer delay measurement messages need to be
time stamped and terminated by the Timing-capable/aware routers/
switches. This means that two adjacent LSRs may be engaged in a peer
delay measurement. Such peer delay measurement messages SHALL NOT
use the Timing LSP that runs between two LERs. For transporting such
peer delay measurement messages there are two options. Either a
single-hop LSP needs to be created between the two adjacent LSRs
engaged in peer delay measurement to carry peer delay measurement
messages, or other methods such as PTP transport over Ethernet may be
used for transporting peer delay measurement messages if the link
between the two routers is Ethernet.
The use of Explicit Null (Label= 0 or 2) is acceptable as long as The use of Explicit Null Label (Label= 0 or 2) is acceptable as long
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.
The use of Penultimate Hop Pop (PHP) is acceptable as long as either 20. Security Considerations
the PHP label is the bottom of stack label (applicable only to UDP/IP
encapsulation) or the label below the PHP label is a PTP label.
18. Security Considerations
MPLS PW security considerations in general are discussed in [RFC3985] MPLS PW security considerations in general are discussed in [RFC3985]
and [RFC4447],and those considerations also apply to this document. and [RFC4447],and those considerations also apply to this document.
An experimental security protocol is defined in [IEEE]. The PTP An experimental security protocol is defined in [IEEE].The PTP
security extension and protocol provides group source authentication, security extension and protocol provides group source authentication,
message integrity, and replay attack protection for PTP messages. message integrity, and replay attack protection for PTP messages.
19. Acknowledgements 21. Applicability Statement
The authors would like to thank Luca Martini, Ron Cohen, Yaakov
Stein, Tal Mizrahi and other members of the TICTOC WG for reviewing
and providing feedback on this draft.
20. IANA Considerations
20.1. IANA Considerations for OSPF
IANA has defined a sub-registry for the sub-TLVs carried in an OSPF
TE Link TLV (type 2). IANA is requested to assign a new sub-TLV
codepoint for the 1588aware capability sub-TLV carried within the
Router Link TLV.
Value Sub-TLV References The Timing over MPLS transport methods described in this document
----- ---------------------- ---------- apply to the following network Elements:
TBD 1588aware node sub-TLV (this document)
20.2. IANA Considerations for IS-IS 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
IANA has defined a sub-registry for the sub-TLVs carried in the IS-IS o An LER receives MPLS encapsulated Timing messages from a Timing
Extended IS Reacability TLV. IANA is requested to assign a new sub- LSP and forwards them to non-MPLS interface as IP or Ethernet
TLV code-point for the 1588aware capability sub-TLV carried within Encapsulated Timing messages, while performing Transparent Clock
the Extended IS Reacability TLV. functionality
Value Sub-TLV References o An LER receives MPLS encapsulated Timing messages from a Timing
----- ---------------------- ---------- LSP and terminates them, while performing the OC or BC
TBD 1588aware node sub-TLV (this document) functionality
20.3. IANA Considerations for RSVP o An LSR receives MPLS encapsulated Timing messages from a Timing
LSP and forwards them to another MPLS interface, while performing
the TC functionality
IANA is requested to assign a new Class Number for 1588 PTP LSP This document also supports the case where not all LSRs are Timing-
object that is used to signal PTP LSPs. capable/aware. It also supports the case where not all LER/LSR
interfaces are Timing-capable/aware.
1588 PTP LSP Object 22. Acknowledgements
Class-Num of type 11bbbbbb The authors would like to thank Luca Martini, Ron Cohen, Yaakov
Stein, Tal Mizrahi, Stefano Ruffini, Luca Moniti and other members of
IETF for reviewing and providing feedback on this draft.
Suggested value TBD 23. IANA Considerations
Defined CType: 1 (1588 PTP LSP) There are no IANA requirements in this specification.
21. References 24. References
21.1. Normative References 24.1. Normative References
[IEEE] IEEE 1588-2008, "IEEE Standard for a Precision Clock [IEEE] 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.
skipping to change at page 32, line 45 skipping to change at page 33, line 45
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.
21.2. Informative References 24.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
Connectionless-mode Network Service (ISO 8473)". Connectionless-mode Network Service (ISO 8473)".
[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, December 1990.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color
Marker", RFC 2697, September 1999.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
September 2003. September 2003.
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)", System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004. RFC 3784, June 2004.
[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.
Shaffer, "Extensions to OSPF for Advertising Optional Shaffer, "Extensions to OSPF for Advertising Optional
skipping to change at page 34, line 5 skipping to change at page 35, line 5
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008. Engineering", RFC 5305, October 2008.
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem,
"Traffic Engineering Extensions to OSPF Version 3", "Traffic Engineering Extensions to OSPF Version 3",
RFC 5329, September 2008. 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, July 2008.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010.
[RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
J., and S. Amante, "Flow-Aware Transport of Pseudowires
over an MPLS Packet Switched Network", RFC 6391,
November 2011.
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
 End of changes. 151 change blocks. 
535 lines changed or deleted 522 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/