TICTOC Working Group                                           S. Davari
Internet-Draft                                                   A. Oren
Intended status: Experimental                             Broadcom Corp.
Expires: October 30, 2014 April 18, 2016                                        M. Bhatia
                                                              P. Roberts
                                                              L. Montini
                                                           Cisco Systems
                                                          April 28, 2014
                                                        October 16, 2015

            Transporting Timing messages over MPLS Networks


   This document defines the a method for transporting Timing messages timing messages, such
   as PTP and NTP Precision Time Protocol (PTP) or Network Time Protocol (NTP), over an MPLS
   a Multiprotocol Label Switched (MPLS) network.  The method allows for the
   easy identification
   facilitates efficient recognition of these PDUs at the port level timing packets to allow for enable their
   port level processing of these PDUs in both LERs Label Edge Routers (LERs) and LSRs. Label
   Switched Routers (LSRs).

   The basic idea mechanism is to transport Timing timing messages inside "Timing
   LSPs", which are dedicated MPLS
   LSPs.  These LSPs only Label Switched Paths (LSPs) that
   carry Timing messages only timing, and possibly Control related Operations, Administration
   Management Maintenance (OAM) or management packets, but they do not carry
   customer traffic.

   Two encapsulations methods for transporting Timing messages over MPLS are defined.  The first method is to transport Timing transports UDP/IP
   encapsulated timing messages directly over the dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for
   MPLS networks. LSP.  The
   second method is to transport Timing transports Ethernet encapsuled timing messages inside a PW via an
   Ethernet encapsulation. pseudowire.

Status of this 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."
   This Internet-Draft will expire on October 30, 2014. April 18, 2016.

Copyright Notice

   Copyright (c) 2014 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  . . . . . . . . . . . . . . . . . . . . . . . . .  6   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  8   4
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .  9   5
   4.  Timing over MPLS Architecture . . . . . . . . . . . . . . . . 10   5
   5.  Dedicated LSPs for Timing messages  . . . . . . . . . . . . . . 13   7
   6.  Timing over LSP Encapsulation . . . . . . . . . . . . . . . . 14   8
     6.1.  Timing over UDP/IP over MPLS Encapsulation  . . . . . . . . 14   8
     6.2.  Timing over PW Encapsulation  . . . . . . . . . . . . . . . 14
     6.3.  Other Timing Encapsulation methods . . . . . . . . . . . . 15   8
   7.  Timing message Processing . . . . . . . . . . . . . . . . . . 16   9
   8.  Protection and Redundancy . . . . . . . . . . . . . . . . . . 17  10
   9.  ECMP and Entropy  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18  10
   10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19  11
   11. Entropy  . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

   12. OAM, Control and Management . . . . . . . . . . . . . . . . . 21

   13.  11
   12. QoS Considerations  . . . . . . . . . . . . . . . . . . . . . . 22

   14.  11
   13. FCS and Checksum Recalculation  . . . . . . . . . . . . . . . . 23

   15.  11
   14. Behavior of LER/LSR  . . . . . . . . . . LER/LSRs  . . . . . . . . . . . 24
     15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . . 24
     15.2.  12
     14.1.  Behavior of Timing-capable/aware LSR . . . . LERs/LSRs . . . . . . . 24
     15.3.  12
     14.2.  Behavior of non-Timing-capable/aware LSR . . . . . . . . . 24

   16.  12
   15. Other considerations  . . . . . . . . . . . . . . . . . . . . . 26

   17.  13
   16. Security Considerations . . . . . . . . . . . . . . . . . . . 27

   18.  13
   17. Applicability Statement . . . . . . . . . . . . . . . . . . . 28

   19.  14
   18. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 29

   20.  14
   19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
   21.  14
   20. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     21.1.  15
     20.1.  Normative References . . . . . . . . . . . . . . . . . . . 31
     21.2.  15
     20.2.  Informative References . . . . . . . . . . . . . . . . . . 31  16
   Appendix 1. A.  Appendix . . . . . . . . . . . . . . . . . . . . . . 34
     1.1.  17
     A.1.  Routing extensions for Timing-aware Routers . . . . . . . 34
     1.2.  17
     A.2.  Signaling Extensions for Creating Timing LSPs . . . . . . 34  17

   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 36  18

1.  Introduction

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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].

