draft-ietf-tictoc-1588overmpls-01.txt   draft-ietf-tictoc-1588overmpls-02.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: November 25, 2011 M. Bhatia Expires: April 9, 2012 M. Bhatia
P. Roberts P. Roberts
Alcatel-Lucent Alcatel-Lucent
L. Montini L. Montini
Cisco Systems Cisco Systems
May 24, 2011 October 7, 2011
Transporting PTP messages (1588) over MPLS Networks Transporting PTP messages (1588) over MPLS Networks
draft-ietf-tictoc-1588overmpls-01 draft-ietf-tictoc-1588overmpls-02
Abstract Abstract
This document defines the method for transporting PTP messages (PDUs) This document defines the method for transporting PTP messages (PDUs)
over an MPLS network to enable a proper handling of these packets over an MPLS network. The method allows for the easy identification
(e.g. implementation of Transparent Clocks (TC)) in LSRs. of these PDUs at the port level to allow for port 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 PTP messages inside dedicated MPLS
LSPs. These LSPs only carry PTP messages and possibly Control and LSPs. These LSPs only carry PTP 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 1588 over MPLS are defined. The first
method is to transport PTP messages directly over the dedicated MPLS method is to transport PTP messages directly over the dedicated MPLS
LSP via UDP/IP encapsulation, which is suitable for IP/MPLS networks. LSP via UDP/IP encapsulation, which is suitable for IP/MPLS networks.
The second method is to transport PTP messages inside a PW via The second method is to transport PTP messages inside a PW via
Ethernet encapsulation, which is more suitable for MPLS-TP networks. Ethernet encapsulation, which is more suitable for MPLS-TP networks.
skipping to change at page 1, line 47 skipping to change at page 1, line 48
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 November 25, 2011. This Internet-Draft will expire on April 9, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 3, line 9 skipping to change at page 3, line 9
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 . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8
4. Dedicated LSPs for PTP messages . . . . . . . . . . . . . . . 10 4. 1588 over MPLS Architecture . . . . . . . . . . . . . . . . . 9
5. 1588 over MPLS Encapsulation . . . . . . . . . . . . . . . . . 11 5. Dedicated LSPs for PTP messages . . . . . . . . . . . . . . . 10
5.1. 1588 over LSP Encapsulation . . . . . . . . . . . . . . . 11
5.2. 1588 over PW Encapsulation . . . . . . . . . . . . . . . . 11
5.3. 1588 over pure MPLS mode . . . . . . . . . . . . . . . . . 13
6. 1588 Message Transport . . . . . . . . . . . . . . . . . . . . 14 6. 1588 over MPLS Encapsulation . . . . . . . . . . . . . . . . . 11
6.1. 1588 over LSP Encapsulation . . . . . . . . . . . . . . . 11
6.2. 1588 over PW Encapsulation . . . . . . . . . . . . . . . . 11
7. Protection and Redundancy . . . . . . . . . . . . . . . . . . 16 7. 1588 Message Transport . . . . . . . . . . . . . . . . . . . . 14
8. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 16
9. OAM, Control and Management . . . . . . . . . . . . . . . . . 18 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 19 10. OAM, Control and Management . . . . . . . . . . . . . . . . . 18
11. FCS Recalculation . . . . . . . . . . . . . . . . . . . . . . 20 11. QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 19
12. UDP Checksum Correction . . . . . . . . . . . . . . . . . . . 21 12. FCS Recalculation . . . . . . . . . . . . . . . . . . . . . . 20
13. Routing extensions for 1588aware LSRs . . . . . . . . . . . . 22 13. UDP Checksum Correction . . . . . . . . . . . . . . . . . . . 21
13.1. 1588aware Link Capability for OSPF . . . . . . . . . . . . 22
13.2. 1588aware Link Capability for IS-IS . . . . . . . . . . . 23
14. RSVP-TE Extensions for support of 1588 . . . . . . . . . . . . 25 14. Routing extensions for 1588aware LSRs . . . . . . . . . . . . 22
14.1. 1588aware Link Capability for OSPF . . . . . . . . . . . . 22
14.2. 1588aware Link Capability for IS-IS . . . . . . . . . . . 23
15. Distributing PW labels . . . . . . . . . . . . . . . . . . . . 26 15. RSVP-TE Extensions for support of 1588 . . . . . . . . . . . . 25
15.1. LDP extensions for distributing PW labels . . . . . . . . 26
15.2. BGP extensions for distributing PW labels . . . . . . . . 26
16. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 27 16. Behavior of LER/LSR . . . . . . . . . . . . . . . . . . . . . 26
16.1. Behavior of 1588-aware LER . . . . . . . . . . . . . . . . 27 16.1. Behavior of 1588-aware LER . . . . . . . . . . . . . . . . 26
16.2. Behavior of 1588-aware LSR . . . . . . . . . . . . . . . . 27 16.2. Behavior of 1588-aware LSR . . . . . . . . . . . . . . . . 26
16.3. Behavior of non-1588-aware LSR . . . . . . . . . . . . . . 27 16.3. Behavior of non-1588-aware LSR . . . . . . . . . . . . . . 26
17. Other considerations . . . . . . . . . . . . . . . . . . . . . 29 17. Other considerations . . . . . . . . . . . . . . . . . . . . . 28
18. Security Considerations . . . . . . . . . . . . . . . . . . . 30 18. Security Considerations . . . . . . . . . . . . . . . . . . . 29
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
20.1. IANA Considerations for OSPF . . . . . . . . . . . . . . . 32
20.2. IANA Considerations for IS-IS . . . . . . . . . . . . . . 32
20.3. IANA Considerations for RSVP . . . . . . . . . . . . . . . 32
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
21.1. Normative References . . . . . . . . . . . . . . . . . . . 33 20.1. IANA Considerations for OSPF . . . . . . . . . . . . . . . 31
21.2. Informative References . . . . . . . . . . . . . . . . . . 33 20.2. IANA Considerations for IS-IS . . . . . . . . . . . . . . 31
20.3. IANA Considerations for RSVP . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
21.1. Normative References . . . . . . . . . . . . . . . . . . . 32
21.2. Informative References . . . . . . . . . . . . . . . . . . 32
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) is to synchronize The objective of Precision Time Protocol (PTP) is to synchronize
independent clocks running on separate nodes of a distributed system. independent clocks running on separate nodes of a distributed system.
[IEEE] defines PTP messages for clock and time synchronization. The [IEEE] defines PTP messages for clock and time synchronization. The
PTP messages include PTP PDUs over UDP/IP (Annex D & E of [IEEE]) and PTP messages include PTP PDUs over UDP/IP (Annex D and E of [IEEE])
PTP PDUs over Ethernet (Annex F of [IEEE]). This document defines and PTP PDUs over Ethernet (Annex F of [IEEE]). This document
mapping and transport of the PTP messages defined in [IEEE] over MPLS defines mapping and transport of the PTP messages defined in [IEEE]
networks. over MPLS networks.
PTP defines intermediate clock functions (called transparent clocks)
between the source of time (Master) and the Slave clocks. Boundary
Clocks (BC) form Master-Slave hierarchy with the Master clock as
root. The messages related to synchronization, establishing the
Master-Slave hierarchy, and signaling, terminate in the protocol
engine of a boundary clock and are not forwarded. Management
messages however, are forwarded to other ports on the boundary clock.
Transparent clocks modify a "correction field" (CF) within the
synchronization messages to compensate for residence and propagation
delays. Transparent clocks do not terminate synchronization, Master-
Slave hierarchy control messages or signaling messages.
There is a need to transport PTP messages over MPLS networks. The
MPLS network could be a transit network between 1588 Masters and
Slaves. The accuracy of the recovered clock improves and the Slave
logic simplifies when intermediate nodes (e.g. LSRs) properly handle
PTP messages (e.g. perform TC), otherwise the jitter at the 1588
Slave may be excessive and therefore the Slave may not be able to
properly recover the clock and time of day.
This document defines a "1588-aware LSR" that is able to identify
1588 timing flows carried over MPLS.
Transparent Clock (TC) function requires a 1588-aware LSR in the
middle of an LSP to identify the PTP messages and perform proper
update of the CF, via a 1-step or 2-step process.
More generally this document requires that an LSR should be able to PTP defines several clock types: ordinary clocks, boundary clocks,
properly handle the PTP messages. For instance for those cases when end-to-end transparent clocks, and peer-to-peer transparent clocks.
the TC function is not viable (e.g. due to layer violation) as an One key attribute of all of these clocks is the recommendation for
alternative it should be possible to instead control the delay for PTP messages processing to occur as close as possible to the actual
these messages on both directions across the node. transmission and reception at the physical port interface. This
targets optimal time and/or frequency recovery by avoiding variable
delay introduced by queues internal to the clocks. To facilitate the
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.
In the above cases it is beneficial that PTP packets can be easily The port based PTP message processing involves PTP event message
identified when carried over MPLS. recognition. Once the PTP event messages are recognized they can be
modified based on the reception or transmission timestamp. An
alternative technique to actual packet modification could include the
enforcement of a fixed delay time across the LSR to remove
variability in the transit delay. This latter would be applicable in
a LSR which does not contain a PTP transparent Clock function.
This document provides two methods for transporting PTP messages over This document provides two methods for transporting PTP messages over
MPLS. The main objectives are for LSRs to be able to MPLS. One is principally focused on an IP/MPLS environment and the
deterministically detect and identify the PTP messages. second is focused on the MPLS-TP environment.
While the techniques included herein allow for the establishment of
paths optimized to include PTP Timestamping capable links, the
performance of the Slave clocks is outside the scope of this
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 PTP: The timing and synchronization protocol used by 1588
Master: The Source of 1588 Timing and clock. This will be a port in Master Clock: The source of 1588 timing to a set of slave clocks.
master state on a Grandmaster Clock or on a Boundary Clock.
Slave: The Destination of 1588 Timing and clock that tries to follow Master Port: A port on a ordinary or boundary clock that is in Master
the Master clock. This will be a port in slave state on a boundary state. This is the source of timing toward slave ports.
clock or on a Slave-Only Ordinary Clock.
OC: Ordinary Clock - a device with a single PTP port. Slave Clock: A receiver of 1588 timing from a master clock
TC: Transparent Clock, a time stamping method applied by intermediate Slave Port: A port on a boundary clock or ordinary clock that is
nodes between Master and Slave receiving timing from a master clock.
BC: Boundary Clock, is a node that recovers the Master clock via a Ordinary Clock: A device with a single PTP port.
Slave function and uses that clock as the Master for other Slaves
Transparent Clock. A device that measures the time taken for a PTP
event message to transit the device and then updates the
correctionField of the message with this transit time.
Boundary Clock: A device with more than one PTP port. Generally
boundary clocks will have one port in slave state to receive timing
and then other ports in master state to re-distribute the timing.
PTP LSP: An LSP dedicated to carry PTP messages PTP LSP: An LSP dedicated to carry PTP messages
PTP PW: A PW within a PTP LSP that is dedicated to carry PTP PTP PW: A PW within a PTP LSP that is dedicated to carry PTP
messages. messages.
CW: Pseudowire Control Word CW: Pseudowire Control Word
LAG: Link Aggregation LAG: Link Aggregation
ECMP: Equal Cost Multipath ECMP: Equal Cost Multipath
CF: Correction Field, a field inside certain PTP messages (message CF: Correction Field, a field inside certain PTP messages (message
type 0-3)that holds the accumulative transit time inside intermediate type 0-3)that holds the accumulative transit time inside intermediate
switches switches
3. Problem Statement 3. Problem Statement
When PTP messages are transported over MPLS networks, there is a need When PTP messages are transported over MPLS networks, there is a need
for intermediate LSRs to detect such messages and perform proper for PTP message processing at the physical port level. This
processing (e.g. Transparent Clock (TC)). Note the TC processing requirement exists to minimum uncertainty in the transit delays. If
could be in the form of 1-Step or 2-Step time stamping. PTP message processing occurs interior to the MPLS routers, then the
variable delay introduced by queuing between the physical port and
the PTP processing will add noise to the timing distribution. Port
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. PTP messages over Ethernet or IP can always be tunneled over MPLS.
However the 1588 over MPLS mapping defined in this document is However there is a requirement to limit the possible encapsulation
applicable whenever MPLS LSRs are 1588-aware and the intention is for options to simplify the PTP message processing required at the port
those LSRs to perform proper processing on these packets. 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 When 1588-awareness is needed, PTP messages should not be transported
over LSPs or PWs that are carrying customer traffic because LSRs over LSPs or PWs that are carrying customer traffic because LSRs
perform Label switching based on the top label in the stack. To perform Label switching based on the top label in the stack. To
detect PTP messages inside such LSPs require special Hardware (HW) to detect PTP messages inside such LSPs require special hardware to do
do deep packet inspection at line rate. Even if one assumes a deep deep packet inspection at line rate. Even if such hardware exists,
packet inspection HW at line rate exists, the payload can't be the payload can't be deterministically identified by LSRs because the
deterministically identified by LSRs because the payload type is a payload type is a context of the PW label and the PW label and its
context of the PW label and the PW label and its context are only context are only known to the Edge routers (PEs); LSRs don't know
known to the Edge routers (PEs) and LSRs don't know what is a PW's what is a PW's payload (Ethernet, ATM, FR, CES, etc). Even if one
payload (Ethernet, ATM, FR, CES, etc). Even if one assumes only restricts an LSP to only carry Etehrent PWs, the LSRs don't have the
Ethernet PWs are permitted in an LSP, the LSRs don't have the
knowledge of whether PW Control Word (CW) is present or not and knowledge of whether PW Control Word (CW) is present or not and
therefore can't deterministically identify the payload. therefore can't deterministically identify the payload.
Therefore a generic method is defined in this document that does not Therefore a generic method is defined in this document that does not
require deep packet inspection at line rate, and can require deep packet inspection at line rate, and can
deterministically identify PTP messages. The defined method is deterministically identify PTP messages. The defined method is
applicable to both MPLS and MPLS-TP networks. applicable to both MPLS and MPLS-TP networks.
4. Dedicated LSPs for PTP messages 4. 1588 over MPLS Architecture
1588 communication flows map onto MPLS nodes as follows: 1588
messages are exchange between PTP ports on Ordinary and boundary
clocks. Transparent clocks do not terminate the PTP messages but
they do modify the contents of the PTP messages as they transit
across the Transparent clock. SO Ordinary and boundary clocks would
exist within LERs as they are the termination points for the PTP
messages carried in MPLS. Transparent clocks would exist within LSRs
as they do not terminate the PTP message exchange.
Perhaps a picture would be good here.
5. Dedicated LSPs for PTP messages
Many methods were considered for identifying the 1588 messages when Many methods were considered for identifying the 1588 messages when
they are encapsulated in MPLS such as by using GAL/ACH or a new they are encapsulated in MPLS such as by using GAL/ACH or a new
reserved label. These methods were not attractive since they either reserved label. These methods were not attractive since they either
required deep packet inspection and snooping at line rate or they required deep packet inspection and snooping at line rate or they
required use of scarce new reserved label. Also one of the goals was required use of a scarce new reserved label. Also one of the goals
to reuse existing OAM and protection mechanisms. was to reuse existing OAM and protection mechanisms.
The method defined in this document can be used by LSRs to identify The method defined in this document can be used by LER/LSRs to
PTP messages in MPLS tunnels by using dedicated LSPs to carry PTP identify PTP messages in MPLS tunnels by using dedicated LSPs to
messages. carry PTP messages.
Compliant implementations MUST use dedicated LSPs to carry PTP Compliant implementations MUST use dedicated LSPs to carry PTP
messages over MPLS. Let's call these LSPs as the "PTP LSPs" and the messages over MPLS. These LSPs are herein referred to as "PTP LSPs"
labels associated with these LSPs as "PTP labels". These LSPs could and the labels associated with these LSPs as "PTP labels". These
be P2P or P2MP LSPs. The PTP LSP between Master and Slaves MAY be LSPs could be P2P or P2MP LSPs. The PTP LSP between Master Clocks
P2MP or P2P LSP while the PTP LSP between each Slave and Master and Slave Clocks MAY be P2MP or P2P LSP while the PTP LSP between
SHOULD be P2P LSP. The PTP LSP between a Master and a Slave and the each Slave Clock and Master Clock SHOULD be P2P LSP. The PTP LSP
PTP LSP between the same Slave and Master MUST be co-routed. between a Master Clock and a Slave Clock and the PTP LSP between the
Alternatively, a single bidirectional co-routed LSP can be used. The same Slave Clock and Master Clock MUST be co-routed. Alternatively,
PTP LSP MAY be MPLS LSP or MPLS-TP LSP. a single bidirectional co-routed LSP can be used. The PTP LSP MAY be
MPLS LSP or MPLS-TP LSP. This co-routing is required to limit
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 The PTP LSPs could be configured or signaled via RSVP-TE/GMPLS. New
RSVP-TE/GMPLS TLVs and objects are defined in this document to RSVP-TE/GMPLS TLVs and objects are defined in this document to
indicate that these LSPs are PTP LSPs. indicate that these LSPs are PTP LSPs.
We should be selective about the kind of traffic that flows over PTP The PTP LSPs MAY carry essential MPLS/MPLS-TP control plane traffic
LSPs as these will be handled as a special case by the LSR. The only such as BFD and LSP Ping but the LSP user plane traffic MUST be PTP
LSP user plane traffic MUST be PTP, but the LSP MAY also carry only.
essential MPLS/MPLS-TP control plane traffic such as BFD and LSP-
Ping.
5. 1588 over MPLS Encapsulation 6. 1588 over MPLS Encapsulation
This document defines two methods for carrying PTP messages over This document defines two methods for carrying PTP messages over
MPLS. The first method is carrying IP encapsulated PTP messages over MPLS. The first method is carrying IP encapsulated PTP messages over
PTP LSPs and the second method is to carry PTP messages over PTP LSPs and the second method is to carry PTP messages over
dedicated Ethernet PWs (called PTP PWs) inside PTP LSPs. dedicated Ethernet PWs (called PTP PWs) inside PTP LSPs.
5.1. 1588 over LSP Encapsulation 6.1. 1588 over LSP Encapsulation
The simplest method of transporting PTP messages over MPLS is to The simplest method of transporting PTP messages over MPLS is to
encapsulate PTP PDUs in UDP/IP and then encapsulate them in PTP LSP. encapsulate PTP PDUs in UDP/IP and then encapsulate them in PTP LSP.
The 1588 over LSP format is shown in Figure 1. The 1588 over LSP format is shown in Figure 1.
+----------------------+ +----------------------+
| PTP Tunnel Label | | PTP Tunnel Label |
+----------------------+ +----------------------+
| IPv4/6 | | IPv4/6 |
+----------------------+ +----------------------+
| UDP | | UDP |
+----------------------+ +----------------------+
| PTP PDU | | PTP PDU |
+----------------------+ +----------------------+
Figure 1 - 1588 over LSP Encapsulation Figure 1 - 1588 over LSP Encapsulation
This encapsulation is very simple and is useful when the networks This encapsulation is very simple and is useful when the networks
between 1588 Master and Slave are IP/MPLS networks. between 1588 Master Clock and Slave Clock are IP/MPLS networks.
In order for an LSR to process PTP messages, the PTP Label must be In order for an LSR to process PTP messages, the PTP Label must be
the top label of the label stack. the top label of the label stack.
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 [IEEE].
5.2. 1588 over PW Encapsulation 6.2. 1588 over PW Encapsulation
Another method of transporting 1588 over MPLS networks is by Another method of transporting 1588 over MPLS networks is by
encapsulating PTP PDUs in Ethernet and then transporting them over encapsulating PTP PDUs in Ethernet and then transporting them over
Ethernet PW (PTP PW) as defined in [RFC4448], which in turn is Ethernet PW (PTP PW) as defined in [RFC4448], which in turn is
transported over PTP LSPs. Alternatively PTP PDUs MAY be transported over PTP LSPs. Alternatively PTP PDUs MAY be
encapsulated in UDP/IP/Ethernet and then transported over Ethernet encapsulated in UDP/IP/Ethernet and then transported over Ethernet
PW. PW.
Both Raw and Tagged modes for Ethernet PW are permitted. The 1588 Both Raw and Tagged modes for Ethernet PW are permitted. The 1588
over PW format is shown in Figure 2. over PW format is shown in Figure 2.
+----------------+ +----------------+
|PTP Tunnel Label| |PTP Tunnel Label|
+----------------+ +----------------+
| PW Label | | PW Label |
+----------------+ +----------------+
| Entropy Label |
| (optional) |
+----------------+
| Control Word | | Control Word |
+----------------+ +----------------+
| Ethernet | | Ethernet |
| Header | | Header |
+----------------+ +----------------+
| VLANs | | VLANs |
| (optional) | | (optional) |
+----------------+ +----------------+
| IPV4/V6 | | IPV4/V6 |
| (optional) | | (optional) |
skipping to change at page 12, line 46 skipping to change at page 12, line 43
The use of VLAN and UDP/IP are optional. Note that 1 or 2 VLANs MAY The use of VLAN and UDP/IP are optional. Note that 1 or 2 VLANs MAY
exist in the PW payload. exist in the PW payload.
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 from PTP label range. However label stack (the Tunnel Label) MUST be from PTP label range. However
in some applications the PW label may be the top label in the stack, 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 such as cases where there is only one-hop between PEs or in case of
PHP. In such cases, the PW label SHOULD be chosen from the PTP Label PHP. In such cases, the PW label SHOULD be chosen from the PTP Label
range. range.
An Entropy label [I-D.ietf-pwe3-fat-pw] MAY be present at the bottom In order to ensure congruency between the two directions of PTP
of stack. 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 The Ethernet encapsulation of PTP MUST follow Annex F of [IEEE] and
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 [IEEE].
For 1588 over MPLS encapsulations that are PW based, there are some For 1588 over MPLS encapsulations that are PW based, there are some
cases in which the PTP LSP label may not be present: cases in which the PTP LSP label may not be present:
o When PHP is applied to the PTP LSP, and the packet is received o When PHP is applied to the PTP LSP, and the packet is received
without PTP LSP label at PW termination point . without PTP LSP label at PW termination point .
o When the PW is established between two routers directly connected o When the PW is established between two routers directly connected
to each other and no PTP LSP is needed. to each other and no PTP LSP is needed.
In such cases it is required for a router to identify these packets In such cases it is required for a router to identify these packets
as PTP packets. This would require the PW label to also be a label as PTP packets. This would require the PW label to also be a label
that is distributed specifically for carrying PTP traffic (aka PTP PW that is distributed specifically for carrying PTP traffic (aka PTP PW
label). Therefore there is a need to add extension to LDP/BGP PW label). Therefore there is a need to add extension to LDP/BGP PW
label distribution protocol to indicate that a PW label is a PTP PW label distribution protocol to indicate that a PW label is a PTP PW
labels. labels.
5.3. 1588 over pure MPLS mode 7. 1588 Message Transport
Editor Note: The encapsulation is general enough and can support
transporting 1588 in a pure MPLS mode (i.e., without any IP/UDP or
Ethernet headers). Should the WG pursue this?
6. 1588 Message Transport
1588 protocol comprises of the following message types: 1588 protocol comprises of the following message types:
o Announce o Announce
o SYNC o SYNC
o FOLLOW UP o FOLLOW UP
o DELAY REQ (Delay Request) o DELAY_REQ (Delay Request)
o DELAY RESP (Delay Response) o DELAY_RESP (Delay Response)
o PDELAY REQ (Peer Delay Request) o PDELAY_REQ (Peer Delay Request)
o PDELAY RESP (Peer Delay Response) o PDELAY_RESP (Peer Delay Response)
o PDELAY RESP FOLLOW UP (Peer Delay Response Follow up) o PDELAY_RESP_FOLLOW_UP (Peer Delay Response Follow up)
o Management o Management
o Signaling o Signaling
A subset of PTP message types that require TC processing are called A subset of PTP message types that require timestamp processing are
Event messages: 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 and Slave and MUST be SYNC and DELAY_REQ are exchanged between Master Clock and Slave Clock
transported over PTP LSPs. PDELAY_REQ and PDELAY_RESP are exchanged and MUST be transported over PTP LSPs. PDELAY_REQ and PDELAY_RESP
between adjacent routers and MAY be transported over single hop PTP are exchanged between adjacent PTP clocks (i.e. Master, Slave,
LSPs. If Two Step Transparent clocks are present, then the FOLLOW_UP Boundary, or Transparent) and MAY be transported over single hop PTP
and DELAY_RESP messages must also be transported over the PTP LSPs. LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP,
DELAY_RESP, and PDELAY_RESP_FOLLOW_UP messages must also be
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 Transparent clocks, Non- Except as indicated above for the two-step PTP clocks, Non-Event PTP
Event PTP message types don't need to be processed by intermediate message types don't need to be processed by intermediate routers.
routers. These message types MAY be carried in PTP Tunnel LSPs. These message types MAY be carried in PTP Tunnel LSPs.
7. 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 1588 Slaves,
usually as a general practice, Redundant Masters are tracked by each usually as a general practice, Redundant Masters are tracked by each
Slave. It is the responsibility of the network operator to ensure Slave. It is the responsibility of the network operator to ensure
that physically disjoint PTP tunnels that don't share any link are that physically disjoint PTP tunnels that don't share any link are
used between the redundant Masters and a Slave. used between the redundant Masters and a Slave.
When redundant Masters are tracked by a Slave, any PTP LSP or PTP PW When redundant Masters are tracked by a Slave, any prolonged PTP LSP
failure will trigger the slave to switch to the Redundant Master. or PTP PW outage will trigger the Slave Clock to switch to the
However LSP/PW protection such as Linear Protection Switching Redundant Master Clock. However LSP/PW protection such as Linear
(1:1,1+1), Ring protection switching or MPLS Fast Reroute (FRR) Protection Switching (1:1,1+1), Ring protection switching or MPLS
SHOULD still be used to ensure the LSP/PW is ready for a future Fast Reroute (FRR) SHOULD still be used to provide resiliency to
failure. individual network segment failures..
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 label to the label stack, such as Facility Backup Fast Reroute, MUST
ensure that the pushed label is a PTP Label to ensure proper ensure that the pushed label is a PTP Label to ensure recognition of
processing of PTP messages by LSRs in the backup path. the MPLS frame as containing PTP messages as it transits the backup
path..
8. ECMP 9. ECMP
To ensure the proper operation of 1588 Slaves, the physical path for To ensure the optimal operation of 1588 Slave clocks and avoid errors
PTP messages from Master to Slave and vice versa must be the same for introduced by forward and reverse path delay asymmetry, the physical
all PTP messages listed in section 7 and must not change even in the path for PTP messages from Master Clock to Slave Clock and vice versa
presence of ECMP in the MPLS network. must be the same for all PTP messages listed in section 7 and must
not change even in the presence of ECMP in the MPLS network.
To ensure the forward and reverse paths are the same PTP LSPs and PWs To ensure the forward and reverse paths are the same PTP LSPs and PWs
MUST not be subject to ECMP. MUST NOT be subject to ECMP.
9. OAM, Control and Management 10. OAM, Control and Management
In order to manage PTP LSPs and PTP PWs, they MAY carry OAM, Control In order to manage PTP LSPs and PTP PWs, they MAY carry OAM, Control
and Management messages. These control and management messages can and Management messages. These control and management messages can
be differentiated from PTP messages via already defined IETF methods. be differentiated from PTP messages via already defined IETF methods.
In particular BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389]MAY run In particular 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 are easily 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 PTP PW
via one of the defined VCCVs (Type 1, 2 or 3) [RFC5085]. In this via one of the defined VCCVs (Type 1, 2 or 3) [RFC5085]. In this
case G-ACH, Router Alert Label (RAL), or PW label (TTL=1) are used to case G-ACH, Router Alert Label (RAL), or PW label (TTL=1) are used to
identify such management messages. identify such management messages.
10. QoS Considerations 11. QoS Considerations
The PTP messages are time critical and must be treated with the In network deployments where not every LSR/LER is PTP-aware, then it
highest priority. Therefore 1588 over MPLS messages must be treated is important to reduce the impact of the non-PTP-aware LSR/LERs on
with the highest priority in the routers. This can be achieved by the timing recovery in the slave clock. The PTP messages are time
proper setup of PTP tunnels. It is recommended that the PTP LSPs are critical and must be treated with the highest priority. Therefore
setup and marked properly to indicate EF-PHB for the CoS and Green 1588 over MPLS messages must be treated with the highest priority in
for drop eligibility. the routers. This can be achieved by proper setup of PTP tunnels.
It is recommended that the PTP LSPs are setup and marked properly to
indicate EF-PHB for the CoS and Green for drop eligibility.
11. FCS Recalculation In network deployments where every LSR/LER supports PTP LSPs, then it
MAY NOT be required to apply the same level of prioritization as
specified above.
12. FCS Recalculation
Ethernet FCS of the outer encapsulation MUST be recalculated at every Ethernet FCS of the outer encapsulation MUST be recalculated at every
LSR that performs the TC processing and FCS retention for the payload LSR that performs the Transparent Clock processing and FCS retention
Ethernet described in [RFC4720] MUST not be used. for the payload Ethernet described in [RFC4720] MUST NOT be used.
12. UDP Checksum Correction 13. UDP Checksum Correction
For UDP/IP encapsulation mode of 1588 over MPLS, the UDP checksum is For UDP/IP encapsulation mode of 1588 over MPLS, the UDP checksum is
optional when used for IPv4 encapsulation and mandatory in case of 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. When IPv4/v6 UDP checksum is used each 1588-aware LSR must
either incrementally update the UDP checksum after the CF update or either incrementally update the UDP checksum after the CF update or
should verify the UDP checksum on reception from upstream and should verify the UDP checksum on reception from upstream and
recalculate the checksum completely on transmission after CF update recalculate the checksum completely on transmission after CF update
to downstream node. to downstream node.
13. Routing extensions for 1588aware LSRs 14. Routing extensions for 1588aware LSRs
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 1588-aware.
This capability MUST then be taken into account during path This capability MUST then be taken into account during path
computation to prefer links that advertise themselves as 1588-aware, computation to prefer or even require links that advertise themselves
so that the PTP LSPs can be properly handled. as 1588-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 timestamping thus minimizing their impact
on the performance of the slave clock.
For this purpose, the following sections specify extensions to OSPF For this purpose, the following sections specify extensions to OSPF
and IS-IS in order to advertise 1588 aware capabilities of a link. and IS-IS in order to advertise 1588 aware capabilities of a link.
13.1. 1588aware Link Capability for OSPF 14.1. 1588aware Link Capability for OSPF
OSPF uses the Link TLV (Type 2) that is itself carried within either OSPF uses the Link TLV (Type 2) that is itself carried within either
the Traffic Engineering LSA specified in [RFC3630] or the OSPFv3 the Traffic Engineering LSA specified in [RFC3630] or the OSPFv3
Intra-Area-TE LSA (function code 10) defined in [RFC5329] to Intra-Area-TE LSA (function code 10) defined in [RFC5329] to
advertise the TE related information for the locally attached router advertise the TE related information for the locally attached router
links. For an LSA Type 10, one LSA can contain one Link TLV links. For an LSA Type 10, one LSA can contain one Link TLV
information for a single link. This extension defines a new 1588- 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. 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 The 1588-aware capability sub-TLV is OPTIONAL and MUST NOT appear
skipping to change at page 23, line 29 skipping to change at page 23, line 32
performing MPLS frame forwarding of the frames with PTP labels using performing MPLS frame forwarding of the frames with PTP labels using
a method that support the end to end delivery of accurate timing. a method that support the end to end delivery of accurate timing.
The exact method is not defined herein. The exact method is not defined herein.
Reserved, 7 bits: Reserved for future use. The reserved bits must be Reserved, 7 bits: Reserved for future use. The reserved bits must be
ignored by the receiver. ignored by the receiver.
The 1588-aware Capability sub-TLV is applicable to both OSPFv2 and The 1588-aware Capability sub-TLV is applicable to both OSPFv2 and
OSPFv3. OSPFv3.
13.2. 1588aware Link Capability for IS-IS 14.2. 1588aware Link Capability for IS-IS
The IS-IS Traffic Engineering [RFC3784] defines the intra-area The IS-IS Traffic Engineering [RFC3784] defines the intra-area
traffic engineering enhancements and uses the Extended IS traffic engineering enhancements and uses the Extended IS
Reachability TLV (Type 22) [RFC5305] to carry the per link TE-related Reachability TLV (Type 22) [RFC5305] to carry the per link TE-related
information. This extension defines a new 1588-aware capability sub- information. This extension defines a new 1588-aware capability sub-
TLV that can be carried as part of the Extended IS Reachability TLV. 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 The 1588-aware capability sub-TLV is OPTIONAL and MUST NOT appear
more than once within the Extended IS Reachability TLV or the Multi- more than once within the Extended IS Reachability TLV or the Multi-
Topology (MT) Intermediate Systems TLV (type 222) specified in Topology (MT) Intermediate Systems TLV (type 222) specified in
skipping to change at page 25, line 5 skipping to change at page 25, line 5
packets and can compensate for residence time by updating the PTP packets and can compensate for residence time by updating the PTP
packet Correction Field. When this is set to 0, it means that this packet Correction Field. When this is set to 0, it means that this
link cannot perform the residence time correction but is capable of link cannot perform the residence time correction but is capable of
performing MPLS frame forwarding of the frames with PTP labels using performing MPLS frame forwarding of the frames with PTP labels using
a method that support the end to end delivery of accurate timing. a method that support the end to end delivery of accurate timing.
The exact method is not defined herein. The exact method is not defined herein.
Reserved, 7 bits: Reserved for future use. The reserved bits must be Reserved, 7 bits: Reserved for future use. The reserved bits must be
ignored by the receiver. ignored by the receiver.
14. RSVP-TE Extensions for support of 1588 15. RSVP-TE Extensions for support of 1588
RSVP-TE signaling MAY be used to setup the PTP LSPs. A new RSVP RSVP-TE signaling MAY be used to setup the PTP LSPs. A new RSVP
object is defined to signal that this is a PTP LSP. The OFFSET to object is defined to signal that this is a PTP LSP. The OFFSET to
the start of the PTP message header MAY also be signaled. the start of the PTP message header MAY also be signaled.
Implementations can trivially locate the correctionField (CF) Implementations can trivially locate the correctionField (CF)
location given this information. The OFFSET points to the start of 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 the PTP header as a node may want to check the PTP messageType before
it touches the correctionField (CF). it touches the correctionField (CF). The OFFSET is counted from TBD
The LSRs that receive and process the RSVP-TE/GMPLS messages MAY use The LSRs that receive and process the RSVP-TE/GMPLS messages MAY use
the OFFSET to locate the start of the PTP message header. the OFFSET to locate the start of the PTP message header.
Note that the new object/TLV Must be ignored by LSRs that are not Note that the new object/TLV Must be ignored by LSRs that are not
compliant to this specification. compliant to this specification.
The new RSVP 1588_PTP_LSP object should be included in signaling PTP The new RSVP 1588_PTP_LSP object should be included in signaling PTP
LSPs and is defined as follows: LSPs and is defined as follows:
skipping to change at page 26, line 5 skipping to change at page 26, line 5
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Offset to locate the start of the PTP message header | | Offset to locate the start of the PTP message header |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
Figure 7: RSVP 1588_PTP_LSP object Figure 7: RSVP 1588_PTP_LSP object
The ingress LSR MUST include this object in the RSVP PATH Message. The ingress LSR MUST include this object in the RSVP PATH Message.
It is just a normal RSVP path that is exclusively set up for PTP It is just a normal RSVP path that is exclusively set up for PTP
messages messages
15. Distributing PW labels
15.1. LDP extensions for distributing PW labels
TBD
15.2. BGP extensions for distributing PW labels
TBD
16. Behavior of LER/LSR 16. Behavior of LER/LSR
16.1. Behavior of 1588-aware LER 16.1. Behavior of 1588-aware LER
A 1588-aware LER advertises it's 1588-awareness via the OSPF A 1588-aware LER advertises it's 1588-awareness via the OSPF
procedure explained in earlier section of this specification. The procedure explained in earlier section of this specification. The
1588-aware LER then signals PTP LSPs by including the 1588_PTP_LSP 1588-aware LER then signals PTP LSPs by including the 1588_PTP_LSP
object in the RSVP-TE signaling. object in the RSVP-TE signaling.
When a 1588 message is received from a non-MPLS interface, the LER When a 1588 message is received from a non-MPLS interface, the LER
MUST redirect them to a previously established PTP LSP. When a 1588 MUST redirect them to a previously established PTP LSP. When a 1588
over MPLS message is received from an MPLS interface, the processing over MPLS message is received from an MPLS interface, the processing
is similar to 1588-aware LSR processing. is similar to 1588-aware LSR processing.
16.2. Behavior of 1588-aware LSR 16.2. Behavior of 1588-aware LSR
1588-aware LSRs are LSRs that understand the 1588_PTP_LSP RSVP object 1588-aware LSRs are LSRs that understand the 1588_PTP_LSP RSVP object
and can perform 1588 processing (e.g. TC processing). and can perform 1588 processing (e.g. Transparent Clock processing).
A 1588-aware LSR advertises it's 1588-awareness via the OSPF A 1588-aware LSR advertises it's 1588-awareness via the OSPF
procedure explained in earlier section of this specification. procedure explained in earlier section of this specification.
When a 1588-aware LSR distributes a label for PTP LSP, it maintains When a 1588-aware LSR distributes a label for PTP LSP, it maintains
this information. When the 1588-aware LSR receives an MPLS packet, 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 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 PTP label then further parsing must be done to positively identify
that the payload is 1588 and not OAM, BFD or control and management. that the payload is 1588 and not OAM, BFD or control and management.
Ruling out non-1588 messages can easily be done when parsing 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 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. 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 After a 1588 message is positively identified in a PTP LSP, the PTP
message type indicates what type of processing (TC) if any is message type indicates whether any timestamp processing is required.
required. After 1588 processing the packet is forwarded as a normal After 1588 processing the packet is forwarded as a normal MPLS packet
MPLS packet to downstream node. to downstream node.
16.3. Behavior of non-1588-aware LSR 16.3. Behavior of non-1588-aware LSR
It is most beneficial that all LSRs in the path of a PTP LSP be 1588- It is most beneficial that all LSRs in the path of a PTP LSP be 1588-
aware LSRs. This would ensure the highest quality time and clock aware LSRs. This would ensure the highest quality time and clock
synchronization by 1588 Slaves. However, this specification does not synchronization by 1588 Slave Clocks. However, this specification
mandate that all LSRs in path of a PTP LSP be 1588-aware. does not mandate that all LSRs in path of a PTP LSP be 1588-aware.
Non-1588-aware LSRs are LSRs that either don't have the capability to Non-1588-aware LSRs are LSRs that either don't have the capability to
process 1588 packets (e.g. TC processing) or don't understand the process 1588 packets (e.g. perform Transparent Clock processing) or
1588_PTP_LSP RSVP object. don't understand the 1588_PTP_LSP RSVP object.
Non-1588-aware LSRs ignore the RSVP 1588_PTP_LSP object and just Non-1588-aware LSRs ignore the RSVP 1588_PTP_LSP object and just
switch the MPLS packets carrying 1588 messages as data packets and switch the MPLS packets carrying 1588 messages as data packets and
don't perform any TC processing. However as explained in QoS section don't perform any timestamp related processing. However as explained
the 1588 over MPLS packets MUST be still be treated with the highest in QoS section the 1588 over MPLS packets MUST be still be treated
priority. with the highest priority.
17. Other considerations 17. Other considerations
The use of Explicit Null (Label= 0 or 2) is acceptable as long as The use of Explicit Null (Label= 0 or 2) is acceptable as long as
either the Explicit Null label is the bottom of stack label 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 The use of Penultimate Hop Pop (PHP) is acceptable as long as either
the PHP label is the bottom of stack label (applicable only to UDP/IP the PHP label is the bottom of stack label (applicable only to UDP/IP
skipping to change at page 33, line 51 skipping to change at page 32, line 51
[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 21.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-06 (work in progress), May 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.
[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.
 End of changes. 88 change blocks. 
218 lines changed or deleted 235 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/