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]