[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-davari-tictoc-1588overmpls) 00 01 02 03 04 05 06 07

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


            Transporting Timing messages over MPLS Networks
                   draft-ietf-tictoc-1588overmpls-07

Abstract

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

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

   Two encapsulations methods are defined.  The first transports UDP/IP
   encapsulated timing messages directly over the dedicated LSP.  The
   second transports Ethernet encapsuled timing messages inside an
   Ethernet pseudowire.

Status of This Memo

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

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

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



Davari, et al.           Expires April 18, 2016                 [Page 1]


Internet-Draft        Transporting Timing over MPLS         October 2015


   This Internet-Draft will expire on April 18, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Timing over MPLS Architecture . . . . . . . . . . . . . . . .   5
   5.  Dedicated LSPs for Timing messages  . . . . . . . . . . . . .   7
   6.  Timing over LSP Encapsulation . . . . . . . . . . . . . . . .   8
     6.1.  Timing over UDP/IP over MPLS Encapsulation  . . . . . . .   8
     6.2.  Timing over PW Encapsulation  . . . . . . . . . . . . . .   8
   7.  Timing message Processing . . . . . . . . . . . . . . . . . .   9
   8.  Protection and Redundancy . . . . . . . . . . . . . . . . . .  10
   9.  ECMP and Entropy  . . . . . . . . . . . . . . . . . . . . . .  10
   10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   11. OAM, Control and Management . . . . . . . . . . . . . . . . .  11
   12. QoS Considerations  . . . . . . . . . . . . . . . . . . . . .  11
   13. FCS and Checksum Recalculation  . . . . . . . . . . . . . . .  11
   14. Behavior of LER/LSRs  . . . . . . . . . . . . . . . . . . . .  12
     14.1.  Behavior of Timing-capable/aware LERs/LSRs . . . . . . .  12
     14.2.  Behavior of non-Timing-capable/aware LSR . . . . . . . .  12
   15. Other considerations  . . . . . . . . . . . . . . . . . . . .  13
   16. Security Considerations . . . . . . . . . . . . . . . . . . .  13
   17. Applicability Statement . . . . . . . . . . . . . . . . . . .  14
   18. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   19. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   20. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     20.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     20.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Appendix A.  Appendix . . . . . . . . . . . . . . . . . . . . . .  17
     A.1.  Routing extensions for Timing-aware Routers . . . . . . .  17
     A.2.  Signaling Extensions for Creating Timing LSPs . . . . . .  17



Davari, et al.           Expires April 18, 2016                 [Page 2]


Internet-Draft        Transporting Timing over MPLS         October 2015


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

1.  Introduction

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

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

   The objective of timing distribution protocols, such as Precision
   Time Protocol (PTP) and Network Timing Protocol (NTP), is to
   synchronize clocks running on nodes of a distributed system.

   Timing distribution protocols are presently transported over IP or
   Ethernet.  The present document presents a mechanism for transport
   over Multiprotocol Label Switched (MPLS) networks.  Our solution
   involves transporting timing messages over dedicated "Timing Label
   Switched Paths (LSPs)".  These are ordinary LSPs that carry timing
   messages and MAY carry Operations, Administration and Maintenance
   (OAM) or management messages, but do not carry any other traffic.

   Timing LSPs may be established statically or via signaling.  When
   using signaling, extensions to routing protocols (e.g., OSPF, ISIS)
   are required to enable routers to distribute their timing processing
   capabilities, and extensions to path set up protocols (e.g., RSVP-TE)
   are required for establishing the LSPs.  All such extensions are
   beyond the scope of this document.

   High accuracy timing distribution requires on-path support, e.g.,
   Transparent Clocks (TCs) or Boundary Clocks (BCs), at intermediate
   nodes.  These intermediate nodes need to recognize and appropriately
   process timing distribution packets.  To facilitate efficient
   recognition of timing messages transported over MPLS, this document
   restricts the specific encapsulations to be used.

   [IEEE-1588] defines PTP messages for frequency, phase and time
   synchronization.  PTP messages may be transported over UDP/IP (Annex
   D and E of [IEEE-1588]) or over Ethernet (Annex F of [IEEE-1588]).
   This document defines two methods to transport PTP messages over MPLS
   networks.

   PTP defines several clock types, including ordinary clocks, boundary
   clocks, end-to-end transparent clocks, and peer-to-peer transparent
   clocks.  Transparent clocks are situated at intermediate nodes and




