TICTOC Working Group                                           S. Davari
Internet-Draft                                                   A. Oren
Intended status: Standards Track                          Broadcom Corp.
Expires: April 9, 2012 25, 2013                                        M. Bhatia
                                                              P. Roberts
                                                          Alcatel-Lucent
                                                              L. Montini
                                                           Cisco Systems
                                                        October 7, 2011 22, 2012

            Transporting PTP Timing messages (1588) over MPLS Networks
                   draft-ietf-tictoc-1588overmpls-02
                   draft-ietf-tictoc-1588overmpls-03

Abstract

   This document defines the method for transporting PTP Timing messages (PDUs)
   such as PTP and NTP over an MPLS network.  The method allows for the
   easy identification of these PDUs at the port level to allow for port
   level processing of these PDUs in both LERs and LSRs.

   The basic idea is to transport PTP Timing messages inside dedicated MPLS
   LSPs.  These LSPs only carry PTP timing messages and possibly Control and
   Management packets, but they do not carry customer traffic.

   Two methods for transporting 1588 Timing messages over MPLS are defined.
   The first method is to transport PTP Timing messages directly over the
   dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for IP/MPLS
   MPLS networks.  The second method is to transport PTP Timing messages
   inside a PW via Ethernet encapsulation, which is more suitable for both
   MPLS and MPLS-TP networks.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 9, 2012. 25, 2013.

Copyright Notice

   Copyright (c) 2011 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.  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

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7  8

   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  8  9

   4.  1588  Timing over MPLS Architecture  . . . . . . . . . . . . . . . . .  9 10

   5.  Dedicated LSPs for PTP Timing messages . . . . . . . . . . . . . . . 10 12

   6.  1588  Timing over MPLS LSP Encapsulation  . . . . . . . . . . . . . . . . . 11 13
     6.1.  1588  Timing over LSP UDP/IP over MPLS Encapsulation . . . . . . . . 13
     6.2.  Timing over PW Encapsulation . . . . . . . 11
     6.2.  1588 over PW Encapsulation . . . . . . . . 13
     6.3.  Other Timing Encapsulation methods . . . . . . . . . 11

   7.  1588 Message Transport . . . 14

   7.  Timing Message Processing  . . . . . . . . . . . . . . . . . . 14 15

   8.  Protection and Redundancy  . . . . . . . . . . . . . . . . . . 16

   9.  ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

   10. OAM, Control and Management PHP  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

   11. QoS Considerations Entropy  . . . . . . . . . . . . . . . . . . . . . . 19

   12. FCS Recalculation . . . . . 19

   12. OAM, Control and Management  . . . . . . . . . . . . . . . . . 20

   13. UDP Checksum Correction QoS Considerations . . . . . . . . . . . . . . . . . . . . . . 21

   14. Routing extensions for 1588aware LSRs FCS Recalculation  . . . . . . . . . . . . . 22
     14.1. 1588aware Link Capability for OSPF . . . . . . . . . 22

   15. UDP Checksum Correction  . . . . . . . . 22
     14.2. 1588aware Link Capability for IS-IS . . . . . . . . . . . 23

   15. RSVP-TE Extensions

   16. Routing extensions for support of 1588 Timing-aware Routers  . . . . . . . . . 24

   17. Signaling Extensions for Creating Timing LSPs  . . . . . . . . 25

   16.

   18. Behavior of LER/LSR  . . . . . . . . . . . . . . . . . . . . . 26
     16.1.
     18.1. Behavior of 1588-aware Timing-capable/aware LER . . . . . . . . . . . . . . . . 26
     16.2.
     18.2. Behavior of 1588-aware Timing-capable/aware LSR . . . . . . . . . . . . . . . . 26
     16.3.
     18.3. Behavior of non-1588-aware non-Timing-capable/aware LSR . . . . . . . . . . . . . . 26

   17.

   19. Other considerations . . . . . . . . . . . . . . . . . . . . . 28

   18.

   20. Security Considerations  . . . . . . . . . . . . . . . . . . . 29

   19. Acknowledgements . . . .
   21. Applicability Statement  . . . . . . . . . . . . . . . . . . . 30

   20. IANA Considerations  . . . . . . . . . . . . .

   22. Acknowledgements . . . . . . . . 31
     20.1. IANA Considerations for OSPF . . . . . . . . . . . . . . . 31
     20.2.

   23. IANA Considerations for IS-IS  . . .  . . . . . . . . . . . 31
     20.3. IANA Considerations for RSVP . . . . . . . . . . . . . . . 31

   21. 32

   24. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     21.1. 33
     24.1. Normative References . . . . . . . . . . . . . . . . . . . 32
     21.2. 33
     24.2. Informative References . . . . . . . . . . . . . . . . . . 32 33

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 36
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [RFC2119].

   When used in lower case, these words convey their typical use in
   common language, and are not to be interpreted as described in
   RFC2119 [RFC2119].

1.  Introduction

   The objective of Precision Time Protocol (PTP) is and Network Timing
   Protocol (NTP) are to synchronize independent clocks running on
   separate nodes of a distributed system.

   [IEEE] defines PTP messages for clock frequency, phase and time
   synchronization.  The PTP messages include PTP PDUs over UDP/IP
   (Annex D and E of [IEEE]) and PTP PDUs over Ethernet (Annex F of [IEEE]).
   [IEEE- 1588]).  This document defines mapping and transport of the
   PTP messages defined in [IEEE] over MPLS MPLS/MPLS-TP networks.  PTP
   defines several clock types: ordinary clocks, boundary clocks,
   end-to-end end-
   to-end transparent clocks, and peer-to-peer transparent clocks.
   One key attribute of all of these
   Transparent clocks is require intermediate nodes to update correction
   field inside PTP message that reflects the transit time in the recommendation node.

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

   One key attribute of all of these Timing messages is that the
   Timestamp processing should occur as close as possible to the actual
   transmission and reception at the physical port interface.  This
   targets optimal time and/or frequency recovery by avoiding variable
   delay introduced by queues internal to the clocks.

   To facilitate the fast and efficient recognition of PTP Timing messages
   at the port level when the PTP 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 LSR/
   LERs where only a subset of the physical ports will have the port port-
   based PTP Timing message processing capabilities.  In order to ensure
   that the PTP carrying LSPs carrying Timing packets always enter and exit ports
   with this capability, routing extensions are defined to advertise
   this capability on a port basis and to allow for the establishment of
   LSPs that only transit such ports.  While this path establishment
   restriction may be applied only at the LER
   ingress/egress Ingress and/or egress
   ports, it becomes more important when using
   Transparent Clock transparent clock capable
   LSRs in the path.

   The port

   Port based PTP Timing message processing involves PTP event Timing message
   recognition.  Once the PTP event Timing messages are recognized they can be
   modified based on the reception or transmission timestamp.  An
   alternative technique to actual packet modification could include the
   enforcement of a fixed delay time across the LSR to remove
   variability in the transit delay.  This latter would be applicable in
   a LSR which does not contain a PTP transparent Clock function.

   This document provides two methods for transporting PTP Timing messages
   over MPLS.  One is principally focused on an IP/MPLS applicable to MPLS environment and the
   second other one
   is focused on the applicable to both MPLS and MPLS-TP environment.

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

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

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