1.  Introduction

   The objective of timing distribution protocols, such as Precision
   Time Protocol (PTP) and Network Timing Protocol (NTP) are (NTP), is to
   synchronize independent clocks running on
   separate 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.  The  PTP messages include PTP PDUs may be transported over UDP/IP (Annex
   D and E of [IEEE-1588]) and PTP PDUs or over Ethernet (Annex F of [IEEE-1588]).
   This document defines mapping and two methods to transport of the PTP messages defined in [IEEE-1588] over MPLS/MPLS-TP MPLS

   PTP defines several clock types: types, including ordinary clocks, boundary
   clocks, end-
   to-end end-to-end transparent clocks, and peer-to-peer transparent
   clocks.  Transparent clocks require are situated at intermediate nodes to and
   update correction
   field the Correction Field inside PTP message that reflects messages in order to reflect
   the transit time in required to transit the node.

   [RFC5905] defines NTP messages for clock and time synchronization.
   The PTP
   NTP messages (PDUs) are transported over UDP/IP.  This document defines mapping and a
   method to transport of the NTP messages defined in
   [RFC5905] over MPLS networks.

   One key attribute

   It can be expected that only a subset of all 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 messages is that the Time
   stamp processing should occur as close as possible LSPs are designed to optimize timing distribution, the actual
   transmission and reception at the physical port interface.  This
   targets optimal time and/or frequency recovery by avoiding variable
   delay introduced by queues internal to the clocks.

   To facilitate the fast and efficient recognition of Timing messages
   at the port level when the Timing messages are carried over MPLS
   LSPs, this document defines the specific encapsulations that should
   be used.  In addition, it can be expected that there will exist LSR/
   LERs where only a subset of the physical ports will have the port-
   based Timing message processing capabilities.  In order to ensure
   that the LSPs carrying Timing packets always enter and exit ports
   with this capability, routing extensions can be defined to advertise
   this capability on a port basis and to allow for the establishment of
   LSPs that only transit such ports.  While this path establishment
   restriction may be applied only at the LER Ingress and/or egress
   ports, it becomes more important when using transparent clock capable
   LSRs in the path.

   Port based Timing message processing involves Timing message
   recognition.  Once the Timing messages are recognized they can be
   modified based on the reception or transmission Time-stamp.

   This document provides two methods for transporting Timing messages
   over MPLS.  One is applicable to MPLS environment and the other one
   is applicable to MPLS/MPLS-TP environment.

   The solution involves transporting Timing messages over dedicated
   LSPs called Timing LSPs.  These LSPs carry Timing messages and MAY
   carry Management and control messages, but not data plane client
   traffic.  Timing LSPs can be established statically or via signaling.
   Extensions to control plane (OSPF, ISIS, etc.) is required to enable
   routers to distribute their Timing processing capabilities over MPLS
   to other routers.  However such extensions are outside
   performance of slave clocks is beyond the scope of this document.

   When signaling is used to setup the PTP LSP, extensions to signaling
   protocols (e.g., RSVP-TE) are required for establishing PTP LSPs.
   However such extensions are outside the scope of this document.

   While the techniques included herein allow for the establishment of
   paths optimized to include Time-stamping capable links, the
   performance of the Slave clocks is outside the scope of this

   At the time of publishing this specification, Transparent Clocking
   (TC) is only defined for PTP.  Therefore at this time any part of
   this specification that talks about Transparent Clocking applies document.

   Presently on-path support is only
   to 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 and synchronization as distribution protocol defined by in IEEE 1588.

   NTP: The

   Boundary Clock: A device with one timing and synchronization protocol defined by IETF RFC-1305
   and RFC-5905.

   PTP: The port to receive timing
   messages and synchronization protocol used by 1588. 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

   Master Port: A port on a ordinary or boundary clock that is in Master
   state.  This is the source of

   NTP: The timing toward slave ports.

   Slave distribution protocol defined in RFC 5905.

   Ordinary Clock: A receiver of 1588 timing from a master clock.

   Slave Port: A port on a boundary clock or ordinary clock that is
   receiving timing from a master slave clock.

   Ordinary Clock: A device with  Note that ordinary clocks
   have only a single PTP port.

   Transparent Clock.  A device that measures the time taken for a PTP
   event message to transit the device and then updates the
   correctionField of the message with this transit time.


   PTP: Precision Time Protocol.  See 1588.

   Slave Clock: A device with more than one PTP port.  Generally
   boundary clocks will have one port in slave state to receive receiver of 1588 timing
   and then other ports in messages from a master state to re-distribute the timing.

   PTP clock.

   Timing LSP: An MPLS LSP dedicated to carry PTP messages

   PTP PW: A PW within a PTP LSP that is dedicated to carry PTP

   CW: Pseudowire Control Word

   LAG: Link Aggregation

   ECMP: Equal Cost Multipath

   CF: Correction Field, a field inside certain PTP messages (message
   type 0-3)that holds the accumulative transit time inside intermediate
   switches carry timing messages.

   Timing messages: Timing Protocol distribution protocol messages that are
   exchanged between
   routers in order to establish clocks.

   Timing port: A port on a synchronized (master, slave, transparent, or boundary)

   Timing PW: A PW within a Timing LSP that is dedicated to carry timing

   Transparent Clock: An intermediate node that forwards timing messages
   while updating their CF.