Davari, et al.           Expires April 18, 2016                 [Page 3]


Internet-Draft        Transporting Timing over MPLS         October 2015


   update the Correction Field inside PTP messages in order to reflect
   the time required to transit the node.

   [RFC5905] defines NTP messages for clock and time synchronization.
   NTP messages are transported over UDP/IP.  This document defines a
   method to transport NTP messages over MPLS networks.

   It can be expected that only a subset of LSR ports will be capable of
   processing timing messages.  Timing LSPs MUST be set up (either by
   manual provisioing or via signaling) to traverse these ports.  While
   Timing LSPs are designed to optimize timing distribution, the
   performance of slave clocks is beyond the scope of this document.

   Presently on-path support is only defined for PTP, and therefore much
   of our discussion will focus on PTP.  NTP timing distribution may
   benefit from transport in a Timing LSP due to prioritorization or
   selection of ports or nodes with minimal delay or delay asymmetry.

2.  Terminology

   1588: The timing distribution protocol defined in IEEE 1588.

   Boundary Clock: A device with one timing port to receive timing
   messages and at least one port to re-distribute timing messages.

   CF: Correction Field, a field inside certain PTP messages that holds
   the accumulated transit time.

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

   NTP: The timing distribution protocol defined in RFC 5905.

   Ordinary Clock: A master or slave clock.  Note that ordinary clocks
   have only a single PTP port.

   PTP: Precision Time Protocol.  See 1588.

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

   Timing LSP: An MPLS LSP dedicated to carry timing messages.

   Timing messages: Timing distribution protocol messages that are
   exchanged between clocks.

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




Davari, et al.           Expires April 18, 2016                 [Page 4]


Internet-Draft        Transporting Timing over MPLS         October 2015


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

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

3.  Problem Statement

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

   There are potentially many ways of transporting timing packets over
   MPLS.  However, it is advisable to limit the number of possible
   encapsulation options to simplify recognition and processing of
   timing packets.

   The solution herein desscribed transports timing messages over
   dedicated "Timing Label Switched Paths (LSPs)".  Were timing packets
   to share LSPs with other traffic, intermediate LSRs would be required
   to perform some deeper inspection to differentiate between timing
   packets and other packets.  The method herein proposed avoids this
   complexity, and can readily detect all PTP messages (one-step or two-
   step), and supports ordinary, boundary and transparent clocks.

4.  Timing over MPLS Architecture

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

   OC, BC and TC functionality may be implemented in either LERs or
   LSRs.

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






Davari, et al.           Expires April 18, 2016                 [Page 5]


Internet-Draft        Transporting Timing over MPLS         October 2015


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


   Figure (1) - Deployment example 1 of timing over MPLS network

   Another example is shown in Figure 2, where LERs act as BCs, and
   switches/routers outside of the MPLS network, act as OCs or BCs.  The
   ingress LER BC recovers timing and initiates timing messages
   encapsulated in the Timing LSP toward the MPLS network, an
   intermediate LSR acts as a TC, and the egress LER acts as a BC
   sending timing messages to equipment outside the MPLS network.


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


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

   Yet another example is shown in Figure 3, where both LERs and LSRs
   act as TCs.  The ingress LER updates the CF and encapsulates the
   timing message in an MPLS packet, intermediate LSRs update the CF and
   perform label switching, and the egress LER updates the CF and sends
   the timing messages to equipment outside the MPLS network.


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


   Figure (3) - Deployment example 3 of timing over MPLS network




Davari, et al.           Expires April 18, 2016                 [Page 6]


Internet-Draft        Transporting Timing over MPLS         October 2015


   A final example is shown in Figure 4, where all nodes act as BCs.
   Single-hop LSPs are created between every two adjacent LSRs.  Of
   course, PTP transport over Ethernet MAY be used between two network
   elements.


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


   Figure (4) - Deployment example 3 of timing over MPLS network

   An MPLS domain MAY serve multiple customers, each having its own
   Timing domain.  In these cases the MPLS domain (maintained by a
   service provider) MUST provide dedicated timing services to each
   customer.

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

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

   Timing LSPs, as defined by this specification, MAY be used for timing
   messages that do not require time-stamping or CF updating.

   PTP Announce messages that determine the Timing LSP terminating point
   behavior such as BC/OC/TC SHOULD be transported over the Timing LSP
   to simplify hardware and software.