2.  Terminology

   1588: The timing and synchronization as defined by IEEE 1588 1588.

   NTP: The timing and synchronization protocol defined by IETF RFC-1305
   and RFC-5905.

   PTP: The timing and synchronization protocol used by 1588 1588.

   Master Clock: The source of 1588 timing to a set of slave clocks.

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

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

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

   Ordinary Clock: A device with a single PTP port.

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

   Boundary Clock: A device with more than one PTP port.  Generally
   boundary clocks will have one port in slave state to receive timing
   and then other ports in master state to re-distribute the timing.

   PTP LSP: An LSP dedicated to carry PTP messages

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

   CW: Pseudowire Control Word

   LAG: Link Aggregation

   ECMP: Equal Cost Multipath

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

3.  Problem Statement

   When

   [IEEE] has defined methods for transporting PTP messages are transported over MPLS networks, there
   Ethernet and IP networks.  [RFC5905] has defined the method of
   transporting NTP messages over IP networks.  There is a need
   for PTP message processing at the physical port level.  This
   requirement exists to minimum uncertainty in the transit delays.  If
   PTP message processing occurs interior to the
   transport Timing messages over MPLS routers, then the
   variable delay introduced by queuing between networks while supporting the physical port
   Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (OC)
   functionality in the PTP processing will add noise to the timing distribution.  Port
   based processing applies at both the originating and terminating LERs LER and also at the intermediate LSRs if they support transparent clock
   functionality.

   PTP messages over Ethernet or IP can always be tunneled in the MPLS network.

   There are multiple ways of transporting Timing over MPLS.
   However  However,
   there is a requirement to limit the possible encapsulation options to
   simplify the PTP Timing message identification and processing required at
   the port level.  This applies to all 1588 clock types implemented in MPLS
   routers.  But this is particularly important in LSRs that provide
   transparent clock functionality.

   When 1588-awareness Timing-awareness is needed, PTP Timing messages should not be
   transported over LSPs or PWs that are carrying customer traffic
   because LSRs perform Label switching based on the top label in the
   stack.  To detect PTP Timing messages inside such LSPs require special
   hardware to do deep packet inspection at line rate.  Even if such
   hardware exists, the payload can't cant be deterministically identified by
   LSRs because the payload type is a context of the PW label label, and the
   PW label and its context are only known to the Edge routers (PEs); (PEs/
   LERs); LSRs don't dont know what is a PW's PWs payload (Ethernet, ATM, FR, CES,
   etc).  Even if one restricts an LSP to only carry Etehrent Ethernet PWs, the
   LSRs don't dont have the knowledge of whether PW Control Word (CW) is
   present or not and therefore can't can not deterministically identify the
   payload.

   Therefore a

   A generic method is defined in this document that does not require
   deep packet inspection at line rate, and can deterministically
   identify PTP Timing messages.  The defined generic method is applicable to both MPLS
   and MPLS-TP networks.

4.  1588  Timing over MPLS Architecture

   1588 communication flows map onto MPLS nodes as follows: 1588

   Timing messages are exchange between PTP Timing ports on Ordinary ordinary and
   boundary clocks.  Boundary clocks terminate the Timing messages and
   act as master for other boundary clocks or for slave clocks.
   Transparent clocks do not terminate the PTP Timing messages but they do
   modify the contents of the PTP Timing messages as they transit across the Transparent
   transparent clock.  SO Ordinary and boundary clocks would
   exist within

   Master/Slave clock could be integrated in the LERs.  An example is
   shown in Figure 1, where the LERs act as they Ordinary Clock (OC) and are
   the termination points initiating/terminating point for Timing messages.  The ingress
   LER encapsulates the PTP Timing messages carried in MPLS.  Transparent clocks would exist within LSRs
   as they do not terminate Timing LSP and the PTP message exchange.

   Perhaps a picture would be good here.

5.  Dedicated LSPs for PTP messages

   Many methods were considered for identifying Egress LER
   terminates the 1588 messages when
   they are encapsulated in MPLS such Timing LSP.  The LSRs act as by using GAL/ACH or a new
   reserved label.  These methods were not attractive since they either
   required deep packet inspection Transparent Clock (TC)
   and snooping at line rate or they
   required use of a scarce new reserved label.  Also one of just update the goals
   was to reuse existing OAM and protection mechanisms.

   The method defined in this document can be used by LER/LSRs to
   identify PTP messages Timing field in MPLS tunnels by using dedicated LSPs to
   carry PTP the Timing messages.

   Compliant implementations MUST use dedicated LSPs to carry PTP
   messages

      +--------+     +-------+     +-------+     +-------+     +--------+
      |Switch, |     |       |     |       |     |       |     |Switch, |
      | Router |-----|  LER  |-----|  LSR  |-----|  LER  |-----| Router |
      |        |     |  OC   |     |  TC   |     |  OC   |     |        |
      +--------+     +-------+     +-------+     +-------+     +--------+
                     /                                 \
      +-------+     /                                   \     +-------+
      |  LER  |    /                                     \    |  LER  |
      | Master|---/                                       \---| Slave |
      | Clock |                                               | Clock |
      +-------+                                               +-------+

     Figure (1) - Deployment example 1 of timing over MPLS.  These LSPs are herein referred to MPLS/MPLS-TP network

   LERs could also act as "PTP LSPs"
   and Boundary Clock (BC).  This is shown in Figure
   2, where LERs terminate the labels associated with these LSPs Timing messages received from switch/
   routers that are outside of the MPLS network acting as "PTP labels".  These
   LSPs could be P2P OC or P2MP LSPs.  The PTP LSP between Master Clocks BC.  In
   this example LERs regenerate the clock and Slave Clocks MAY be P2MP or P2P initiate timing messages
   encapsulated in Timing LSP toward the MPLS network, while the PTP LSP between
   each Slave Clock and Master Clock SHOULD be P2P LSP.  The PTP LSP
   between a Master Clock and a Slave LSRs
   act as Transparent Clock (TC) and just update the PTP LSP between Timing field in the
   same Slave Clock and Master
   Timing messages, which are already encapsulated in Timing LSPs.

     +--------+     +-------+     +-------+     +-------+     +--------+
     |Switch, |     |       |     |       |     |       |     |Switch, |
     | Router |-----|  LER  |-----|  LSR  |-----|  LER  |-----| Router |
     | OC/BC  |     |  BC   |     |  TC   |     |  BC   |     | OC/BC  |
     +--------+     +-------+     +-------+     +-------+     +--------+

     Figure (2) - Deployment example 2 of timing over MPLS/MPLS-TP network

   LERs could also act as Transparent Clock MUST be co-routed.  Alternatively,
   a single bidirectional co-routed LSP can be used.  The PTP LSP MAY be
   MPLS LSP or MPLS-TP LSP. (TC).  This co-routing is required to limit
   differences shown in
   Figure 3, where LERs do not terminate the delays in Timing messages received
   from switch/routers that are outside of the Master clock to Slave clock
   direction compared to the Slave clock to Master clock direction.

   The PTP LSPs could be configured MPLS network acting as
   OC, TC or signaled via RSVP-TE/GMPLS.  New
   RSVP-TE/GMPLS TLVs and objects are defined in this document to
   indicate that these LSPs are PTP LSPs. BC.  The PTP LSPs MAY carry essential MPLS/MPLS-TP control plane traffic
   such LERs act as BFD TC and LSP Ping but update the LSP user plane traffic MUST be PTP
   only.