3.  Problem Statement

   [IEEE-1588] has defined defines methods for transporting PTP messages over
   Ethernet and IP networks.  [RFC5905] has defined the defines a method of transporting
   NTP messages over IP networks.  There is a need to transport Timing timing
   messages over MPLS networks while supporting the Transparent Clock
   (TC), Boundary Clock (BC) and Ordinary Clock (OC)
   functionality functionalities in the
   LER and LSRs in of the MPLS network.

   There are multiple potentially many ways of transporting Timing timing packets over
   MPLS.  However,
   there it is a requirement advisable to limit the number of possible
   encapsulation options to simplify the Timing message identification recognition and processing required at
   the port level.

   When Timing-awareness is needed, Timing of
   timing packets.

   The solution herein desscribed transports timing messages should not be
   transported over LSPs or PWs that are carrying customer traffic
   because LSRs perform
   dedicated "Timing Label switching based on the top label in the
   stack.  To detect Timing messages inside such LSPs require special
   hardware Switched Paths (LSPs)".  Were timing packets
   to do deep packet inspection at line rate.  Even if such
   hardware exists, the payload cant be deterministically identified by share LSPs with other traffic, intermediate LSRs because the payload type is a context of the PW label, and the
   PW label and its context are only known would be required
   to the Edge routers (PEs/
   LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR, CES,
   etc).  Even if one restricts an LSP perform some deeper inspection to only carry Ethernet PWs, the
   LSRs dont have the knowledge of whether PW Control Word (CW) is
   present or not differentiate between timing
   packets and therefore can not deterministically identify the

   A generic other packets.  The method is defined in herein proposed avoids this document that does not require
   deep packet inspection at line rate,
   complexity, and can deterministically
   identify Timing messages.  This method can be used to readily detect Timing
   Messages in both one-step all PTP messages (one-step or two-
   step), and two-step clock implementations of supports ordinary, boundary and transparent clocks.