5.  Dedicated LSPs for Timing messages

   The method defined in this document is used by LER and LSRs to
   identify timing messages by observing the top label of the MPLS label
   stack.  Compliant implementations MUST use dedicated LSPs to carry
   timing messages over MPLS.  Such LSPs are herein referred to as
   "Timing LSPs" and the labels associated with these LSPs as "Timing
   LSP labels".




Davari, et al.           Expires April 18, 2016                 [Page 7]


Internet-Draft        Transporting Timing over MPLS         October 2015


   Timing distribution requires symmetrical bidirectional
   communications.  Co-routing of the two directions is required to
   limit delay asymmetry.  Thus timing messages MUST be transported
   either over two co-routed unidirectional Timing LSPs, or a single
   bidirectional co-routed Timing LSP.

   Timing LSPs MAY be configured using RSVP-TE.  Extensions to RSVP-TE
   are required for this purpose, but are beyond the scope of this
   document.

6.  Timing over LSP Encapsulation

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

6.1.  Timing over UDP/IP over MPLS Encapsulation

   The first method directly encapsulates UDP/IP timing messages in a
   Timing LSP.  The UDP/IP encapsulation of PTP messages MUST comply to
   Annex D and E of [IEEE-1588], and the UDP/IP encapsulation of NTP
   messages MUST comply to [RFC5905].  This format is shown in Figure 4.


                    +----------------------+
                    |   Timing LSP Label   |
                    +----------------------+
                    |        IPv4/6        |
                    +----------------------+
                    |         UDP          |
                    +----------------------+
                    |   timing message     |
                    +----------------------+

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


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

6.2.  Timing over PW Encapsulation

   Another method of transporting timing over MPLS networks is to use
   Ethernet encapsulated timing messages, and to transport these in an
   Ethernet PW which in turn is transported over a Timing LSP.  In the



Davari, et al.           Expires April 18, 2016                 [Page 8]


Internet-Draft        Transporting Timing over MPLS         October 2015


   case of PTP, the Ethernet encapsulation MUST comply to Annex F of
   [IEEE-1588] and the Ethernet PW encapsulation to [RFC4448], resulting
   in the format shown in Figure 5(A).

   Either the Raw mode or Tagged mode defined in [RFC-4448] MAY be used
   and the payload MAY have 0, 1, or 2 VLAN tags.  The Timing over PW
   encapsulation MUST use the Control Word (CW) as specified in
   [RFC4448].  The use of Sequence Number in the CW is optional.

   NTP MAY be transported using an IP PW (as defined in [RFC4447]) as
   shown in Fig 5(B).

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


              Figure (5) - Timing over PW Encapsulations

7.  Timing message Processing

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

   Some timing messages require per-packet processing, such as time-
   stamping or CF updating.  A compliant LER/LSR parses each timing
   message to determine the required processing.

   For example, the following PTP messages (event messages) require
   time-stamping or CF updating:

   o  SYNC




Davari, et al.           Expires April 18, 2016                 [Page 9]


Internet-Draft        Transporting Timing over MPLS         October 2015


   o  DELAY_REQ (Delay Request)

   o  PDELAY_REQ (Peer Delay Request)

   o  PDELAY_RESP (Peer Delay Response)

   SYNC and DELAY_REQ are exchanged between a Master Clock and a Slave
   Clock and MUST be transported over Timing LSPs.  PDELAY_REQ and
   PDELAY_RESP are exchanged between adjacent PTP clocks (master, slave,
   boundary, or transparent) and SHOULD be transported over single hop
   Timing LSPs.  If two-Step PTP clocks are present, then the FOLLOW_UP,
   and PDELAY_RESP_FOLLOW_UP messages MUST also be transported over
   Timing LSPs.

   For a given instance of the 1588 protocol, SYNC and DELAY_REQ MUST be
   transported in opposite directions.  As aforementioned, two co-routed
   unidirectional LSPs or a single bidirectional co-routed LSP MAY be
   used.

   Except as indicated above for two-step PTP clocks, PTP messages that
   are not "event messages" need not be processed by intermediate
   routers.  These message types MAY be carried in PTP Tunnel LSPs.