6.  1588 over MPLS Encapsulation

   This document defines two methods for carrying PTP messages over
   MPLS.  The first method is carrying IP encapsulated PTP messages over
   PTP LSPs and Timing field in the second method is to carry PTP messages over
   dedicated Ethernet PWs (called PTP PWs) inside PTP LSPs.

6.1.  1588 over LSP Encapsulation

   The simplest method of transporting PTP
   Timing messages over MPLS is to
   encapsulate PTP PDUs in UDP/IP and then encapsulate as they transit the LER, while encapsulating them in PTP
   timing LSP.  The 1588 over LSP format is shown LSRs also act as Transparent Clock (TC) and just
   update the Timing field in Figure 1.

          +----------------------+ the Timing messages which are already
   encapsulated in Timing LSPs.

      +--------+     +-------+     +-------+     +-------+     +--------+
      |Switch, |   PTP Tunnel Label     |
          +----------------------+       |        IPv4/6     |
          +----------------------+       |         UDP     |
          +----------------------+       |        PTP PDU     |Switch, |
          +----------------------+
      | Router |-----|  LER  |-----|  LSR  |-----|  LER  |-----| Router |
      |OC/TC/BC|     |  TC   |     |  TC   |     |  TC   |     |OC/TC/BC|
      +--------+     +-------+     +-------+     +-------+     +--------+

    Figure 1 (3) - 1588 Deployment example 3 of timing over LSP Encapsulation

   This encapsulation is very simple and is useful when the networks
   between 1588 Master Clock and Slave Clock are IP/MPLS networks.

   In order MPLS/MPLS-TP network

5.  Dedicated LSPs for an LSR to process PTP messages, the PTP Label must be
   the top label of Timing messages

   Many methods have been considered for identifying the label stack.

   The UDP/IP encapsulation of PTP MUST follow Annex D and E of [IEEE].

6.2.  1588 over PW Encapsulation

   Another method of transporting 1588 over MPLS networks is by
   encapsulating PTP PDUs in Ethernet and then transporting them over
   Ethernet PW (PTP PW) as defined in [RFC4448], which in turn is
   transported over PTP LSPs.  Alternatively PTP PDUs MAY be
   encapsulated in UDP/IP/Ethernet and then transported over Ethernet
   PW.

   Both Raw and Tagged modes for Ethernet PW Timing messages
   when they are permitted.  The 1588
   over PW format is shown encapsulated in Figure 2.

                    +----------------+
                    |PTP Tunnel Label|
                    +----------------+
                    |    PW Label    |
                    +----------------+
                    |  Control Word  |
                    +----------------+
                    |    Ethernet    |
                    |     Header     |
                    +----------------+
                    |     VLANs      |
                    |   (optional)   |
                    +----------------+
                    |    IPV4/V6     |
                    |   (optional)   |
                    +----------------+
                    |      UDP       |
                    |   (optional)   |
                    +----------------+
                    |    PTP PDU     |
                    +----------------+

            Figure 2 - 1588 over PW Encapsulation

   The Control Word (CW) MPLS such as specified in [RFC4448] SHOULD be used to
   ensure using GAL/ACH or a more robust detection of PTP messages inside the MPLS
   packet.  If CW is used, 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 Sequence number is optional.

   The use a scarce new reserved label.  Also one of VLAN and UDP/IP are optional.  Note that 1 or 2 VLANs MAY
   exist in the PW payload.

   In order for an LSR
   goals was to process PTP messages, reuse existing OAM mechanisms.

   The method defined in this document can be used by LER and LSRs to
   identify Timing messages in MPLS tunnels by just looking at the top
   label of in the MPLS label stack (the Tunnel Label) MUST be from PTP label range.  However
   in some applications the PW label may be the top label in the stack,
   such as cases where there is which only one-hop between PEs or in case of
   PHP.  In such cases, the PW label SHOULD be chosen from the PTP Label
   range.

   In order to ensure congruency between the two directions of PTP
   message flow, ECMP should carry Timing messages as
   well as OAM, but not be used for the PTP LSPs.  Therefore,
   no Entropy label [I-D.ietf-pwe3-fat-pw] is necessary and it SHOULD
   NOT be present in the stack.

   The Ethernet encapsulation of PTP MUST follow Annex F of [IEEE] and
   the UDP/IP encapsulation of PTP data plane client traffic.

   Compliant implementations MUST follow Annex D and E of [IEEE].

   For 1588 use dedicated LSPs to carry Timing
   messages over MPLS encapsulations that are PW based, there MPLS.  These LSPs are some
   cases in which the PTP LSP label may not be present:

   o  When PHP is applied herein referred to the PTP LSP, as "Timing
   LSPs" and the packet is received
      without PTP labels associated with these LSPs as "Timing LSP label at PW termination point .

   o  When the PW is established
   labels".  The Timing LSPs that runs between two routers directly connected
      to each other Ingress and no PTP Egress LERs
   MUST be co-routed.  Alternatively, a single bidirectional co-routed
   LSP is needed.

   In such cases it can be used.

   Co-routing of the two directions is required for a router to identify these packets
   as PTP packets.  This would require limit the PW label to also be a label
   that is distributed specifically for carrying PTP traffic (aka PTP PW
   label).  Therefore there is a need difference
   in the delays in the Master clock to add extension Slave clock direction compared
   to LDP/BGP PW
   label distribution protocol the Slave clock to indicate that a PW label is a PTP PW
   labels.