4.  Timing over MPLS Architecture

   Timing messages are exchange exchanged between Timing timing ports on ordinary and
   boundary clocks.  Boundary clocks terminate the Timing timing messages and
   act as master clock for other boundary clocks or for slave clocks.  End-to-
   End Transparent  End-
   to-End transparent clocks do not terminate the Timing timing messages but they do
   modify the contents of the Timing timing messages as they transit across
   the transparent clock.

   Master/Slave clocks (OCs), Boundary Clocks (BC) in transit.

   OC, BC and Transparent Clock
   (TC) could TC functionality may be implemented in either LERs or

   An example is shown in Figure 1, where the LERs act as Ordinary Clock
   (OC) OCs and are
   the initiating/terminating point points for Timing timing messages.  The ingress
   LER encapsulates the Timing timing messages in a Timing LSP and the Egress egress LER
   terminates the this Timing LSP.  The  Intermediate LSRs (only one is shown
   here) act as
   Transparent Clock (TC) and just update the Timing field in TCs, updating the Timing
   messages. CF of transiting timing messages, as
   well as performing label switching operations.

    +--------+     +-------+     +-------+     +-------+     +--------+
    |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 terminate the Timing
   messages received from switch/routers that are act as BCs, and
   switches/routers outside of the MPLS
   network acting network, act as OC OCs or BC.  In this example LERs regenerate the
   clock BCs.  The
   ingress LER BC recovers timing and initiate initiates timing messages
   encapsulated in the Timing LSP toward the MPLS network, while the LSRs act an
   intermediate LSR acts as Transparent Clock (TC) a TC, and
   just update the Timing field in egress LER acts as a BC
   sending timing messages to equipment outside the Timing messages, which are
   already encapsulated in Timing LSPs. 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 do not terminate the
   Timing messages received from switch/routers that are outside of the
   MPLS network acting as OC, TC or BC.  The LERs and LSRs
   act as TC and update
   the Timing field in TCs.  The ingress LER updates the Timing messages as they transit CF and encapsulates the LER,
   while encapsulating them in
   timing LSP.  The message in an MPLS packet, intermediate LSRs also act as
   Transparent Clock (TC) and just update the Timing field in CF and
   perform label switching, and the Timing egress LER updates the CF and sends
   the timing messages which are already encapsulated in Timing LSPs. 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

   A final example is shown in Figure 4, where LERs and LSRs support
   Boundary Clocks.  A single-hop LSP is all nodes act as BCs.
   Single-hop LSPs are created between every two adjacent
   LSRs engaged in BC operation.  Other methods such as LSRs.  Of
   course, PTP transport over Ethernet MAY be used for transporting timing messages if the
   link between the two routers is Ethernet. network

    +--------+     +-------+     +-------+     +-------+     +--------+
    |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. customers, each having its own
   Timing domain.  In these cases the MPLS domain (maintained by a
   service provider) may MUST provide timing services
   to multiple customers, each having their own Timing domain. dedicated timing services to each

   The Timing timing over MPLS architecture assumes a full mesh of Timing LSPs
   between all LERs supporting this specification.  It supports
   Point-to- point-
   to- point (VPWS) and Multipoint (VPLS) services.  This means that a
   customer may purchase a Point-to-point Timing point-to-point timing service between two
   customer sites or a Multipoint Timing multipoint timing service between more than two
   customer sites.

   The Timing over MPLS architecture supports P2P or P2MP Timing LSPs.
   This means that the Timing Multicast messages such as PTP Multicast
   event messages can MAY be transported over P2MP Timing LSP LSPs or MAY be
   replicated and transported over many multiple P2P Timing LSPs.

   Timing messages, LSPs, as defined by this specification, MAY be used for timing
   messages that do not require Time stamping time-stamping or Correction
   Field update MAY be transported over Timing LSPs to simplify hardware
   and software. 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

   Many methods have been considered for identifying the Timing messages
   when they are encapsulated in MPLS such as using GAL/G-ACH or a new
   reserved label.  These methods were not attractive since they either
   required deep packet inspection at line rate in the intermediate LSRs
   or they required use of a scarce new reserved label.  Also one of the
   goals was to reuse existing OAM mechanisms.

   The method defined in this document can be is used by LER and LSRs to
   identify Timing timing messages in MPLS tunnels by just looking at observing the top label in of the MPLS label stack, which only carry Timing messages as
   well as OAM, but not data plane client traffic.
   stack.  Compliant implementations MUST use dedicated LSPs to carry Timing
   timing messages over MPLS.  These  Such LSPs are herein referred to as
   "Timing LSPs" and the labels associated with these LSPs as "Timing
   LSP labels".  The

   Timing LSPs that runs between Ingress and Egress LERs
   MUST be co-routed.  Alternatively, a single distribution requires symmetrical bidirectional co-routed
   LSP can be used.
   communications.  Co-routing of the two directions is required to
   limit the difference
   in the delays in the Master clock to Slave clock direction compared
   to the Slave clock to Master clock direction.  The Timing LSP MAY delay asymmetry.  Thus timing messages MUST be
   MPLS LSP/MPLS-TP transported
   either over two co-routed unidirectional Timing LSPs, or a single
   bidirectional co-routed Timing LSP.


   Timing LSPs could MAY be configured or signaled via RSVP-TE/GMPLS.
   New using RSVP-TE.  Extensions to RSVP-TE/GMPLS TLVs RSVP-TE
   are required; however they required for this purpose, but are
   outside beyond the scope of this

   The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such as
   BFD and LSP Ping but the LSP data plane client plane traffic MUST be
   Timing packets only.

6.  Timing over LSP Encapsulation

   This standard defines

   We define two methods for carrying Timing timing messages over MPLS.  The
   first method is carrying UDP/IP encapsulated Timing transports UDP/IP-encapsulated timing messages over
   Timing LSPs, and the second method, is carrying method transports Ethernet encapsulated Timing
   timing messages over Ethernet PWs inside placed in Timing LSPs.

6.1.  Timing over UDP/IP over MPLS Encapsulation

   The simplest first method of transporting 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 over MPLS is MUST comply to
   encapsulate Timing PDUs in UDP/IP and then encapsulate them in Timing
   LSP. [RFC5905].  This format is shown in Figure 4.

                    |   Timing LSP Label   |
                    |        IPv4/6        |
                    |         UDP          |
                    |     Timing PDU   timing message     |

      Figure (4) - Timing over UDP/IP over MPLS Encapsulation

   This encapsulation is very simple and is useful when the network
   between Timing Master Clock and Slave Clock is MPLS network.

   In order for an LER/LSR to process Timing timing messages, the Timing LSP
   Label must be at the top label of the label stack.  The LER/LSR MUST
   know that the Timing LSP Label this label is used for carrying a Timing messages.
   This LSP Label.  It can be accomplished via learn this by
   static configuration or via RSVP-TE signaling.

   The UDP/IP encapsulation of PTP MUST follow Annex D and E of
   [IEEE-1588].  While the UDP/IP encapsulation of NTP MUST follow

