Internet DRAFT - draft-jobert-tictoc-ptp-link-local
draft-jobert-tictoc-ptp-link-local
TICTOC Working Group S. Jobert
Internet Draft France Telecom Orange
Intended status: Informational March 5, 2012
Expires: September 2012
Transporting PTP messages over MPLS networks
using a link local addressing
draft-jobert-tictoc-ptp-link-local-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 5, 2012.
Jobert Expires September 5, 2012 [Page 1]
Internet-Draft Transporting PTP messages over March 2012
MPLS networks using a link local addressing
Copyright Notice
Copyright (c) 2012 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.
Abstract
This document introduces a method for transporting PTP messages over
an MPLS network supported by an Ethernet physical layer. The MPLS
layer itself is not used to carry the PTP messages with this method;
instead, a link local Ethernet channel is used. Several advantages
related to this method are highlighted in this document. The method
targets in particular telecom applications requiring accurate
phase/time synchronization, with "link-by-link" PTP architectures,
where all the network nodes support a PTP function, such as Boundary
Clock or Transparent Clock.
Table of Contents
1. Introduction ................................................ 3
2. Conventions used in this document............................ 4
3. Analysis of the PTP frequency telecom profile with MPLS networks
............................................................... 4
4. Transporting PTP messages over MPLS networks with a "link-by-
link" PTP architecture ......................................... 5
4.1. Need for identifying the PTP messages in MPLS networks... 6
4.2. Use of a link local addressing over MPLS networks supported
by an Ethernet physical layer................................ 7
4.3. Use of link local addressing with Transparent Clocks..... 8
5. Security Considerations..................................... 12
6. IANA Considerations ........................................ 12
7. References ................................................. 13
7.1. Normative References................................... 13
7.2. Informative References................................. 13
8. Acknowledgments ............................................ 13
Jobert Expires September 5, 2012 [Page 2]
Internet-Draft Transporting PTP messages over March 2012
MPLS networks using a link local addressing
1. Introduction
The Precision Time Protocol version 2 (PTPv2), defined by the
[IEEE1588-2008] standard, is used to support telecom applications
that may include MPLS networks. Telecoms applications may require
frequency synchronization only or accurate phase/time
synchronization.
This has led to the definition of two PTP telecom profiles at the
ITU-T: the Recommendation [G.8265.1] (finalized) defines a PTP
telecom profile for frequency synchronization in an "end-to-end"
mode (the intermediate network nodes do not support PTP functions)
and the future Recommendation G.8275.1 (under development) will
define a PTP telecom profile for phase/time synchronization in a
"link-by-link" mode (all the intermediate network nodes support PTP
functions).
For frequency applications using the ITU-T frequency profile, there
is no particular need to identify the PTP messages in case they are
carried in an MPLS layer. The use of a high priority class of
service is in general sufficient to minimize the Packet Delay
Variation (PDV) introduced by the network nodes. The identification
of the PTP messages in a network node which does not support PTP
functions is not expected in general to provide a better performance
than the positioning of the PTP messages in a dedicated high
priority queue.
For phase/time applications with stringent requirements (e.g. sub-
micro-second accuracy), it is in general recognized that PTP support
from the network nodes is required to avoid the generation of Packet
Delay Variation. Therefore, being able to identify the PTP messages
is considered important. This is the one of the objectives of the
definition of a PTP mapping. Some mappings are already defined in
the [IEEE1588-2008] standard, and may be applicable to an MPLS
network.
This document introduces a method for transporting PTP messages over
an MPLS network supported by an Ethernet physical layer. The MPLS
layer itself is not used to carry the PTP messages with this method;
instead, a link local Ethernet channel is used.
Several advantages related to this method are highlighted in this
document. The method targets in particular telecom applications
requiring accurate phase/time synchronization, with "link-by-link"
PTP architectures, where all the network nodes support a PTP
function, such as Boundary Clock (BC) or Transparent Clock (TC).
Jobert Expires September 5, 2012 [Page 3]
Internet-Draft Transporting PTP messages over March 2012
MPLS networks using a link local addressing
2. Conventions used in this document
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 RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
PTP: Precision Time Protocol
PDV: Packet Delay Variation
BC: Boundary Clock
TC: Transparent Clock
3. Analysis of the PTP frequency telecom profile with MPLS networks
For applications requiring frequency synchronization only, when the
use of physical layer synchronization methods such as Synchronous
Ethernet is not possible, the ITU-T PTP frequency telecom profile
defined in the Recommendation G.8265.1 is in general relevant,
especially in order to address mobile networks needs.
This PTP telecom profile is based on an "end-to-end" PTP
architecture: the intermediate network nodes do not support PTP
functions such as Boundary Clock (BC) or Transparent Clock (TC). As
such, they generate Packet Delay Variation (PDV). The PTP
communication is only performed between a PTP master function and a
PTP slave function.
This PTP dialog may involve different layers, due to different
encapsulations. In particular, it is common that PTP messages are
carried within an MPLS layer when using this PTP profile.
In order to minimize the PDV generated by the intermediate network
nodes, PTP messages MUST be marked as high priority traffic, and
MUST be positioned in high priority queues. This marking does not
involve new PTP functions in the network nodes; it corresponds
simply to the usual DiffServ functions supported in these devices.
Jobert Expires September 5, 2012 [Page 4]
Internet-Draft Transporting PTP messages over March 2012
MPLS networks using a link local addressing
In particular, the intermediate network nodes do not identify the
PTP messages among the rest of the traffic; only the marking of the
packets is considered to position them in the relevant queues.
The identification of the PTP messages by an intermediate network
node which does not support PTP functions with this PTP frequency
telecom profile is not expected in general to provide real
performance improvements compared to the prioritization of the PTP
traffic and the positioning of the PTP messages in a dedicated high
priority queue.
Indeed, more specialized treatment of the PTP messages would make
the network node very close to a node supporting PTP functions such
as Boundary Clocks or Transparent Clocks. This would be quite
contradictory to the architecture assumptions of this PTP frequency
telecom profile.
In conclusion, when the ITU-T PTP frequency telecom profile defined
in the Recommendation G.8265.1 is used, the identification of the
PTP messages among the rest of the MPLS traffic does neither appear
necessary, nor providing real performance benefits.
4. Transporting PTP messages over MPLS networks with a "link-by-link"
PTP architecture
For applications requiring accurate phase/time synchronization, the
use of the future ITU-T PTP phase/time telecom profile under
definition in the Recommendation G.8275.1 is foreseen to be relevant
to address the needs of mobile networks.
This PTP telecom profile is based on a "link-by-link" PTP
architecture: the intermediate network nodes MUST support PTP
functions such as Boundary Clock or Transparent Clock. This
architecture is considered as necessary to avoid the generation of
Packet Delay Variation, due to the stringent accuracy requirements
that are targeted. The PTP communication is therefore performed
between different PTP entities: PTP master function, PTP slave
function, PTP Boundary Clocks, PTP Transparent Clocks.
Hence, being able to identify the PTP messages is considered
important, in order to allow the intermediate network nodes to apply
the special treatment on the PTP packets corresponding to the PTP
function that they implement (BC or TC).
Jobert Expires September 5, 2012 [Page 5]
Internet-Draft Transporting PTP messages over March 2012
MPLS networks using a link local addressing
This is one of the objectives of the definition of a PTP mapping.
Some mappings are already defined in the [IEEE1588-2008] standard,
and may be applicable to an MPLS network. The transport of PTP
messages over MPLS networks SHOULD NOT involve the MPLS layer itself
in this type of "link-by-link" PTP architecture.
4.1. Need for identifying the PTP messages in MPLS networks
The "link-by-link" PTP architecture described above may be
applicable over MPLS networks. As such, it is relevant to discuss
the mapping options for transporting the PTP messages over MPLS
networks when considering this type of PTP architecture.
Two PTP operations may be necessary in the MPLS nodes in order to
handle the PTP packets in the general case:
o PTP packets detection: how to detect that a packet contains PTP
payload? (this question is applicable to both Boundary Clock or
Transparent Clock types of PTP support)
o PTP payload position in the packet: how to determine where the
PTP payload is in the message once the relevant packets have been
detected? (this question is applicable only to Transparent Clock
PTP support, because Boundary Clocks terminate and process the
PTP payload)
Regarding the first point listed above (PTP packets detection), the
three following mappings could be considered in the general case:
o in case of an Ethernet mapping, the PTP packets can be detected
thanks to a specific Ethertype. Some PTP mappings already defined
in [IEEE1588-2008] already cover this point (see Annex F).
o in case of an IP/UDP mapping, the PTP packets can be detected
thanks to specific UDP port numbers. Some PTP mapping already
defined in [IEEE1588-2008] already cover this point (see Annexes
D and E). This mapping corresponds to the mapping specified for
the PTP frequency telecom profile defined in [G.8265.1].
Jobert Expires September 5, 2012 [Page 6]
Internet-Draft Transporting PTP messages over March 2012
MPLS networks using a link local addressing
o in case of MPLS mapping, if relevant, the draft [4]
("Transporting PTP messages (1588) over MPLS Networks") currently
discussed in the IETF TICTOC Working Group aims at specifying new
MPLS mappings enabling to detect the PTP packets among the
traffic. Note that these new PTP mappings are not defined in
[IEEE1588-2008].
This document advocates that the third type of mapping (MPLS
mappings) is not necessary for carrying PTP messages over MPLS
networks supported by an Ethernet physical layer when using a "link-
by-link" PTP architecture as depicted above in this document.
Instead, it is considered that the use of a link local addressing is
more relevant when the MPLS network is supported by an Ethernet
physical layer. This point will be discussed further in the next
sections of this document.
Regarding the second point (PTP payload position in the packet), it
should be stressed the network nodes may not know exactly where the
PTP payload is in the packet in some cases (e.g. when tunnels are
used), because of other potential encapsulations beyond the layer
handled by the node. This situation may happen in the case of MPLS
network nodes. In particular, as mentioned above, it raises problems
for modifying the PTP payload in case of a Transparent Clock PTP
support.
This document explains that the use of a link local addressing
simplifies this point, since the PTP payload is in this case at a
fixed location in the message. It is moreover in line the with the
principles of a "link-by-link" PTP architecture, where the PTP
messages are sent to the next network node, and are not assumed to
be forwarded through a tunnel. This point will be discussed further
in the next sections of this document.
4.2. Use of a link local addressing over MPLS networks supported by an
Ethernet physical layer
This section introduces a solution to carry PTP messages over an
MPLS network supported by an Ethernet physical layer, using a link
local Ethernet addressing. This solution fits very well with the
"link-by-link" PTP architecture depicted before.
With this solution, Ethernet interfaces supporting MPLS traffic MUST
use the Ethernet multicast address: '01-80-C2-00-00-0E' based on the
Annex F of IEEE1588-2008 for all the PTP messages that are sent.
Jobert Expires September 5, 2012 [Page 7]
Internet-Draft Transporting PTP messages over March 2012
MPLS networks using a link local addressing
This type of addressing aims at making sure that the PTP messages
will be sent to the next network node in the chain (which may be or
not an MPLS node).
This solution has several advantages:
o It prevents unwanted forwarding of PTP messages over network
nodes which do not provide PTP support: indeed, such a network
node is assumed in general to drop the PTP messages, and not to
forward them. It is useful in order to avoid the generation of
PDV. This property is considered in line with the "link-by-link"
PTP architecture principles depicted earlier.
o It facilitates the configuration for the operator, since no
particular addressing needs to be configured in the network
nodes.
o It allows having a consistent PTP mapping all along the chain:
all the PTP messages are transported the same way, using the same
mapping, whatever the actual layers used to transport the user
plane. In particular, an MPLS node may establish a PTP dialog
with an IP node or a node working at the layer 2 with this type
of solution.
o It facilitates the PTP payload identification, since the PTP
payload is necessarily at a fixed location.
Note: in case of MPLS nodes connected together via a different
physical layer than Ethernet, another link local channel linked to
the physical layer might be used. This is beyond the scope of this
document.
4.3. Use of link local addressing with Transparent Clocks
The case of Transparent Clock type of PTP support deserves a
specific analysis when considering the use of a link local
addressing. Indeed, some designs of Transparent Clock may not
terminate the PTP messages; it creates issues in order to forward
the PTP messages when link local addressing is used.
This section highlights however that some simple mechanisms might be
implemented in Transparent Clocks to ensure their compatibility with
the use of a link local addressing as proposed in the previous
Jobert Expires September 5, 2012 [Page 8]
Internet-Draft Transporting PTP messages over March 2012
MPLS networks using a link local addressing
section. It also shows that a link local addressing may avoid the
layer violation issues with TCs.
Three main steps are observed in a standard Transparent Clock which
does not terminate the PTP messages in order to treat and forward
them:
1- Detection of the PTP packet among the rest of the traffic on an
active PTP port, and precise timestamping of the arrival instant of
the packet in the network node.
2- The PTP packet is treated/forwarded in the network node as a
standard packet, e.g. analysis of the network header of the packet
corresponding to the layer treated by the network node, in order to
determine using the forwarding engine towards which output port the
packet must be forwarded (for instance: IP lookup operation in a
routing table). In summary: the output port is determined based on
information contained in the PTP packet itself, using standard
forwarding functions in the network node.
3- Transmission of the PTP packet at the output of the network node
on the port determined before, and precise timestamping of the
emission instant of the packet in the network. Modification of the
"correction field" of the packet to include the residence time
calculation.
The layer violation is due here to the fact that the PTP packet has
been modified (correction field update) by an intermediate node
which was assumed only to forward it. Moreover, there might be some
difficulties to determine where the PTP payload is located, as
mentioned earlier.
The use of a link local addressing might not be suitable with this
model of TC. Indeed, it can be observed that the step 2 requires in
the general case that the necessary information (e.g. final
destination address) would be contained in the network header of the
PTP messages to determine the output port where each PTP message
must be forwarded. This is not the case with link local addressing,
because each message is sent to the next node over a single link.
However, there are easy ways to overcome this issue. One possible
straightforward solution could be to include locally in the network
node the necessary information for the forwarding of the PTP
messages. This might correspond to a "PTP local forwarding
Jobert Expires September 5, 2012 [Page 9]
Internet-Draft Transporting PTP messages over March 2012
MPLS networks using a link local addressing
function", which could be part of the network node configuration
(manual configuration would be possible, but automatic procedures
would also work).
As for the case of a standard TC, three main steps are observed in
order to treat and forward a PTP message in a Transparent Clock
implementing a PTP local forwarding function:
o The step 1 is similar in both cases (standard TC and TC with PTP
local forwarding function).
o The step 2 would differ in this example (TC with PTP local
forwarding function): the standard forwarding function of the
network node (forwarding engine) MUST NOT be used in this case to
forward the PTP packets; instead, the PTP local forwarding
function MUST be used. This allows handling PTP packets without
forwarding information in the network header of the packet.
o The step 3 is quite similar in both cases (standard TC and TC
with PTP local forwarding function).
It must be stressed that the use of link local addressing leads to
terminate the PTP packets that are received by the network node,
since the recipient of the PTP messages is the network node itself.
The PTP packets sent at the output of the TC with PTP local
forwarding function are therefore new PTP packets, similarly to a
BC. This is the reason why it can be considered as a way to avoid
the layer violation issue.
In practice, the operations are similar between standard TC and TC
with PTP local forwarding function for generating a new PTP packet
based on the PTP packet received (e.g. update of the correction
field, etc...).
Moreover, it must also be stressed that the use of link local
addressing leads to a fixed location of the PTP payload in the
packet. This is expected to greatly simplify the operations.
The PTP local forwarding function includes locally in the network
node all the necessary information for forwarding the PTP packets.
For instance, it may associate one or several output ports to an
input port. An example of what could be a PTP local forwarding
function is provided in the figure 1 below.
Jobert Expires September 5, 2012 [Page 10]
Internet-Draft Transporting PTP messages over March 2012
MPLS networks using a link local addressing
+------------------------------------------------------------------+
| |
| +------------------------------------------------------+ |
| | Network node | |
| \---/ +---+ |
| | x | ----------------------------------------| 4 | |
| /---\ / +---+ |
| | / | |
| +-----+ / | |
| |+---+|/ +---+ |
| || 2 ||--------------------------------------------| 5 | |
| |+---+| +---+ |
| +-----+ | |
| | +-----+ |
| +---+ |+---+| |
| | 3 |--------------------------------------------|| 6 || |
| +---+ |+---+| |
| | +-----+ |
| | | |
| +------------------------------------------------------+ |
| |
| +-----+ |
| |+---+| |
| || || Enabled PTP upstream port |
| |+---+| |
| +-----+ |
| |
| +---+ |
| | | Enabled PTP downstream port |
| +---+ |
| |
| \---/ |
| | x | Disabled PTP port |
| /---\ |
| |
+------------------------------------------------------------------+
Figure 1 - Example of a possible configuration of the PTP local
forwarding function
In the figure 1 above, three configurations are possible for a PTP
port in a TC with PTP local forwarding function:
Jobert Expires September 5, 2012 [Page 11]
Internet-Draft Transporting PTP messages over March 2012
MPLS networks using a link local addressing
o Disabled PTP port: any potential PTP packet received on this port
MUST be discarded.
o Enabled PTP upstream port: corresponds to a port where upstream
PTP packets are received (e.g. the PTP packets generated by a PTP
master port). When a PTP packet is received on an enabled PTP
upstream port, a new PTP packet MUST be transmitted by one or
several enabled PTP downstream ports of the network node
associated to the enabled PTP upstream port. This/these new PTP
packet(s) is/are formed using the information of the original PTP
packet that was received, and by modifying the fields normally
modified by a TC (the correction field in particular).
o Enabled PTP downstream port: corresponds to a port where
downstream PTP packets are received (e.g. the PTP packets
generated by a PTP slave port). When a PTP packet is received on
an enabled PTP downstream port, a new PTP packet MUST be
transmitted by the enabled PTP upstream port of the network node
associated to the enabled PTP downstream port. This new PTP
packet is formed using the information of the original PTP packet
that was received, and by modifying the fields normally modified
by a TC (the correction field in particular).
Note that the case of a two-port device is an example where implicit
PTP local forwarding function exists: every port PTP packet received
on one port must be forwarded by the other port.
The advantages of this type of mechanism are that it allows mixing
BCs and TCs in a chain in a consistent way, using link local
addressing. It also allows avoiding layer violation issues, since
the PTP messages are terminated and processed by each network node,
including the TC with PTP local forwarding function.
5. Security Considerations
<Add any security considerations>
6. IANA Considerations
<Add any IANA considerations>
Jobert Expires September 5, 2012 [Page 12]
Internet-Draft Transporting PTP messages over March 2012
MPLS networks using a link local addressing
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
[IEEE1588-2008] IEEE 1588-2008, "IEEE Standard for a Precision
Clock Synchronization Protocol for Networked Measurement
and Control Systems", July 2008.
[G.8265.1] ITU-T Recommendation G.8265.1 "Precision time protocol
telecom profile for frequency synchronization", October
2010.
7.2. Informative References
[3] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP
and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573-
1583.
[4] Davari, Oren, Bhatia, Roberts, Montini "Transporting PTP
messages (1588) over MPLS Networks", October 2011
[Fab1999] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in
TCP and Its Effect on Busy Servers", Proc. Infocom 1999
pp. 1573-1583.
8. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Jobert Expires September 5, 2012 [Page 13]
Internet-Draft Transporting PTP messages over March 2012
MPLS networks using a link local addressing
Authors' Addresses
Sebastien Jobert
France Telecom Orange
2 avenue Pierre Marzin
22300 LANNION, FRANCE
Email: sebastien.jobert@orange.com
Jobert Expires September 5, 2012 [Page 14]