7.  1588 Message Transport

   1588 protocol comprises of the following message types:

   o  Announce

   o  SYNC

   o  FOLLOW UP

   o  DELAY_REQ (Delay Request)

   o  DELAY_RESP (Delay Response)

   o  PDELAY_REQ (Peer Delay Request)

   o  PDELAY_RESP (Peer Delay Response)

   o  PDELAY_RESP_FOLLOW_UP (Peer Delay Response Follow up)

   o  Management

   o  Signaling

   A subset of PTP message types that require timestamp processing are
   called Event messages:

   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 Master Clock and Slave Clock
   and MUST clock direction.  The Timing LSP MAY be transported over PTP LSPs.  PDELAY_REQ and PDELAY_RESP
   are exchanged between adjacent PTP clocks (i.e.  Master, Slave,
   Boundary,
   MPLS LSP or Transparent) and MAY MPLS-TP LSP.

   The Timing LSPs could be transported over single hop PTP
   LSPs.  If Two Step PTP clocks configured or signaled via RSVP-TE/GMPLS.
   New Extensions to RSVP-TE/GMPLS TLVs are present, then the FOLLOW_UP,
   DELAY_RESP, and PDELAY_RESP_FOLLOW_UP messages must also be
   transported over required; however they are
   outside the PTP LSPs.

   For a given instance scope of 1588 protocol, SYNC this document.

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

6.  Timing over LSP Encapsulation

   This document defines two PTP LSPs that are in opposite directions.  These
   PTP methods for carrying Timing messages over
   MPLS.  The first method is carrying UDP/IP encapsulated Timing
   messages over Timing LSPs, which are in opposite directions MUST be congruent and co-
   routed.  Alternatively, a single bidirectional co-routed LSP can be
   used.

   Except as indicated above is suitable for MPLS networks and
   the two-step PTP clocks, Non-Event PTP
   message types don't need to be processed by intermediate routers.
   These message types MAY be carried in PTP Tunnel LSPs.

8.  Protection second method, is carrying Ethernet encapsulated Timing messages
   over Ethernet PWs inside Timing LSPs, which is suitable for MPLS and Redundancy

   In order to ensure continuous uninterrupted operation
   MPLS-TP networks.

6.1.  Timing over UDP/IP over MPLS Encapsulation

   The simplest method of 1588 Slaves,
   usually as a general practice, Redundant Masters are tracked by each
   Slave.  It transporting Timing messages over MPLS is the responsibility of the network operator to ensure
   that physically disjoint PTP tunnels that don't share any link are
   used between the redundant Masters
   encapsulate Timing PDUs in UDP/IP and a Slave.

   When redundant Masters are tracked by a Slave, any prolonged PTP then encapsulate them in Timing
   LSP.  This format is shown in Figure 4.

                    +----------------------+
                    |   Timing LSP
   or PTP PW outage will trigger Label   |
                    +----------------------+
                    |        IPv4/6        |
                    +----------------------+
                    |         UDP          |
                    +----------------------+
                    |     Timing PDU       |
                    +----------------------+

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

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

   In order for an LER/LSR to switch to process Timing messages, the
   Redundant Master Clock.  However LSP/PW protection such as Linear
   Protection Switching (1:1,1+1), Ring protection switching or MPLS
   Fast Reroute (FRR) SHOULD still Timing LSP
   Label must be used to provide resiliency to
   individual network segment failures..

   Note that any protection or reroute mechanism that adds additional at the top label to of the label stack, such as Facility Backup Fast Reroute, stack.  The LER/LSR MUST
   ensure
   know that the pushed label Timing LSP Label is a used for carrying Timing messages.
   This can be accomplished via static configuration or via RSVP-TE
   signaling.

   The UDP/IP encapsulation of PTP Label to ensure recognition MUST follow Annex D and E of [IEEE].
   While the MPLS frame as containing PTP messages as it transits the backup
   path..

9.  ECMP

   To ensure the optimal operation UDP/IP encapsulation of 1588 Slave clocks and avoid errors
   introduced NTP MUST follow [RFC5905].

6.2.  Timing over PW Encapsulation

   Another method of transporting Timing over MPLS networks is by forward and reverse path delay asymmetry, the physical
   path for PTP messages from Master Clock to Slave Clock and vice versa
   must be the same for all PTP messages listed
   encapsulating Timing PDUs in section 7 and must
   not change even PW which in the presence turn is transported over
   Timing LSPs.  In case of ECMP PTP, Ethernet PW encapsulation [RFC4448],
   shown in the MPLS network.

   To ensure the forward Fig 5(A) MUST be used and reverse paths are the same Ethernet encapsulation of PTP LSPs and PWs
   MUST NOT follow Annex F of [IEEE].

   The Tagged mode defined in [RFC-4448] MUST be subject to ECMP.

10.  OAM, Control used and Management

   In order to manage PTP LSPs the Payload
   MUST have 2 VLAN tags (S-VLAN and PTP PWs, they MAY carry OAM, C-VLAN).  The Timing over PW
   encapsulation MUST use the Control
   and Management messages.  These control and management messages can
   be differentiated from Word (CW) as specified in
   [RFC4448] to ensure proper detection of PTP messages via already defined IETF methods.

   In particular BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389]MAY run
   over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH.  These
   Management protocols are easily identified by inside the UDP Destination
   Port number or by GAL/ACH respectively.

   Also BFD, LSP-Ping MPLS
   packets for Timing over LSP and other Management messages MAY run Timing over PTP PW
   via one encapsulation.  The
   use of Sequence Number in the defined VCCVs (Type 1, 2 or 3) [RFC5085].  In this
   case G-ACH, Router Alert Label (RAL), or CW is optional.

   Timing over PW label (TTL=1) are used to
   identify such management messages.

