TICTOC Working Group S. Davari
Internet-Draft A. Oren
Intended status: Experimental Broadcom Corp.
Expires: April 18, 2016 M. Bhatia
P. Roberts
Alcatel-Lucent
L. Montini
Cisco Systems
October 16, 2015
Transporting Timing messages over MPLS Networks
draft-ietf-tictoc-1588overmpls-07
Abstract
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).
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.
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.
Status of This Memo
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."
Davari, et al. Expires April 18, 2016 [Page 1]
Internet-Draft Transporting Timing over MPLS October 2015
This Internet-Draft will expire on April 18, 2016.
Copyright Notice
Copyright (c) 2015 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
4. Timing over MPLS Architecture . . . . . . . . . . . . . . . . 5
5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . 7
6. Timing over LSP Encapsulation . . . . . . . . . . . . . . . . 8
6.1. Timing over UDP/IP over MPLS Encapsulation . . . . . . . 8
6.2. Timing over PW Encapsulation . . . . . . . . . . . . . . 8
7. Timing message Processing . . . . . . . . . . . . . . . . . . 9
8. Protection and Redundancy . . . . . . . . . . . . . . . . . . 10
9. ECMP and Entropy . . . . . . . . . . . . . . . . . . . . . . 10
10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11. OAM, Control and Management . . . . . . . . . . . . . . . . . 11
12. QoS Considerations . . . . . . . . . . . . . . . . . . . . . 11
13. FCS and Checksum Recalculation . . . . . . . . . . . . . . . 11
14. Behavior of LER/LSRs . . . . . . . . . . . . . . . . . . . . 12
14.1. Behavior of Timing-capable/aware LERs/LSRs . . . . . . . 12
14.2. Behavior of non-Timing-capable/aware LSR . . . . . . . . 12
15. Other considerations . . . . . . . . . . . . . . . . . . . . 13
16. Security Considerations . . . . . . . . . . . . . . . . . . . 13
17. Applicability Statement . . . . . . . . . . . . . . . . . . . 14
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
20.1. Normative References . . . . . . . . . . . . . . . . . . 15
20.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 17
A.1. Routing extensions for Timing-aware Routers . . . . . . . 17
A.2. Signaling Extensions for Creating Timing LSPs . . . . . . 17
Davari, et al. Expires April 18, 2016 [Page 2]
Internet-Draft Transporting Timing over MPLS October 2015
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
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 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.
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.
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.
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.
[IEEE-1588] defines PTP messages for frequency, phase and time
synchronization. PTP messages may be transported over UDP/IP (Annex
D and E of [IEEE-1588]) or over Ethernet (Annex F of [IEEE-1588]).
This document defines two methods to transport PTP messages over MPLS
networks.
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
Davari, et al. Expires April 18, 2016 [Page 3]
Internet-Draft Transporting Timing over MPLS October 2015
update the Correction Field inside PTP messages in order to reflect
the time required to transit the node.
[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.
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.
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.
2. Terminology
1588: The timing distribution protocol defined in IEEE 1588.
Boundary Clock: A device with one timing port to receive timing
messages and at least one port to re-distribute timing messages.
CF: Correction Field, a field inside certain PTP messages that holds
the accumulated transit time.
Master Clock: The source of 1588 timing messages to a set of slave
clocks.
NTP: The timing distribution protocol defined in RFC 5905.
Ordinary Clock: A master or slave clock. Note that ordinary clocks
have only a single PTP port.
PTP: Precision Time Protocol. See 1588.
Slave Clock: A receiver of 1588 timing messages from a master clock.
Timing LSP: An MPLS LSP dedicated to carry timing messages.
Timing messages: Timing distribution protocol messages that are
exchanged between clocks.
Timing port: A port on a (master, slave, transparent, or boundary)
clock.
Davari, et al. Expires April 18, 2016 [Page 4]
Internet-Draft Transporting Timing over MPLS October 2015
Timing PW: A PW within a Timing LSP that is dedicated to carry timing
messages.
Transparent Clock: An intermediate node that forwards timing messages
while updating their CF.
3. Problem Statement
[IEEE-1588] defines methods for transporting PTP messages over
Ethernet and IP networks. [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.
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.
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.
4. Timing over MPLS Architecture
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.
OC, BC and TC functionality may be implemented in either LERs or
LSRs.
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.
Davari, et al. Expires April 18, 2016 [Page 5]
Internet-Draft Transporting Timing over MPLS October 2015
+--------+ +-------+ +-------+ +-------+ +--------+
|Switch, | | | | | | | |Switch, |
| Router |-----| LER |-----| LSR |-----| LER |-----| Router |
| | | OC | | TC | | OC | | |
+--------+ +-------+ +-------+ +-------+ +--------+
/ \
+-------+ / \ +-------+
| LER | / \ | LER |
| Master|---/ \---| Slave |
| Clock | | Clock |
+-------+ +-------+
Figure (1) - Deployment example 1 of timing over MPLS network
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.
+--------+ +-------+ +-------+ +-------+ +--------+
|Switch, | | | | | | | |Switch, |
| Router |-----| LER |-----| LSR |-----| LER |-----| Router |
| OC/BC | | BC | | TC | | BC | | OC/BC |
+--------+ +-------+ +-------+ +-------+ +--------+
Figure (2) - Deployment example 2 of timing over MPLS network
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.
+--------+ +-------+ +-------+ +-------+ +--------+
|Switch, | | | | | | | |Switch, |
| Router |-----| LER |-----| LSR |-----| LER |-----| Router |
|OC/TC/BC| | TC | | TC | | TC | |OC/TC/BC|
+--------+ +-------+ +-------+ +-------+ +--------+
Figure (3) - Deployment example 3 of timing over MPLS network
Davari, et al. Expires April 18, 2016 [Page 6]
Internet-Draft Transporting Timing over MPLS October 2015
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.
+--------+ +-------+ +-------+ +-------+ +--------+
|Switch, | | | | | | | |Switch, |
| Router |-----| LER |-----| LSR |-----| LER |-----| Router |
| OC/BC | | BC | | BC | | BC | | OC/BC |
+--------+ +-------+ +-------+ +-------+ +--------+
Figure (4) - Deployment example 3 of timing over MPLS network
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.
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.
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.
Timing LSPs, as defined by this specification, MAY be used for timing
messages that do not require time-stamping or CF updating.
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.
5. Dedicated LSPs for Timing messages
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".
Davari, et al. Expires April 18, 2016 [Page 7]
Internet-Draft Transporting Timing over MPLS October 2015
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.
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.
6. Timing over LSP Encapsulation
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.
6.1. Timing over UDP/IP over MPLS Encapsulation
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 [IEEE-1588], and the UDP/IP encapsulation of NTP
messages MUST comply to [RFC5905]. This format is shown in Figure 4.
+----------------------+
| Timing LSP Label |
+----------------------+
| IPv4/6 |
+----------------------+
| UDP |
+----------------------+
| timing message |
+----------------------+
Figure (4) - Timing over UDP/IP over MPLS Encapsulation
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.
6.2. Timing over PW Encapsulation
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
Davari, et al. Expires April 18, 2016 [Page 8]
Internet-Draft Transporting Timing over MPLS October 2015
case of PTP, the Ethernet encapsulation MUST comply to Annex F of
[IEEE-1588] and the Ethernet PW encapsulation to [RFC4448], resulting
in the format shown in Figure 5(A).
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
[RFC4448]. The use of Sequence Number in the CW is optional.
NTP MAY be transported using an IP PW (as defined in [RFC4447]) as
shown in Fig 5(B).
+-----------------+ +----------------+
|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
7. Timing message Processing
Each Timing protocol such as PTP and NTP, defines a set of timing
messages. PTP defines SYNC, DELAY_REQ, DELAY_RESP, FOLLOW_UP, etc.
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.
For example, the following PTP messages (event messages) require
time-stamping or CF updating:
o SYNC
Davari, et al. Expires April 18, 2016 [Page 9]
Internet-Draft Transporting Timing over MPLS October 2015
o DELAY_REQ (Delay Request)
o PDELAY_REQ (Peer Delay Request)
o PDELAY_RESP (Peer Delay Response)
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.
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.
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.
8. Protection and Redundancy
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.
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.
9. ECMP and Entropy
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
Davari, et al. Expires April 18, 2016 [Page 10]
Internet-Draft Transporting Timing over MPLS October 2015
messages. In particular, the PTP event messages listed in section 7
MUST be routed in the same way.
Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost
Multipath). Entropy labels MUST NOT be used for the Timing LSP
[RFC6790] and MUST NOT be used for PWs inside the Timing LSP
[RFC6391].
10. PHP
To ensure that the label on the top of the label stack is the Timing
LSP Label, PHP MUST not be employed.
11. OAM, Control and Management
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.
For example BFD [RFC5880], [RFC5884] and LSP-Ping [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.
Also BFD, LSP-Ping and other messages MAY run over Timing PWs via
VCCV [RFC5085]. In this case these messages are recognized according
to the VCCV type.
12. QoS Considerations
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.
It is recommended that Timing LSPs be configured to indicate EF-PHB
[RFC3246] for the CoS and "green" [RFC2697] for drop eligibility.
13. FCS and Checksum Recalculation
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
[RFC4720] MUST NOT be used.
For the UDP/IP encapsulation mode, calculation of the UDP checksum
will generally be required. After updating the CF a Transparent
Davari, et al. Expires April 18, 2016 [Page 11]
Internet-Draft Transporting Timing over MPLS October 2015
Clock MUST either incrementally update the UDP checksum or completely
recalculate the checksum before transmission to downstream node.
14. Behavior of LER/LSRs
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.
14.1. Behavior of Timing-capable/aware LERs/LSRs
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.
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.
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.
14.2. Behavior of non-Timing-capable/aware LSR
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.
Non-timing-capable/aware LSRs just perform label switching on the
packets encapsulated in Timing LSPs and don't perform any timing
Davari, et al. Expires April 18, 2016 [Page 12]
Internet-Draft Transporting Timing over MPLS October 2015
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.
15. Other considerations
[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.
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.
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.
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).
16. Security Considerations
Security considerations for MPLS and pseudowires are discussed in
[RFC3985] and [RFC4447]. Security considerations for timing are
discussed in [RFC7384]. Everything discussed in those documents
applies to the Timing LSP of this document.
An experimental security protocol is defined in [IEEE-1588]. 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 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.
Davari, et al. Expires April 18, 2016 [Page 13]
Internet-Draft Transporting Timing over MPLS October 2015
Timing messages MAY be encrypted or authenticated, provided that the
timing-capable LERs/LSRs can authenticate/ decrypt the timing
messages.
17. Applicability Statement
The Timing over MPLS transport methods described in this document
apply to the following network Elements:
o 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.
o 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.
o 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.
o 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.
o 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.
This document also supports the case where not all LSRs are timing-
capable/aware, or not all LER/LSR interfaces are timing-capable/
aware.
18. Acknowledgements
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.
19. IANA Considerations
There are no IANA requirements in this specification.
Davari, et al. Expires April 18, 2016 [Page 14]
Internet-Draft Transporting Timing over MPLS October 2015
20. References
20.1. Normative References
[IEEE-1588]
IEEE 1588-2008, "IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and
Control Systems", July 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005,
<http://www.rfc-editor.org/info/rfc3985>.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April
2006, <http://www.rfc-editor.org/info/rfc4389>.
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC 4447,
DOI 10.17487/RFC4447, April 2006,
<http://www.rfc-editor.org/info/rfc4447>.
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,
<http://www.rfc-editor.org/info/rfc4448>.
[RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire
Emulation Edge-to-Edge (PWE3) Frame Check Sequence
Retention", RFC 4720, DOI 10.17487/RFC4720, November 2006,
<http://www.rfc-editor.org/info/rfc4720>.
[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual
Circuit Connectivity Verification (VCCV): A Control
Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085,
December 2007, <http://www.rfc-editor.org/info/rfc5085>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<http://www.rfc-editor.org/info/rfc5880>.
Davari, et al. Expires April 18, 2016 [Page 15]
Internet-Draft Transporting Timing over MPLS October 2015
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
June 2010, <http://www.rfc-editor.org/info/rfc5884>.
20.2. Informative References
[ISO] ISO/IEC 10589:1992, "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)", April
1992.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <http://www.rfc-editor.org/info/rfc1195>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>.
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color
Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999,
<http://www.rfc-editor.org/info/rfc2697>.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
<http://www.rfc-editor.org/info/rfc3246>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<http://www.rfc-editor.org/info/rfc5340>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>.
[RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V.,
Regan, J., and S. Amante, "Flow-Aware Transport of
Pseudowires over an MPLS Packet Switched Network",
RFC 6391, DOI 10.17487/RFC6391, November 2011,
<http://www.rfc-editor.org/info/rfc6391>.
Davari, et al. Expires April 18, 2016 [Page 16]
Internet-Draft Transporting Timing over MPLS October 2015
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<http://www.rfc-editor.org/info/rfc6790>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <http://www.rfc-editor.org/info/rfc7384>.
Appendix A. Appendix
A.1. Routing extensions for Timing-aware Routers
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.
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.
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:
o Capable of processing PTP, NTP or other timing flows
o Capable of performing TC operation
o Capable of performing BC operation
A.2. Signaling Extensions for Creating Timing LSPs
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:
o Offset from Bottom of Stack (BoS) to the start of the Time-stamp
field
o Number of VLANs in case of PW encapsulation
Davari, et al. Expires April 18, 2016 [Page 17]
Internet-Draft Transporting Timing over MPLS October 2015
o Time-stamp field Type
* Correction Field, time-stamp
o Time-stamp Field format
* 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit
NTP, etc.
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.
Authors' Addresses
Shahram Davari
Broadcom Corp.
San Jose, CA 95134
USA
Email: davari@broadcom.com
Amit Oren
Broadcom Corp.
San Jose, CA 95134
USA
Email: amito@broadcom.com
Manav Bhatia
Alcatel-Lucent
Bangalore
India
Email: manav.bhatia@alcatel-lucent.com
Peter Roberts
Alcatel-Lucent
Kanata
Canada
Email: peter.roberts@alcatel-lucent.com
Davari, et al. Expires April 18, 2016 [Page 18]
Internet-Draft Transporting Timing over MPLS October 2015
Laurent Montini
Cisco Systems
San Jose CA
USA
Email: lmontini@cisco.com
Davari, et al. Expires April 18, 2016 [Page 19]
