| TICTOC Working Group | S. Davari |
| Internet-Draft | A. Oren |
| Intended status: Standards Track | Broadcom Corp. |
| Expires: August 27, 2013 | M.B. Bhatia |
| P. Roberts | |
| Alcatel-Lucent | |
| L. Montini | |
| Cisco Systems | |
| February 23, 2013 |
Transporting Timing messages over MPLS Networks
draft-ietf-tictoc-1588overmpls-04
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.
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.
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, which is suitable for both MPLS and MPLS-TP networks.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 27, 2013.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 [RFC2119].
When used in lower case, these words convey their typical use in common language, and are not to be interpreted as described in RFC2119 [RFC2119].
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.
[IEEE] defines PTP messages for frequency, phase and time synchronization. The PTP messages include PTP PDUs over UDP/IP (Annex D and E of [IEEE]) and PTP PDUs over Ethernet (Annex F of [IEEE- 1588]). This document defines mapping and transport of the PTP messages defined in [IEEE] over MPLS/MPLS-TP networks. PTP defines several clock types: ordinary clocks, boundary clocks, end-to-end transparent clocks, and peer-to-peer transparent clocks. Transparent clocks require intermediate nodes to update correction field inside PTP message that reflects the transit time in the node.
[RFC5905] defines NTP messages for clock and time synchronization. The PTP messages (PDUs) are transported over UDP/IP. This document defines mapping and transport of the NTP messages defined in [RFC5905] over MPLS networks.
One key attribute of all of these Timing messages is that the 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.
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.
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.
This document provides two methods for transporting Timing messages over MPLS. One is applicable to MPLS environment and the other one is applicable to both MPLS and MPLS-TP environment.
The solution involves transporting Timing messages over dedicated LSPs called Timing LSPs. These LSPs carry Timing messages and MAY carry Management and control messages, but not data plane client traffic. Timing LSPs can be established statically or via signaling. Extensions to control plane (OSPF, ISIS, etc.) is required to enable routers to distribute their Timing processing capabilities over MPLS to other routers. However such extensions are outside the scope of this document.
Extensions to signaling protocols (e.g., RSVP-TE) are required for establishing PTP LSPs. However such extensions are outside the scope of this document.
While the techniques included herein allow for the establishment of paths optimized to include Time-stamping capable links, the performance of the Slave clocks is outside the scope of this document.
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.
1588: The timing and synchronization as defined by IEEE 1588.
NTP: The timing and synchronization protocol defined by IETF RFC-1305 and RFC-5905.
PTP: The timing and synchronization protocol used by 1588.
Master Clock: The source of 1588 timing to a set of slave clocks.
Master Port: A port on a ordinary or boundary clock that is in Master state. This is the source of timing toward slave ports.
Slave Clock: A receiver of 1588 timing from a master clock.
Slave Port: A port on a boundary clock or ordinary clock that is receiving timing from a master clock.
Ordinary Clock: A device with a single PTP port.
Transparent Clock. A device that measures the time taken for a PTP event message to transit the device and then updates the correctionField of the message with this transit time.
Boundary Clock: A device with more than one PTP port. Generally boundary clocks will have one port in slave state to receive timing and then other ports in master state to re-distribute the timing.
PTP LSP: An LSP dedicated to carry PTP messages
PTP PW: A PW within a PTP LSP that is dedicated to carry PTP messages.
CW: Pseudowire Control Word
LAG: Link Aggregation
ECMP: Equal Cost Multipath
CF: Correction Field, a field inside certain PTP messages (message type 0-3)that holds the accumulative transit time inside intermediate switches
Timing messages: Timing Protocol messages that are exchanged between routers in order to establish a synchronized clock.
[IEEE] has defined methods for transporting PTP messages over Ethernet and IP networks. [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.
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.
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 cant 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.
A generic method is defined in this document that does not require deep packet inspection at line rate, and can deterministically identify Timing messages. The generic method is applicable to MPLS and MPLS-TP networks.
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.
Master/Slave clock could be integrated in the LERs. 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.
+--------+ +-------+ +-------+ +-------+ +--------+
|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/MPLS-TP network
LERs could also act as Boundary Clock (BC). This is shown in Figure 2, 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.
+--------+ +-------+ +-------+ +-------+ +--------+
|Switch, | | | | | | | |Switch, |
| Router |-----| LER |-----| LSR |-----| LER |-----| Router |
| OC/BC | | BC | | TC | | BC | | OC/BC |
+--------+ +-------+ +-------+ +-------+ +--------+
Figure (2) - Deployment example 2 of timing over MPLS/MPLS-TP network
LERs could also act as Transparent Clock (TC). This is shown in Figure 3, where LERs do not terminate the Timing messages received from switch/routers that are outside of the MPLS network acting as OC, TC or BC. The LERs act as TC and update the Timing field in the Timing messages as they transit the LER, while encapsulating them in timing LSP. The LSRs also act as Transparent Clock (TC) and just update the Timing field in the Timing messages which are already encapsulated in Timing LSPs.
+--------+ +-------+ +-------+ +-------+ +--------+
|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/MPLS-TP network
An MPLS domain can serve multiple customers. This means that the MPLS domain (maintained by a service provider) may provide timing services to multiple customers, each having their own Timing domain. Therefore LER BCs need to interact with multiple grandmasters, and consequently multiple time references. Also, LER/LSR TCs MUST be synchronized to the same master clock (which is the service provider Master clock), which implies that they need to choose one master to synchronize to.
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.
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.
Timing messages, that do not require Time stamping or Correction Field update MAY be transported over Timing LSPs to simplify hardware and software.
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.
Many methods have been considered for identifying the Timing messages when they are encapsulated in MPLS such as using GAL/ACH or a new reserved label. These methods were not attractive since they either required deep packet inspection at line rate in the intermediate LSRs or they required use of a scarce new reserved label. Also one of the goals was to reuse existing OAM mechanisms.
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.
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.
Co-routing of the two directions is required to limit the difference in the delays in the Master clock to Slave clock direction compared to the Slave clock to Master clock direction. The Timing LSP MAY be MPLS LSP or MPLS-TP LSP.
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.
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.
This document defines two methods for carrying Timing messages over MPLS. The first method is carrying UDP/IP encapsulated Timing messages over Timing LSPs, which is suitable for MPLS networks and the second method, is carrying Ethernet encapsulated Timing messages over Ethernet PWs inside Timing LSPs, which is suitable for MPLS and MPLS-TP networks.
The 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.
+----------------------+
| Timing LSP Label |
+----------------------+
| IPv4/6 |
+----------------------+
| UDP |
+----------------------+
| Timing PDU |
+----------------------+
Figure (4) - Timing over UDP/IP over MPLS Encapsulation
This encapsulation is very simple and is useful when the network between Timing Master Clock and Slave Clock is MPLS network.
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.
The UDP/IP encapsulation of PTP MUST follow Annex D and E of [IEEE]. While the UDP/IP encapsulation of NTP MUST follow [RFC5905].
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 [RFC4448], shown in Fig 5(A) MUST be used and the Ethernet encapsulation of PTP MUST follow Annex F of [IEEE].
The Tagged mode defined in [RFC-4448] MUST be used and the Payload MUST have 2 VLAN tags (S-VLAN and C-VLAN). The Timing over PW encapsulation MUST use the Control Word (CW) as specified in [RFC4448] to ensure proper detection of PTP messages inside the MPLS packets for Timing over LSP and Timing over PW encapsulation. The use of Sequence Number in the CW is optional.
Timing over PW encapsulation for NTP MUST use NTP over UDP/IP over PW (the IP PW discussed in [RFC4447]) shown in Fig 5(B).
+----------------+ +----------------+
|Timing LSP Label| |Timing LSP Label|
+----------------+ +----------------+
| PW Label | | PW Label |
+----------------+ +----------------+
| Control Word | | IP |
+----------------+ +----------------+
| Ethernet | | UDP |
| Header | +----------------+
+----------------+ | Timing PDU |
| S-VLAN | | |
+----------------+ +----------------+
| C-VLAN | (B)
+----------------+
| Timing PDU |
| |
+----------------+
(A)
Figure (5) - Timing over PW Encapsulations
In order for an LSR to process PTP messages, the top label of the label stack (the Tunnel Label) MUST be a Timing label.
The PW method of transporting Timing over MPLS is applicable to both MPLS and MPLS-TP networks.
In future other timing encapsulation methods may be introduced, such as a new shim header after the Bottom of Stack to carry the Timing information. Such new encapsulations are outside the scope of this document. The control and signaling requirements in this document are defined generically enough to accommodate any such new encapsulations.
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.
Some of the Timing messages require time stamping at port level and some dont. It is the job of the LER/LSR to parse the timing message and find out the type of the Timing message and decide whether and how to Time- stamp it (e.g., BC) or modify existing time-stamp in it (e.g., TC).
For example the following PTP messages (called Event messages) require time-stamping, while other Non-Event PTP messages do not need time-stamping.
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, DELAY_RESP, and PDELAY_RESP_FOLLOW_UP messages MUST also be transported over the PTP LSPs.
For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be 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.
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.
In order to ensure continuous uninterrupted operation of slave clocks, usually as a general practice, slave clocks (or ports) track redundant master clocks.
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).
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.
LSP/PW protection such as Linear protection Switching (1:1, 1+1), Ring protection switching or MPLS Fast Reroute (FRR) generally switch alternative path that usually cause a change in delay, which if undetected by slave clock can reduce accuracy of the slave clock. However it is expected that most Slave clocks could detect the change in delay. Therefore this specification recommends that protection switching SHOULD be used, unless the operator knows that the protection switching may have adverse effect on the slave clock.
Note that any protection or reroute mechanism that adds additional 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.
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.
Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost Multipath).
To ensure that the label on the top of the label stack is the Timing LSP Label, PHP MUST not be used.
To ensure all Timing messages in a Timing LSP take the same path, Entropy MUST NOT be used for the Timing LSP [mpls-entropy] and Entropy MSUT NOT be used for the PWs that are carried inside Timing LSP [RFC6391].
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.
For example BFD [RFC5880], [RFC5884] and LSP-Ping [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/ACH respectively.
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) [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.
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.
It is recommended that the Timing LSPs are setup or configured properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC2697] for drop eligibility.
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 [RFC4720] MUST NOT be used.
For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum may be required as per UDP transport standards.
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.
MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE) link information used for constraint-based routing.
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.
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:
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:
The following information MAY also be included in the new Extensions to RSVP-TE:
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.
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.
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.
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.
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.
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.
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.
Non-Timing-capable/aware LSRs just switch the packets encapsulated in Timing LSPs and dont perform any Timing operation (TC). However as explained in QoS section the Timing8 over MPLS packets MUST be still be treated with the highest priority based on their Traffic Class (TC) marking.
[IEEE] 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.
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.
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.
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.
MPLS PW security considerations in general are discussed in [RFC3985] and [RFC4447],and those considerations also apply to this document.
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.
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.
Timing messages (as opposed to regular customer data) SHOULD not be encrypted or authenticated on an end-to-end basis. Alternatively, authentication/integrity verification mechanism can be used by a shared secret between the customer and provider nodes.
The Timing over MPLS transport methods described in this document apply to the following network Elements:
This document also supports the case where not all LSRs are Timing- capable/aware. It also supports the case where not all LER/LSR interfaces are Timing-capable/aware.
The authors would like to thank Luca Martini, Ron Cohen, Yaakov Stein, Tal Mizrahi, Stefano Ruffini, Luca Moniti and other members of IETF for reviewing and providing feedback on this draft.
There are no IANA requirements in this specification.