11.  QoS Considerations encapsulation for NTP MUST use NTP over UDP/IP over PW
   (the IP PW discussed in [RFC4447]) shown in Fig 5(B).

                  +----------------+  +----------------+
                  |Timing LSP Label|  |Timing LSP Label|
                  +----------------+  +----------------+
                  |    PW Label    |  |    PW Label    |
                  +----------------+  +----------------+
                  |  Control Word  |  |      IP        |
                  +----------------+  +----------------+
                  |    Ethernet    |  |      UDP       |
                  |     Header     |  +----------------+
                  +----------------+  |   Timing PDU   |
                  |     S-VLAN     |  |                |
                  +----------------+  +----------------+
                  |     C-VLAN     |        (B)
                  +----------------+
                  |   Timing PDU   |
                  |                |
                  +----------------+
                         (A)

              Figure (5) - Timing over PW Encapsulations

   In network deployments where not every LSR/LER is PTP-aware, then it
   is important order for an LSR to reduce process PTP messages, the impact top label of the non-PTP-aware LSR/LERs on
   the timing recovery in the slave clock.  The PTP messages are time
   critical and must
   label stack (the Tunnel Label) MUST be treated with the highest priority.  Therefore
   1588 a Timing label.

   The PW method of transporting Timing over MPLS messages must is applicable to both
   MPLS and MPLS-TP networks.

6.3.  Other Timing Encapsulation methods

   In future other timing encapsulation methods may be treated with introduced, such
   as a new shim header after the highest priority in Bottom of Stack to carry the routers.  This can be achieved by proper setup Timing
   information.  Such new encapsulations are outside the scope of this
   document.  The control and signaling requirements in this document
   are defined generically enough to accommodate any such new
   encapsulations.

7.  Timing Message Processing

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

   Some of the Timing messages require time stamping at port level and
   some dont.  It is recommended that the PTP LSPs are setup and marked properly job of the LER/LSR to
   indicate EF-PHB for parse the CoS timing message
   and Green for drop eligibility.

   In network deployments where every LSR/LER supports PTP LSPs, then it
   MAY NOT be required to apply find out the same level of prioritization as
   specified above.

12.  FCS Recalculation

   Ethernet FCS type of the outer encapsulation MUST be recalculated at every
   LSR that performs Timing message and decide whether and
   how to Time- stamp it (e.g., BC) or modify existing timestamp in it
   (e.g., TC).

   For example the Transparent following PTP messages (called Event messages)
   require time-stamping, while other Non-Event PTP messages do not need
   time-stamping.

   o  Announce

   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 Master Clock and Slave Clock processing
   and FCS retention
   for the payload Ethernet described in [RFC4720] MUST NOT be used.

13.  UDP Checksum Correction

   For UDP/IP encapsulation mode of 1588 transported over MPLS, the UDP checksum is
   optional when used for IPv4 encapsulation PTP LSPs.  PDELAY_REQ and mandatory in case of
   IPv6.  When IPv4/v6 UDP checksum is used each 1588-aware LSR must
   either incrementally update the UDP checksum after the CF update PDELAY_RESP
   are exchanged between adjacent PTP clocks (i.e.  Master, Slave,
   Boundary, or
   should verify Transparent) and MAY be transported over single hop PTP
   LSPs.  If Two Step PTP clocks are present, then the UDP checksum on reception from upstream FOLLOW_UP,
   DELAY_RESP, and
   recalculate PDELAY_RESP_FOLLOW_UP messages must also be
   transported over the checksum completely on transmission after CF update
   to downstream node.

14.  Routing extensions for 1588aware LSRs

   MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] PTP LSPs.

   For a given instance of 1588 protocol, SYNC and
   IS-IS [ISO] [RFC1195] DELAY_REQ MUST be
   transported over two PTP LSPs that are in order to advertise Traffic Engineering (TE)
   link information used for constraint-based routing.

   Indeed, it is useful to advertise data plane TE router link
   capabilities, such opposite directions.  These
   PTP LSPs, which are in opposite directions MUST be congruent and co-
   routed.  Alternatively, a single bidirectional co-routed LSP can be
   used.

   Except as the capability indicated above for a router the two-step PTP clocks, Non-Event PTP
   message types do not need to be 1588-aware.
   This capability MUST then processed by intermediate routers.
   These message types MAY be taken into account during path
   computation to prefer or even require links that advertise themselves
   as 1588-aware. carried in PTP Tunnel LSPs.

8.  Protection and Redundancy

   In this way the path can order to ensure continuous uninterrupted operation of slave
   clocks, usually as a general practice, slave clocks (or ports) track
   redundant master clocks.

   It is the entry and exit
   points into the LERs and, if desired, the links into responsibility of the LSRs network operator to ensure that
   physically disjoint Timing LSPs are
   able established between a slave clock
   (or port) and redundant master clocks (or ports).

   When a slave clock (or port) listens to perform port based timestamping thus minimizing their impact
   on redundant master clocks or
   ports, any prolonged Timing LSP outage will trigger the performance slave clock
   or port to switch to a redundant master clock or port.

   LSP/PW protection such as Linear protection Switching (1:1, 1+1),
   Ring protection switching or MPLS Fast Reroute (FRR) generally switch
   alternative path that usually cause a change in delay, which if
   undetected by slave clock can reduce accuracy of the slave clock.

   For this purpose,
   However it is expected that most Slave clocks could detect the following sections specify extensions to OSPF
   and IS-IS change
   in order to advertise 1588 aware capabilities of a link.

14.1.  1588aware Link Capability for OSPF

   OSPF uses delay.  Therefore this specification recommends that protection
   switching SHOULD be used, unless the Link TLV (Type 2) operator knows that is itself carried within either the Traffic Engineering LSA specified in [RFC3630] or
   protection switching may have adverse effect on the OSPFv3
   Intra-Area-TE LSA (function code 10) defined in [RFC5329] slave clock.

   Note that any protection or reroute mechanism that adds additional
   MPLS label to
   advertise the TE related information for the locally attached router
   links.  For an LSA Type 10, one LSA can contain one Link TLV
   information for a single link.  This extension defines a new 1588-
   aware capability sub-TLV that can be carried label stack, such as part of the Link TLV.

   The 1588-aware capability sub-TLV is OPTIONAL and Facility Backup Fast Reroute,
   MUST NOT appear
   more than once within ensure that the Link TLV.  If pushed label is also a second instance Timing Label to ensure
   recognition of the
   1588-aware capability sub-TLV is present, MPLS frame as containing Timing messages, as it
   transits the receiving system MUST
   only process backup path.

