One document matched: draft-ietf-tictoc-1588overmpls-02.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-02"
ipr="trust200902">
<front>
<title abbrev="1588 over MPLS">Transporting PTP messages (1588) 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="7" month="October" year="2011" />
<area>Internet Area</area>
<workgroup>TICTOC Working Group</workgroup>
<abstract>
<t>This document defines the method for transporting PTP messages (PDUs)
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 PTP messages inside dedicated MPLS
LSPs. These LSPs only carry PTP messages and possibly Control and
Management packets, but they do not carry customer traffic.</t>
<t>Two methods for transporting 1588 over MPLS are defined. The first
method is to transport PTP messages directly over the dedicated MPLS LSP
via UDP/IP encapsulation, which is suitable for IP/MPLS networks. The
second method is to transport PTP messages inside a PW via Ethernet
encapsulation, which is more suitable for MPLS-TP networks.</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) is to synchronize
independent clocks running on separate nodes of a distributed system.
<xref target="IEEE" /> defines PTP messages for clock and time
synchronization. The PTP messages include PTP PDUs over UDP/IP (Annex D
and E of <xref target="IEEE" />) and PTP PDUs over Ethernet (Annex F of
<xref target="IEEE" />). This document defines mapping and transport of
the PTP messages defined in <xref target="IEEE" /> over MPLS
networks.</t>
<t>PTP defines several clock types: ordinary clocks, boundary clocks,
end-to-end transparent clocks, and peer-to-peer transparent clocks. One
key attribute of all of these clocks is the recommendation for PTP
messages processing to 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. 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.</t>
<t>The port based PTP message processing involves PTP event message
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.</t>
<t>This document provides two methods for transporting PTP messages over
MPLS. One is principally focused on an IP/MPLS environment and the
second is focused on the MPLS-TP environment.</t>
<t>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.</t>
<t />
</section>
<section title="Terminology">
<t>1588: The timing and synchronization as defined by IEEE 1588</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>
</section>
<section title="Problem Statement">
<t>When PTP messages are transported over MPLS networks, there is a need
for PTP message processing at the physical port level. This requirement
exists to minimum uncertainty in the transit delays. If 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.</t>
<t>PTP messages over Ethernet or IP can always be tunneled over MPLS.
However there is a requirement to limit the possible encapsulation
options to simplify the PTP message processing required at the port
level. This applies to all 1588 clock types implemented in MPLS routers.
But this is particularly important in LSRs that provide transparent
clock functionality.</t>
<t>When 1588-awareness is needed, PTP messages should not be transported
over LSPs or PWs that are carrying customer traffic because LSRs perform
Label switching based on the top label in the stack. To detect PTP
messages inside such LSPs require special hardware to do deep packet
inspection at line rate. Even if such hardware exists, the payload can't
be deterministically identified by LSRs because the payload type is a
context of the PW label and the PW label and its context are only known
to the Edge routers (PEs); LSRs don't know what is a PW's payload
(Ethernet, ATM, FR, CES, etc). Even if one restricts an LSP to only
carry Etehrent PWs, the LSRs don't have the knowledge of whether PW
Control Word (CW) is present or not and therefore can't
deterministically identify the payload.</t>
<t>Therefore a generic method is defined in this document that does not
require deep packet inspection at line rate, and can deterministically
identify PTP messages. The defined method is applicable to both MPLS and
MPLS-TP networks.</t>
<t />
</section>
<section title="1588 over MPLS Architecture">
<t>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.</t>
<t>Perhaps a picture would be good here.</t>
</section>
<section title="Dedicated LSPs for PTP messages">
<t>Many methods were considered for identifying the 1588 messages when
they are encapsulated in MPLS such as by using GAL/ACH or a new reserved
label. These methods were not attractive since they either required deep
packet inspection and snooping at line rate or they required use of a
scarce new reserved label. Also one of the goals was to reuse existing
OAM and protection mechanisms.</t>
<t>The method defined in this document can be used by LER/LSRs to
identify PTP messages in MPLS tunnels by using dedicated LSPs to carry
PTP messages.</t>
<t>Compliant implementations MUST use dedicated LSPs to carry PTP
messages over MPLS. These LSPs are herein referred to as "PTP LSPs" and
the labels associated with these LSPs as "PTP labels". These LSPs could
be P2P or P2MP LSPs. The PTP LSP between Master Clocks and Slave Clocks
MAY be P2MP or P2P LSP while the PTP LSP between each Slave Clock and
Master Clock SHOULD be P2P LSP. The PTP LSP between a Master Clock and a
Slave Clock and the PTP LSP between the same Slave Clock and Master
Clock MUST be co-routed. Alternatively, 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.</t>
<t>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 indicate
that these LSPs are PTP LSPs.</t>
<t>The PTP LSPs MAY carry essential MPLS/MPLS-TP control plane traffic
such as BFD and LSP Ping but the LSP user plane traffic MUST be PTP
only.</t>
</section>
<section title="1588 over MPLS Encapsulation">
<t>This document defines two methods for carrying 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 dedicated
Ethernet PWs (called PTP PWs) inside PTP LSPs.</t>
<section title="1588 over LSP Encapsulation">
<t>The simplest method of transporting PTP messages over MPLS is to
encapsulate PTP PDUs in UDP/IP and then encapsulate them in PTP LSP.
The 1588 over LSP format is shown in Figure 1.</t>
<figure>
<artwork><![CDATA[
+----------------------+
| PTP Tunnel Label |
+----------------------+
| IPv4/6 |
+----------------------+
| UDP |
+----------------------+
| PTP PDU |
+----------------------+
Figure 1 - 1588 over LSP Encapsulation
]]></artwork>
</figure>
<t>This encapsulation is very simple and is useful when the networks
between 1588 Master Clock and Slave Clock are IP/MPLS networks.</t>
<t>In order for an LSR to process PTP messages, the PTP Label must be
the top label of the label stack.</t>
<t>The UDP/IP encapsulation of PTP MUST follow Annex D and E of <xref
target="IEEE" />.</t>
</section>
<section title="1588 over PW Encapsulation">
<t>Another method of transporting 1588 over MPLS networks is by
encapsulating PTP PDUs in Ethernet and then transporting them over
Ethernet PW (PTP PW) as defined in <xref target="RFC4448" />, which in
turn is transported over PTP LSPs. Alternatively PTP PDUs MAY be
encapsulated in UDP/IP/Ethernet and then transported over Ethernet
PW.</t>
<t>Both Raw and Tagged modes for Ethernet PW are permitted. The 1588
over PW format is shown in Figure 2.</t>
<figure>
<artwork><![CDATA[
+----------------+
|PTP Tunnel Label|
+----------------+
| PW Label |
+----------------+
| Control Word |
+----------------+
| Ethernet |
| Header |
+----------------+
| VLANs |
| (optional) |
+----------------+
| IPV4/V6 |
| (optional) |
+----------------+
| UDP |
| (optional) |
+----------------+
| PTP PDU |
+----------------+
Figure 2 - 1588 over PW Encapsulation
]]></artwork>
</figure>
<t>The Control Word (CW) as specified in <xref target="RFC4448" />
SHOULD be used to ensure a more robust detection of PTP messages
inside the MPLS packet. If CW is used, the use of Sequence number is
optional.</t>
<t>The use of VLAN and UDP/IP are optional. Note that 1 or 2 VLANs MAY
exist in the PW payload.</t>
<t>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
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
PHP. In such cases, the PW label SHOULD be chosen from the PTP Label
range.</t>
<t>In order to ensure congruency between the two directions of PTP
message flow, ECMP should not be used for the PTP LSPs. Therefore, no
Entropy label <xref target="I-D.ietf-pwe3-fat-pw" /> is necessary and
it SHOULD NOT be present in the stack.</t>
<t>The Ethernet encapsulation of PTP MUST follow Annex F of <xref
target="IEEE" /> and the UDP/IP encapsulation of PTP MUST follow Annex
D and E of <xref target="IEEE" />.</t>
<t>For 1588 over MPLS encapsulations that are PW based, there are some
cases in which the PTP LSP label may not be present:</t>
<t>
<list style="symbols">
<t>When PHP is applied to the PTP LSP, and the packet is received
without PTP LSP label at PW termination point .</t>
<t>When the PW is established between two routers directly
connected to each other and no PTP LSP is needed.</t>
</list>
</t>
<t>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
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
distribution protocol to indicate that a PW label is a PTP PW
labels.</t>
</section>
</section>
<section anchor="MessageTransport" title="1588 Message Transport">
<t>1588 protocol comprises of the following message types:</t>
<t>
<list style="symbols">
<t>Announce</t>
<t>SYNC</t>
<t>FOLLOW UP</t>
<t>DELAY_REQ (Delay Request)</t>
<t>DELAY_RESP (Delay Response)</t>
<t>PDELAY_REQ (Peer Delay Request)</t>
<t>PDELAY_RESP (Peer Delay Response)</t>
<t>PDELAY_RESP_FOLLOW_UP (Peer Delay Response Follow up)</t>
<t>Management</t>
<t>Signaling</t>
</list>
</t>
<t>A subset of PTP message types that require timestamp processing are
called Event messages:</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 MAY be transported over single hop PTP 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.</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 don't 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 1588 Slaves,
usually as a general practice, Redundant Masters are tracked by each
Slave. It is the responsibility of the network operator to ensure that
physically disjoint PTP tunnels that don't share any link are used
between the redundant Masters and a Slave.</t>
<t>When redundant Masters are tracked by a Slave, any prolonged PTP LSP
or PTP PW outage will trigger the Slave Clock to switch to the Redundant
Master Clock. However LSP/PW protection such as Linear Protection
Switching (1:1,1+1), Ring protection switching or MPLS Fast Reroute
(FRR) SHOULD still be used to provide resiliency to individual network
segment failures..</t>
<t>Note that any protection or reroute mechanism that adds additional
label to the label stack, such as Facility Backup Fast Reroute, MUST
ensure that the pushed label is a PTP Label to ensure recognition of the
MPLS frame as containing PTP messages as it transits the backup
path..</t>
</section>
<section anchor="ECMP" title="ECMP">
<t>To ensure the optimal operation of 1588 Slave clocks and avoid errors
introduced by forward and reverse path delay asymmetry, the physical
path for PTP messages from Master Clock to Slave Clock and vice versa
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.</t>
<t>To ensure the forward and reverse paths are the same PTP LSPs and PWs
MUST NOT be subject to ECMP.</t>
</section>
<section anchor="OAM" title="OAM, Control and Management">
<t>In order to manage PTP LSPs and PTP PWs, they MAY carry OAM, Control
and Management messages. These control and management messages can be
differentiated from PTP messages via already defined IETF methods.</t>
<t>In particular 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 are easily identified by the UDP Destination Port number or by
GAL/ACH respectively.</t>
<t>Also BFD, LSP-Ping and other Management messages MAY run over PTP PW
via one of the defined VCCVs (Type 1, 2 or 3) <xref target="RFC5085" />.
In this case G-ACH, Router Alert Label (RAL), or PW label (TTL=1) 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 PTP-aware, then it
is important to reduce the impact of the non-PTP-aware LSR/LERs on the
timing recovery in the slave clock. The PTP messages are time critical
and must be treated with the highest priority. Therefore 1588 over MPLS
messages must be treated with the highest priority in 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.</t>
<t>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.</t>
</section>
<section anchor="FCS" title="FCS Recalculation">
<t>Ethernet FCS of the outer encapsulation MUST be recalculated at every
LSR that performs the Transparent Clock processing and FCS retention for
the payload Ethernet described in <xref target="RFC4720" /> MUST NOT be
used.</t>
</section>
<section anchor="UDP" title="UDP Checksum Correction">
<t>For UDP/IP encapsulation mode of 1588 over MPLS, the UDP checksum is
optional when used for IPv4 encapsulation and mandatory in case of IPv6.
When IPv4/v6 UDP checksum is used each 1588-aware LSR must either
incrementally update the UDP checksum after the CF update or should
verify the UDP checksum on reception from upstream and recalculate the
checksum completely on transmission after CF update to downstream
node.</t>
</section>
<section anchor="Routing" title="Routing extensions for 1588aware LSRs">
<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 1588-aware. This
capability MUST then be taken into account during path computation to
prefer or even require links that advertise themselves 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.</t>
<t>For this purpose, the following sections specify extensions to OSPF
and IS-IS in order to advertise 1588 aware capabilities of a link.</t>
<section anchor="OSPFCapability"
title="1588aware Link Capability for OSPF">
<t>OSPF uses the Link TLV (Type 2) that is itself carried within
either the Traffic Engineering LSA specified in <xref
target="RFC3630" /> or the OSPFv3 Intra-Area-TE LSA (function code 10)
defined in <xref target="RFC5329" /> to advertise the TE related
information for the locally attached router links. For an LSA Type 10,
one LSA can contain one Link TLV information for a single link. This
extension defines a new 1588-aware capability sub-TLV that can be
carried as part of the Link TLV.</t>
<t>The 1588-aware capability sub-TLV is OPTIONAL and MUST NOT appear
more than once within the Link TLV. If a second instance of the
1588-aware capability sub-TLV is present, the receiving system MUST
only process the first instance of the sub-TLV. It is defined as
follows:</t>
<figure>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+
Figure 3: 1588-aware Capability TLV
]]></artwork>
</figure>
<t>Where:</t>
<t>Type, 16 bits: 1588-aware Capability TLV where the value is TBD</t>
<t>Length, 16 bits: Gives the length of the flags field in octets, and
is currently set to 1</t>
<t>Flags, 8 bits: The bits are defined least-significant-bit (LSB)
first, so bit 7 is the least significant bit of the flags octet.</t>
<figure>
<artwork><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |C|
+-+-+-+-+-+-+-+-+
Figure 4: Flags Format
]]></artwork>
</figure>
<t>Correction (C) field Update field, 1 bit: Setting the C bit to 1
indicates that the link is capable of recognizing the PTP event
packets and can compensate for residence time by updating the PTP
packet Correction Field. When this is set to 0, it means that this
link cannot perform the residence time correction but is capable of
performing MPLS frame forwarding of the frames with PTP labels using a
method that support the end to end delivery of accurate timing. The
exact method is not defined herein.</t>
<t>Reserved, 7 bits: Reserved for future use. The reserved bits must
be ignored by the receiver.</t>
<t>The 1588-aware Capability sub-TLV is applicable to both OSPFv2 and
OSPFv3.</t>
</section>
<section anchor="ISIS" title="1588aware Link Capability for IS-IS">
<t>The IS-IS Traffic Engineering <xref target="RFC3784" /> defines the
intra-area traffic engineering enhancements and uses the Extended IS
Reachability TLV (Type 22) <xref target="RFC5305" /> to carry the per
link TE-related information. This extension defines a new 1588-aware
capability sub-TLV that can be carried as part of the Extended IS
Reachability TLV.</t>
<t>The 1588-aware capability sub-TLV is OPTIONAL and MUST NOT appear
more than once within the Extended IS Reachability TLV or the
Multi-Topology (MT) Intermediate Systems TLV (type 222) specified in
<xref target="RFC5120" />. If a second instance of the 1588-aware
capability sub-TLV is present, the receiving system MUST only process
the first instance of the sub-TLV.</t>
<t>The format of the IS-IS 1588-aware sub-TLV is identical to the TLV
format used by the Traffic Engineering Extensions to IS-IS <xref
target="RFC3784" />. That is, the TLV is comprised of 1 octet for the
type, 1 octet specifying the TLV length, and a value field. The Length
field defines the length of the value portion in octets.</t>
<figure>
<artwork><![CDATA[
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: 1588-aware Capability sub-TLV
]]></artwork>
</figure>
<t>Where:</t>
<t>Type, 8 bits: 1588-aware Capability sub-TLV where the value is
TBD</t>
<t>Length, 8 bits: Gives the length of the flags field in octets, and
is currently set to 1</t>
<t>Flags, 8 bits: The bits are defined least-significant-bit (LSB)
first, so bit 7 is the least significant bit of the flags octet.</t>
<figure>
<artwork><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |C|
+-+-+-+-+-+-+-+-+
Figure 6: Flags Format
]]></artwork>
</figure>
<t>Correction (C) field Update field, 1 bit: Setting the C bit to 1
indicates that the link is capable of recognizing the PTP event
packets and can compensate for residence time by updating the PTP
packet Correction Field. When this is set to 0, it means that this
link cannot perform the residence time correction but is capable of
performing MPLS frame forwarding of the frames with PTP labels using a
method that support the end to end delivery of accurate timing. The
exact method is not defined herein.</t>
<t>Reserved, 7 bits: Reserved for future use. The reserved bits must
be ignored by the receiver.</t>
</section>
</section>
<section anchor="RSVP" title="RSVP-TE Extensions for support of 1588">
<t>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 the
start of the PTP message header MAY also be signaled. Implementations
can trivially locate the correctionField (CF) location given this
information. The OFFSET points to the start of the PTP header as a node
may want to check the PTP messageType before it touches the
correctionField (CF). The OFFSET is counted from TBD</t>
<t>The LSRs that receive and process the RSVP-TE/GMPLS messages MAY use
the OFFSET to locate the start of the PTP message header.</t>
<t>Note that the new object/TLV Must be ignored by LSRs that are not
compliant to this specification.</t>
<t>The new RSVP 1588_PTP_LSP object should be included in signaling PTP
LSPs and is defined as follows:</t>
<figure>
<artwork><![CDATA[
0 1 2 3
+-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+
| Offset to locate the start of the PTP message header |
+-------------+-------------+-------------+-------------+
Figure 7: RSVP 1588_PTP_LSP object
]]></artwork>
</figure>
<t>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
messages</t>
</section>
<section title="Behavior of LER/LSR">
<section title="Behavior of 1588-aware LER">
<t>A 1588-aware LER advertises it's 1588-awareness via the OSPF
procedure explained in earlier section of this specification. The
1588-aware LER then signals PTP LSPs by including the 1588_PTP_LSP
object in the RSVP-TE signaling.</t>
<t>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
over MPLS message is received from an MPLS interface, the processing
is similar to 1588-aware LSR processing.</t>
</section>
<section title="Behavior of 1588-aware LSR">
<t>1588-aware LSRs are LSRs that understand the 1588_PTP_LSP RSVP
object and can perform 1588 processing (e.g. Transparent Clock
processing).</t>
<t>A 1588-aware LSR advertises it's 1588-awareness via the OSPF
procedure explained in earlier section of this specification.</t>
<t>When a 1588-aware LSR distributes a label for PTP LSP, it maintains
this information. When the 1588-aware LSR receives an MPLS packet, it
performs a label lookup and if the label lookup indicates it is a PTP
label then further parsing must be done to positively identify that
the payload is 1588 and not OAM, BFD or control and management. Ruling
out non-1588 messages can easily be done when parsing indicates the
presence of GAL, ACH or VCCV (Type 1, 2, 3) or when the UDP port
number does not match one of the 1588 UDP port numbers.</t>
<t>After a 1588 message is positively identified in a PTP LSP, the PTP
message type indicates whether any timestamp processing is required.
After 1588 processing the packet is forwarded as a normal MPLS packet
to downstream node.</t>
</section>
<section title="Behavior of non-1588-aware LSR">
<t>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
synchronization by 1588 Slave Clocks. However, this specification does
not mandate that all LSRs in path of a PTP LSP be 1588-aware.</t>
<t>Non-1588-aware LSRs are LSRs that either don't have the capability
to process 1588 packets (e.g. perform Transparent Clock processing) or
don't understand the 1588_PTP_LSP RSVP object.</t>
<t>Non-1588-aware LSRs ignore the RSVP 1588_PTP_LSP object and just
switch the MPLS packets carrying 1588 messages as data packets and
don't perform any timestamp related processing. However as explained
in QoS section the 1588 over MPLS packets MUST be still be treated
with the highest priority.</t>
</section>
</section>
<section title="Other considerations">
<t>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 (applicable
only to UDP/IP encapsulation) or the label below the Explicit Null label
is a PTP label.</t>
<t>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
encapsulation) or the label below the PHP 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 [IEEE]. The PTP
security extension and protocol provides group source authentication,
message integrity, and replay attack protection for PTP messages.</t>
</section>
<section anchor="Ack" title="Acknowledgements">
<t>The authors would like to thank Luca Martini, Ron Cohen, Yaakov
Stein, Tal Mizrahi and other members of the TICTOC WG for reviewing and
providing feedback on this draft.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<section anchor="OSPF-IANA" title="IANA Considerations for OSPF">
<t>IANA has defined a sub-registry for the sub-TLVs carried in an OSPF
TE Link TLV (type 2). IANA is requested to assign a new sub-TLV
codepoint for the 1588aware capability sub-TLV carried within the
Router Link TLV.</t>
<figure>
<artwork><![CDATA[
Value Sub-TLV References
----- ---------------------- ----------
TBD 1588aware node sub-TLV (this document)
]]></artwork>
</figure>
</section>
<section anchor="ISIS-IANA" title="IANA Considerations for IS-IS">
<t>IANA has defined a sub-registry for the sub-TLVs carried in the
IS-IS Extended IS Reacability TLV. IANA is requested to assign a new
sub-TLV code-point for the 1588aware capability sub-TLV carried within
the Extended IS Reacability TLV.</t>
<figure>
<artwork><![CDATA[
Value Sub-TLV References
----- ---------------------- ----------
TBD 1588aware node sub-TLV (this document)
]]></artwork>
</figure>
</section>
<section anchor="RSVp-IANA" title="IANA Considerations for RSVP">
<t>IANA is requested to assign a new Class Number for 1588 PTP LSP
object that is used to signal PTP LSPs.</t>
<t>1588 PTP LSP Object</t>
<t>Class-Num of type 11bbbbbb</t>
<t>Suggested value TBD</t>
<t>Defined CType: 1 (1588 PTP LSP)</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="IEEE">
<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.4389'?>
<?rfc include='reference.RFC.5085'?>
<?rfc include='reference.RFC.5880'?>
<?rfc include='reference.RFC.3985'?>
<?rfc include='reference.RFC.4447'?>
</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'?>
<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>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 00:42:31 |