8.  Protection and Redundancy

   In order to ensure continuous uninterrupted operation of timing
   distribution, slave clocks often track redundant master clocks.
   Prolonged outages of Timing LSPs trigger switching to a redundant
   master clock It is the responsibility of the network operator to
   ensure that physically disjoint Timing LSPs are established between a
   slave clock and redundant master clocks.

   LSP or PW layer protection, such as linear protection Switching, ring
   protection switching or MPLS Fast Reroute (FRR), will lead to changes
   in propagation delay between master and slave clocks.  Such a change,
   if undetected by the slave clock, would negatively impact timing
   performance.  While it is expected that slave clocks will often be
   able to detect such delay changes, this specification RECOMMENDS that
   automatic protection switching NOT be used for Timing LSPs, unless
   the operator can ensure that it will not negatively impact timing
   performance.

9.  ECMP and Entropy

   To ensure the correct operation of slave clocks and avoid error
   introduced by forward and reverse path delay asymmetry, the physical
   path taken by timing messages MUST be the same for all timing




Davari, et al.           Expires April 18, 2016                [Page 10]


Internet-Draft        Transporting Timing over MPLS         October 2015


   messages.  In particular, the PTP event messages listed in section 7
   MUST be routed in the same way.

   Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost
   Multipath).  Entropy labels MUST NOT be used for the Timing LSP
   [RFC6790] and MUST NOT be used for PWs inside the Timing LSP
   [RFC6391].

10.  PHP

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

11.  OAM, Control and Management

   In order to monitor Timing LSPs or PWs, it is necessary to enable
   them to carry OAM messages.  OAM packets MUST be differentiated from
   timing messages by already defined IETF methods.

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

   Also BFD, LSP-Ping and other messages MAY run over Timing PWs via
   VCCV [RFC5085].  In this case these messages are recognized according
   to the VCCV type.

12.  QoS Considerations

   There may be deployments where timing messages traverse LSR/LERs that
   are not capable of the required processing.  In order to minimize the
   negative impact on the timing performance of the slave clock timing
   messages MUST be treated with the highest priority.  This can be
   achieved by proper setup of Timing LSPs.

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

13.  FCS and Checksum Recalculation

   Since Boundary and Transparent Clocks modify packets, when the MPLS
   packets are transported over Ethernet the processing MUST include
   recalculation of the Ethernet FCS.  FCS retention as described in
   [RFC4720] MUST NOT be used.

   For the UDP/IP encapsulation mode, calculation of the UDP checksum
   will generally be required.  After updating the CF a Transparent



Davari, et al.           Expires April 18, 2016                [Page 11]


Internet-Draft        Transporting Timing over MPLS         October 2015


   Clock MUST either incrementally update the UDP checksum or completely
   recalculate the checksum before transmission to downstream node.

14.  Behavior of LER/LSRs

   Timing-aware LERs or LSRs are MPLS routers that are able to recognize
   timing packets.  Timing-capable LERs and LSRs further have one or
   more interfaces that can perform timing processing (OC/BC/TC) on
   timing packets.  Timing-capable/aware LERs and LSRs MAY advertise the
   timing capabilities of their interfaces via control plane protocols
   such as OSPF or IS-IS, and timing-aware LERs can then be set up
   Timing LSPs via RSVP-TE signaling.  Alternatively the timing
   capabilities of LERs and LSRs may be known by a centralized
   controller or management system, and Timing LSPs may be manually
   configured, or set up by a management platform or a Software Defined
   Networking (SDN) controller.

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

   When a timing-capable ingress LER acting as a TC receives a timing
   message packet from a timing-capable non-MPLS interface, the LER
   updates the CF, encapsulates and forwards the packet over a
   previously established Timing LSP.  When a timing-capable egress LER
   acting as a TC receives a timing message packet on timing-capable
   MPLS interface, the LER updates the CF, decapsulates the MPLS
   encapsulation, and forwards the packet via a non-MPLS interface.
   When a timing-capable LSR acting as a TC receives a timing message
   from a timing-capable MPLS interface, the LSR updates the CF and
   forwards the timing message over another MPLS interface.

   When a timing-capable LER acting as a BC receives a timing message
   packet from a timing-capable interface, the LER time-stamps the
   packet and sends it to the BC processing module.

   When a timing-capable LER acting as an OC receives a timing message
   from a timing-capable MPLS interface, the LER time-stamps the packet
   and sends it to the OC processing module.

