One document matched: draft-ietf-tictoc-1588overmpls-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 4 U (http://www.xmlspy.com) by Fred Baker (private) -->
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc category="std" docName="draft-ietf-tictoc-1588overmpls-05"
ipr="trust200902">
<front>
<title abbrev="Transporting Timing over MPLS">Transporting Timing messages over MPLS Networks</title>
<author fullname="Shahram Davari" initials="S." surname="Davari">
<organization>Broadcom Corp.</organization>
<address>
<postal>
<street></street>
<city>San Jose, CA</city>
<code>95134</code>
<country>USA</country>
</postal>
<email>davari@broadcom.com</email>
</address>
</author>
<author fullname="Amit Oren" initials="A." surname="Oren">
<organization>Broadcom Corp.</organization>
<address>
<postal>
<street></street>
<city>San Jose, CA</city>
<code>95134</code>
<country>USA</country>
</postal>
<email>amito@broadcom.com</email>
</address>
</author>
<author fullname="Manav Bhatia" initials="M.B." surname="Bhatia">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street></street>
<city>Bangalore</city>
<code></code>
<region></region>
<country>India</country>
</postal>
<email>manav.bhatia@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Peter Roberts" initials="P." surname="Roberts">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street></street>
<city>Kanata</city>
<code></code>
<region></region>
<country>Canada</country>
</postal>
<email>peter.roberts@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Laurent Montini" initials="L." surname="Montini">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>San Jose CA</city>
<code />
<country>USA</country>
</postal>
<email>lmontini@cisco.com</email>
</address>
</author>
<author fullname="Luca" initials="L." surname="Martini">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>San Jose CA</city>
<code />
<country>USA</country>
</postal>
<email>lmartini@cisco.com</email>
</address>
</author>
<date day="15" month="June" year="2013" />
<area>Internet Area</area>
<workgroup>TICTOC Working Group</workgroup>
<abstract>
<t>This document defines the method for transporting Timing messages such as
PTP and NTP over an MPLS network. The method allows for the easy
identification of these PDUs at the port level to allow for port level
processing of these PDUs in both LERs and LSRs. </t>
<t>The basic idea is to transport Timing messages inside dedicated MPLS
LSPs. These LSPs only carry Timing messages and possibly Control and
Management packets, but they do not carry customer traffic. </t>
<t>Two methods for transporting Timing messages over MPLS are defined. The
first method is to transport Timing messages directly over the dedicated
MPLS LSP via UDP/IP encapsulation, which is suitable for MPLS networks.
The second method is to
transport Timing messages inside a PW via Ethernet encapsulation. </t>
</abstract>
</front>
<middle>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 <xref
target="RFC2119" />.</t>
<t>When used in lower case, these words convey their typical use in common
language, and are not to be interpreted as described in RFC2119 <xref
target="RFC2119" />.</t>
<section title="Introduction">
<t>The objective of Precision Time Protocol (PTP) and Network Timing
Protocol (NTP) are to synchronize independent clocks running on separate
nodes of a distributed system. </t>
<t> <xref target="IEEE-1588" /> defines PTP messages for frequency, phase and time
synchronization. The PTP messages include PTP PDUs over UDP/IP (Annex D
and E of <xref target="IEEE-1588" />) and PTP PDUs over Ethernet (Annex F of <xref target="IEEE-1588" />).
This document defines mapping and transport of the PTP messages
defined in <xref target="IEEE-1588" /> over MPLS/MPLS-TP networks. PTP defines several
clock types: ordinary clocks, boundary clocks, end-to-end transparent
clocks, and peer-to-peer transparent clocks. Transparent clocks require
intermediate nodes to update correction field inside PTP message that
reflects the transit time in the node. </t>
<t> <xref target="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 <xref target="RFC5905" /> over MPLS
networks. </t>
<t> One key attribute of all of these Timing messages is that the Time stamp
processing should occur as close as possible to the actual 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. </t>
<t> To facilitate the fast and efficient recognition of Timing messages at
the port level when the Timing 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 Timing message
processing capabilities. In order to ensure 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. </t>
<t> Port based Timing message processing involves Timing message recognition.
Once the Timing messages are recognized they can be modified based on the
reception or transmission Time-stamp. </t>
<t> This document provides two methods for transporting Timing messages over
MPLS. One is applicable to MPLS environment and the other one is
applicable to MPLS/MPLS-TP environment </t>
<t> 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. </t>
<t> When signaling is used to setup the PTP LSP, Extensions to signaling
protocols (e.g., RSVP-TE) are required for establishing PTP LSPs.
However such extensions are outside the scope of this document.
</t>
<t> While the techniques included herein allow for the establishment of paths
optimized to include Time-stamping capable links, the performance of the
Slave clocks is outside the scope of this document. </t>
<t> At the time of publishing this specification, Transparent Clocking (TC) is only defined for
PTP. Therefore at this time any part of this specification that talks about Transparent Clocking
applies only to PTP.
</t>
<t />
</section>
<section title="Terminology">
<t>1588: The timing and synchronization as defined by IEEE 1588.</t>
<t> NTP: The timing and synchronization protocol defined by IETF RFC-1305 and
RFC-5905. </t>
<t>PTP: The timing and synchronization protocol used by 1588.</t>
<t>Master Clock: The source of 1588 timing to a set of slave clocks.</t>
<t>Master Port: A port on a ordinary or boundary clock that is in Master
state. This is the source of timing toward slave ports.</t>
<t>Slave Clock: A receiver of 1588 timing from a master clock.</t>
<t>Slave Port: A port on a boundary clock or ordinary clock that is
receiving timing from a master clock.</t>
<t>Ordinary Clock: A device with a single PTP port.</t>
<t>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.</t>
<t>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.</t>
<t>PTP LSP: An LSP dedicated to carry PTP messages</t>
<t>PTP PW: A PW within a PTP LSP that is dedicated to carry PTP
messages.</t>
<t>CW: Pseudowire Control Word</t>
<t>LAG: Link Aggregation</t>
<t>ECMP: Equal Cost Multipath</t>
<t>CF: Correction Field, a field inside certain PTP messages (message
type 0-3)that holds the accumulative transit time inside intermediate
switches</t>
<t> Timing messages: Timing Protocol messages that are exchanged between
routers in order to establish a synchronized clock.
</t>
</section>
<section title="Problem Statement">
<t><xref target="IEEE-1588" /> has defined methods for transporting PTP messages over
Ethernet and IP networks. <xref target="RFC5905" /> has defined the method of
transporting NTP messages over IP networks. There is a need to transport
Timing messages over MPLS networks while supporting the Transparent Clock
(TC), Boundary Clock (BC) and Ordinary Clock (OC) functionality in the
LER and LSRs in the MPLS network. </t>
<t> 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. </t>
<t> When Timing-awareness is needed, Timing 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 Timing 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/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. </t>
<t> A generic method is defined in this document that does not require deep
packet inspection at line rate, and can deterministically identify Timing
messages. This method can be used to detect Timing Messages in both one-step
and two-step clock implementations of ordinary, boundary and transparent clocks. </t>
<t />
</section>
<section title="Timing over MPLS Architecture">
<t>Timing messages are exchange between Timing ports on ordinary and
boundary clocks. Boundary clocks terminate the Timing messages and act as
master for other boundary clocks or for slave clocks. End-to-End Transparent clocks do not terminate the Timing messages but
they do modify the contents of the Timing messages as they transit
across the transparent clock. </t>
<t> Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent Clock </t>
<t> (TC) could be implemented in either LERs or LSRs. </t>
<t> An example is shown in Figure 1, where the LERs act as Ordinary Clock (OC) and are the
initiating/terminating point for Timing messages. The ingress LER encapsulates
the Timing messages in Timing LSP and the Egress LER terminates the Timing LSP.
The LSRs act as Transparent Clock (TC) and just update the Timing field in the Timing messages.</t>
<figure>
<artwork><![CDATA[
+--------+ +-------+ +-------+ +-------+ +--------+
|Switch, | | | | | | | |Switch, |
| Router |-----| LER |-----| LSR |-----| LER |-----| Router |
| | | OC | | TC | | OC | | |
+--------+ +-------+ +-------+ +-------+ +--------+
/ \
+-------+ / \ +-------+
| LER | / \ | LER |
| Master|---/ \---| Slave |
| Clock | | Clock |
+-------+ +-------+
Figure (1) - Deployment example 1 of timing over MPLS network
]]></artwork>
</figure>
<t> Another example is shown in Figure2, where LERs terminate the Timing
messages received from switch/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.
</t>
<figure>
<artwork><![CDATA[
+--------+ +-------+ +-------+ +-------+ +--------+
|Switch, | | | | | | | |Switch, |
| Router |-----| LER |-----| LSR |-----| LER |-----| Router |
| OC/BC | | BC | | TC | | BC | | OC/BC |
+--------+ +-------+ +-------+ +-------+ +--------+
Figure (2) - Deployment example 2 of timing over MPLS network
]]></artwork>
</figure>
<t> Another example 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.
</t>
<figure>
<artwork><![CDATA[
+--------+ +-------+ +-------+ +-------+ +--------+
|Switch, | | | | | | | |Switch, |
| Router |-----| LER |-----| LSR |-----| LER |-----| Router |
|OC/TC/BC| | TC | | TC | | TC | |OC/TC/BC|
+--------+ +-------+ +-------+ +-------+ +--------+
Figure (3) - Deployment example 3 of timing over MPLS network ]]></artwork>
</figure>
<t> Another example is shown in Figure 4, where LERs and LSRs support
Boundary Clocks. A single-hop LSP is created between two adjacent
LSRs engaged in BC operation. Other methods such as PTP transport over
Ethernet MAY be used for transporting timing messages if the link
between the two routers is Ethernet.
</t>
<figure>
<artwork><![CDATA[
+--------+ +-------+ +-------+ +-------+ +--------+
|Switch, | | | | | | | |Switch, |
| Router |-----| LER |-----| LSR |-----| LER |-----| Router |
| OC/BC | | BC | | BC | | BC | | OC/BC |
+--------+ +-------+ +-------+ +-------+ +--------+
Figure (4) - Deployment example 3 of timing over MPLS network ]]></artwork>
</figure>
<t> An MPLS domain MAY serve multiple customers. In these cases the
MPLS domain (maintained by a service provider) may provide timing
services to multiple customers, each having their own Timing domain.
</t>
<t> The Timing over MPLS architecture assumes full mesh of Timing LSPs
between all LERs supporting this specification. It supports Point-to-
point (VPWS) and Multipoint (VPLS) services. This means that a customer
may purchase a Point-to-point Timing service between two customer sites
or a Multipoint Timing service between more than two customer sites. </t>
<t> The Timing over MPLS architecture supports P2P or P2MP Timing LSPs. This
means that the Timing Multicast messages such as PTP Multicast event
messages can be transported over P2MP Timing LSP or be replicated and
transported over many P2P Timing LSPs. </t>
<t> Timing messages, that do not require Time stamping or Correction Field
update MAY be transported over Timing LSPs to simplify hardware and
software. </t>
<t> PTP Announce messages that determine the Timing LSP terminating point
behavior such as BC/OC/TC SHOULD be transported over the Timing LSP to
simplify hardware and software.
</t>
</section>
<section title="Dedicated LSPs for Timing messages">
<t>Many methods have been considered for identifying the Timing messages
when they are encapsulated in MPLS such as using GAL/G-ACH or a new
reserved label. These methods were not attractive since they either
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. </t>
<t> The method defined in this document can be used by LER and LSRs to
identify Timing messages in MPLS tunnels by just looking at the top label
in the MPLS label stack, which only carry Timing messages as well as OAM,
but not data plane client traffic. </t>
<t> 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. </t>
<t> 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/MPLS-TP LSP.</t>
<t> The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS. New
Extensions to RSVP-TE/GMPLS TLVs are required; however they are outside
the scope of this document. </t>
<t> The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such as BFD
and LSP Ping but the LSP data plane client plane traffic MUST be Timing
packets only. </t>
</section>
<section title="Timing over LSP Encapsulation ">
<t>This document defines two methods for carrying Timing messages over
MPLS. The first method is carrying UDP/IP encapsulated Timing
messages over Timing LSPs, and the second method, is carrying Ethernet
encapsulated Timing messages over Ethernet PWs inside Timing LSPs.
</t>
<section title="Timing over UDP/IP over MPLS Encapsulation ">
<t>The simplest method of transporting Timing messages over MPLS is to
encapsulate Timing PDUs in UDP/IP and then encapsulate them in Timing
LSP. This format is shown in Figure 4. </t>
<figure>
<artwork><![CDATA[
+----------------------+
| Timing LSP Label |
+----------------------+
| IPv4/6 |
+----------------------+
| UDP |
+----------------------+
| Timing PDU |
+----------------------+
Figure (4) - Timing over UDP/IP over MPLS Encapsulation
]]></artwork>
</figure>
<t>This encapsulation is very simple and is useful when the network between
Timing Master Clock and Slave Clock is MPLS network. </t>
<t> In order for an LER/LSR to process Timing messages, the Timing LSP Label
must be at the top label of the label stack. The LER/LSR MUST know that
the Timing LSP Label is used for carrying Timing messages. This can be
accomplished via static configuration or via RSVP-TE signaling. </t>
<t> The UDP/IP encapsulation of PTP MUST follow Annex D and E of <xref
target="IEEE-1588" />.
While the UDP/IP encapsulation of NTP MUST follow <xref target="RFC5905" />. </t>
</section>
<section title="Timing over PW Encapsulation ">
<t>Another method of transporting Timing over MPLS networks is by
encapsulating Timing PDUs in PW which in turn is transported over Timing
LSPs. In case of PTP, Ethernet PW encapsulation <xref target="RFC4448" />, shown in Fig
5(A) MUST be used and the Ethernet encapsulation of PTP MUST follow Annex
F of <xref
target="IEEE-1588" />.</t>
<t> The RAW mode or Tagged mode defined in <xref target="RFC4448" /> MAY be used and the Payload MUST
have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). The Timing over PW encapsulation
MUST use the Control Word (CW) as specified in <xref target="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. </t>
<t> Timing over PW encapsulation for NTP MUST use NTP over UDP/IP over PW
(the IP PW discussed in <xref target="RFC4447" />) shown in Fig 5(B). </t>
<figure>
<artwork><![CDATA[
+----------------+ +----------------+
|Timing LSP Label| |Timing LSP Label|
+----------------+ +----------------+
| PW Label | | PW Label |
+----------------+ +----------------+
| Control Word | | IP |
+----------------+ +----------------+
| Ethernet | | UDP |
| Header | +----------------+
+----------------+ | Timing PDU |
|S-VLAN(Optional)| | |
+----------------+ +----------------+
|C-VLAN(Optional)| (B)
+----------------+
| Timing PDU |
| |
+----------------+
(A)
Figure (5) - Timing over PW Encapsulations
]]></artwork>
</figure>
<t> In order for an LSR to process PTP messages, the top label of the label
stack (the Tunnel Label) MUST be a Timing label. </t>
</section>
<section title="Other Timing Encapsulation methods ">
<t> 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.
</t>
</section>
</section>
<section anchor="TimingMessageProcessing" title="Timing message Processing">
<t>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. </t>
<t> Some of the Timing messages require time stamping or correction field
update 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 update correction field(e.g., TC).</t>
<t> For example the following PTP messages (called Event messages) require
time-stamping or correction field update: </t>
<t>
<list style="symbols">
<t>SYNC</t>
<t>DELAY_REQ (Delay Request)</t>
<t>PDELAY_REQ (Peer Delay Request)</t>
<t>PDELAY_RESP (Peer Delay Response)</t>
</list>
</t>
<t>SYNC and DELAY_REQ are exchanged between Master Clock and Slave Clock
and MUST be transported over PTP LSPs. PDELAY_REQ and PDELAY_RESP
are exchanged between adjacent PTP clocks (i.e. Master, Slave,
Boundary, or Transparent) and SHOULD be transported over single hop
PTP LSPs. If Two Step PTP clocks are present, then the FOLLOW_UP,
and PDELAY_RESP_FOLLOW_UP messages MUST also be transported over the PTP LSPs. </t>
<t>For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be
transported over two PTP LSPs that are in opposite directions. These PTP
LSPs, which are in opposite directions MUST be congruent and co-routed.
Alternatively, a single bidirectional co-routed LSP can be used.</t>
<t>Except as indicated above for the two-step PTP clocks, Non-Event PTP
message types do not need to be processed by intermediate routers. These
message types MAY be carried in PTP Tunnel LSPs.</t>
</section>
<section anchor="Protection" title="Protection and Redundancy">
<t>In order to ensure continuous uninterrupted operation of slave clocks,
usually as a general practice, slave clocks (or ports) track redundant
master clocks. </t>
<t> It is the responsibility of the network operator to ensure that
physically disjoint Timing LSPs are established between a slave clock (or
port) and redundant master clocks (or ports). </t>
<t> When a slave clock (or port) listens to redundant master clocks or ports,
any prolonged Timing LSP outage will trigger the slave clock or port to
switch to a redundant master clock or port. </t>
<t> 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. </t>
<t>Therefore protection switching MAY be used, as long as phase jumps
upon switchover due to differences in path latency are detected and
compensated for (such compensation not being required if BCs or peer-peer TCs are used throughout). </t>
<t> Note that any protection or reroute mechanism that adds additional MPLS
label to the label stack, such as Facility Backup Fast Reroute, MUST
ensure that the pushed label is also a Timing Label to ensure recognition
of the MPLS frame as containing Timing messages, as it transits the
backup path. </t>
</section>
<section anchor="ECMP" title="ECMP">
<t> To ensure the optimal operation of slave clocks and avoid error
introduced by forward and reverse path delay asymmetry, the physical path
for Timing messages from master clock to slave Clock and vice versa must
be the same for all Event Timing messages listed in section 7. </t>
<t>Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost
Multipath). </t>
</section>
<section anchor="PHP" title="PHP">
<t> To ensure that the label on the top of the label stack is the Timing LSP
Label, PHP MUST not be used. </t>
</section>
<section anchor="Entropy" title="Entropy">
<t> To ensure all Timing messages in a Timing LSP take the same path, Entropy Label
MUST NOT be used for the Timing LSP<xref target="RFC6790" /> and Entropy Label MUST NOT be
used for the PWs that are carried inside Timing LSP <xref target="RFC6391" />. </t>
</section>
<section anchor="OAM" title="OAM, Control and Management">
<t>In order to monitor 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. </t>
<t> For example BFD <xref target="RFC5880" />, <xref target="RFC5884" /> and
LSP-Ping <xref target="RFC4389" /> MAY run
over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These
Management protocols can easily be identified by the UDP Destination
Port number or by GAL/G-ACH respectively. </t>
<t>Also BFD, LSP-Ping and other management messages MAY run over the PWs
encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3 or 4)
<xref target="RFC5085" /> (note that VCCV Type 2 using Router Alert Label is going to be
deprecated by IETF). In this case G-ACH, PW label (TTL=1) or GAL-ACH are
used to identify such management messages. </t>
</section>
<section anchor="QoS" title="QoS Considerations">
<t>In network deployments where not every LSR/LER is Timing-aware, it is
important to reduce the impact of the non-Timing-aware LSR/LERs on the
timing recovery in the slave clock. The Timing messages are time
critical and must be treated with the highest priority. Therefore Timing
over MPLS messages must be treated with the highest priority in the
routers. This can be achieved by proper setup of Timing LSPs. </t>
<t> It is recommended that the Timing LSPs are setup or configured properly
to indicate EF-PHB <xref target="RFC3246" />for the CoS and Green <xref target="RFC2697" /> for drop
eligibility. </t>
</section>
<section anchor="FCS" title="FCS and Checksum Recalculation">
<t>When time-stamp generation and timing packet adjustment is performed near
the physical port hardware, the process MUST include recalculation of the
Ethernet FCS. Also FCS retention for the payload Ethernet described in
<xref target="RFC4720" /> MUST NOT be used. </t>
<t>For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum
may be required as per UDP transport standards. </t>
<t> 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. </t>
</section>
<section anchor="Behavior" title="Behavior of LER/LSR ">
<t> Timing-capable/aware LERs and LSRs are routers that have one or more
interfaces that can perform Timing operations (OC/BC/TC) on Timing
packets and are configured to do so. Timing-capable/aware LERs and
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.
</t>
<section anchor="Behavior_LER" title="Behavior of Timing-capable/aware LER ">
<t>
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.
</t>
<t>
When a Timing-capable/aware LER behaves as a Boundary clock and
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. </t>
<t> When a Timing-capable/aware LER behaves as an Ordinary Clock toward
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.
</t>
</section>
<section anchor="Behavior_LSR" title="Behavior of Timing-capable/aware LSR ">
<t>
When a Timing-capable/aware LSR behaves as a Transparent clock and
receives a Timing message from a Timing-capable/aware MPLS interface,
The LSR updates the Correction Filed (CF) and forwards the timing
message over another MPLS interface. </t>
<t> When a Timing-capable/aware LSR behaves as a Boundary clock and
receives a Timing message from a Timing-capable/aware MPLS interface.
The LSR performs the functions of a Boundary Clock in terminating
the received Timing message and re-generating a new timing message
over another (or the same) MPLS interface.
</t>
</section>
<section anchor="NonBehavior_LSR" title="Behavior of non-Timing-capable/aware LSR ">
<t>
It is most beneficial when all LSRs in the path of a Timing LSP be
timing-Capable/aware LSRs. This would ensure the highest quality
time and clock synchronization by Timing Slave Clocks. However, this specification does not mandate that all LSRs in path of a Timing LSP
be Timing- capable/aware. </t>
<t> Non-Timing-capable/aware LSRs just switch the packets encapsulated in
Timing LSPs and dont perform any Timing operation (TC or BC). However as explained in QoS section the Timing over MPLS packets MUST be still
be treated with the highest priority based on their Traffic Class
(TC) marking.
</t>
</section>
</section>
<section title="Other considerations">
<t> <xref target="IEEE-1588" /> defines an optional peer-to-peer Transparent clocking that
requires peer delay measurement between two adjacent Timing-capable/
aware 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.
</t>
<t> For transporting such peer delay measurement messages a single-hop LSP
SHOULD to be created between the two adjacent LSRs engaged in peer
delay measurement to carry peer delay measurement messages. 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.
</t>
<t> In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/
ware routers/switches MUST maintain a list of all the neighbors it
needs to send a PDelay_Req to, where each neighbor corresponds to a
timing LSP.
</t>
<t>The use of Explicit Null Label (Label= 0 or 2) is acceptable as long as
either the Explicit Null label is the bottom of stack label (applicable
only to UDP/IP encapsulation) or the label below the Explicit Null label
is a PTP label.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>MPLS PW security considerations in general are discussed in <xref
target="RFC3985" /> and <xref target="RFC4447" />,and those
considerations also apply to this document.</t>
<t>An experimental security protocol is defined in <xref target="IEEE-1588" />.The PTP
security extension and protocol provides group source authentication,
message integrity, and replay attack protection for PTP messages.</t>
<t> When the MPLS network (provider network) serves multiple customers, it
is important to maintain and process each customers clock and Timing
messages separately from other customers to ensure there is no cross-
customer effect. For example if an LER BC is synchronized to a
specific grandmaster, belonging to customer A, then the LER MUST use
that BC clock only for customer A to ensure that customer A cannot
attack other customers by manipulating its time. </t>
<t> Timing messages MAY be encrypted or authenticated, provided that the LERs/LSRs that are Timing capable/aware can authenticate/ decrypt the timing messages.
</t>
</section>
<section anchor="Ack" title="Acknowledgements">
<t>The authors would like to thank Ron Cohen, Yaakov Stein, Tal Mizrahi,
Stefano Ruffini, Peter Meyer, and other members of IETF for reviewing and providing feedback on this draft. </t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>There are no IANA requirements in this specification. </t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="IEEE-1588">
<front>
<title>IEEE Standard for a Precision Clock Synchronization Protocol
for Networked Measurement and Control Systems</title>
<author fullname="" initials="" surname="">
<organization>IEEE 1588-2008</organization>
</author>
</front>
</reference>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.4720'?>
<?rfc include='reference.RFC.5884'?>
<?rfc include='reference.RFC.4448'?>
<?rfc include='reference.RFC.4447'?>
<?rfc include='reference.RFC.4389'?>
<?rfc include='reference.RFC.5085'?>
<?rfc include='reference.RFC.5880'?>
<?rfc include='reference.RFC.3985'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-pwe3-fat-pw'?>
<?rfc include='reference.RFC.1195'?>
<?rfc include='reference.RFC.2328'?>
<?rfc include='reference.RFC.3784'?>
<?rfc include='reference.RFC.4970'?>
<?rfc include='reference.RFC.4971'?>
<?rfc include='reference.RFC.5340'?>
<?rfc include='reference.RFC.3630'?>
<?rfc include='reference.RFC.5329'?>
<?rfc include='reference.RFC.5305'?>
<?rfc include='reference.RFC.5120'?>
<?rfc include='reference.RFC.5905'?>
<?rfc include='reference.RFC.6391'?>
<?rfc include='reference.RFC.3246'?>
<?rfc include='reference.RFC.2697'?>
<?rfc include='reference.RFC.6790'?>
<reference anchor="ISO">
<front>
<title>Intermediate system to Intermediate system routeing
information exchange protocol for use in conjunction with the
Protocol for providing the Connectionless-mode Network Service (ISO
8473)</title>
<author fullname="" initials="" surname="">
<organization>ISO/IEC 10589:1992</organization>
</author>
</front>
</reference>
</references>
</back>
<section anchor="Appendix A" title="Routing extensions for Timing-aware Routers ">
<t>MPLS-TE routing relies on extensions to OSPF <xref
target="RFC2328" /> <xref target="RFC5340" /> and IS-IS <xref
target="ISO" /> <xref target="RFC1195" /> in order to advertise Traffic
Engineering (TE) link information used for constraint-based routing.</t>
<t>Indeed, it is useful to advertise data plane TE router link
capabilities, such as the capability for a router to be Timing-aware. This
capability MUST then be taken into account during path computation to
prefer or even require links that advertise themselves as Timing-aware. In
this way the path can ensure the entry and exit points into the LERs
and, if desired, the links into the LSRs are able to perform port based
time-stamping thus minimizing their impact on the performance of the
slave clock.</t>
<t>extensions are required to OSPF and IS-IS in order to
advertise Timing-aware capabilities of a link. Such extensions are
outside the scope of this document; however such extension SHOULD be able
to signal the following information per Router Link:</t>
<t>
<list style="symbols">
<t>Capable of processing PTP, NTP or other Timing flows </t>
<t>Capable of performing Transparent Clock operation </t>
<t>Capable of performing Boundary Clock operation </t>
</list>
</t>
</section>
<section anchor="Appendix 2" title="Signaling Extensions for Creating Timing LSPs">
<t>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: </t>
<t>The following information MAY also be included in the new Extensions to
RSVP-TE:
</t>
<t>
<list style="symbols">
<t> Offset from Bottom of Stack (BoS) to the start of the
Time-stamp field </t>
<t> Number of VLANs in case of PW encapsulation </t>
<t> Timestamp field Type </t>
<list style="symbols">
<t> Correction Field, Timestamp </t>
</list>
<t> Timestamp Field format </t>
<list style="symbols">
<t> 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit
NTP, etc. </t>
</list>
</list>
</t>
<t>Note that in case the above optional information is signaled with RSVP-TE
for a Timing LSP, all the Timing packets carried in that LSP must have
the same signaled characteristics. For example if Timestamp format is
signaled as 64-bit PTPv1, then all Timing packets must use 64-bit PTPv1
time-stamp. </t>
</section>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 23:25:55 |