9.  ECMP

   To ensure the first instance optimal operation of slave clocks and avoid error
   introduced by forward and reverse path delay asymmetry, the sub-TLV.  It is defined as
   follows:

      0                    1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Type             |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Flags     |
      +-+-+-+-+-+-+-+-+

                Figure 3: 1588-aware Capability TLV

   Where:

   Type, 16 bits: 1588-aware Capability TLV where physical
   path for Timing messages from master clock to slave Clock and vice
   versa must be the same for all Event Timing messages listed in
   section 7.

   Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost
   Multipath).

10.  PHP

   To ensure that the value is TBD
   Length, 16 bits: Gives label on the length top of the flags field in octets, and
   is currently set to 1

   Flags, 8 bits: The bits are defined least-significant-bit (LSB)
   first, so bit 7 label stack is the least significant bit of the flags octet.

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |   Reserved  |C|
      +-+-+-+-+-+-+-+-+

     Figure 4: Flags Format

   Correction (C) field Update field, 1 bit: Setting Timing
   LSP Label, PHP MUST not be used.

11.  Entropy

   To ensure all Timing messages in a Timing LSP take the C bit to 1
   indicates that same path,
   Entropy MUST NOT be used for the link is capable of recognizing Timing LSP [mpls-entropy] and
   Entropy MSUT NOT be used for the PTP event
   packets PWs that are carried inside Timing
   LSP [RFC6391].

12.  OAM, Control and Management

   IIn order to manage Timing LSPs and their encapsulated PWs, they MUST
   be able to carry OAM and management messages.  These management
   messages MUST be differentiated from Timing messages via already
   defined IETF methods.

   For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY run
   over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH.  These
   Management protocols can compensate for residence time easily be identified by updating the PTP
   packet Correction Field.  When this is set to 0, it means that this
   link cannot perform UDP Destination
   Port number or by GAL/ACH respectively.

   Also BFD, LSP-Ping and other management messages MAY run over the residence time correction but is capable of
   performing MPLS frame forwarding PWs
   encapsulated in Timing LSP via one of the frames with PTP labels using
   a method defined VCCVs (Type 1, 3 or
   4) [RFC5085] (note that support the end to end delivery of accurate timing.
   The exact method VCCV Type 2 using Router Alert Label is not defined herein.

   Reserved, 7 bits: Reserved for future use.  The reserved bits must going
   to be
   ignored deprecated by the receiver.

   The 1588-aware Capability sub-TLV IETF).  In this case G-ACH, PW label (TTL=1) or
   GAL-ACH are used to identify such management messages.

13.  QoS Considerations

   In network deployments where not every LSR/LER is Timing-aware, it is applicable
   important to both OSPFv2 and
   OSPFv3.

14.2.  1588aware Link Capability for IS-IS

   The IS-IS Traffic Engineering [RFC3784] defines reduce the intra-area
   traffic engineering enhancements impact of the non-Timing-aware LSR/LERs on
   the timing recovery in the slave clock.  The Timing messages are time
   critical and uses must be treated with the Extended IS
   Reachability TLV (Type 22) [RFC5305] to carry highest priority.  Therefore
   Timing over MPLS messages must be treated with the per link TE-related
   information. highest priority
   in the routers.  This extension defines a new 1588-aware capability sub-
   TLV that can be carried as part achieved by proper setup of the Extended IS Reachability TLV.

   The 1588-aware capability sub-TLV Timing LSPs.

   It is OPTIONAL and MUST NOT appear
   more than once within recommended that the Extended IS Reachability TLV Timing LSPs are setup or configured
   properly to indicate EF-PHB [RFC3246]for the Multi-
   Topology (MT) Intermediate Systems TLV (type 222) specified in
   [RFC5120].  If a second instance of the 1588-aware capability sub-TLV CoS and Green [RFC2697]
   for drop eligibility.

14.  FCS Recalculation

   When timestamp generation and timing packet adjustment is present, performed
   near the receiving system MUST only process physical port hardware, the first instance process MUST include
   recalculation of the sub-TLV.

   The format Ethernet FCS.  Also FCS retention for the
   payload Ethernet described in [RFC4720] MUST NOT be used.

15.  UDP Checksum Correction

   For UDP/IP encapsulation mode of Timing over MPLS, the IS-IS 1588-aware sub-TLV UDP checksum
   is identical to the TLV
   format optional when used by the Traffic Engineering Extensions to IS-IS [RFC3784].
   That is, the TLV is comprised of 1 octet for the type, 1 octet
   specifying the TLV length, IPv4 encapsulation and a value field.  The Length field
   defines the length of the value portion mandatory in octets.

      0                    1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Length    |    Flags      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 5: 1588-aware Capability sub-TLV

   Where:

   Type, 8 bits: 1588-aware Capability sub-TLV where the value is TBD

   Length, 8 bits: Gives the length case of the flags field in octets, and is
   currently set to 1

   Flags, 8 bits: The bits are defined least-significant-bit (LSB)
   first, so bit 7
   IPv6.

   When UDP checksum is used, each Timing-aware LER/LSR must either
   incrementally update the UDP checksum after Time stamping or
   Correction Field update or verify the least significant bit of UDP checksum on reception from
   upstream and recalculate the flags octet.

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |   Reserved  |C|
      +-+-+-+-+-+-+-+-+

     Figure 6: Flags Format checksum completely on transmission to
   downstream node after Time stamping or Correction (C) field Update field, 1 bit: Setting the C bit Field update.

16.  Routing extensions for Timing-aware Routers

   MPLS-TE routing relies on extensions to 1
   indicates that the 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 capable of recognizing useful to advertise data plane TE router link
   capabilities, such as the PTP event
   packets and can compensate capability for residence time by updating the PTP
   packet Correction Field.  When this is set a router to 0, it means be Timing-aware.
   This capability MUST then be taken into account during path
   computation to prefer or even require links that advertise themselves
   as Timing-aware.  In this
   link cannot way the path can ensure the entry and exit
   points into the LERs and, if desired, the links into the LSRs are
   able to perform port based timestamping thus minimizing their impact
   on the residence time correction but is capable of
   performing MPLS frame forwarding performance of the frames with PTP labels using
   a method that support the end slave clock.

   extensions are required to OSPF and IS-IS in order to end delivery advertise
   Timing-aware capabilities of accurate timing.
   The exact method is not defined herein.

   Reserved, 7 bits: Reserved for future use.  The reserved bits must be
   ignored by a link.  Such extensions are outside the receiver.

