Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls

"Shahram Davari" <davari@broadcom.com> Fri, 02 August 2013 13:42 UTC

Return-Path: <davari@broadcom.com>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2AE21E80AA; Fri, 2 Aug 2013 06:42:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mrat-QwE5wud; Fri, 2 Aug 2013 06:42:40 -0700 (PDT)
Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9747D11E8321; Fri, 2 Aug 2013 06:42:35 -0700 (PDT)
Received: from [10.9.208.57] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 02 Aug 2013 06:32:28 -0700
X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF
Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.14) by IRVEXCHCAS08.corp.ad.broadcom.com (10.9.208.57) with Microsoft SMTP Server (TLS) id 14.1.438.0; Fri, 2 Aug 2013 06:42:19 -0700
Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS06.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Fri, 2 Aug 2013 06:42:19 -0700
From: Shahram Davari <davari@broadcom.com>
To: John E Drake <jdrake@juniper.net>
Thread-Topic: [mpls] Comments on draft-ietf-tictoc-1588overmpls
Thread-Index: AQHOj2dsoD26UTw5FECSgmrxo5m7wJmBtd9EgAB9NYD//7pTBA==
Date: Fri, 02 Aug 2013 13:42:18 +0000
Message-ID: <BD041262-27FA-4C2B-888C-9F7DC2D99794@broadcom.com>
References: <51FB8396.9020504@cisco.com> <D2796BF4-4DDB-4816-B730-1289CAB11080@broadcom.com>, <0182DEA5604B3A44A2EE61F3EE3ED69E2076CBA4@BL2PRD0510MB349.namprd05.prod.outlook.com>
In-Reply-To: <0182DEA5604B3A44A2EE61F3EE3ED69E2076CBA4@BL2PRD0510MB349.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
MIME-Version: 1.0
X-WSS-ID: 7DE56B662L870061941-01-01
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: "mpls@ietf.org" <mpls@ietf.org>, "tictoc-chairs@tools.ietf.org" <tictoc-chairs@tools.ietf.org>, "tictoc@ietf.org" <tictoc@ietf.org>, "draft-ietf-tictoc-1588overmpls@tools.ietf.org" <draft-ietf-tictoc-1588overmpls@tools.ietf.org>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>, "int-ads@tools.ietf.org" <int-ads@tools.ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tictoc>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Aug 2013 13:42:47 -0000

Hi John

In that case I fail to understand the difference between your proposal and the current draft.

In both cases you need a special LSP to tell the HW to Timestamp the packet and I assume you need to use RSVPTE to sign it. That is what the draft does.

Regards,
Shahram


On Aug 2, 2013, at 12:52 PM, "John E Drake" <jdrake@juniper.net> wrote:

> Shahram,
> 
> The LSPs would be between LSRs that are 1588 capable, so they could be one or more hops.
> 
> Yours Irrespectively,
> 
> John
> 
> 
>> -----Original Message-----
>> From: Shahram Davari [mailto:davari@broadcom.com]
>> Sent: Friday, August 02, 2013 3:24 AM
>> To: <stbryant@cisco.com>
>> Cc: mpls-chairs@tools.ietf.org; tictoc-chairs@tools.ietf.org; int-
>> ads@tools.ietf.org; rtg-ads@tools.ietf.org; draft-ietf-tictoc-
>> 1588overmpls@tools.ietf.org; John E Drake; mpls@ietf.org;
>> tictoc@ietf.org
>> Subject: Re: [mpls] Comments on draft-ietf-tictoc-1588overmpls
>> 
>> Hi Stewart
>> 
>> We have already looked at similar approach. The issue with one hop LSP
>> is that not all LSRs are 1588 capable. One of the requirements is for
>> non-1588 capable routers to just switch the packet normally.
>> 
>> Regards,
>> Shahram
>> 
>> 
>> On Aug 2, 2013, at 12:02 PM, "Stewart Bryant" <stbryant@cisco.com>
>> wrote:
>> 
>>> Talking to John Drake about this, an alternative general
>>> model is for the LSP is that it is an LSP that timestamps
>>> the packet and then passes it to an application associated
>>> with the LSP at that hop.
>>> 
>>> This has a lot of merit.
>>> 
>>> If however we think about it some more we have a
>>> type of network service chaining going on here and
>>> so we don't need an LSP per say, because the path
>>> and instruction can be in the packet.
>>> 
>>> In other words a general solution  to the problem
>>> is to define an LSP with the properties that the
>>> packet is passed one hop, timestamped and delivered
>>> to the associated application.
>>> 
>>> How this is MPLS construct is used to support time
>>> tranfer is entirely within the scope of TICTOC, but
>>> at the MPLS layer we have a clean reusable network
>>> service.
>>> 
>>> - Stewart
>>> 
>>> 
>>> ============
>>> SB> This draft does not seem to provide a precise definition
>>> SB> the properties of the new LSP type that it wishes to
>>> SB> define, in particular it does it define the PHB of those
>>> SB> LSPs, nor the full interaction with the MPLS
>>> SB> architecture.
>>> SB>
>>> SB> I have not tracked TICTOC for a while but I thought that
>>> SB> the original plan was to define the concept of an offset
>>> SB> into a packet to do the correction.
>>> SB>
>>> SB> It is disappointing that the opportunity was not taken
>>> SB> to define a timing shim inside the timing LSP so that
>>> SB> a time correction could be added to any packet such that
>>> SB> the MPLS system was isolated from the details of the
>>> SB> complexity of the particular time transfer type.
>>> 
>>> SB> I think that much more clarify is needed in terms of
>>> SB> definition of the new LSP type, since it is unclear
>>> SB> from this text how to implement one.
>>> SB>
>>> SB> There are a lot of other MPLS services such as
>>> SB> LSP ping that need to be considered.
>>> SB>
>>> SB> Please see inline for more comments. However these
>>> SB> comments are made in the context of the text as written
>>> SB> whilst I have a fundamental concern that this approach
>>> SB> lacks an MPLS architectural soundness that need
>>> SB> greater thought with significant impact on the
>>> SB> draft.
>>> 
>>> - Stewart
>>> 
>>> 
>>> TICTOC Working Group                                           S.
>> Davari
>>> Internet-Draft                                                   A.
>> Oren
>>> Intended status: Standards Track                          Broadcom
>> Corp.
>>> Expires: December 17, 2013                                     M.
>> Bhatia
>>>                                                             P.
>> Roberts
>>>                                                         Alcatel-
>> Lucent
>>>                                                             L.
>> Montini
>>>                                                             L.
>> Martini
>>>                                                          Cisco
>> Systems
>>>                                                          June 15,
>> 2013
>>> 
>>> 
>>>           Transporting Timing messages over MPLS Networks
>>>                  draft-ietf-tictoc-1588overmpls-05
>>> 
>>> Abstract
>>> 
>>>  This document defines the method for transporting Timing messages
>>>  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
>>> 
>>> SB> What is a port
>>> 
>>>  level processing of these PDUs in both LERs and LSRs.
>>> 
>>>  The basic idea is to transport Timing messages inside dedicated
>> MPLS
>>>  LSPs.  These LSPs only carry Timing messages and possibly Control
>> and
>>>  Management packets, but they do not carry customer traffic.
>>> 
>>> SB> More specifically they only carry traffic associated with the
>>> SB> timing service and its support.
>>> SB> The question arose WRT BFD - surely BFD is allowed, BUT surely
>>> SB> also it gets carried in a structure that causes it to get
>>> SB> timestamped.
>>> 
>>>  Two methods for transporting Timing messages over MPLS are defined.
>>> 
>>> SB> Perhaps the right approach is to define the new LSP type and then
>>> SB> seperately to define  the mapping of the various timing services
>>> SB> over that LSP type.
>>> 
>>>  The first method is to transport Timing messages directly over the
>>>  dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for
>>>  MPLS networks.  The second method is to transport Timing messages
>>>  inside a PW via Ethernet encapsulation.
>>> 
>>> SB> I think that we should note that there are some
>>> SB> h/w reasons for this preference. A clean sheet approach
>>> SB> would have been to use PTP over MPLS with no intermediate
>>> SB> layers.
>>> 
>>> 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 December 17, 2013.
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013               [Page
>> 1]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> Copyright Notice
>>> 
>>>  Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . .
>> 5
>>> 
>>>  2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .
>> 7
>>> 
>>>  3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .
>> 8
>>> 
>>>  4.  Timing over MPLS Architecture  . . . . . . . . . . . . . . . .
>> 9
>>> 
>>>  5.  Dedicated LSPs for Timing messages . . . . . . . . . . . . . .
>> 12
>>> 
>>>  6.  Timing over LSP Encapsulation  . . . . . . . . . . . . . . . .
>> 13
>>>    6.1.  Timing over UDP/IP over MPLS Encapsulation . . . . . . . .
>> 13
>>>    6.2.  Timing over PW Encapsulation . . . . . . . . . . . . . . .
>> 13
>>>    6.3.  Other Timing Encapsulation methods . . . . . . . . . . . .
>> 14
>>> 
>>>  7.  Timing message Processing  . . . . . . . . . . . . . . . . . .
>> 15
>>> 
>>>  8.  Protection and Redundancy  . . . . . . . . . . . . . . . . . .
>> 16
>>> 
>>>  9.  ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
>> 17
>>> 
>>>  10. PHP  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
>> 18
>>> 
>>>  11. Entropy  . . . . . . . . . . . . . . . . . . . . . . . . . . .
>> 19
>>> 
>>>  12. OAM, Control and Management  . . . . . . . . . . . . . . . . .
>> 20
>>> 
>>>  13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . .
>> 21
>>> 
>>>  14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . .
>> 22
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013               [Page
>> 2]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>>  15. Behavior of LER/LSR  . . . . . . . . . . . . . . . . . . . . .
>> 23
>>>    15.1. Behavior of Timing-capable/aware LER . . . . . . . . . . .
>> 23
>>>    15.2. Behavior of Timing-capable/aware LSR . . . . . . . . . . .
>> 23
>>>    15.3. Behavior of non-Timing-capable/aware LSR . . . . . . . . .
>> 24
>>> 
>>>  16. Other considerations . . . . . . . . . . . . . . . . . . . . .
>> 25
>>> 
>>>  17. Security Considerations  . . . . . . . . . . . . . . . . . . .
>> 26
>>> 
>>>  18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .
>> 27
>>> 
>>>  19. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .
>> 28
>>> 
>>>  20. References . . . . . . . . . . . . . . . . . . . . . . . . . .
>> 29
>>>    20.1. Normative References . . . . . . . . . . . . . . . . . . .
>> 29
>>>    20.2. Informative References . . . . . . . . . . . . . . . . . .
>> 29
>>> 
>>>  Appendix 1.  Routing extensions for Timing-aware Routers . . . . .
>> 32
>>> 
>>>  Appendix 2.  Signaling Extensions for Creating Timing LSPs . . . .
>> 33
>>> 
>>>  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .
>> 34
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013               [Page
>> 3]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>>  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].
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013               [Page
>> 4]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> 1.  Introduction
>>> 
>>>  The objective of Precision Time Protocol (PTP) and Network Timing
>>>  Protocol (NTP) are to synchronize independent clocks running on
>>>  separate nodes of a distributed system.
>>> 
>>>  [IEEE-1588] defines PTP messages for frequency, phase and time
>>>  synchronization.  The PTP messages include PTP PDUs over UDP/IP
>>>  (Annex D and E of [IEEE-1588]) and PTP PDUs over Ethernet (Annex F
>> of
>>>  [IEEE-1588]).
>>> 
>>> SB> Sure BUT it is acknowledged that IEEE is open to the definition
>>> SB> of other PTP mappings if they provide better optimisation.
>>> 
>>>  This document defines mapping and transport of the PTP
>>>  messages defined in [IEEE-1588] over MPLS/MPLS-TP networks.  PTP
>>>  defines several clock types: ordinary clocks, boundary clocks, end-
>>>  to-end transparent clocks, and peer-to-peer transparent clocks.
>>>  Transparent clocks require intermediate nodes to update correction
>>>  field inside PTP message that reflects the transit time in the
>> node.
>>> 
>>>  [RFC5905] defines NTP messages for clock and time synchronization.
>>>  The PTP messages (PDUs) are transported over UDP/IP.  This document
>>> SB> Should that be NTP messages?
>>> SB> It needs to be made clear as soon as you introduce NTP that
>>> SB> they use different time representations.
>>> 
>>>  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 Time
>>>  stamp 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.
>>> 
>>> SB> As I recall NTP has no epoch point defined, and I am not sure
>>> SB> where that point is in the case of PTP in this mapping
>>> SB> Hopefully this will get defined in due course.
>>> 
>>>  To facilitate the fast and efficient recognition of Timing messages
>>>  at the port level when the Timing messages are carried over MPLS
>>>  LSPs,
>>> 
>>> SB> Over a new LSP type with time optimied characteristics
>>> 
>>>  this document defines the specific encapsulations that should
>>>  be used.
>>> SB> Hopefully it will also define the PHP
>>> 
>>>  In addition, it can be expected that there will exist LSR/
>>>  LERs where only a subset of the physical ports will have the port-
>>>  based Timing message processing capabilities.
>>> SB> Do you need to clarify that this only works at base and not in
>>> SB> a label heirarchy.
>>> 
>>> 
>>>  In order to ensure
>>>  that the 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 and/or egress
>>>  ports, it becomes more important when using transparent clock
>> capable
>>>  LSRs in the path.
>>> SB> I do not understand the implications of the last
>>> SB> sentences - starting ", it becomes"
>>> 
>>> 
>>>  Port based Timing message processing involves Timing message
>>>  recognition.  Once the Timing messages are recognized they can be
>>>  modified based on the reception or transmission Time-stamp.
>>> 
>>>  This document provides two methods for transporting Timing messages
>>>  over MPLS.  One is applicable to MPLS environment and the other one
>>>  is applicable to MPLS/MPLS-TP environment
>>> 
>>> SB> I think the sentence is incomplete.
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013               [Page
>> 5]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>>  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.
>>> 
>>> SB> It is not clear why this restriction applies.
>>> 
>>>  Timing LSPs can be established statically or via signaling.
>>> SB> s/statically/by provisioning/network management/
>>> 
>>>  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.
>>> 
>>>  When signaling is used to setup the PTP LSP, Extensions to
>> signaling
>>> SB> is it a PTP LSP or a Timing LSP?
>>> 
>>>  protocols (e.g., RSVP-TE) are required for establishing PTP LSPs.
>>>  However such extensions are outside the scope of this document.
>>> 
>>> SB> for mpls-tp GMPLS is the signalling protocol
>>> 
>>>  While the techniques included herein allow for the establishment of
>>>  paths optimized to include Time-stamping capable links, the
>>>  performance of the Slave clocks is outside the scope of this
>>>  document.
>>> 
>>>  At the time of publishing this specification, Transparent Clocking
>>>  (TC) is only defined for PTP.  Therefore at this time any part of
>>>  this specification that talks about Transparent Clocking applies
>> only
>>>  to PTP.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013               [Page
>> 6]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> 2.  Terminology
>>> 
>>>  1588: The timing and synchronization as defined by IEEE 1588.
>>> 
>>> SB> I think that there is a more formal name for the 1588 group
>>> SB> that needs to be used here.
>>> SB> Also do we need to talk about 1588-200? as there is
>>> SB> an update in progress
>>> 
>>>  NTP: The timing and synchronization protocol defined by IETF RFC-
>> 1305
>>>  and RFC-5905.
>>> 
>>>  PTP: The timing and synchronization protocol used by 1588.
>>> SB> need the proper name for 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.
>>> 
>>> SB> I am not sure the reader knows what a port is
>>> 
>>>  Slave Clock: A receiver of 1588 timing from a master clock.
>>> 
>>>  Slave Port: A port on a boundary clock or ordinary clock that is
>>>  receiving timing from a master 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
>>> 
>>> SB> PTP or timing?
>>> 
>>> 
>>>  PTP PW: A PW within a PTP LSP that is dedicated to carry PTP
>>>  messages.
>>> 
>>> SB> Ah I don't think that PWE3 know what one of these is
>>> 
>>>  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
>>> 
>>>  Timing messages: Timing Protocol messages that are exchanged
>> between
>>>  routers in order to establish a synchronized clock.
>>> 
>>> SB> A number of these definitions look like copies of IEEE1588
>>> SB> definitions. We need to provide references and note the
>>> SB> priority of the IEEE base reference.
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013               [Page
>> 7]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> 3.  Problem Statement
>>> 
>>>  [IEEE-1588] has defined methods for transporting PTP messages over
>>>  Ethernet and IP networks.  [RFC5905] has defined the 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)
>>>  functionality in the LER and LSRs in the MPLS network.
>>> 
>>>  There are multiple ways of transporting Timing over MPLS.  However,
>>>  there is a requirement to limit the possible encapsulation options
>> to
>>>  simplify the Timing message identification and processing required
>> at
>>>  the port level.
>>> 
>>>  When Timing-awareness is needed, 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.
>>> 
>>> SB> Have you explained why?
>>> 
>>>  To detect 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 be deterministically identified
>> by
>>>  LSRs because the payload type is a context of the PW label, and the
>>>  PW label and its context are only known to the Edge routers (PEs/
>>>  LERs); LSRs dont know what is a PWs payload (Ethernet, ATM, FR,
>> CES,
>>>  etc).  Even if one restricts an LSP to only carry Ethernet PWs, the
>>>  LSRs dont have the knowledge of whether PW Control Word (CW) is
>>>  present or not and therefore can not deterministically identify the
>>>  payload.
>>> 
>>>  A generic method is defined in this document that does not require
>>>  deep packet inspection at line rate, and can deterministically
>>>  identify Timing messages.  This method can be used to detect Timing
>>>  Messages in both one-step and two-step clock implementations of
>>>  ordinary, boundary and transparent clocks.
>>> 
>>> SB> Needs a ref and I am sure many MPLS specialists will not
>> understand
>>> SB> the msg types.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013               [Page
>> 8]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> 4.  Timing over MPLS Architecture
>>> 
>>>  Timing messages are exchange between Timing ports on ordinary and
>>> 
>>> SB> Have you defined a timing port?
>>> 
>>>  boundary clocks.  Boundary clocks terminate the Timing messages and
>>>  act as master for other boundary clocks or for slave clocks.  End-
>> to-
>>>  End Transparent clocks do not terminate the Timing messages but
>> they
>>>  do modify the contents of the Timing messages as they transit
>> across
>>>  the transparent clock.
>>> 
>>>  Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent
>> Clock
>>> 
>>>  (TC) could be implemented in either LERs or LSRs.
>>> 
>>> SB> LER and LSR need to be expanded
>>> 
>>>  An example is shown in Figure 1, where the LERs act as Ordinary
>> Clock
>>>  (OC) and are the initiating/terminating point for Timing messages.
>>>  The ingress LER encapsulates the Timing messages in Timing LSP and
>>>  the Egress LER terminates the Timing LSP.  The LSRs act as
>>>  Transparent Clock (TC) and just update the Timing field in the
>> Timing
>>>  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 network
>>> 
>>>  Another example is shown in Figure2, where LERs terminate the
>> Timing
>>>  messages received from switch/routers that are outside of the MPLS
>>>  network acting as OC or BC.  In this example LERs regenerate the
>>>  clock and initiate timing messages encapsulated in Timing LSP
>> toward
>>>  the MPLS network, while the LSRs act as Transparent Clock (TC) and
>>>  just update the Timing field in the Timing messages, which are
>>>  already encapsulated in Timing LSPs.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013               [Page
>> 9]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>>    +--------+     +-------+     +-------+     +-------+     +-------
>> -+
>>>    |Switch, |     |       |     |       |     |       |     |Switch,
>> |
>>>    | Router |-----|  LER  |-----|  LSR  |-----|  LER  |-----| Router
>> |
>>>    | OC/BC  |     |  BC   |     |  TC   |     |  BC   |     | OC/BC
>> |
>>>    +--------+     +-------+     +-------+     +-------+     +-------
>> -+
>>> 
>>>    Figure (2) - Deployment example 2 of timing over MPLS network
>>> 
>>> 
>>>  Another example is shown in Figure 3, where LERs do not terminate
>> the
>>>  Timing messages received from switch/routers that are outside of
>> the
>>>  MPLS network acting as OC, TC or BC.  The LERs act as TC and update
>>>  the Timing field in the Timing messages as they transit the LER,
>>>  while encapsulating them in timing LSP.  The LSRs also act as
>>>  Transparent Clock (TC) and just update the Timing field in the
>> Timing
>>>  messages which are already encapsulated in Timing LSPs.
>>> 
>>>     +--------+     +-------+     +-------+     +-------+     +------
>> --+
>>>     |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
>>> 
>>>  Another example is shown in Figure 4, where LERs and LSRs support
>>>  Boundary Clocks.  A single-hop LSP is created between two adjacent
>>>  LSRs engaged in BC operation.  Other methods such as PTP transport
>>>  over Ethernet MAY be used for transporting timing messages if the
>>>  link between the two routers is Ethernet.
>>> 
>>>    +--------+     +-------+     +-------+     +-------+     +-------
>> -+
>>>    |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.  In these cases the
>> MPLS
>>>  domain (maintained by a service provider) may provide timing
>> services
>>>  to multiple customers, each having their own Timing domain.
>>> 
>>>  The Timing over MPLS architecture assumes full mesh of Timing LSPs
>>>  between all LERs supporting this specification.
>>> 
>>> SB> Note sure this is right - the salves surely do not need to
>>> SB> exchange timing amongst themselves
>>> 
>>>  It supports
>>>  Point-to- point (VPWS) and Multipoint (VPLS) services.
>>> 
>>> SB> What does that mean? You do not carry user data traffic?
>>> SB> Maybe it's the ordering of the statemnets that is causing
>>> SB> confusion.
>>> 
>>>  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
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 10]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>>  two customer sites.
>>> 
>>>  The Timing over MPLS architecture supports P2P or P2MP Timing LSPs.
>>>  This means that the Timing Multicast messages such as PTP Multicast
>>>  event messages can be transported over P2MP Timing LSP or be
>>>  replicated and transported over many P2P Timing LSPs.
>>> 
>>> SB> Note we do not yet have a definition of a P2MP mpls-tp LSP
>>> SB> nor a P2MP PW, although we are close.
>>> 
>>>  Timing messages, that do not require Time stamping or Correction
>>>  Field update MAY be transported over Timing LSPs to simplify
>> hardware
>>>  and software.
>>> 
>>>  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.
>>> 
>>> SB> have you defined and referenced PTP announce msgs?
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 11]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> 5.  Dedicated LSPs for Timing messages
>>> 
>>>  Many methods have been considered for identifying the Timing
>> messages
>>>  when they are encapsulated in MPLS such as using GAL/G-ACH or a new
>>>  reserved label.  These methods were not attractive since they
>> either
>>>  required deep packet inspection at line rate in the intermediate
>> LSRs
>>>  or they required use of a scarce new reserved label.  Also one of
>> the
>>>  goals was to reuse existing OAM mechanisms.
>>> 
>>> SB> RLs = SPLs are not so rare now. In any case needs a ref.
>>> 
>>>  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 in the MPLS label stack, which only carry Timing messages as
>>>  well as OAM, but not data plane client traffic.
>>> 
>>>  Compliant implementations MUST use dedicated LSPs to carry Timing
>>>  messages over MPLS.
>>> 
>>> SB> I think that we need a definition of the properies of these LSPs
>>> 
>>>  These LSPs are herein referred to as "Timing
>>>  LSPs" and the labels associated with these LSPs as "Timing LSP
>>>  labels".  The Timing LSPs that runs between Ingress and Egress LERs
>>>  MUST be co-routed.  Alternatively, a single bidirectional co-routed
>>>  LSP can be used.
>>> 
>>> SB> I though that you said you could use M2MP LSPs - these are not
>>> SB> bidirectional.
>>> 
>>>  Co-routing of the two directions is required to limit the
>> difference
>>>  in the delays in the Master clock to Slave clock direction compared
>>>  to the Slave clock to Master clock direction.  The Timing LSP MAY
>> be
>>>  MPLS/MPLS-TP LSP.
>>> 
>>>  The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS.
>>>  New Extensions to RSVP-TE/GMPLS TLVs are required; however they are
>>>  outside the scope of this document.
>>> 
>>>  The Timing LSPs MAY carry essential MPLS/MPLS-TP OAM traffic such
>> as
>>>  BFD and LSP Ping but the LSP data plane client plane traffic MUST
>> be
>>>  Timing packets only.
>>> 
>>> SB> Why?
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 12]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> 6.  Timing over LSP Encapsulation
>>> 
>>> The encapsulations is not LSP is it?
>>> 
>>>  This document defines two methods for carrying Timing messages over
>>>  MPLS.  The first method is carrying UDP/IP encapsulated Timing
>>>  messages over Timing LSPs, and the second method, is carrying
>>>  Ethernet encapsulated Timing messages over Ethernet PWs inside
>> Timing
>>>  LSPs.
>>> 
>>> 6.1.  Timing over UDP/IP over MPLS Encapsulation
>>> 
>>>  The simplest method of transporting Timing messages over MPLS is to
>>>  encapsulate Timing PDUs in UDP/IP and then encapsulate them in
>> Timing
>>>  LSP.  This format is shown in Figure 4.
>>> 
>>> 
>>>                   +----------------------+
>>>                   |   Timing LSP 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.
>>> 
>>> SB> Simple is a judgement call
>>> 
>>>  In order for an LER/LSR to process Timing messages, the Timing LSP
>>>  Label must be at the top label of the label stack.  The LER/LSR
>> MUST
>>>  know that the Timing LSP Label is used for carrying Timing
>> messages.
>>>  This can be accomplished via static configuration or via RSVP-TE
>>>  signaling.
>>> 
>>>  The UDP/IP encapsulation of PTP MUST follow Annex D and E of
>>>  [IEEE-1588].  While the UDP/IP encapsulation of NTP MUST follow
>>>  [RFC5905].
>>> 
>>> 6.2.  Timing over PW Encapsulation
>>> 
>>>  Another method of transporting Timing over MPLS networks is by
>>>  encapsulating Timing PDUs in PW which in turn is transported over
>>>  Timing LSPs.  In case of PTP, Ethernet PW encapsulation [RFC4448],
>>>  shown in Fig 5(A) MUST be used and the Ethernet encapsulation of
>> PTP
>>>  MUST follow Annex F of [IEEE-1588].
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 13]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>>  The RAW mode or Tagged mode defined in [RFC4448] MAY be used and
>> the
>>>  Payload MUST have 0, 1, or 2 VLAN tags (S-VLAN and C-VLAN).  The
>>>  Timing over PW encapsulation MUST use the Control Word (CW) as
>>>  specified in [RFC4448] to ensure proper detection of PTP messages
>>>  inside the MPLS packets for Timing over LSP and Timing over PW
>>>  encapsulation.
>>> 
>>> SB> That needs explanation
>>> 
>>>  The use of Sequence Number in the CW is optional.
>>> 
>>> SB> Given that s/n are never in practice deployed, you could probably
>>> SB> simplify things by sayig that they are not used.
>>> 
>>>  Timing over PW 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(Optional)|  |                |
>>>                    +----------------+  +----------------+
>>>                    |C-VLAN(Optional)|        (B)
>>>                    +----------------+
>>>                    |   Timing PDU   |
>>>                    |                |
>>>                    +----------------+
>>>                           (A)
>>> 
>>>             Figure (5) - Timing over PW Encapsulations
>>> 
>>>  In order for an LSR to process PTP messages, the top label of the
>>>  label stack (the Tunnel Label) MUST be a Timing label.
>>> 
>>> S> You said that before.
>>> 
>>> 6.3.  Other Timing Encapsulation methods
>>> 
>>>  In future other timing encapsulation methods may be introduced,
>> such
>>>  as a new shim header after the Bottom of Stack to carry the Timing
>>>  information.  Such new encapsulations are outside the scope of this
>>>  document.
>>> 
>>> 
>>> SB> Taking a pure MPLS pov, you can simplify a lot of the text
>>> SB> out of the definition of the LSP
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 14]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> SB> I think we need a section on LSP processing
>>> 
>>> 7.  Timing message Processing
>>> 
>>>  Each Timing protocol such as PTP and NTP, define their set of
>> Timing
>>>  messages.  For example PTP defines SYNC, DELAY_REQ, DELAY_RESP,
>>>  FOLLOW_UP, etc messages.
>>> 
>>>  Some of the Timing messages require time stamping or correction
>> field
>>>  update at port level and some dont.  It is the job of the LER/LSR
>> to
>>>  parse the timing message and find out the type of the Timing
>> message
>>>  and decide whether and how to Time- stamp it (e.g., BC) or update
>>>  correction field(e.g., TC).
>>> 
>>> 
>>> SB> AAAAAAAAAAAH. Surely this is the function of the PTP prcessing
>>> SB> function rather than the LER?
>>> 
>>>  For example the following PTP messages (called Event messages)
>>>  require time-stamping or correction field update:
>>> 
>>>  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 be transported over PTP LSPs.  PDELAY_REQ and PDELAY_RESP
>>>  are exchanged between adjacent PTP clocks (i.e.  Master, Slave,
>>>  Boundary, or Transparent) and SHOULD be transported over single hop
>>>  PTP LSPs.  If Two Step PTP clocks are present, then the FOLLOW_UP,
>>>  and PDELAY_RESP_FOLLOW_UP messages MUST also be transported over
>> the
>>>  PTP LSPs.
>>> 
>>>  For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be
>>>  transported over two PTP LSPs that are in opposite directions.
>> These
>>>  PTP LSPs, which are in opposite directions MUST be congruent and
>> co-
>>>  routed.  Alternatively, a single bidirectional co-routed LSP can be
>>>  used.
>>> 
>>>  Except as indicated above for the two-step PTP clocks, Non-Event
>> PTP
>>>  message types do not need to be processed by intermediate routers.
>>>  These message types MAY be carried in PTP Tunnel LSPs.
>>> 
>>> SB> Are you saying that a timing P router has to be msg type
>> sensitive?
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 15]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> 8.  Protection and Redundancy
>>> 
>>> 
>>> SB> This is a bit of a jump - I don't know how the LSP itself works
>> yet!
>>> 
>>>  In 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 responsibility of the network operator to ensure that
>>>  physically disjoint Timing LSPs are established between a slave
>> clock
>>>  (or port) and redundant master clocks (or ports).
>>> 
>>>  When a slave clock (or port) listens to redundant master clocks or
>>>  ports, any prolonged Timing LSP outage will trigger the 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.
>>> 
>>>  Therefore protection switching MAY be used, as long as phase jumps
>>>  upon switchover due to differences in path latency are detected and
>>>  compensated for (such compensation not being required if BCs or
>> peer-
>>>  peer TCs are used throughout).
>>> 
>>>  Note that any protection or reroute mechanism that adds additional
>>>  MPLS label to the label stack, such as Facility Backup Fast
>> Reroute,
>>>  MUST ensure that the pushed label is also a Timing Label to ensure
>>>  recognition of the MPLS frame as containing Timing messages, as it
>>>  transits the backup path.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 16]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> 9.  ECMP
>>> 
>>>  To ensure the optimal operation of slave clocks and avoid error
>>>  introduced by forward and reverse path delay asymmetry, the
>> 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).
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 17]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> 10.  PHP
>>> 
>>>  To ensure that the label on the top of the label stack is the
>> Timing
>>>  LSP Label, PHP MUST not be used.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 18]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> 11.  Entropy
>>> 
>>>  To ensure all Timing messages in a Timing LSP take the same path,
>>>  Entropy Label MUST NOT be used for the Timing LSP[RFC6790] and
>>>  Entropy Label MUST NOT be used for the PWs that are carried inside
>>>  Timing LSP [RFC6391].
>>> 
>>> SB> This is incorrect - you mean that all msgs of the same timing
>>> SB> flow need to have the same EL value.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 19]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> 12.  OAM, Control and Management
>>> 
>>>  In order to monitor 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 easily be identified by the UDP
>> Destination
>>>  Port number or by GAL/G-ACH respectively.
>>> 
>>>  Also BFD, LSP-Ping and other management messages MAY run over the
>> PWs
>>>  encapsulated in Timing LSP via one of the defined VCCVs (Type 1, 3
>> or
>>>  4) [RFC5085] (note that VCCV Type 2 using Router Alert Label is
>> going
>>>  to be deprecated by IETF).  In this case G-ACH, PW label (TTL=1) or
>>>  GAL-ACH are used to identify such management messages.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 20]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> 13.  QoS Considerations
>>> 
>>>  In network deployments where not every LSR/LER is Timing-aware, it
>> is
>>>  important to reduce the impact of the non-Timing-aware LSR/LERs on
>>>  the timing recovery in the slave clock.  The Timing messages are
>> time
>>>  critical and must be treated with the highest priority.  Therefore
>>>  Timing over MPLS messages must be treated with the highest priority
>>>  in the routers.  This can be achieved by proper setup of Timing
>> LSPs.
>>> 
>>>  It is recommended that the Timing LSPs are setup or configured
>>>  properly to indicate EF-PHB [RFC3246]for the CoS and Green
>> [RFC2697]
>>>  for drop eligibility.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 21]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> 14.  FCS and Checksum Recalculation
>>> 
>>>  When time-stamp generation and timing packet adjustment is
>> performed
>>>  near the physical port hardware, the process MUST include
>>>  recalculation of the Ethernet FCS.
>>> 
>>> SB> The above is confusing - an LSR always recomputes the link layer
>>> SB> CRC which may or may not be Ethernet.
>>> 
>>>  Also FCS retention for the
>>>  payload Ethernet described in [RFC4720] MUST NOT be used.
>>> 
>>>  For UDP/IP encapsulation mode of Timing over MPLS, the UDP checksum
>>>  may be required as per UDP transport standards.
>>> 
>>> SB> You really need to be working on getting the IPv6 C?S computation
>>> SB> removed from PTP msgs.
>>> 
>>>  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 UDP checksum on reception
>> from
>>>  upstream and recalculate the checksum completely on transmission to
>>>  downstream node after Time stamping or Correction Field update.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 22]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> 15.  Behavior of LER/LSR
>>> 
>>>  Timing-capable/aware LERs and LSRs are routers that have one or
>> more
>>> 
>>> SB> You mean physical interfaces?
>>> 
>>>  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
>> control
>>>  plane such as OSPF or IS-IS.
>>> SB> ISIS and OSPF are routing protocols.
>>> 
>>> 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 a centralized
>>>  controller and the Timing LSP may be setup using manual
>> configuration
>>>  or other methods such as SDN.
>>> 
>>> SB> it can also be configured individually rather then through
>>> SB> a cebtral controllwe
>>> 
>>> 15.1.  Behavior of Timing-capable/aware LER
>>> 
>>>  When a Timing-capable/aware LER behaves as a Transparent clock and
>>>  receives a Timing message from a Timing-capable/aware non-MPLS
>>>  interface, the LER updates the Correction Field (CF) and
>> encapsulates
>>>  and forwards the timing message over previously established Timing
>>>  LSP.
>>> 
>>> SB> You need to call out the details so that people properly
>>> SB> understand the definition of the new LSP.
>>> 
>>>  Also when a Timing message is received from a Timing-capable/
>>>  aware MPLS interface, LER updates the Correction Filed (CF) and
>>>  decapsulates the MPLS encapsulation and forwards the timing message
>>>  to a non-MPLS interface.
>>> 
>>>  When a Timing-capable/aware LER behaves as a Boundary clock and
>>>  receives a Timing message from a Timing-capable/aware non MPLS
>>>  interface, the LER Timestamps the Timing packet and sends it to the
>>>  LERs Boundary clock processing module.  Also when a Timing message
>> is
>>>  received from a Timing- capable/aware MPLS interface, the LER
>>>  Timestamps the Timing packet and sends it to the LERs Boundary
>> clock
>>>  processing module.
>>> 
>>>  When a Timing-capable/aware LER behaves as an Ordinary Clock toward
>>>  the MPLS network, and receives a Timing message from a Timing-
>>>  capable/aware MPLS interface, the LER Timestamps the Timing packet
>>>  and sends it to the LERs Ordinary clock processing module.
>>> 
>>> 15.2.  Behavior of Timing-capable/aware LSR
>>> 
>>>  When a Timing-capable/aware LSR behaves as a Transparent clock and
>>>  receives a Timing message from a Timing-capable/aware MPLS
>> interface,
>>>  The LSR updates the Correction Filed (CF) and forwards the timing
>>>  message over another MPLS interface.
>>> 
>>>  When a Timing-capable/aware LSR behaves as a Boundary clock and
>>>  receives a Timing message from a Timing-capable/aware MPLS
>> interface.
>>>  The LSR performs the functions of a Boundary Clock in terminating
>> the
>>>  received Timing message and re-generating a new timing message over
>>>  another (or the same) MPLS interface.
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 23]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> 15.3.  Behavior of non-Timing-capable/aware LSR
>>> 
>>>  It is most beneficial when all LSRs in the path of a Timing LSP be
>>>  timing-Capable/aware LSRs.  This would ensure the highest quality
>>>  time and clock synchronization by Timing Slave Clocks.  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 switch the packets encapsulated
>> in
>>>  Timing LSPs and dont perform any Timing operation (TC or BC).
>>>  However as explained in QoS section the Timing over MPLS packets
>> MUST
>>>  be still be treated with the highest priority based on their
>> Traffic
>>>  Class (TC) marking.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 24]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> 16.  Other considerations
>>> 
>>>  [IEEE-1588] defines an optional peer-to-peer Transparent clocking
>>>  that requires peer delay measurement between two adjacent Timing-
>>>  capable/ aware 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.
>>> 
>>>  For transporting such peer delay measurement messages a single-hop
>>>  LSP SHOULD to be created between the two adjacent LSRs engaged in
>>>  peer delay measurement to carry peer delay measurement messages.
>>>  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.
>>> 
>>>  In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/
>> ware
>>>  routers/switches MUST maintain a list of all the neighbors it needs
>>>  to send a PDelay_Req to, where each neighbor corresponds to a
>> timing
>>>  LSP.
>>> 
>>>  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.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 25]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> 17.  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 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 maintain and process each customers clock and
>>>  Timing messages separately from other customers to ensure there is
>> no
>>>  cross- customer effect.  For example if an LER BC is synchronized
>> to
>>>  a specific grandmaster, belonging to customer A, then the LER MUST
>>>  use that BC clock only for customer A to ensure that customer A
>>>  cannot attack other customers by manipulating its time.
>>> 
>>>  Timing messages MAY be encrypted or authenticated, provided that
>> the
>>>  LERs/LSRs that are Timing capable/aware can authenticate/ decrypt
>> the
>>>  timing messages.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 26]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> 18.  Acknowledgements
>>> 
>>>  The authors would like to thank Ron Cohen, Yaakov Stein, Tal
>> Mizrahi,
>>>  Stefano Ruffini, Peter Meyer, and other members of IETF for
>> reviewing
>>>  and providing feedback on this draft.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 27]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> 19.  IANA Considerations
>>> 
>>>  There are no IANA requirements in this specification.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 28]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> 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".
>>> 
>>>  [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.
>>> 
>>> 20.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.
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 29]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>>  [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.
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 30]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>>  [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.
>>> 
>>>  [RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
>>>             L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
>>>             RFC 6790, November 2012.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 31]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> 1.  Routing extensions for Timing-aware Routers
>>> 
>>>  MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340]
>> and
>>>  IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering
>> (TE)
>>>  link information used for constraint-based routing.
>>> 
>>>  Indeed, it is useful to advertise data plane TE router link
>>>  capabilities, such as the capability for a router to 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 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 time-stamping thus minimizing their
>> impact
>>>  on the performance of the slave clock.
>>> 
>>>  extensions are required to OSPF and IS-IS in order to advertise
>>>  Timing-aware capabilities of a link.  Such extensions are outside
>> the
>>>  scope of this document; however such extension 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 Transparent Clock operation
>>> 
>>>  o  Capable of performing Boundary Clock operation
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 32]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> 2.  Signaling Extensions for Creating Timing LSPs
>>> 
>>>  RSVP-TE signaling MAY be used to setup the timing LSPs.  When RSVP-
>> TE
>>>  is used to setup Timing LSPs, some information that indicates that
>>>  the LSP is carrying Timing flows MUST be included in the new
>>>  Extensions to RSVP-TE:
>>> 
>>>  The following information MAY also be included in the new
>> Extensions
>>>  to RSVP-TE:
>>> 
>>>  o  Offset from Bottom of Stack (BoS) to the start of the Time-stamp
>>>     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 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
>>>  Timestamp format is signaled as 64-bit PTPv1, then all Timing
>> packets
>>>  must use 64-bit PTPv1 time-stamp.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 33]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>> 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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 34]
> 
>>> Internet-Draft        Transporting Timing over MPLS            June
>> 2013
>>> 
>>> 
>>>  Luca
>>>  Cisco Systems
>>>  San Jose CA
>>>  USA
>>> 
>>>  Email: lmartini@cisco.com
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Davari, et al.          Expires December 17, 2013              [Page
>> 35]
> 
>>> 
>>> --
>>> For corporate legal information go to:
>>> 
>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>> 
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls
> 
> 
> 
>