14.2.  Behavior of non-Timing-capable/aware LSR

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

   Non-timing-capable/aware LSRs just perform label switching on the
   packets encapsulated in Timing LSPs and don't perform any timing



Davari, et al.           Expires April 18, 2016                [Page 12]


Internet-Draft        Transporting Timing over MPLS         October 2015


   related processing.  However, as explained in QoS section, timing
   packets MUST be still be treated with the highest priority based on
   their Traffic Class marking.

15.  Other considerations

   [IEEE-1588] defines an optional peer-to-peer transparent clocking
   (P2P TC) mode that compensates both for residence time in the network
   node and for propagation time on the link between modes.  To support
   P2P TC, delay measurement must be performed between two adjacent
   timing-capable/aware LSRs.  Thus, in addition to the TC functionality
   detailed above on transit PTP timing messages, adjacent peer to peer
   TCs MUST engage in single-hop peer delay measurement.

   For single hop peer delay measurement a single-hop LSP SHOULD be
   created between the two adjacent LSRs.  Other methods MAY be used;
   for example, if the link between the two adjacent routers is
   Ethernet, PTP transport over Ethernet MAY be used.

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

   The use of Explicit Null Label (label 0 or 2) is acceptable as long
   as either the Explicit Null label is the bottom of stack label (for
   the UDP/IP encapsulation) or the label below the Explicit Null label
   (for the PW case).

16.  Security Considerations

   Security considerations for MPLS and pseudowires are discussed in
   [RFC3985] and [RFC4447].  Security considerations for timing are
   discussed in [RFC7384].  Everything discussed in those documents
   applies to the Timing LSP of this document.

   An experimental security protocol is defined in [IEEE-1588].  The PTP
   security extension and protocol provides group source authentication,
   message integrity, and replay attack protection for PTP messages.

   When the MPLS network (provider network) serves multiple customers,
   it is important to distinguish between timing messages belonging to
   different customers.  For example if an LER BC is synchronized to a
   grandmaster belonging to customer A, then the LER MUST only use that
   BC for slaves of customer A, to ensure that customer A cannot
   adversely affect the timing distribution of other customers.






Davari, et al.           Expires April 18, 2016                [Page 13]


Internet-Draft        Transporting Timing over MPLS         October 2015


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

17.  Applicability Statement

   The Timing over MPLS transport methods described in this document
   apply to the following network Elements:

   o  An ingress LER that receives IP or Ethernet encapsulated timing
      messages from a non-MPLS interface and forwards them as MPLS
      encapsulated timing messages over Timing LSP, optionally
      performing TC functionality.

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

   o  An ingress LER that receives MPLS encapsulated timing messages
      from a non-MPLS interface, performs BC functionality, and sends
      timing messages over a Timing LSP.

   o  An egress LER that receives MPLS encapsulated timing messages from
      a Timing LSP, performs BC functionality, and sends timing messages
      over a non-MPLS interface.

   o  An LSR on a Timing LSP that receives MPLS encapsulated timing
      messages from one MPLS interface and forwards them to another MPLS
      interface, optionally performing TC functionality.

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

18.  Acknowledgements

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

19.  IANA Considerations

   There are no IANA requirements in this specification.







Davari, et al.           Expires April 18, 2016                [Page 14]


Internet-Draft        Transporting Timing over MPLS         October 2015


20.  References

20.1.  Normative References

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3985]  Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
              Edge-to-Edge (PWE3) Architecture", RFC 3985,
              DOI 10.17487/RFC3985, March 2005,
              <http://www.rfc-editor.org/info/rfc3985>.

   [RFC4389]  Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
              Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April
              2006, <http://www.rfc-editor.org/info/rfc4389>.

   [RFC4447]  Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
              G. Heron, "Pseudowire Setup and Maintenance Using the
              Label Distribution Protocol (LDP)", RFC 4447,
              DOI 10.17487/RFC4447, April 2006,
              <http://www.rfc-editor.org/info/rfc4447>.

   [RFC4448]  Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
              "Encapsulation Methods for Transport of Ethernet over MPLS
              Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,
              <http://www.rfc-editor.org/info/rfc4448>.

   [RFC4720]  Malis, A., Allan, D., and N. Del Regno, "Pseudowire
              Emulation Edge-to-Edge (PWE3) Frame Check Sequence
              Retention", RFC 4720, DOI 10.17487/RFC4720, November 2006,
              <http://www.rfc-editor.org/info/rfc4720>.

   [RFC5085]  Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual
              Circuit Connectivity Verification (VCCV): A Control
              Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085,
              December 2007, <http://www.rfc-editor.org/info/rfc5085>.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
              <http://www.rfc-editor.org/info/rfc5880>.