15.  RSVP-TE Extensions for support
   scope of 1588

   RSVP-TE signaling MAY this document; however such extension SHOULD be used to setup the PTP LSPs.  A new RSVP
   object is defined able to
   signal that this is a PTP LSP.  The OFFSET to the start following information per Router Link:

   o  Capable of the PTP message header processing PTP, NTP or other Timing flows

   o  Capable of performing Transparent Clock operation

   o  Capable of performing Boundary Clock operation

17.  Signaling Extensions for Creating Timing LSPs

   RSVP-TE signaling MAY also be signaled.
   Implementations can trivially locate the correctionField (CF)
   location given this information.  The OFFSET points to the start of
   the PTP header as a node may want used to check the PTP messageType before
   it touches setup the correctionField (CF).  The OFFSET timing LSPs.  When RSVP-TE
   is counted from TBD

   The LSRs that receive and process the RSVP-TE/GMPLS messages MAY use
   the OFFSET used to locate the start of the PTP message header.

   Note setup Timing LSPs, some information that indicates that
   the new object/TLV Must LSP is carrying Timing flows MUST be ignored by LSRs that are not
   compliant included in the new
   Extensions to this specification. RSVP-TE:

   The new RSVP 1588_PTP_LSP object should following information MAY also be included in signaling PTP
   LSPs and is defined as follows:

                   0             1             2             3
            +-------------+-------------+-------------+-------------+
            |       Length (bytes)      |  Class-Num  |   C-Type    |
            +-------------+-------------+-------------+-------------+
            | the new Extensions
   to RSVP-TE:

   o  Offset from Bottom of Stack (BoS) to locate the start of the PTP message header  |
            +-------------+-------------+-------------+-------------+

                     Figure 7: RSVP 1588_PTP_LSP object

   The ingress LSR MUST include this object Timestamp
      field

   o  Number of VLANs in case of PW encapsulation

   o  Timestamp field Type

      *  Correction Field, Timestamp

   o  Timestamp Field format

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

   Note that in case the RSVP PATH Message.
   It above optional information is just signaled with
   RSVP-TE for a normal RSVP path Timing LSP, all the Timing packets carried in that LSP
   must have the same signaled characteristics.  For example if
   Timestamp format is exclusively set up for PTP
   messages

16. signaled as 64-bit PTPv1, then all Timing packets
   must use 64-bit PTPv1 timestamp.

18.  Behavior of LER/LSR

16.1.  Behavior of 1588-aware LER

   A 1588-aware LER advertises it's 1588-awareness

   Timing-capable/aware LERs and LSRs are routers that have one or more
   interfaces that can perform Timing operations (OC/BC/TC) on Timing
   packets and are configured to do so.  Timing-capable/aware LERs and
   LSRs can advertise their Timing-capability per-interface via the control
   plane such as OSPF
   procedure explained or IS-IS.  The Timing-capable/aware LERs can then
   signals Timing LSPs via RSVP-TE signaling.  Alternatively the Timing
   capability of LER and LSRs may be configured in earlier section a centralized
   controller and the Timing LSP may be setup using manual configuration
   or other methods such as SDN.

18.1.  Behavior of this specification.  The
   1588-aware Timing-capable/aware LER then signals PTP LSPs by including the 1588_PTP_LSP
   object in the RSVP-TE signaling.

   When a 1588 Timing-capable/aware LER behaves as a Transparent clock and
   receives a Timing message is received from a Timing-capable/aware non-MPLS
   interface, the LER
   MUST redirect them to a updates the Correction Field (CF) and encapsulates
   and forwards the timing message over previously established PTP Timing
   LSP.  When  Also when a 1588
   over MPLS Timing message is received from an a Timing-capable/
   aware MPLS interface, LER updates the processing
   is similar to 1588-aware LSR processing.

16.2.  Behavior of 1588-aware LSR

   1588-aware LSRs are LSRs that understand Correction Filed (CF) and
   decapsulates the 1588_PTP_LSP RSVP object MPLS encapsulation and can perform 1588 processing (e.g.  Transparent Clock processing).

   A 1588-aware LSR advertises it's 1588-awareness via forwards the OSPF
   procedure explained in earlier section of this specification. timing message
   to a non-MPLS interface.

   When a 1588-aware LSR distributes Timing-capable/aware LER behaves as a label for PTP LSP, it maintains
   this information.  When the 1588-aware LSR Boundary clock and
   receives an MPLS packet,
   it performs a label lookup and if Timing message from a Timing-capable/aware non MPLS
   interface, the label lookup indicates LER Timestamps the Timing packet and sends it is a
   PTP label then further parsing must be done to positively identify
   that the payload is 1588 and not OAM, BFD or control and management.
   Ruling out non-1588 messages can easily be done
   LERs Boundary clock processing module.  Also when parsing
   indicates a Timing message is
   received from a Timing- capable/aware MPLS interface, the presence of GAL, ACH or VCCV (Type 1, 2, 3) or when LER
   Timestamps the
   UDP port number does not match one of Timing packet and sends it to the 1588 UDP port numbers.

   After LERs Boundary clock
   processing module.

   When a 1588 Timing-capable/aware LER behaves as an Ordinary Clock toward
   the MPLS network, and receives a Timing message is positively identified in from a PTP LSP, Timing-
   capable/aware MPLS interface, the PTP
   message type indicates whether any timestamp processing is required.
   After 1588 processing LER Timestamps the Timing packet is forwarded
   and sends it to the LERs Ordinary clock processing module.

18.2.  Behavior of Timing-capable/aware LSR

   A Timing-capable/aware LSR behaves as a normal 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 packet
   to downstream node.

16.3. interface.

18.3.  Behavior of non-1588-aware non-Timing-capable/aware LSR

   It is most beneficial that when all LSRs in the path of a PTP Timing LSP be 1588-
   aware
   timing-Capable/aware LSRs.  This would ensure the highest quality
   time and clock synchronization by 1588 Timing Slave Clocks.  However, this
   specification does not mandate that all LSRs in path of a PTP Timing LSP
   be 1588-aware.

   Non-1588-aware LSRs are LSRs that either don't have the capability to
   process 1588 packets (e.g. perform Transparent Clock processing) or
   don't understand the 1588_PTP_LSP RSVP object.

   Non-1588-aware Timing- capable/aware.

   Non-Timing-capable/aware LSRs ignore the RSVP 1588_PTP_LSP object and just switch the MPLS packets carrying 1588 messages as data packets encapsulated in
   Timing LSPs and
   don't dont perform any timestamp related processing. Timing operation (TC).  However as
   explained in QoS section the 1588 Timing8 over MPLS packets MUST be still
   be treated with the highest priority.

