One document matched: draft-ietf-tictoc-1588overmpls-07.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc category="exp" docName="draft-ietf-tictoc-1588overmpls-07" 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>
<date day="16" month="October" year="2015" />
<area>Internet Area</area>
<workgroup>TICTOC Working Group</workgroup>
<abstract>
<t> This document defines a method for transporting timing messages, such as
Precision Time Protocol (PTP) or Network Time Protocol (NTP),
over a Multiprotocol Label Switched (MPLS) network.
The method facilitates efficient recognition of timing packets to enable their port level
processing in both Label Edge Routers (LERs) and Label Switched Routers (LSRs). </t>
<t> The basic mechanism is to transport timing messages inside "Timing LSPs",
which are dedicated MPLS Label Switched Paths (LSPs)
that carry only timing, and possibly related Operations, Administration and Maintenance (OAM) or management packets,
but do not carry customer traffic. </t>
<t> Two encapsulations methods are defined.
The first transports UDP/IP encapsulated timing messages directly over the dedicated LSP.
The second transports Ethernet encapsuled timing messages inside an Ethernet pseudowire. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<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>
<t> The objective of timing distribution protocols, such as Precision Time Protocol (PTP) and Network Timing Protocol (NTP),
is to synchronize clocks running on nodes of a distributed system. </t>
<t> Timing distribution protocols are presently transported over IP or Ethernet.
The present document presents a mechanism for transport over Multiprotocol Label Switched (MPLS) networks.
Our solution involves transporting timing messages over dedicated "Timing Label Switched Paths (LSPs)".
These are ordinary LSPs that carry timing messages and MAY carry Operations, Administration and Maintenance (OAM) or management messages,
but do not carry any other traffic. </t>
<t> Timing LSPs may be established statically or via signaling.
When using signaling, extensions to routing protocols (e.g., OSPF, ISIS)
are required to enable routers to distribute their timing processing capabilities,
and extensions to path set up protocols (e.g., RSVP-TE) are required for establishing the LSPs.
All such extensions are beyond the scope of this document. </t>
<t> High accuracy timing distribution requires on-path support,
e.g., Transparent Clocks (TCs) or Boundary Clocks (BCs), at intermediate nodes.
These intermediate nodes need to recognize and appropriately process timing distribution packets.
To facilitate efficient recognition of timing messages transported over MPLS,
this document restricts the specific encapsulations to be used. </t>
<t> <xref target="IEEE-1588" /> defines PTP messages for frequency, phase and time synchronization.
PTP messages may be transported over UDP/IP (Annex D and E of <xref target="IEEE-1588" />)
or over Ethernet (Annex F of [IEEE-1588]).
This document defines two methods to transport PTP messages over MPLS networks.</t>
<t> PTP defines several clock types, including ordinary clocks, boundary clocks, end-to-end transparent
clocks, and peer-to-peer transparent clocks.
Transparent clocks are situated at intermediate nodes and update the Correction Field inside PTP messages
in order to reflect the time required to transit the node. </t>
<t> <xref target="RFC5905" /> defines NTP messages for clock and time synchronization.
NTP messages are transported over UDP/IP.
This document defines a method to transport NTP messages over MPLS networks. </t>
<t> It can be expected that only a subset of LSR ports will be capable of processing timing messages.
Timing LSPs MUST be set up (either by manual provisioing or via signaling) to traverse these ports.
While Timing LSPs are designed to optimize timing distribution,
the performance of slave clocks is beyond the scope of this document. </t>
<t> Presently on-path support is only defined for PTP,
and therefore much of our discussion will focus on PTP.
NTP timing distribution may benefit from transport in a Timing LSP
due to prioritorization or selection of ports or nodes with minimal delay or delay asymmetry. </t>
</section>
<section title="Terminology">
<t>1588: The timing distribution protocol defined in IEEE 1588.</t>
<t>Boundary Clock: A device with one timing port to receive timing messages and
at least one port to re-distribute timing messages.</t>
<t>CF: Correction Field, a field inside certain PTP messages that holds the accumulated transit time.</t>
<t>Master Clock: The source of 1588 timing messages to a set of slave clocks.</t>
<t>NTP: The timing distribution protocol defined in RFC 5905. </t>
<t>Ordinary Clock: A master or slave clock. Note that ordinary clocks have only a single PTP port.</t>
<t>PTP: Precision Time Protocol. See 1588.</t>
<t>Slave Clock: A receiver of 1588 timing messages from a master clock.</t>
<t>Timing LSP: An MPLS LSP dedicated to carry timing messages.</t>
<t>Timing messages: Timing distribution protocol messages that are exchanged between clocks. </t>
<t>Timing port: A port on a (master, slave, transparent, or boundary) clock. </t>
<t>Timing PW: A PW within a Timing LSP that is dedicated to carry timing messages.</t>
<t>Transparent Clock: An intermediate node that forwards timing messages while updating their CF.</t>
</section>
<section title="Problem Statement">
<t> <xref target="IEEE-1588" /> defines methods for transporting PTP messages over
Ethernet and IP networks. <xref target="RFC5905" /> defines a 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) functionalities in
LER and LSRs of the MPLS network. </t>
<t> There are potentially many ways of transporting timing packets over MPLS.
However, it is advisable to limit the number of possible encapsulation options
to simplify recognition and processing of timing packets. </t>
<t> The solution herein desscribed transports timing messages over dedicated "Timing Label Switched Paths (LSPs)".
Were timing packets to share LSPs with other traffic,
intermediate LSRs would be required to perform some deeper inspection to
differentiate between timing packets and other packets.
The method herein proposed avoids this complexity,
and can readily detect all PTP messages (one-step or two-step),
and supports ordinary, boundary and transparent clocks. </t>
</section>
<section title="Timing over MPLS Architecture">
<t> Timing messages are exchanged between timing ports on ordinary and
boundary clocks. Boundary clocks terminate the timing messages and act as
master clock for other boundary clocks or slave clocks.
End-to-End transparent clocks do not terminate the timing messages but
do modify the contents of the timing messages in transit. </t>
<t> OC, BC and TC functionality may be implemented in either LERs or LSRs. </t>
<t> An example is shown in Figure 1, where the LERs act as OCs
and are the initiating/terminating points for timing messages.
The ingress LER encapsulates timing messages in a Timing LSP and
the egress LER terminates this Timing LSP.
Intermediate LSRs (only one is shown here) act as TCs, updating the CF of transiting timing messages,
as well as performing label switching operations. </t>
<figure>
<artwork><![CDATA[
+--------+ +-------+ +-------+ +-------+ +--------+
|Switch, | | | | | | | |Switch, |
| Router |-----| LER |-----| LSR |-----| LER |-----| Router |
| | | OC | | TC | | OC | | |
+--------+ +-------+ +-------+ +-------+ +--------+
/ \
+-------+ / \ +-------+
| LER | / \ | LER |
| Master|---/ \---| Slave |
| Clock | | Clock |
+-------+ +-------+
]]></artwork>
<postamble> Figure (1) - Deployment example 1 of timing over MPLS network </postamble>
</figure>
<t> Another example is shown in Figure 2, where LERs act as BCs,
and switches/routers outside of the MPLS network, act as OCs or BCs.
The ingress LER BC recovers timing and initiates timing messages encapsulated in the Timing LSP toward
the MPLS network, an intermediate LSR acts as a TC,
and the egress LER acts as a BC sending timing messages to equipment outside the MPLS network. </t>
<figure>
<artwork><![CDATA[
+--------+ +-------+ +-------+ +-------+ +--------+
|Switch, | | | | | | | |Switch, |
| Router |-----| LER |-----| LSR |-----| LER |-----| Router |
| OC/BC | | BC | | TC | | BC | | OC/BC |
+--------+ +-------+ +-------+ +-------+ +--------+
]]></artwork>
<postamble> Figure (2) - Deployment example 2 of timing over MPLS network </postamble>
</figure>
<t> Yet another example is shown in Figure 3, where both LERs and LSRs act as TCs.
The ingress LER updates the CF and encapsulates the timing message in an MPLS packet,
intermediate LSRs update the CF and perform label switching,
and the egress LER updates the CF and sends the timing messages to equipment outside the MPLS network.
</t>
<figure>
<artwork><![CDATA[
+--------+ +-------+ +-------+ +-------+ +--------+
|Switch, | | | | | | | |Switch, |
| Router |-----| LER |-----| LSR |-----| LER |-----| Router |
|OC/TC/BC| | TC | | TC | | TC | |OC/TC/BC|
+--------+ +-------+ +-------+ +-------+ +--------+
]]></artwork>
<postamble> Figure (3) - Deployment example 3 of timing over MPLS network </postamble>
</figure>
<t> A final example is shown in Figure 4, where all nodes act as BCs.
Single-hop LSPs are created between every two adjacent LSRs.
Of course, PTP transport over Ethernet MAY be used between two network elements.
</t>
<figure>
<artwork><![CDATA[
+--------+ +-------+ +-------+ +-------+ +--------+
|Switch, | | | | | | | |Switch, |
| Router |-----| LER |-----| LSR |-----| LER |-----| Router |
| OC/BC | | BC | | BC | | BC | | OC/BC |
+--------+ +-------+ +-------+ +-------+ +--------+
]]></artwork>
<postamble> Figure (4) - Deployment example 3 of timing over MPLS network </postamble>
</figure>
<t> An MPLS domain MAY serve multiple customers, each having its own Timing domain.
In these cases the MPLS domain (maintained by a service provider)
MUST provide dedicated timing services to each customer. </t>
<t> The timing over MPLS architecture assumes a 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 MAY be transported over P2MP Timing LSPs or MAY be replicated and
transported over multiple P2P Timing LSPs. </t>
<t> Timing LSPs, as defined by this specification, MAY be used for
timing messages that do not require time-stamping or CF updating. </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> The method defined in this document is used by LER and LSRs to
identify timing messages by observing the top label of the MPLS label stack.
Compliant implementations MUST use dedicated LSPs to carry timing
messages over MPLS. Such LSPs are herein referred to as "Timing LSPs"
and the labels associated with these LSPs as "Timing LSP labels". </t>
<t> Timing distribution requires symmetrical bidirectional communications.
Co-routing of the two directions is required to limit delay asymmetry.
Thus timing messages MUST be transported either over two co-routed unidirectional Timing LSPs,
or a single bidirectional co-routed Timing LSP. </t>
<t> Timing LSPs MAY be configured using RSVP-TE.
Extensions to RSVP-TE are required for this purpose, but are beyond the scope of this document. </t>
</section>
<section title="Timing over LSP Encapsulation">
<t> We define two methods for carrying timing messages over MPLS.
The first method transports UDP/IP-encapsulated timing messages over Timing LSPs,
and the second method transports Ethernet encapsulated timing messages over Ethernet PWs
placed in Timing LSPs.</t>
<section title="Timing over UDP/IP over MPLS Encapsulation ">
<t> The first method directly encapsulates UDP/IP timing messages in a Timing LSP.
The UDP/IP encapsulation of PTP messages MUST comply to Annex D and E of <xref target="IEEE-1588" />,
and the UDP/IP encapsulation of NTP messages MUST comply to <xref target="RFC5905" />.
This format is shown in Figure 4. </t>
<figure>
<artwork><![CDATA[
+----------------------+
| Timing LSP Label |
+----------------------+
| IPv4/6 |
+----------------------+
| UDP |
+----------------------+
| timing message |
+----------------------+
Figure (4) - Timing over UDP/IP over MPLS Encapsulation
]]></artwork>
</figure>
<t> In order for an LER/LSR to process timing messages, the Timing LSP Label
must be the top label of the label stack. The LER/LSR MUST know that
this label is a Timing LSP Label.
It can learn this by static configuration or via RSVP-TE signaling. </t>
</section>
<section title="Timing over PW Encapsulation ">
<t> Another method of transporting timing over MPLS networks is to use Ethernet encapsulated
timing messages, and to transport these in an Ethernet PW which in turn is transported over a Timing LSP.
In the case of PTP, the Ethernet encapsulation MUST comply to Annex F of <xref target="IEEE-1588" />
and the Ethernet PW encapsulation to <xref target="RFC4448" />,
resulting in the format shown in Figure 5(A).</t>
<t> Either the Raw mode or Tagged mode defined in [RFC-4448] MAY be used and the payload MAY
have 0, 1, or 2 VLAN tags. The Timing over PW encapsulation
MUST use the Control Word (CW) as specified in <xref target="RFC4448" />.
The use of Sequence Number in the CW is optional. </t>
<t> NTP MAY be transported using an IP PW (as defined in <xref target="RFC4447" />)
as 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 message |
|S-VLAN (Optional)| | |
+-----------------+ +----------------+
|C-VLAN (Optional)| (B)
+-----------------+
| Timing message |
| |
+-----------------+
(A)
Figure (5) - Timing over PW Encapsulations
]]></artwork>
</figure>
</section>
</section>
<section anchor="TimingMessageProcessing" title="Timing message Processing">
<t>Each Timing protocol such as PTP and NTP, defines a set of timing messages.
PTP defines SYNC, DELAY_REQ, DELAY_RESP, FOLLOW_UP, etc. </t>
<t>Some timing messages require per-packet processing, such as time-stamping or CF updating.
A compliant LER/LSR parses each timing message to determine the required processing. </t>
<t> For example, the following PTP messages (event messages) require time-stamping or CF updating:
<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 a Master Clock and a Slave Clock
and MUST be transported over Timing LSPs.
PDELAY_REQ and PDELAY_RESP are exchanged between adjacent PTP clocks (master, slave,
boundary, or transparent) and SHOULD be transported over single hop Timing LSPs.
If two-Step PTP clocks are present, then the FOLLOW_UP, and PDELAY_RESP_FOLLOW_UP messages
MUST also be transported over Timing LSPs. </t>
<t> For a given instance of the 1588 protocol, SYNC and DELAY_REQ MUST be transported in opposite directions.
As aforementioned, two co-routed unidirectional LSPs or a single bidirectional co-routed LSP MAY be used.</t>
<t> Except as indicated above for two-step PTP clocks,
PTP messages that are not "event messages" need not 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 timing distribution,
slave clocks often track redundant master clocks.
Prolonged outages of Timing LSPs trigger switching to a redundant master clock
It is the responsibility of the network operator to ensure that
physically disjoint Timing LSPs are established between a slave clock and redundant master clocks. </t>
<t> LSP or PW layer protection, such as linear protection Switching, ring
protection switching or MPLS Fast Reroute (FRR), will lead to changes in propagation delay between master and slave clocks.
Such a change, if undetected by the slave clock, would negatively impact timing performance.
While it is expected that slave clocks will often be able to detect such delay changes,
this specification RECOMMENDS that automatic protection switching NOT be used for Timing LSPs,
unless the operator can ensure that it will not negatively impact timing performance. </t>
</section>
<section anchor="ECMP" title="ECMP and Entropy">
<t> To ensure the correct operation of slave clocks and avoid error
introduced by forward and reverse path delay asymmetry, the physical path
taken by timing messages MUST be the same for all timing messages.
In particular, the PTP event messages listed in section 7 MUST be routed in the same way. </t>
<t> Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost Multipath).
Entropy labels MUST NOT be used for the Timing LSP <xref target="RFC6790" />
and MUST NOT be used for PWs inside the Timing LSP <xref target="RFC6391" />. </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 employed. </t>
</section>
<section anchor="OAM" title="OAM, Control and Management">
<t> In order to monitor Timing LSPs or PWs, it is necessary to enable them to carry OAM messages.
OAM packets MUST be differentiated from timing messages by already defined IETF methods. </t>
<t> For example BFD <xref target="RFC5880" />, <xref target="RFC5884" /> and
LSP-Ping <xref target="RFC4389" /> MAY run over Timing LSPs via UDP/IP encapsulation or via GAL/G-ACh.
These 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 messages MAY run over Timing PWs via VCCV <xref target="RFC5085" />.
In this case these messages are recognized according to the VCCV type. </t>
</section>
<section anchor="QoS" title="QoS Considerations">
<t> There may be deployments where timing messages traverse LSR/LERs that are
not capable of the required processing.
In order to minimize the negative impact on the timing performance of the slave clock
timing messages MUST be treated with the highest priority.
This can be achieved by proper setup of Timing LSPs. </t>
<t> It is recommended that Timing LSPs be configured 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> Since Boundary and Transparent Clocks modify packets,
when the MPLS packets are transported over Ethernet
the processing MUST include recalculation of the Ethernet FCS.
FCS retention as described in <xref target="RFC4720" /> MUST NOT be used. </t>
<t> For the UDP/IP encapsulation mode, calculation of the UDP checksum will generally be required.
After updating the CF a Transparent Clock MUST either incrementally update the UDP checksum
or completely recalculate the checksum before transmission to downstream node. </t>
</section>
<section title="Behavior of LER/LSRs">
<t> Timing-aware LERs or LSRs are MPLS routers that are able to recognize timing packets.
Timing-capable LERs and LSRs further have one or more
interfaces that can perform timing processing (OC/BC/TC) on timing packets.
Timing-capable/aware LERs and LSRs MAY advertise the timing capabilities of their interfaces
via control plane protocols such as OSPF or IS-IS,
and timing-aware LERs can then be set up Timing LSPs via RSVP-TE signaling.
Alternatively the timing capabilities of LERs and LSRs may be known by a centralized controller
or management system, and Timing LSPs may be manually configured,
or set up by a management platform or a Software Defined Networking (SDN) controller.
</t>
<section title="Behavior of Timing-capable/aware LERs/LSRs">
<t> When a timing-capable ingress LER acting as a TC
receives a timing message packet from a timing-capable non-MPLS interface,
the LER updates the CF, encapsulates and forwards the packet
over a previously established Timing LSP.
When a timing-capable egress LER acting as a TC
receives a timing message packet on timing-capable MPLS interface,
the LER updates the CF, decapsulates the MPLS encapsulation,
and forwards the packet via a non-MPLS interface.
When a timing-capable LSR acting as a TC
receives a timing message from a timing-capable MPLS interface,
the LSR updates the CF and forwards the timing message over another MPLS interface. </t>
<t> When a timing-capable LER acting as a BC
receives a timing message packet from a timing-capable interface,
the LER time-stamps the packet and sends it to the BC processing module. </t>
<t> When a timing-capable LER acting as an OC
receives a timing message from a timing-capable MPLS interface,
the LER time-stamps the packet and sends it to the OC processing module. </t>
</section>
<section 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 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 perform label switching on the packets encapsulated in
Timing LSPs and don't perform any timing related processing. However, as
explained in QoS section, timing packets MUST be still be
treated with the highest priority based on their Traffic Class marking. </t>
</section>
</section>
<section title="Other considerations">
<t> <xref target="IEEE-1588" /> defines an optional peer-to-peer transparent clocking (P2P TC) mode
that compensates both for residence time in the network node and for propagation time
on the link between modes.
To support P2P TC, delay measurement must be performed between two adjacent timing-capable/aware LSRs.
Thus, in addition to the TC functionality detailed above on transit PTP timing messages,
adjacent peer to peer TCs MUST engage in single-hop peer delay measurement. </t>
<t> For single hop peer delay measurement a single-hop LSP SHOULD be created
between the two adjacent LSRs.
Other methods MAY be used; for example, if the link between the
two adjacent routers is Ethernet, PTP transport over Ethernet MAY be used. </t>
<t> To support P2P TC, a timing-capable/ware LSR MUST maintain a list of all neighbors
to which it needs to send a PDelay_Req, and maintain a single-hop timing LSP to each. </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 (for the UDP/IP encapsulation)
or the label below the Explicit Null label (for the PW case). </t>
</section>
<section anchor="Security" title="Security Considerations">
<t> Security considerations for MPLS and pseudowires are discussed in
<xref target="RFC3985" /> and <xref target="RFC4447" />.
Security considerations for timing are discussed in <xref target="RFC7384" />.
Everything discussed in those documents applies to the Timing LSP of 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 distinguish between timing messages belonging to different customers.
For example if an LER BC is synchronized to a grandmaster belonging to customer A,
then the LER MUST only use that BC for slaves of customer A,
to ensure that customer A cannot adversely affect the timing distribution of other customers. </t>
<t> Timing messages MAY be encrypted or authenticated, provided that the
timing-capable LERs/LSRs can authenticate/ decrypt the timing messages. </t>
</section>
<section anchor="Applicability" title="Applicability Statement ">
<t> The Timing over MPLS transport methods described in this document apply
to the following network Elements:
<list style="symbols">
<t> An ingress LER that receives IP or Ethernet encapsulated timing messages from a
non-MPLS interface and forwards them as MPLS encapsulated timing
messages over Timing LSP, optionally performing TC functionality. </t>
<t> An egress LER that receives MPLS encapsulated timing messages from a Timing LSP
and forwards them to non-MPLS interface as IP or Ethernet encapsulated timing messages,
optionally performing TC functionality. </t>
<t> An ingress LER that receives MPLS encapsulated timing messages from a non-MPLS interface,
performs BC functionality, and sends timing messages over a Timing LSP. </t>
<t> An egress LER that receives MPLS encapsulated timing messages from a Timing LSP,
performs BC functionality, and sends timing messages over a non-MPLS interface. </t>
<t> An LSR on a Timing LSP that receives MPLS encapsulated timing messages from one MPLS interface
and forwards them to another MPLS interface, optionally performing TC functionality. </t>
</list>
</t>
<t> This document also supports the case where not all LSRs are timing-capable/aware,
or not all LER/LSR interfaces are timing-capable/aware.
</t>
</section>
<section anchor="Ack" title="Acknowledgements">
<t>The authors would like to thank Yaakov Stein, Luca Martini, Ron Cohen,
Tal Mizrahi, Stefano Ruffini, Peter Meyer and other IETF participants for
reviewing and providing feedback on this draft. </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>
<date month="July" year="2008" />
</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.RFC.1195'?>
<?rfc include='reference.RFC.2328'?>
<?rfc include='reference.RFC.5340'?>
<?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'?>
<?rfc include='reference.RFC.7384'?>
<reference anchor="ISO">
<front>
<title>Intermediate system to Intermediate system routing
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>
<date month="April" year="1992" />
</front>
</reference>
</references>
<section anchor="Appendix" title="Appendix">
<section anchor="Routing" 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> Timing related capabilities, such as the capability for a router to perform time-stamping, and OC, TC or BC processing,
need to be advertised in order for them to be taken into account during path computation.
A management system or SDN controller cognizant of timing related capabilities,
can prefer or even require a Timing LSP to traverse links or nodes or intefaces with the required capabilities.
The optimal path will optimize the performance of the slave clock.</t>
<t> Extensions are required to OSPF and IS-IS in order to advertise timing related capabilities of a link.
Such extensions are outside the scope of this document;
however such extensions SHOULD be able to signal the following information per Router Link:
<list style="symbols">
<t>Capable of processing PTP, NTP or other timing flows </t>
<t>Capable of performing TC operation </t>
<t>Capable of performing BC operation </t>
</list>
</t>
</section>
<section anchor="RSVP" title="Signaling Extensions for Creating Timing LSPs">
<t> RSVP-TE signaling MAY be used to set up Timing LSPs.
Extensions are required to RSVP-TE for this purpose.
Such extensions are outside the scope of this document;
however, the following information MAY be included in such extensions:
<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> Time-stamp field Type
<list style="symbols">
<t> Correction Field, time-stamp </t>
</list>
</t>
<t> Time-stamp Field format
<list style="symbols">
<t> 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit NTP, etc. </t>
</list>
</t>
</list>
</t>
<t> Note that when 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 time-stamp format is
signaled as 64-bit PTPv1, then all timing packets must use 64-bit PTPv1 time-stamp. </t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:40:35 |