Davari, et al.           Expires April 18, 2016                [Page 15]


Internet-Draft        Transporting Timing over MPLS         October 2015


   [RFC5884]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
              "Bidirectional Forwarding Detection (BFD) for MPLS Label
              Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
              June 2010, <http://www.rfc-editor.org/info/rfc5884>.

20.2.  Informative References

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

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

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
              DOI 10.17487/RFC2328, April 1998,
              <http://www.rfc-editor.org/info/rfc2328>.

   [RFC2697]  Heinanen, J. and R. Guerin, "A Single Rate Three Color
              Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999,
              <http://www.rfc-editor.org/info/rfc2697>.

   [RFC3246]  Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
              J., Courtney, W., Davari, S., Firoiu, V., and D.
              Stiliadis, "An Expedited Forwarding PHB (Per-Hop
              Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
              <http://www.rfc-editor.org/info/rfc3246>.

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
              <http://www.rfc-editor.org/info/rfc5340>.

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <http://www.rfc-editor.org/info/rfc5905>.

   [RFC6391]  Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V.,
              Regan, J., and S. Amante, "Flow-Aware Transport of
              Pseudowires over an MPLS Packet Switched Network",
              RFC 6391, DOI 10.17487/RFC6391, November 2011,
              <http://www.rfc-editor.org/info/rfc6391>.






Davari, et al.           Expires April 18, 2016                [Page 16]


Internet-Draft        Transporting Timing over MPLS         October 2015


   [RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
              L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
              RFC 6790, DOI 10.17487/RFC6790, November 2012,
              <http://www.rfc-editor.org/info/rfc6790>.

   [RFC7384]  Mizrahi, T., "Security Requirements of Time Protocols in
              Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
              October 2014, <http://www.rfc-editor.org/info/rfc7384>.

Appendix A.  Appendix

A.1.  Routing extensions for Timing-aware Routers

   MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] and
   IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (TE)
   link information used for constraint-based routing.

   Timing related capabilities, such as the capability for a router to
   perform time-stamping, and OC, TC or BC processing, need to be
   advertised in order for them to be taken into account during path
   computation.  A management system or SDN controller cognizant of
   timing related capabilities, can prefer or even require a Timing LSP
   to traverse links or nodes or intefaces with the required
   capabilities.  The optimal path will optimize the performance of the
   slave clock.

   Extensions are required to OSPF and IS-IS in order to advertise
   timing related capabilities of a link.  Such extensions are outside
   the scope of this document; however such extensions SHOULD be able to
   signal the following information per Router Link:

   o  Capable of processing PTP, NTP or other timing flows

   o  Capable of performing TC operation

   o  Capable of performing BC operation

A.2.  Signaling Extensions for Creating Timing LSPs

   RSVP-TE signaling MAY be used to set up Timing LSPs.  Extensions are
   required to RSVP-TE for this purpose.  Such extensions are outside
   the scope of this document; however, the following information MAY be
   included in such extensions:

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

   o  Number of VLANs in case of PW encapsulation



Davari, et al.           Expires April 18, 2016                [Page 17]


Internet-Draft        Transporting Timing over MPLS         October 2015


   o  Time-stamp field Type

      *  Correction Field, time-stamp

   o  Time-stamp Field format

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

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

Authors' Addresses

   Shahram Davari
   Broadcom Corp.
   San Jose, CA  95134
   USA

   Email: davari@broadcom.com


   Amit Oren
   Broadcom Corp.
   San Jose, CA  95134
   USA

   Email: amito@broadcom.com


   Manav Bhatia
   Alcatel-Lucent
   Bangalore
   India

   Email: manav.bhatia@alcatel-lucent.com


   Peter Roberts
   Alcatel-Lucent
   Kanata
   Canada

   Email: peter.roberts@alcatel-lucent.com




Davari, et al.           Expires April 18, 2016                [Page 18]


Internet-Draft        Transporting Timing over MPLS         October 2015


   Laurent Montini
   Cisco Systems
   San Jose CA
   USA

   Email: lmontini@cisco.com













































Davari, et al.           Expires April 18, 2016                [Page 19]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/