17. priority based on their Traffic Class
   (TC) marking.

19.  Other considerations

   [IEEE] Tdefines an optional peer-to-peer Transparent clocking that
   requires peer delay measurement between two adjacent Timing-capable/
   ware routers/switches.  Peer delay measurement messages need to be
   time stamped and terminated by the Timing-capable/aware routers/
   switches.  This means that two adjacent LSRs may be engaged in a peer
   delay measurement.  Such peer delay measurement messages SHALL NOT
   use the Timing LSP that runs between two LERs.  For transporting such
   peer delay measurement messages there are two options.  Either a
   single-hop LSP needs to be created between the two adjacent LSRs
   engaged in peer delay measurement to carry peer delay measurement
   messages, or other methods such as PTP transport over Ethernet may be
   used for transporting peer delay measurement messages if the link
   between the two routers is Ethernet.

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

   The use of Penultimate Hop Pop (PHP) is acceptable as long as either
   the PHP label

20.  Security Considerations

   MPLS PW security considerations in general are discussed in [RFC3985]
   and [RFC4447],and those considerations also apply to this document.

   An experimental security protocol is the bottom of stack label (applicable only defined in [IEEE].The PTP
   security extension and protocol provides group source authentication,
   message integrity, and replay attack protection for PTP messages.

21.  Applicability Statement

   The Timing over MPLS transport methods described in this document
   apply to UDP/IP
   encapsulation) or the label below the PHP label is following network Elements:

   o  An LER receives IP or Ethernet Encapsulated Timing messages from a PTP label.

18.  Security Considerations
      non-MPLS interface and forwards them as MPLS encapsulated Timing
      messages over Timing LSP, while performing Transparent Clock
      functionality

   o  An LER receives MPLS PW security considerations in general are discussed in [RFC3985] encapsulated Timing messages from a Timing
      LSP and [RFC4447],and those considerations also apply forwards them to this document. non-MPLS interface as IP or Ethernet
      Encapsulated Timing messages, while performing Transparent Clock
      functionality

   o  An experimental security protocol is defined in [IEEE].  The PTP
   security extension LER receives MPLS encapsulated Timing messages from a Timing
      LSP and protocol provides group source authentication,
   message integrity, terminates them, while performing the OC or BC
      functionality

   o  An LSR receives MPLS encapsulated Timing messages from a Timing
      LSP and replay attack protection for PTP messages.

19. forwards them to another MPLS interface, while performing
      the TC functionality

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

22.  Acknowledgements

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

20.  IANA Considerations

20.1.  IANA Considerations for OSPF

   IANA has defined a sub-registry for the sub-TLVs carried in an OSPF
   TE Link TLV (type 2).  IANA is requested to assign a new sub-TLV
   codepoint for the 1588aware capability sub-TLV carried within the
   Router Link TLV.

      Value            Sub-TLV                   References
      -----     ----------------------           ----------
       TBD       1588aware node sub-TLV        (this document)

20.2.

23.  IANA Considerations for IS-IS

   There are no IANA has defined a sub-registry for the sub-TLVs carried requirements in the IS-IS
   Extended IS Reacability TLV.  IANA is requested to assign a new sub-
   TLV code-point for the 1588aware capability sub-TLV carried within
   the Extended IS Reacability TLV.

      Value            Sub-TLV                   References
      -----     ----------------------           ----------
       TBD       1588aware node sub-TLV        (this document)

20.3.  IANA Considerations for RSVP

   IANA is requested to assign a new Class Number for 1588 PTP LSP
   object that is used to signal PTP LSPs.

   1588 PTP LSP Object

   Class-Num of type 11bbbbbb

   Suggested value TBD

   Defined CType: 1 (1588 PTP LSP)

21. this specification.

24.  References

21.1.

24.1.  Normative References

   [IEEE]     IEEE 1588-2008, "IEEE Standard for a Precision Clock
              Synchronization Protocol for Networked Measurement and
              Control Systems".

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC4389]  Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
              Proxies (ND Proxy)", RFC 4389, April 2006.

   [RFC4447]  Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
              Heron, "Pseudowire Setup and Maintenance Using the Label
              Distribution Protocol (LDP)", RFC 4447, April 2006.

   [RFC4448]  Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
              "Encapsulation Methods for Transport of Ethernet over MPLS
              Networks", RFC 4448, April 2006.

   [RFC4720]  Malis, A., Allan, D., and N. Del Regno, "Pseudowire
              Emulation Edge-to-Edge (PWE3) Frame Check Sequence
              Retention", RFC 4720, November 2006.

   [RFC5085]  Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
              Connectivity Verification (VCCV): A Control Channel for
              Pseudowires", RFC 5085, December 2007.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, June 2010.

   [RFC5884]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
              "Bidirectional Forwarding Detection (BFD) for MPLS Label
              Switched Paths (LSPs)", RFC 5884, June 2010.

21.2.

24.2.  Informative References

   [I-D.ietf-pwe3-fat-pw]
              Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
              J., and S. Amante, "Flow Aware Transport of Pseudowires
              over an MPLS Packet Switched Network",
              draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011.

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

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, December 1990.

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

   [RFC2697]  Heinanen, J. and R. Guerin, "A Single Rate Three Color
              Marker", RFC 2697, September 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, 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.

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

   [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
              Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, June 2010.

   [RFC6391]  Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
              J., and S. Amante, "Flow-Aware Transport of Pseudowires
              over an MPLS Packet Switched Network", RFC 6391,
              November 2011.

Authors' Addresses

   Shahram Davari
   Broadcom Corp.
   San Jose, CA  95134
   USA

   Email: davari@broadcom.com

   Amit Oren
   Broadcom Corp.
   San Jose, CA  95134
   USA

   Email: amito@broadcom.com

   Manav Bhatia
   Alcatel-Lucent
   Bangalore,
   India

   Email: manav.bhatia@alcatel-lucent.com

   Peter Roberts
   Alcatel-Lucent
   Kanata,
   Canada

   Email: peter.roberts@alcatel-lucent.com

   Laurent Montini
   Cisco Systems
   San Jose CA
   USA

   Email: lmontini@cisco.com