6.2.  Timing over PW Encapsulation

   Another method of transporting Timing timing over MPLS networks is by
   encapsulating Timing PDUs to use
   Ethernet encapsulated timing messages, and to transport these in an
   Ethernet PW which in turn is transported over a Timing LSPs. LSP.  In the
   case of PTP, Ethernet PW encapsulation [RFC4448],
   shown in Fig 5(A) MUST be used and the Ethernet encapsulation of PTP MUST follow comply to Annex F of [IEEE-1588].

   The RAW
   [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 MUST payload MAY have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN). tags.  The Timing over PW
   encapsulation MUST use the Control Word (CW) as specified in [RFC4448] to ensure proper detection of PTP messages
   inside the MPLS packets for Timing over LSP and Timing over PW
   [RFC4448].  The use of Sequence Number in the CW is optional.

   Timing over PW encapsulation for

   NTP MUST use NTP over UDP/IP over PW
   (the MAY be transported using an IP PW discussed (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 PDU message |
                  |S-VLAN (Optional)|  |                |
                  +-----------------+  +----------------+
                  |C-VLAN (Optional)|        (B)
                  | Timing PDU message  |
                  |                 |

              Figure (5) - Timing over PW Encapsulations

   In order for an LSR to process PTP messages, the top label of the
   label stack (the Tunnel Label) MUST be a Timing label.

6.3.  Other Timing Encapsulation methods

   In future other timing encapsulation methods may be introduced, such
   as a new shim header after the Bottom of Stack to carry the Timing
   information.  Such new encapsulations are outside the scope of this

7.  Timing message Processing

   Each Timing protocol such as PTP and NTP, define their defines a set of Timing timing
   messages.  For example  PTP defines SYNC, DELAY_REQ, DELAY_RESP, FOLLOW_UP, etc messages.

   Some of the Timing messages require time stamping or correction field
   update at port level and some dont.  It is the job of the etc.

   Some timing messages require per-packet processing, such as time-
   stamping or CF updating.  A compliant LER/LSR to
   parse the parses each timing
   message and find out the type of the Timing message
   and decide whether and how to Time- stamp it (e.g., BC) or update
   correction field(e.g., TC). determine the required processing.

   For example example, the following PTP messages (called Event (event messages) require
   time-stamping or correction field update: CF updating:

   o  SYNC
   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 PTP Timing LSPs.  PDELAY_REQ and
   PDELAY_RESP are exchanged between adjacent PTP clocks (i.e.  Master, Slave,
   Boundary, (master, slave,
   boundary, or Transparent) transparent) and SHOULD be transported over single hop
   Timing LSPs.  If Two Step two-Step PTP clocks are present, then the FOLLOW_UP,
   and PDELAY_RESP_FOLLOW_UP messages MUST also be transported over the
   Timing LSPs.

   For a given instance of the 1588 protocol, SYNC and DELAY_REQ MUST be
   transported over two PTP LSPs that are in opposite directions.  These
   PTP LSPs, which are in opposite directions MUST be congruent and co-
   routed.  Alternatively,  As aforementioned, two co-routed
   unidirectional LSPs or a single bidirectional co-routed LSP can MAY be

   Except as indicated above for the two-step PTP clocks, Non-Event PTP
   message types do messages that
   are not "event messages" need to 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 slave
   clocks, usually as a general practice, timing
   distribution, slave clocks (or ports) 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
   (or port) and redundant master clocks (or ports).

   When a slave clock (or port) listens to redundant master clocks or
   ports, any prolonged Timing clocks.

   LSP outage will trigger the slave clock
   or port to switch to a redundant master clock or port.

   LSP/PW protection PW layer protection, such as Linear linear protection Switching (1:1, 1+1),
   Ring Switching, ring
   protection switching or MPLS Fast Reroute (FRR) can switch (FRR), will lead to an
   alternative path that can cause a change changes
   in delay, which propagation delay between master and slave clocks.  Such a change,
   if undetected by the slave clock, can reduce accuracy of the slave
   clock. would negatively impact timing
   performance.  While it is expected that most Slave slave clocks will often be
   able to detect the change in delay, such delay changes, this specification still recommends RECOMMENDS that
   automatic protection switching MUST NOT be used, used for Timing LSPs, unless
   the operator knows can ensure that
   the protection switching it will not have any adverse effect on the
   slave clock. negatively impact timing

9.  ECMP and Entropy

   To ensure the optimal correct operation of slave clocks and avoid error
   introduced by forward and reverse path delay asymmetry, the physical
   path for Timing taken by timing messages from master clock to slave Clock and vice
   versa must MUST be the same for all Event Timing timing
   messages.  In particular, the PTP event messages listed in section 7. 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

10.  PHP

   To ensure that the label on the top of the label stack is the Timing
   LSP Label, PHP MUST not be used.

11.  Entropy

   To ensure all Timing messages in a Timing LSP take the same path,
   Entropy Label MUST NOT be used for of the label stack is the Timing
   LSP [RFC6790] and
   Entropy Label Label, PHP MUST NOT not be used for the PWs that are carried inside
   Timing LSP [RFC6391].

12. employed.

11.  OAM, Control and Management

   In order to monitor Timing LSPs and their encapsulated or PWs, they MUST
   be able it is necessary to enable
   them to carry OAM and management messages.  These management
   messages  OAM packets MUST be differentiated from Timing
   timing messages via by already defined IETF methods.

   For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY run
   over PTP Timing LSPs via UDP/IP encapsulation or via GAL/G-ACH. GAL/G-ACh.  These
   protocols can easily be identified by the UDP Destination
   Port port number
   or by GAL/G-ACH GAL/G-ACh respectively.

   Also BFD, LSP-Ping and other management messages MAY run over the PWs
   encapsulated in Timing LSP PWs via one of the defined VCCVs (Type 1, 3 or
   4) [RFC5085] (note that
   VCCV Type 2 using Router Alert Label is going
   to be deprecated by IETF). [RFC5085].  In this case G-ACH, PW label (TTL=1) or
   GAL-ACH these messages are used recognized according
   to identify such management messages.

13. the VCCV type.

12.  QoS Considerations

   In network

   There may be deployments where timing messages traverse LSR/LERs that
   are not every LSR/LER is Timing-aware, it is
   important capable of the required processing.  In order to reduce minimize the
   negative impact of the non-Timing-aware LSR/LERs on the timing recovery in performance of the slave clock.  The Timing clock timing
   messages are time
   critical and must MUST be treated with the highest priority.  Therefore
   Timing over MPLS messages must be treated with the highest priority
   in the routers.  This can be
   achieved by proper setup of Timing LSPs.

   It is recommended that the Timing LSPs are setup or be configured
   properly to indicate EF-PHB [RFC3246]for
   [RFC3246] for the CoS and Green "green" [RFC2697] for drop eligibility.


13.  FCS and Checksum Recalculation

   When time-stamp generation

   Since Boundary and timing packet adjustment is performed
   near Transparent Clocks modify packets, when the physical port hardware, MPLS
   packets are transported over Ethernet the process processing MUST include
   recalculation of the Ethernet FCS.  Also  FCS retention for the
   payload Ethernet as described in
   [RFC4720] MUST NOT be used.

   For the UDP/IP encapsulation mode mode, calculation of Timing over MPLS, the UDP checksum
   will generally be required as per UDP transport standards.

   When UDP checksum is used, each Timing-aware LER/LSR must required.  After updating the CF a Transparent
   Clock MUST either incrementally update the UDP checksum after Time stamping or
   Correction Field update or verify the UDP checksum on reception from
   upstream and completely
   recalculate the checksum completely on before transmission to downstream node after Time stamping or Correction Field update.

15. node.

14.  Behavior of LER/LSR

   Timing-capable/aware LER/LSRs

   Timing-aware LERs and 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 operations timing processing (OC/BC/TC) on Timing
   packets and are configured to do so. on
   timing packets.  Timing-capable/aware LERs and LSRs can MAY advertise the
   timing capabilities of their Timing-capability per-interface interfaces via control plane protocols
   such as OSPF or IS-IS.  The Timing-capable/aware IS-IS, and timing-aware LERs can then
   signals be set up
   Timing LSPs via RSVP-TE signaling.  Alternatively the Timing
   capability timing
   capabilities of LER LERs and LSRs may be configured in known by a centralized
   controller or management system, and the Timing LSP LSPs may be setup using manual configuration manually
   configured, or other methods such as SDN.

15.1. set up by a management platform or a Software Defined
   Networking (SDN) controller.

14.1.  Behavior of Timing-capable/aware LER LERs/LSRs

   When a Timing-capable/aware timing-capable ingress LER behaves acting as a Transparent clock and TC receives a Timing timing
   message packet from a Timing-capable/aware timing-capable non-MPLS interface, the LER
   updates the Correction Field (CF) and CF, encapsulates and forwards the timing message packet over a
   previously established Timing LSP.  Also when  When a Timing message is received from timing-capable egress LER
   acting as a TC receives a Timing-capable/
   aware timing message packet on timing-capable
   MPLS interface, the LER updates the Correction Filed (CF) and CF, decapsulates the MPLS encapsulation
   encapsulation, and forwards the timing message
   to packet via a non-MPLS interface.
   When a Timing-capable/aware LER behaves timing-capable LSR acting as a Boundary clock and TC receives a Timing timing message
   from a Timing-capable/aware non timing-capable MPLS interface, the LER Timestamps LSR updates the Timing packet CF and sends it to
   forwards the
   LERs Boundary clock processing module.  Also when timing message over another MPLS interface.

   When a Timing timing-capable LER acting as a BC receives a timing message is
   packet from a Timing- capable/aware MPLS timing-capable interface, the LER
   Timestamps time-stamps the Timing
   packet and sends it to the LERs Boundary clock BC processing module.

   When a Timing-capable/aware timing-capable LER behaves acting as an Ordinary Clock toward
   the MPLS network, and OC receives a Timing timing message
   from a Timing-
   capable/aware timing-capable MPLS interface, the LER Timestamps time-stamps the Timing packet
   and sends it to the LERs Ordinary clock OC processing module.

15.2.  Behavior of Timing-capable/aware LSR

   A Timing-capable/aware LSR behaves as a Transparent clock and
   receives a Timing message from a Timing-capable/aware MPLS interface.
   The LSR updates the Correction Filed (CF) and forwards the timing
   message over another MPLS interface.


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 Timing Slave Clocks. 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 timing-capable/aware.

   Non-timing-capable/aware LSRs just switch perform label switching on the
   packets encapsulated in Timing LSPs and dont don't perform any Timing operation (TC).  However timing
   related processing.  However, as explained in QoS section the Timing over MPLS section, timing
   packets MUST be still be treated with the highest priority based on
   their Traffic Class
   (TC) marking.


15.  Other considerations

   [IEEE-1588] defines an optional peer-to-peer Transparent transparent clocking
   (P2P TC) mode that requires peer delay measurement compensates both for residence time in the network
   node and for propagation time on the link between two adjacent Timing-
   capable/ aware routers/switches.  Peer modes.  To support
   P2P TC, delay measurement messages
   need to must be time stamped and terminated by the Timing-capable/aware
   routers/ switches.  This means that performed between two adjacent LSRs may be engaged
   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 a single-hop peer delay measurement.

   For transporting such single hop peer delay measurement messages a single-hop LSP SHOULD to be
   created between the two adjacent LSRs engaged in
   peer delay measurement to carry peer delay measurement messages. LSRs.  Other methods such as PTP transport over Ethernet MAY be used used;
   transporting peer delay measurement messages example, if the link between the two adjacent routers is Ethernet.

   In Peer-to-peer transparent clocking (P2P TC),
   Ethernet, PTP transport over Ethernet MAY be used.

   To support P2P TC, a Timing-capable/ ware
   routers/switches timing-capable/ware LSR MUST maintain a list of
   all the neighbors to which it needs to send a PDelay_Req to, where each neighbor corresponds to PDelay_Req, and maintain a
   single-hop timing
   LSP. LSP to each.

   The use of Explicit Null Label (Label= (label 0 or 2) is acceptable as long
   as either the Explicit Null label is the bottom of stack label
   (applicable only to (for
   the UDP/IP encapsulation) or the label below the Explicit Null label is a PTP label.

   (for the PW case).

16.  Security Considerations

   MPLS PW security

   Security considerations in general for MPLS and pseudowires are discussed in
   [RFC3985] and [RFC4447],and those [RFC4447].  Security considerations also apply 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 [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 maintain and process each customers clock and
   Timing distinguish between timing messages separately from other customers belonging to ensure there is no
   cross- customer effect.
   different customers.  For example if an LER BC is synchronized to a specific grandmaster,
   grandmaster belonging to customer A, then the LER MUST only use that
   BC clock only for slaves of customer A A, to ensure that customer A cannot attack
   adversely affect the timing distribution of other customers by manipulating its time. customers.

   Timing messages MAY be encrypted or authenticated, provided that the
   timing-capable LERs/LSRs that are Timing capable/aware can authenticate/ decrypt the timing


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 encapsulated timing
      messages from a non-MPLS interface and forwards them as MPLS
      encapsulated Timing timing messages over Timing LSP, while optionally
      performing Transparent Clock
      functionality TC functionality.

   o  An egress LER that receives MPLS encapsulated Timing timing messages from
      a Timing LSP and forwards them to non-MPLS interface as IP or
      Encapsulated Timing encapsulated timing messages, while optionally performing Transparent Clock
      functionality TC

   o  An ingress LER that receives MPLS encapsulated Timing timing messages
      from a Timing
      LSP and terminates them, while performing the OC or non-MPLS interface, performs BC
      functionality functionality, and sends
      timing messages over a Timing LSP.

   o  An LSR egress LER that receives MPLS encapsulated Timing 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, while optionally performing
      the TC functionality functionality.

   This document also supports the case where not all LSRs are Timing-
   capable/aware.  It also supports the case where timing-
   capable/aware, or not all LER/LSR interfaces are Timing-capable/aware.

19. timing-capable/

18.  Acknowledgements

   The authors would like to thank Yaakov Stein, Luca Martini, Ron
   Cohen, Yaakov
   Stein, Tal Mizrahi, Stefano Ruffini, Peter Meyer and other members of IETF
   participants for reviewing and providing feedback on this draft.


19.  IANA Considerations

   There are no IANA requirements in this specification.


20.  References


20.1.  Normative References

              IEEE 1588-2008, "IEEE Standard for a Precision Clock
              Synchronization Protocol for Networked Measurement and
              Control Systems". 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. 1997,

   [RFC3985]  Bryant, S. S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-
              Edge-to-Edge (PWE3) Architecture", RFC 3985,
              DOI 10.17487/RFC3985, March 2005. 2005,

   [RFC4389]  Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
              Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 2006.
              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. 2006,

   [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. 2006,

   [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. 2006,

   [RFC5085]  Nadeau, T. 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. 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. 2010,

   [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.

21.2. 2010, <http://www.rfc-editor.org/info/rfc5884>.

20.2.  Informative References

   [ISO]      ISO/IEC 10589:1992, "Intermediate system to Intermediate
              system routeing routing information exchange protocol for use in
              conjunction with the Protocol for providing the
              Connectionless-mode Network Service (ISO 8473)". 8473)", April

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, DOI 10.17487/RFC1195,
              December 1990. 1990, <http://www.rfc-editor.org/info/rfc1195>.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
              DOI 10.17487/RFC2328, April 1998. 1998,

   [RFC2697]  Heinanen, J. and R. Guerin, "A Single Rate Three Color
              Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999. 1999,

   [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.

   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
              (TE) Extensions to OSPF Version 2", RFC 3630,
              September 2003.

   [RFC3784]  Smit, H. and T. Li, "Intermediate System to Intermediate
              System (IS-IS) Extensions for Traffic Engineering (TE)",
              RFC 3784, June 2004.

   [RFC4970]  Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.
              Shaffer, "Extensions to OSPF for Advertising Optional
              Router Capabilities", RFC 4970, July 2007.

   [RFC4971]  Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate
              System to Intermediate System (IS-IS) Extensions for
              Advertising Router Information", RFC 4971, July 2007.

   [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
              Topology (MT) Routing in Intermediate System to
              Intermediate Systems (IS-ISs)", RFC 5120, February 2008.

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, October 2008.

   [RFC5329]  Ishiguro, K., Manral, V., Davey, A., and A. Lindem,
              "Traffic Engineering Extensions to OSPF Version 3",
              RFC 5329, September 2008. 2002,

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008. 2008,

   [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. 2010,

   [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. 2011,

   [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.

1. 2012,

   [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.

   Indeed, it is useful to advertise data plane TE router link

   Timing related capabilities, such as the capability for a router to
   perform time-stamping, and OC, TC or BC processing, need to be Timing-aware.
   This capability MUST then
   advertised in order for them to be taken into account during path
   computation to
   computation.  A management system or SDN controller cognizant of
   timing related capabilities, can prefer or even require a Timing LSP
   to traverse links that advertise themselves
   as Timing-aware.  In this way or nodes or intefaces with the required
   capabilities.  The optimal path can ensure the entry and exit
   points into the LERs and, if desired, the links into the LSRs are
   able to perform port based time-stamping thus minimizing their impact
   on 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 extension extensions SHOULD be able to
   signal the following information per Router Link:

   o  Capable of processing PTP, NTP or other Timing timing flows

   o  Capable of performing Transparent Clock TC operation

   o  Capable of performing Boundary Clock BC operation


A.2.  Signaling Extensions for Creating Timing LSPs

   RSVP-TE signaling MAY be used to setup the timing set up Timing LSPs.  When RSVP-TE
   is used  Extensions are
   required to setup Timing LSPs, some information that indicates that RSVP-TE for this purpose.  Such extensions are outside
   the LSP is carrying Timing flows MUST be included in scope of this document; however, the new
   Extensions to RSVP-TE:

   The following information MAY also be
   included in the new Extensions
   to RSVP-TE: such extensions:

   o  Offset from Bottom of Stack (BoS) to the start of the Time-stamp

   o  Number of VLANs in case of PW encapsulation
   o  Timestamp  Time-stamp field Type

      *  Correction Field, Timestamp time-stamp

   o  Timestamp  Time-stamp Field format

      *  64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit
         NTP, etc.

   Note that in case when the above optional information is signaled with
   TE for a Timing LSP, all the Timing timing packets carried in that LSP must
   have the same signaled characteristics.  For example if
   Timestamp time-stamp
   format is signaled as 64-bit PTPv1, then all Timing timing packets must use
   64-bit PTPv1 time-stamp.

Authors' Addresses

   Shahram Davari
   Broadcom Corp.
   San Jose, CA  95134

   Email: davari@broadcom.com

   Amit Oren
   Broadcom Corp.
   San Jose, CA  95134

   Email: amito@broadcom.com

   Manav Bhatia

   Email: manav.bhatia@alcatel-lucent.com

   Peter Roberts

   Email: peter.roberts@alcatel-lucent.com
   Laurent Montini
   Cisco Systems
   San Jose CA

   Email: lmontini@cisco.com