Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A6421F8F97 for ; Tue, 20 Aug 2013 10:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 vGw7CDxh1zBu for ; Tue, 20 Aug 2013 10:01:00 -0700 (PDT) Received: from nm18-vm3.bullet.mail.ne1.yahoo.com (nm18-vm3.bullet.mail.ne1.yahoo.com [98.138.91.148]) by ietfa.amsl.com (Postfix) with ESMTP id EF9F321F8CB4 for ; Tue, 20 Aug 2013 10:00:59 -0700 (PDT) Received: from [98.138.90.49] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 20 Aug 2013 17:00:57 -0000 Received: from [98.138.226.60] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 20 Aug 2013 17:00:57 -0000 Received: from [127.0.0.1] by smtp211.mail.ne1.yahoo.com with NNFMP; 20 Aug 2013 17:00:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1377018057; bh=M0bf6LnX77wu2l/Yao9cgZiMVg5N6yW9OnOa9AClIhU=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:References:Mime-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=pmwnsOf7H3U8mEDAY16GhCQm5kHWl9m2Iai1kzAJBFlRw9X0z5NhIZHd8XfHerukmF0p9D6HPVLTb+fbAahIvaQ2nJKC2Id/FvemKGpKLng2+9IQR51mEnY4SK2+v3uu56/EdSVqHTuIXvdmrVwQF83be4mTn2B/kTVs++1Rv08= X-Yahoo-Newman-Id: 221381.57402.bm@smtp211.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ojNBIeAVM1mcvuHGcrWrxotzD54cneuv3UZd_vPT1alj2ZB GSnPkLIkrPuKO8tnrHADdIE9b253rOzbxIj37zkwhCGrt44Oz.jlbs5FKKZq NhDsscpKYFtFZyGInk1EJmJZdosIkoh26m.vnhunr29YPlWt1l_DYGYs9rcL N4_4nXmnejDcJvhN8aqcsXBIne5pUUy5N2Mm9klrPb2nKlFgsYX0bbtBbMlX diZQsPiQtD77Pzj.rC2hthEvBRY2LagIxFBhDMZfNQ1Tm5SdzG5wqp1aQcqp 7l3qQVyXFEqtMp.qzZOJt.bIDkEpbwX5E_EmSyU_alQSQQaqRT_qKvo4hZZm uHicQYiv8ry.paTje5AElFocLYXh35VhX2jDtPzDfcsUYFT05M2ypUuKCSHG uMncv6nt5dJaMke_n2Zpgnx5YD8ANv1XlUsbqF5Fe7Gucb_3haeeyCtwhAi. IC3g7oe4cxvaJjf40wgpJEiMRhULa.6HZ0vs3er5P4lKDP5flMGtUBmPAAwd xS8wn9vcRpGwreBBCNxWDjcQEwi7dsJUA0z8k.S0g2dZ0tipLhR1hgQ-- X-Yahoo-SMTP: ygPrP9CswBCWPbPtKJlJyLY0KMlg X-Rocket-Received: from [192.168.0.103] (davarish@98.248.42.143 with ) by smtp211.mail.ne1.yahoo.com with SMTP; 20 Aug 2013 10:00:57 -0700 PDT References: <51FB7543.801@cisco.com> <51FF7068.9080600@cisco.com> <4A6CE49E6084B141B15C0713B8993F281BEC731A@SJEXCHMB12.corp.ad.broadcom.com> <52139903.8040801@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A403) From: "S. Davari" Date: Tue, 20 Aug 2013 10:00:41 -0700 To: Alexander Vainshtein Cc: "mpls@ietf.org" , "tictoc@ietf.org" Subject: Re: [mpls] [TICTOC] Comments on draft-ietf-tictoc-1588overmpls X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 17:01:05 -0000 Sasha In (2) are you proposing to create multiple segment LSPs, where each if thos= e segment LSPs span between two Timing aware LSR? So if I have 10 timing awa= re LSR in the path I would need 9 LSPs? Regards, Shahram On Aug 20, 2013, at 9:53 AM, Alexander Vainshtein wrote: > Stewart, Shahram and all, >=20 > A couple of (hopefully, last) comments: >=20 > 1. Supporting a "Timing Alert" label at the top of the label stack introdu= ces a backward compatibility problem. We differ in our estimate of the impor= tance of this problem, but we all agree that it exists. >=20 > 2. On the other hand, this problem does not exist if the "Timing Alert" la= bel is inserted at the bottom of the label stack. At the same time, HW that a= nalyzes the label stack hopefully could analyze the bottom label (almost) as= easily as it would analyze the top label. Thus we could both provide backwa= rd compatibility (incompatible transit LSRs simply would not notice the "Tim= ing Alert" label") and avoid the need for dedicated "Timing-only" LSPs. In p= articular, all the MPLS OAM tools (including MPLS-TP) would work without any= changes.=20 >=20 > 3. A "timing shim header" (between the bottom of the label stack and the b= eginning of the timing packet) has been mentioned by Stewart as an already p= roposed mechanism. IMHO and FWIW its usage would eliminate the need to under= stand format of the specific timing distribution protocol in the transit LSR= s. It would further solve the problem of secure transport of timing packets= since security mechanisms would be applied to its original encapsulation (o= ver IP or over Ethernet) without involving the transit LSRs. >=20 > Did I miss something substantial? >=20 > Regards, and lots of thanks in advance, > Sasha >=20 >=20 > ________________________________________ > From: Stewart Bryant [stbryant@cisco.com] > Sent: Tuesday, August 20, 2013 6:27 PM > To: S. Davari > Cc: Alexander Vainshtein; Shahram Davari; mpls@ietf.org; tictoc@ietf.org > Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls >=20 > On 06/08/2013 14:35, S. Davari wrote: >> Sasha, >>=20 >> If a router is not 1588 aware we want it to switch the packet with minimu= m jitter and delay via high priority queue. > Yes, but you can explicitly tunnel across such island of incompatibility >=20 > Stewart >=20 >>=20 >>=20 >> Sending it to CPU creates large jitter and delay since the CPUs are gener= ally busy doing other things. Time stamping or updating CF in the CPU won't h= elp since it does not cover the variable delay that is incurred from the tim= e the packet enters the router to the time the packet gets processed by CPU.= >>=20 >> I wish it was that easy! >>=20 >> Regards, >> Shahram >>=20 >>=20 >> On Aug 6, 2013, at 12:38 AM, Alexander Vainshtein wrote: >>=20 >>> Shahram, >>> I agree with you that the routers that do not recognize a Timing Alert l= abel would send the packet to the CPU. (This would be easy to arrange since w= e are speaking about a reserved label.) >>>=20 >>> I do not, however, see this as a serious issue, because the SW running o= n this CPU would (hopefully) be upgradable to handle the packet correctly i.= e., to forward it to where it should be forwarded and, if it is forwarded as= a labeled packet, to prepend the Timing Alert Label on top of its label sta= ck. It could even record the residence time (as observed by the CPU in the p= roper place in the packet. This would mean that introducing additional error= to whatever timing information is associated with this packet - but this is= what you should anyway expect if there are non-compliant routers on your pa= th, right? >>>=20 >>> Regards, >>> Sasha >>>=20 >>>> -----Original Message----- >>>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behal= f Of >>>> Shahram Davari >>>> Sent: Monday, August 05, 2013 11:29 PM >>>> To: stbryant@cisco.com; S. Davari >>>> Cc: mpls@ietf.org; tictoc@ietf.org >>>> Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls= >>>>=20 >>>> Hi Stewart, >>>>=20 >>>> Your suggestion of " I suggested an LSP type that has the properties "t= imestamp >>>> and pass to application", is a subset of the existing draft and should w= ork. It >>>> basically limits the time stamping and correction field update to LERs (= while the >>>> draft supports time stamping at LER and LSR). >>>>=20 >>>> However Sasha's suggestion of using a reserved label (RAL, GAL or any o= ther >>>> reserved label) does not satisfy one of the major requirements, which i= s >>>> backward compatibility. Routers that don't understand this reserved lab= el will >>>> drop or copy to CPU such packets. >>>>=20 >>>> Regards, >>>> Shahram >>>>=20 >>>> -----Original Message----- >>>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behal= f Of >>>> Stewart Bryant >>>> Sent: Monday, August 05, 2013 2:29 AM >>>> To: S. Davari >>>> Cc: mpls@ietf.org; tictoc@ietf.org >>>> Subject: Re: [TICTOC] [mpls] Comments on draft-ietf-tictoc-1588overmpls= >>>>=20 >>>> My concern is that we are creating a new LSP type in MPLS >>>> (which is a architectural change and thus needs to be very carefully >>>> considered) without asking the question "how can I do this >>>> in the most general way, to maximize flexibility/reuse" >>>>=20 >>>> I suggested an LSP type that has the properties "timestamp >>>> and pass to application", but I think that Sasha raises a good >>>> point about using router alert. However RA has no implicit >>>> timestamp, so maybe we need a new type of RA that has the >>>> properties "timestamp, and pass top application indicated by >>>> the next label". That would be quite useful in a number >>>> of OAM applications. There is possibly some GAL variant >>>> of that design that should also be considered. >>>>=20 >>>> The application could worry about the path and where it >>>> was necessary to skip some hops a hierarchical LSP would >>>> accomplish that, with the specific benefit that the application >>>> would consciously do this, and may be able to apply some >>>> form of compensation within the network. >>>>=20 >>>> - Stewart >>>>=20 >>>> On 04/08/2013 10:40, S. Davari wrote: >>>>> Hi Sasha >>>>>=20 >>>>> Perhaps you have not understood the draft well. The main reason that t= he >>>> draft chose to use a dedicated LSP that is signaled via RSVPTE indicati= ng it is a >>>> timing LSP is to be backward compatible with non-1588 nodes. Such nodes= >>>> simply just switch the packet. >>>>> Your proposal had been considered and was rejected since it was not >>>> backward compatible. Nodes receiving alert label or TTL =3D 1 send the p= acket to >>>> CPU. You can refer to the meeting notes. >>>>> Regards, >>>>> Shahram >>>>>=20 >>>>>=20 >>>>> On Aug 4, 2013, at 1:21 AM, Alexander Vainshtein >>>> wrote: >>>>>> Stewart and all, >>>>>> I concur with Stewart's statement that the draft does not define "ful= l >>>> interaction with MPLS architecture". >>>>>> E.g., one of the objectives of the draft is to provide a technique th= at would >>>> be backward-compatible with old LSRs that cannot provide on-path suppor= t for >>>> timing distribution, while the other objective is to make every LSR on t= he path >>>> aware that some MPLS packets are carrying timing-related messages and h= ence >>>> require on-path support. >>>>>> IMHO and FWIW, the MPLS data plane architecture allows just two metho= ds >>>> for making a transit LSR to provide special processing to a labeled pac= ket: >>>>>> - It would carry some kind of an "alert label" on top of the label st= ack and, >>>> specifically, on top of any labels used for actual forwarding >>>>>> OR, >>>>>> - The TTL in the top label stack entry has been set to 1. >>>>>>=20 >>>>>>=20 >>>>>> The draft does not follow any of these approaches. >>>>>>=20 >>>>>> I must also admit that Section 12 "OAM, Control and Management" of th= e >>>> draft looks somewhat in >>>>>> E.g., I could not understand from the text whether BFD, LSP-Ping etc.= OAM >>>> messages would be subjected to on-path support procedures for timing >>>> messages or not. >>>>>> My 2c, >>>>>> Sasha >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Be= half >>>> Of >>>>>>> Stewart Bryant >>>>>>> Sent: Friday, August 02, 2013 12:01 PM >>>>>>> To: mpls-chairs@tools.ietf.org; tictoc-chairs@tools.ietf.org; int- >>>>>>> ads@tools.ietf.org; rtg-ads@tools.ietf.org; mpls-chairs@tools.ietf.o= rg; >>>> draft- >>>>>>> ietf-tictoc-1588overmpls@tools.ietf.org >>>>>>> Cc: mpls@ietf.org; tictoc@ietf.org >>>>>>> Subject: [TICTOC] Comments on draft-ietf-tictoc-1588overmpls >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> - Stewart >>>>>>>=20 >>>>>>>=20 >>>>>>> TICTOC Working Group S. Da= vari >>>>>>> Internet-Draft A. O= ren >>>>>>> Intended status: Standards Track Broadcom C= orp. >>>>>>> Expires: December 17, 2013 M. Bh= atia >>>>>>> P. Rob= erts >>>>>>> Alcatel-Lu= cent >>>>>>> L. Mon= tini >>>>>>> L. Mar= tini >>>>>>> Cisco Sys= tems >>>>>>> June 15, 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> Transporting Timing messages over MPLS Networks >>>>>>> draft-ietf-tictoc-1588overmpls-05 >>>>>>>=20 >>>>>>> Abstract >>>>>>>=20 >>>>>>> This document defines the method for transporting Timing messages= >>>>>>> such as PTP and NTP over an MPLS network. The method allows for t= he >>>>>>> easy identification of these PDUs at the port level to allow for p= ort >>>>>>>=20 >>>>>>> SB> What is a port >>>>>>>=20 >>>>>>> level processing of these PDUs in both LERs and LSRs. >>>>>>>=20 >>>>>>> The basic idea is to transport Timing messages inside dedicated M= PLS >>>>>>> LSPs. These LSPs only carry Timing messages and possibly Control= and >>>>>>> Management packets, but they do not carry customer traffic. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Two methods for transporting Timing messages over MPLS are define= d. >>>>>>>=20 >>>>>>> SB> Perhaps the right approach is to define the new LSP type and the= n >>>>>>> SB> seperately to define the mapping of the various timing services= >>>>>>> SB> over that LSP type. >>>>>>>=20 >>>>>>> The first method is to transport Timing messages directly over th= e >>>>>>> dedicated MPLS LSP via UDP/IP encapsulation, which is suitable fo= r >>>>>>> MPLS networks. The second method is to transport Timing messages= >>>>>>> inside a PW via Ethernet encapsulation. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Status of this Memo >>>>>>>=20 >>>>>>> This Internet-Draft is submitted in full conformance with the >>>>>>> provisions of BCP 78 and BCP 79. >>>>>>>=20 >>>>>>> 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 Intern= et- >>>>>>> Drafts is at http://datatracker.ietf.org/drafts/current/. >>>>>>>=20 >>>>>>> Internet-Drafts are draft documents valid for a maximum of six mo= nths >>>>>>> and may be updated, replaced, or obsoleted by other documents at a= ny >>>>>>> time. It is inappropriate to use Internet-Drafts as reference >>>>>>> material or to cite them other than as "work in progress." >>>>>>>=20 >>>>>>> This Internet-Draft will expire on December 17, 2013. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 1] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> Copyright Notice >>>>>>>=20 >>>>>>> Copyright (c) 2013 IETF Trust and the persons identified as the >>>>>>> document authors. All rights reserved. >>>>>>>=20 >>>>>>> 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 res= pect >>>>>>> to this document. Code Components extracted from this document m= ust >>>>>>> include Simplified BSD License text as described in Section 4.e o= f >>>>>>> the Trust Legal Provisions and are provided without warranty as >>>>>>> described in the Simplified BSD License. >>>>>>>=20 >>>>>>>=20 >>>>>>> Table of Contents >>>>>>>=20 >>>>>>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .= 5 >>>>>>>=20 >>>>>>> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .= 7 >>>>>>>=20 >>>>>>> 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . .= 8 >>>>>>>=20 >>>>>>> 4. Timing over MPLS Architecture . . . . . . . . . . . . . . . .= 9 >>>>>>>=20 >>>>>>> 5. Dedicated LSPs for Timing messages . . . . . . . . . . . . . .= 12 >>>>>>>=20 >>>>>>> 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 >>>>>>>=20 >>>>>>> 7. Timing message Processing . . . . . . . . . . . . . . . . . .= 15 >>>>>>>=20 >>>>>>> 8. Protection and Redundancy . . . . . . . . . . . . . . . . . .= 16 >>>>>>>=20 >>>>>>> 9. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .= 17 >>>>>>>=20 >>>>>>> 10. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .= 18 >>>>>>>=20 >>>>>>> 11. Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . .= 19 >>>>>>>=20 >>>>>>> 12. OAM, Control and Management . . . . . . . . . . . . . . . . .= 20 >>>>>>>=20 >>>>>>> 13. QoS Considerations . . . . . . . . . . . . . . . . . . . . . .= 21 >>>>>>>=20 >>>>>>> 14. FCS and Checksum Recalculation . . . . . . . . . . . . . . . .= 22 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 2] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 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 >>>>>>>=20 >>>>>>> 16. Other considerations . . . . . . . . . . . . . . . . . . . . .= 25 >>>>>>>=20 >>>>>>> 17. Security Considerations . . . . . . . . . . . . . . . . . . .= 26 >>>>>>>=20 >>>>>>> 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .= 27 >>>>>>>=20 >>>>>>> 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . .= 28 >>>>>>>=20 >>>>>>> 20. References . . . . . . . . . . . . . . . . . . . . . . . . . .= 29 >>>>>>> 20.1. Normative References . . . . . . . . . . . . . . . . . . .= 29 >>>>>>> 20.2. Informative References . . . . . . . . . . . . . . . . . .= 29 >>>>>>>=20 >>>>>>> Appendix 1. Routing extensions for Timing-aware Routers . . . . .= 32 >>>>>>>=20 >>>>>>> Appendix 2. Signaling Extensions for Creating Timing LSPs . . . .= 33 >>>>>>>=20 >>>>>>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .= 34 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 3] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 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].= >>>>>>>=20 >>>>>>> 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]. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 4] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 1. Introduction >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> [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]). >>>>>>>=20 >>>>>>> SB> Sure BUT it is acknowledged that IEEE is open to the definition >>>>>>> SB> of other PTP mappings if they provide better optimisation. >>>>>>>=20 >>>>>>> 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, en= d- >>>>>>> to-end transparent clocks, and peer-to-peer transparent clocks. >>>>>>> Transparent clocks require intermediate nodes to update correctio= n >>>>>>> field inside PTP message that reflects the transit time in the no= de. >>>>>>>=20 >>>>>>> [RFC5905] defines NTP messages for clock and time synchronization= . >>>>>>> The PTP messages (PDUs) are transported over UDP/IP. This docume= nt >>>>>>> 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. >>>>>>>=20 >>>>>>> defines mapping and transport of the NTP messages defined in >>>>>>> [RFC5905] over MPLS networks. >>>>>>>=20 >>>>>>> One key attribute of all of these Timing messages is that the Tim= e >>>>>>> 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 variab= le >>>>>>> delay introduced by queues internal to the clocks. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> To facilitate the fast and efficient recognition of Timing messag= es >>>>>>> at the port level when the Timing messages are carried over MPLS >>>>>>> LSPs, >>>>>>>=20 >>>>>>> SB> Over a new LSP type with time optimied characteristics >>>>>>>=20 >>>>>>> this document defines the specific encapsulations that should >>>>>>> be used. >>>>>>> SB> Hopefully it will also define the PHP >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>>=20 >>>>>>> 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 establishmen= t 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 cap= able >>>>>>> LSRs in the path. >>>>>>> SB> I do not understand the implications of the last >>>>>>> SB> sentences - starting ", it becomes" >>>>>>>=20 >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> This document provides two methods for transporting Timing messag= es >>>>>>> over MPLS. One is applicable to MPLS environment and the other o= ne >>>>>>> is applicable to MPLS/MPLS-TP environment >>>>>>>=20 >>>>>>> SB> I think the sentence is incomplete. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 5] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> The solution involves transporting Timing messages over dedicated= >>>>>>> LSPs called Timing LSPs. These LSPs carry Timing messages and MA= Y >>>>>>> carry Management and control messages, but not data plane client >>>>>>> traffic. >>>>>>>=20 >>>>>>> SB> It is not clear why this restriction applies. >>>>>>>=20 >>>>>>> Timing LSPs can be established statically or via signaling. >>>>>>> SB> s/statically/by provisioning/network management/ >>>>>>>=20 >>>>>>> Extensions to control plane (OSPF, ISIS, etc.) is required to ena= ble >>>>>>> routers to distribute their Timing processing capabilities over M= PLS >>>>>>> to other routers. However such extensions are outside the scope o= f >>>>>>> this document. >>>>>>>=20 >>>>>>> When signaling is used to setup the PTP LSP, Extensions to signal= ing >>>>>>> SB> is it a PTP LSP or a Timing LSP? >>>>>>>=20 >>>>>>> protocols (e.g., RSVP-TE) are required for establishing PTP LSPs.= >>>>>>> However such extensions are outside the scope of this document. >>>>>>>=20 >>>>>>> SB> for mpls-tp GMPLS is the signalling protocol >>>>>>>=20 >>>>>>> While the techniques included herein allow for the establishment o= f >>>>>>> paths optimized to include Time-stamping capable links, the >>>>>>> performance of the Slave clocks is outside the scope of this >>>>>>> document. >>>>>>>=20 >>>>>>> At the time of publishing this specification, Transparent Clockin= g >>>>>>> (TC) is only defined for PTP. Therefore at this time any part of= >>>>>>> this specification that talks about Transparent Clocking applies o= nly >>>>>>> to PTP. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 6] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 2. Terminology >>>>>>>=20 >>>>>>> 1588: The timing and synchronization as defined by IEEE 1588. >>>>>>>=20 >>>>>>> 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 >>>>>>>=20 >>>>>>> NTP: The timing and synchronization protocol defined by IETF RFC-= 1305 >>>>>>> and RFC-5905. >>>>>>>=20 >>>>>>> PTP: The timing and synchronization protocol used by 1588. >>>>>>> SB> need the proper name for 1588 >>>>>>>=20 >>>>>>> Master Clock: The source of 1588 timing to a set of slave clocks.= >>>>>>>=20 >>>>>>> Master Port: A port on a ordinary or boundary clock that is in Ma= ster >>>>>>> state. This is the source of timing toward slave ports. >>>>>>>=20 >>>>>>> SB> I am not sure the reader knows what a port is >>>>>>>=20 >>>>>>> Slave Clock: A receiver of 1588 timing from a master clock. >>>>>>>=20 >>>>>>> Slave Port: A port on a boundary clock or ordinary clock that is >>>>>>> receiving timing from a master clock. >>>>>>>=20 >>>>>>> Ordinary Clock: A device with a single PTP port. >>>>>>>=20 >>>>>>> Transparent Clock. A device that measures the time taken for a P= TP >>>>>>> event message to transit the device and then updates the >>>>>>> correctionField of the message with this transit time. >>>>>>>=20 >>>>>>> Boundary Clock: A device with more than one PTP port. Generally >>>>>>> boundary clocks will have one port in slave state to receive timi= ng >>>>>>> and then other ports in master state to re-distribute the timing.= >>>>>>>=20 >>>>>>> PTP LSP: An LSP dedicated to carry PTP messages >>>>>>>=20 >>>>>>> SB> PTP or timing? >>>>>>>=20 >>>>>>>=20 >>>>>>> PTP PW: A PW within a PTP LSP that is dedicated to carry PTP >>>>>>> messages. >>>>>>>=20 >>>>>>> SB> Ah I don't think that PWE3 know what one of these is >>>>>>>=20 >>>>>>> CW: Pseudowire Control Word >>>>>>>=20 >>>>>>> LAG: Link Aggregation >>>>>>>=20 >>>>>>> ECMP: Equal Cost Multipath >>>>>>>=20 >>>>>>> CF: Correction Field, a field inside certain PTP messages (messag= e >>>>>>> type 0-3)that holds the accumulative transit time inside intermed= iate >>>>>>> switches >>>>>>>=20 >>>>>>> Timing messages: Timing Protocol messages that are exchanged >>>> between >>>>>>> routers in order to establish a synchronized clock. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 7] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 3. Problem Statement >>>>>>>=20 >>>>>>> [IEEE-1588] has defined methods for transporting PTP messages ove= r >>>>>>> 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 (O= C) >>>>>>> functionality in the LER and LSRs in the MPLS network. >>>>>>>=20 >>>>>>> There are multiple ways of transporting Timing over MPLS. Howeve= r, >>>>>>> there is a requirement to limit the possible encapsulation option= s to >>>>>>> simplify the Timing message identification and processing require= d at >>>>>>> the port level. >>>>>>>=20 >>>>>>> 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 th= e >>>>>>> stack. >>>>>>>=20 >>>>>>> SB> Have you explained why? >>>>>>>=20 >>>>>>> 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 identifie= d by >>>>>>> LSRs because the payload type is a context of the PW label, and t= he >>>>>>> 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, C= ES, >>>>>>> etc). Even if one restricts an LSP to only carry Ethernet PWs, t= he >>>>>>> LSRs dont have the knowledge of whether PW Control Word (CW) is >>>>>>> present or not and therefore can not deterministically identify t= he >>>>>>> payload. >>>>>>>=20 >>>>>>> A generic method is defined in this document that does not requir= e >>>>>>> deep packet inspection at line rate, and can deterministically >>>>>>> identify Timing messages. This method can be used to detect Timi= ng >>>>>>> Messages in both one-step and two-step clock implementations of >>>>>>> ordinary, boundary and transparent clocks. >>>>>>>=20 >>>>>>> SB> Needs a ref and I am sure many MPLS specialists will not underst= and >>>>>>> SB> the msg types. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 8] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 4. Timing over MPLS Architecture >>>>>>>=20 >>>>>>> Timing messages are exchange between Timing ports on ordinary and= >>>>>>>=20 >>>>>>> SB> Have you defined a timing port? >>>>>>>=20 >>>>>>> boundary clocks. Boundary clocks terminate the Timing messages a= nd >>>>>>> act as master for other boundary clocks or for slave clocks. End= -to- >>>>>>> End Transparent clocks do not terminate the Timing messages but t= hey >>>>>>> do modify the contents of the Timing messages as they transit acr= oss >>>>>>> the transparent clock. >>>>>>>=20 >>>>>>> Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent C= lock >>>>>>>=20 >>>>>>> (TC) could be implemented in either LERs or LSRs. >>>>>>>=20 >>>>>>> SB> LER and LSR need to be expanded >>>>>>>=20 >>>>>>> An example is shown in Figure 1, where the LERs act as Ordinary C= lock >>>>>>> (OC) and are the initiating/terminating point for Timing messages= . >>>>>>> The ingress LER encapsulates the Timing messages in Timing LSP an= d >>>>>>> the Egress LER terminates the Timing LSP. The LSRs act as >>>>>>> Transparent Clock (TC) and just update the Timing field in the Ti= ming >>>>>>> messages. >>>>>>>=20 >>>>>>>=20 >>>>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ >>>>>>> |Switch, | | | | | | | |Swit= ch, | >>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rou= ter | >>>>>>> | | | OC | | TC | | OC | | = | >>>>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ >>>>>>> / \ >>>>>>> +-------+ / \ +-----= --+ >>>>>>> | LER | / \ | LER= | >>>>>>> | Master|---/ \---| Slav= e | >>>>>>> | Clock | | Cloc= k | >>>>>>> +-------+ +-----= --+ >>>>>>>=20 >>>>>>> Figure (1) - Deployment example 1 of timing over MPLS network >>>>>>>=20 >>>>>>> Another example is shown in Figure2, where LERs terminate the Tim= ing >>>>>>> messages received from switch/routers that are outside of the MPL= S >>>>>>> network acting as OC or BC. In this example LERs regenerate the >>>>>>> clock and initiate timing messages encapsulated in Timing LSP tow= ard >>>>>>> the MPLS network, while the LSRs act as Transparent Clock (TC) an= d >>>>>>> just update the Timing field in the Timing messages, which are >>>>>>> already encapsulated in Timing LSPs. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Pag= e 9] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ >>>>>>> |Switch, | | | | | | | |Switc= h, | >>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rout= er | >>>>>>> | OC/BC | | BC | | TC | | BC | | OC/B= C | >>>>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ >>>>>>>=20 >>>>>>> Figure (2) - Deployment example 2 of timing over MPLS network >>>>>>>=20 >>>>>>>=20 >>>>>>> Another example is shown in Figure 3, where LERs do not terminate= the >>>>>>> Timing messages received from switch/routers that are outside of t= he >>>>>>> MPLS network acting as OC, TC or BC. The LERs act as TC and upda= te >>>>>>> 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 Ti= ming >>>>>>> messages which are already encapsulated in Timing LSPs. >>>>>>>=20 >>>>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ >>>>>>> |Switch, | | | | | | | |Swit= ch, | >>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rou= ter | >>>>>>> |OC/TC/BC| | TC | | TC | | TC | |OC/T= C/BC| >>>>>>> +--------+ +-------+ +-------+ +-------+ +----= ----+ >>>>>>>=20 >>>>>>> Figure (3) - Deployment example 3 of timing over MPLS network >>>>>>>=20 >>>>>>> Another example is shown in Figure 4, where LERs and LSRs support= >>>>>>> Boundary Clocks. A single-hop LSP is created between two adjacen= t >>>>>>> LSRs engaged in BC operation. Other methods such as PTP transpor= t >>>>>>> over Ethernet MAY be used for transporting timing messages if the= >>>>>>> link between the two routers is Ethernet. >>>>>>>=20 >>>>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ >>>>>>> |Switch, | | | | | | | |Switc= h, | >>>>>>> | Router |-----| LER |-----| LSR |-----| LER |-----| Rout= er | >>>>>>> | OC/BC | | BC | | BC | | BC | | OC/B= C | >>>>>>> +--------+ +-------+ +-------+ +-------+ +-----= ---+ >>>>>>>=20 >>>>>>> Figure (4) - Deployment example 3 of timing over MPLS network >>>>>>>=20 >>>>>>> An MPLS domain MAY serve multiple customers. In these cases the >>>> MPLS >>>>>>> domain (maintained by a service provider) may provide timing serv= ices >>>>>>> to multiple customers, each having their own Timing domain. >>>>>>>=20 >>>>>>> The Timing over MPLS architecture assumes full mesh of Timing LSP= s >>>>>>> between all LERs supporting this specification. >>>>>>>=20 >>>>>>> SB> Note sure this is right - the salves surely do not need to >>>>>>> SB> exchange timing amongst themselves >>>>>>>=20 >>>>>>> It supports >>>>>>> Point-to- point (VPWS) and Multipoint (VPLS) services. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> This means >>>>>>> that a customer may purchase a Point-to-point Timing service betw= een >>>>>>> two customer sites or a Multipoint Timing service between more th= an >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 10] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> two customer sites. >>>>>>>=20 >>>>>>> The Timing over MPLS architecture supports P2P or P2MP Timing LSP= s. >>>>>>> This means that the Timing Multicast messages such as PTP Multica= st >>>>>>> event messages can be transported over P2MP Timing LSP or be >>>>>>> replicated and transported over many P2P Timing LSPs. >>>>>>>=20 >>>>>>> SB> Note we do not yet have a definition of a P2MP mpls-tp LSP >>>>>>> SB> nor a P2MP PW, although we are close. >>>>>>>=20 >>>>>>> Timing messages, that do not require Time stamping or Correction >>>>>>> Field update MAY be transported over Timing LSPs to simplify hard= ware >>>>>>> and software. >>>>>>>=20 >>>>>>> PTP Announce messages that determine the Timing LSP terminating >>>> point >>>>>>> behavior such as BC/OC/TC SHOULD be transported over the Timing L= SP >>>>>>> to simplify hardware and software. >>>>>>>=20 >>>>>>> SB> have you defined and referenced PTP announce msgs? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 11] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 5. Dedicated LSPs for Timing messages >>>>>>>=20 >>>>>>> Many methods have been considered for identifying the Timing >>>> messages >>>>>>> when they are encapsulated in MPLS such as using GAL/G-ACH or a n= ew >>>>>>> reserved label. These methods were not attractive since they eit= her >>>>>>> required deep packet inspection at line rate in the intermediate L= SRs >>>>>>> or they required use of a scarce new reserved label. Also one of= the >>>>>>> goals was to reuse existing OAM mechanisms. >>>>>>>=20 >>>>>>> SB> RLs =3D SPLs are not so rare now. In any case needs a ref. >>>>>>>=20 >>>>>>> The method defined in this document can be used by LER and LSRs t= o >>>>>>> identify Timing messages in MPLS tunnels by just looking at the t= op >>>>>>> label in the MPLS label stack, which only carry Timing messages a= s >>>>>>> well as OAM, but not data plane client traffic. >>>>>>>=20 >>>>>>> Compliant implementations MUST use dedicated LSPs to carry Timing= >>>>>>> messages over MPLS. >>>>>>>=20 >>>>>>> SB> I think that we need a definition of the properies of these LSPs= >>>>>>>=20 >>>>>>> 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 LE= Rs >>>>>>> MUST be co-routed. Alternatively, a single bidirectional co-rout= ed >>>>>>> LSP can be used. >>>>>>>=20 >>>>>>> SB> I though that you said you could use M2MP LSPs - these are not >>>>>>> SB> bidirectional. >>>>>>>=20 >>>>>>> Co-routing of the two directions is required to limit the differe= nce >>>>>>> in the delays in the Master clock to Slave clock direction compar= ed >>>>>>> to the Slave clock to Master clock direction. The Timing LSP MAY= be >>>>>>> MPLS/MPLS-TP LSP. >>>>>>>=20 >>>>>>> The Timing LSPs could be configured or signaled via RSVP-TE/GMPLS= . >>>>>>> New Extensions to RSVP-TE/GMPLS TLVs are required; however they a= re >>>>>>> outside the scope of this document. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> SB> Why? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 12] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 6. Timing over LSP Encapsulation >>>>>>>=20 >>>>>>> The encapsulations is not LSP is it? >>>>>>>=20 >>>>>>> This document defines two methods for carrying Timing messages ov= er >>>>>>> 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. >>>>>>>=20 >>>>>>> 6.1. Timing over UDP/IP over MPLS Encapsulation >>>>>>>=20 >>>>>>> The simplest method of transporting Timing messages over MPLS is t= o >>>>>>> encapsulate Timing PDUs in UDP/IP and then encapsulate them in >>>> Timing >>>>>>> LSP. This format is shown in Figure 4. >>>>>>>=20 >>>>>>>=20 >>>>>>> +----------------------+ >>>>>>> | Timing LSP Label | >>>>>>> +----------------------+ >>>>>>> | IPv4/6 | >>>>>>> +----------------------+ >>>>>>> | UDP | >>>>>>> +----------------------+ >>>>>>> | Timing PDU | >>>>>>> +----------------------+ >>>>>>>=20 >>>>>>> Figure (4) - Timing over UDP/IP over MPLS Encapsulation >>>>>>>=20 >>>>>>>=20 >>>>>>> This encapsulation is very simple and is useful when the network >>>>>>> between Timing Master Clock and Slave Clock is MPLS network. >>>>>>>=20 >>>>>>> SB> Simple is a judgement call >>>>>>>=20 >>>>>>> In order for an LER/LSR to process Timing messages, the Timing LS= P >>>>>>> Label must be at the top label of the label stack. The LER/LSR M= UST >>>>>>> know that the Timing LSP Label is used for carrying Timing messag= es. >>>>>>> This can be accomplished via static configuration or via RSVP-TE >>>>>>> signaling. >>>>>>>=20 >>>>>>> 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]. >>>>>>>=20 >>>>>>> 6.2. Timing over PW Encapsulation >>>>>>>=20 >>>>>>> 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 P= TP >>>>>>> MUST follow Annex F of [IEEE-1588]. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 13] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> SB> That needs explanation >>>>>>>=20 >>>>>>> The use of Sequence Number in the CW is optional. >>>>>>>=20 >>>>>>> SB> Given that s/n are never in practice deployed, you could probabl= y >>>>>>> SB> simplify things by sayig that they are not used. >>>>>>>=20 >>>>>>> Timing over PW encapsulation for NTP MUST use NTP over UDP/IP ove= r >>>> PW >>>>>>> (the IP PW discussed in [RFC4447]) shown in Fig 5(B). >>>>>>>=20 >>>>>>> +----------------+ +----------------+ >>>>>>> |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) >>>>>>>=20 >>>>>>> Figure (5) - Timing over PW Encapsulations >>>>>>>=20 >>>>>>> In order for an LSR to process PTP messages, the top label of the= >>>>>>> label stack (the Tunnel Label) MUST be a Timing label. >>>>>>>=20 >>>>>>> S> You said that before. >>>>>>>=20 >>>>>>> 6.3. Other Timing Encapsulation methods >>>>>>>=20 >>>>>>> In future other timing encapsulation methods may be introduced, s= uch >>>>>>> as a new shim header after the Bottom of Stack to carry the Timin= g >>>>>>> information. Such new encapsulations are outside the scope of th= is >>>>>>> document. >>>>>>>=20 >>>>>>>=20 >>>>>>> SB> Taking a pure MPLS pov, you can simplify a lot of the text >>>>>>> SB> out of the definition of the LSP >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 14] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> SB> I think we need a section on LSP processing >>>>>>>=20 >>>>>>> 7. Timing message Processing >>>>>>>=20 >>>>>>> Each Timing protocol such as PTP and NTP, define their set of Tim= ing >>>>>>> messages. For example PTP defines SYNC, DELAY_REQ, DELAY_RESP, >>>>>>> FOLLOW_UP, etc messages. >>>>>>>=20 >>>>>>> Some of the Timing messages require time stamping or correction f= ield >>>>>>> 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 mess= age >>>>>>> and decide whether and how to Time- stamp it (e.g., BC) or update= >>>>>>> correction field(e.g., TC). >>>>>>>=20 >>>>>>>=20 >>>>>>> SB> AAAAAAAAAAAH. Surely this is the function of the PTP prcessing >>>>>>> SB> function rather than the LER? >>>>>>>=20 >>>>>>> For example the following PTP messages (called Event messages) >>>>>>> require time-stamping or correction field update: >>>>>>>=20 >>>>>>> o SYNC >>>>>>>=20 >>>>>>> o DELAY_REQ (Delay Request) >>>>>>>=20 >>>>>>> o PDELAY_REQ (Peer Delay Request) >>>>>>>=20 >>>>>>> o PDELAY_RESP (Peer Delay Response) >>>>>>>=20 >>>>>>> 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 h= op >>>>>>> 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. >>>>>>>=20 >>>>>>> For a given instance of 1588 protocol, SYNC and DELAY_REQ MUST be= >>>>>>> transported over two PTP LSPs that are in opposite directions. T= hese >>>>>>> PTP LSPs, which are in opposite directions MUST be congruent and c= o- >>>>>>> routed. Alternatively, a single bidirectional co-routed LSP can b= e >>>>>>> used. >>>>>>>=20 >>>>>>> Except as indicated above for the two-step PTP clocks, Non-Event P= TP >>>>>>> message types do not need to be processed by intermediate routers= . >>>>>>> These message types MAY be carried in PTP Tunnel LSPs. >>>>>>>=20 >>>>>>> SB> Are you saying that a timing P router has to be msg type sensiti= ve? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 15] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 8. Protection and Redundancy >>>>>>>=20 >>>>>>>=20 >>>>>>> SB> This is a bit of a jump - I don't know how the LSP itself works y= et! >>>>>>>=20 >>>>>>> In order to ensure continuous uninterrupted operation of slave >>>>>>> clocks, usually as a general practice, slave clocks (or ports) tr= ack >>>>>>> redundant master clocks. >>>>>>>=20 >>>>>>> It is the responsibility of the network operator to ensure that >>>>>>> physically disjoint Timing LSPs are established between a slave c= lock >>>>>>> (or port) and redundant master clocks (or ports). >>>>>>>=20 >>>>>>> When a slave clock (or port) listens to redundant master clocks o= r >>>>>>> ports, any prolonged Timing LSP outage will trigger the slave clo= ck >>>>>>> or port to switch to a redundant master clock or port. >>>>>>>=20 >>>>>>> LSP/PW protection such as Linear protection Switching (1:1, 1+1),= >>>>>>> Ring protection switching or MPLS Fast Reroute (FRR) generally sw= itch >>>>>>> alternative path that usually cause a change in delay, which if >>>>>>> undetected by slave clock can reduce accuracy of the slave clock.= >>>>>>>=20 >>>>>>> Therefore protection switching MAY be used, as long as phase jump= s >>>>>>> upon switchover due to differences in path latency are detected a= nd >>>>>>> compensated for (such compensation not being required if BCs or p= eer- >>>>>>> peer TCs are used throughout). >>>>>>>=20 >>>>>>> Note that any protection or reroute mechanism that adds additiona= l >>>>>>> MPLS label to the label stack, such as Facility Backup Fast Rerou= te, >>>>>>> MUST ensure that the pushed label is also a Timing Label to ensur= e >>>>>>> recognition of the MPLS frame as containing Timing messages, as i= t >>>>>>> transits the backup path. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 16] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 9. ECMP >>>>>>>=20 >>>>>>> To ensure the optimal operation of slave clocks and avoid error >>>>>>> introduced by forward and reverse path delay asymmetry, the physi= cal >>>>>>> path for Timing messages from master clock to slave Clock and vic= e >>>>>>> versa must be the same for all Event Timing messages listed in >>>>>>> section 7. >>>>>>>=20 >>>>>>> Therefore the Timing LSPs MUST not be subject to ECMP (Equal Cost= >>>>>>> Multipath). >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 17] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 10. PHP >>>>>>>=20 >>>>>>> To ensure that the label on the top of the label stack is the Tim= ing >>>>>>> LSP Label, PHP MUST not be used. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 18] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 11. Entropy >>>>>>>=20 >>>>>>> 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 insid= e >>>>>>> Timing LSP [RFC6391]. >>>>>>>=20 >>>>>>> SB> This is incorrect - you mean that all msgs of the same timing >>>>>>> SB> flow need to have the same EL value. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 19] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 12. OAM, Control and Management >>>>>>>=20 >>>>>>> In order to monitor Timing LSPs and their encapsulated PWs, they M= UST >>>>>>> be able to carry OAM and management messages. These management >>>>>>> messages MUST be differentiated from Timing messages via already >>>>>>> defined IETF methods. >>>>>>>=20 >>>>>>> For example BFD [RFC5880], [RFC5884] and LSP-Ping [RFC4389] MAY r= un >>>>>>> over PTP LSPs via UDP/IP encapsulation or via GAL/G-ACH. These >>>>>>> Management protocols can easily be identified by the UDP Destinat= ion >>>>>>> Port number or by GAL/G-ACH respectively. >>>>>>>=20 >>>>>>> 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 g= oing >>>>>>> to be deprecated by IETF). In this case G-ACH, PW label (TTL=3D1= ) or >>>>>>> GAL-ACH are used to identify such management messages. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 20] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 13. QoS Considerations >>>>>>>=20 >>>>>>> In network deployments where not every LSR/LER is Timing-aware, i= t is >>>>>>> important to reduce the impact of the non-Timing-aware LSR/LERs o= n >>>>>>> the timing recovery in the slave clock. The Timing messages are t= ime >>>>>>> critical and must be treated with the highest priority. Therefor= e >>>>>>> Timing over MPLS messages must be treated with the highest priori= ty >>>>>>> in the routers. This can be achieved by proper setup of Timing L= SPs. >>>>>>>=20 >>>>>>> It is recommended that the Timing LSPs are setup or configured >>>>>>> properly to indicate EF-PHB [RFC3246]for the CoS and Green [RFC26= 97] >>>>>>> for drop eligibility. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 21] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 14. FCS and Checksum Recalculation >>>>>>>=20 >>>>>>> When time-stamp generation and timing packet adjustment is perfor= med >>>>>>> near the physical port hardware, the process MUST include >>>>>>> recalculation of the Ethernet FCS. >>>>>>>=20 >>>>>>> SB> The above is confusing - an LSR always recomputes the link layer= >>>>>>> SB> CRC which may or may not be Ethernet. >>>>>>>=20 >>>>>>> Also FCS retention for the >>>>>>> payload Ethernet described in [RFC4720] MUST NOT be used. >>>>>>>=20 >>>>>>> For UDP/IP encapsulation mode of Timing over MPLS, the UDP checks= um >>>>>>> may be required as per UDP transport standards. >>>>>>>=20 >>>>>>> SB> You really need to be working on getting the IPv6 C?S computatio= n >>>>>>> SB> removed from PTP msgs. >>>>>>>=20 >>>>>>> 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 f= rom >>>>>>> upstream and recalculate the checksum completely on transmission t= o >>>>>>> downstream node after Time stamping or Correction Field update. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 22] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 15. Behavior of LER/LSR >>>>>>>=20 >>>>>>> Timing-capable/aware LERs and LSRs are routers that have one or m= ore >>>>>>>=20 >>>>>>> SB> You mean physical interfaces? >>>>>>>=20 >>>>>>> interfaces that can perform Timing operations (OC/BC/TC) on Timin= g >>>>>>> packets and are configured to do so. Timing-capable/aware LERs a= nd >>>>>>> LSRs can advertise their Timing-capability per-interface via cont= rol >>>>>>> plane such as OSPF or IS-IS. >>>>>>> SB> ISIS and OSPF are routing protocols. >>>>>>>=20 >>>>>>> The Timing-capable/aware LERs can then >>>>>>> signals Timing LSPs via RSVP-TE signaling. Alternatively the Tim= ing >>>>>>> capability of LER and LSRs may be configured in a centralized >>>>>>> controller and the Timing LSP may be setup using manual configura= tion >>>>>>> or other methods such as SDN. >>>>>>>=20 >>>>>>> SB> it can also be configured individually rather then through >>>>>>> SB> a cebtral controllwe >>>>>>>=20 >>>>>>> 15.1. Behavior of Timing-capable/aware LER >>>>>>>=20 >>>>>>> When a Timing-capable/aware LER behaves as a Transparent clock an= d >>>>>>> receives a Timing message from a Timing-capable/aware non-MPLS >>>>>>> interface, the LER updates the Correction Field (CF) and encapsul= ates >>>>>>> and forwards the timing message over previously established Timin= g >>>>>>> LSP. >>>>>>>=20 >>>>>>> SB> You need to call out the details so that people properly >>>>>>> SB> understand the definition of the new LSP. >>>>>>>=20 >>>>>>> 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 messa= ge >>>>>>> to a non-MPLS interface. >>>>>>>=20 >>>>>>> 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 t= he >>>>>>> LERs Boundary clock processing module. Also when a Timing messag= e is >>>>>>> received from a Timing- capable/aware MPLS interface, the LER >>>>>>> Timestamps the Timing packet and sends it to the LERs Boundary cl= ock >>>>>>> processing module. >>>>>>>=20 >>>>>>> When a Timing-capable/aware LER behaves as an Ordinary Clock towa= rd >>>>>>> the MPLS network, and receives a Timing message from a Timing- >>>>>>> capable/aware MPLS interface, the LER Timestamps the Timing packe= t >>>>>>> and sends it to the LERs Ordinary clock processing module. >>>>>>>=20 >>>>>>> 15.2. Behavior of Timing-capable/aware LSR >>>>>>>=20 >>>>>>> When a Timing-capable/aware LSR behaves as a Transparent clock an= d >>>>>>> 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. >>>>>>>=20 >>>>>>> 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 ov= er >>>>>>> another (or the same) MPLS interface. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 23] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 15.3. Behavior of non-Timing-capable/aware LSR >>>>>>>=20 >>>>>>> It is most beneficial when all LSRs in the path of a Timing LSP b= e >>>>>>> timing-Capable/aware LSRs. This would ensure the highest quality= >>>>>>> time and clock synchronization by Timing Slave Clocks. However, t= his >>>>>>> specification does not mandate that all LSRs in path of a Timing L= SP >>>>>>> be Timing- capable/aware. >>>>>>>=20 >>>>>>> Non-Timing-capable/aware LSRs just switch the packets encapsulate= d 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 Traf= fic >>>>>>> Class (TC) marking. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 24] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 16. Other considerations >>>>>>>=20 >>>>>>> [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/awar= e >>>>>>> routers/ switches. This means that two adjacent LSRs may be enga= ged >>>>>>> in a peer delay measurement. >>>>>>>=20 >>>>>>> For transporting such peer delay measurement messages a single-ho= p >>>>>>> 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 t= he >>>>>>> two routers is Ethernet. >>>>>>>=20 >>>>>>> In Peer-to-peer transparent clocking (P2P TC), a Timing-capable/ w= are >>>>>>> routers/switches MUST maintain a list of all the neighbors it nee= ds >>>>>>> to send a PDelay_Req to, where each neighbor corresponds to a tim= ing >>>>>>> LSP. >>>>>>>=20 >>>>>>> The use of Explicit Null Label (Label=3D 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. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 25] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 17. Security Considerations >>>>>>>=20 >>>>>>> MPLS PW security considerations in general are discussed in [RFC3= 985] >>>>>>> and [RFC4447],and those considerations also apply to this documen= t. >>>>>>>=20 >>>>>>> An experimental security protocol is defined in [IEEE-1588].The P= TP >>>>>>> security extension and protocol provides group source authenticat= ion, >>>>>>> message integrity, and replay attack protection for PTP messages.= >>>>>>>=20 >>>>>>> When the MPLS network (provider network) serves multiple customer= s, >>>>>>> it is important to maintain and process each customers clock and >>>>>>> Timing messages separately from other customers to ensure there i= s no >>>>>>> cross- customer effect. For example if an LER BC is synchronized= to >>>>>>> a specific grandmaster, belonging to customer A, then the LER MUS= T >>>>>>> use that BC clock only for customer A to ensure that customer A >>>>>>> cannot attack other customers by manipulating its time. >>>>>>>=20 >>>>>>> Timing messages MAY be encrypted or authenticated, provided that t= he >>>>>>> LERs/LSRs that are Timing capable/aware can authenticate/ decrypt= the >>>>>>> timing messages. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 26] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 18. Acknowledgements >>>>>>>=20 >>>>>>> The authors would like to thank Ron Cohen, Yaakov Stein, Tal Mizr= ahi, >>>>>>> Stefano Ruffini, Peter Meyer, and other members of IETF for revie= wing >>>>>>> and providing feedback on this draft. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 27] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 19. IANA Considerations >>>>>>>=20 >>>>>>> There are no IANA requirements in this specification. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 28] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 20. References >>>>>>>=20 >>>>>>> 20.1. Normative References >>>>>>>=20 >>>>>>> [IEEE-1588] >>>>>>> IEEE 1588-2008, "IEEE Standard for a Precision Clock >>>>>>> Synchronization Protocol for Networked Measurement and= >>>>>>> Control Systems". >>>>>>>=20 >>>>>>> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >>>>>>> Requirement Levels", BCP 14, RFC 2119, March 1997. >>>>>>>=20 >>>>>>> [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to= - >>>>>>> Edge (PWE3) Architecture", RFC 3985, March 2005. >>>>>>>=20 >>>>>>> [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discov= ery >>>>>>> Proxies (ND Proxy)", RFC 4389, April 2006. >>>>>>>=20 >>>>>>> [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G= . >>>>>>> Heron, "Pseudowire Setup and Maintenance Using the Lab= el >>>>>>> Distribution Protocol (LDP)", RFC 4447, April 2006. >>>>>>>=20 >>>>>>> [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, >>>>>>> "Encapsulation Methods for Transport of Ethernet over M= PLS >>>>>>> Networks", RFC 4448, April 2006. >>>>>>>=20 >>>>>>> [RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire >>>>>>> Emulation Edge-to-Edge (PWE3) Frame Check Sequence >>>>>>> Retention", RFC 4720, November 2006. >>>>>>>=20 >>>>>>> [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circu= it >>>>>>> Connectivity Verification (VCCV): A Control Channel fo= r >>>>>>> Pseudowires", RFC 5085, December 2007. >>>>>>>=20 >>>>>>> [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detect= ion >>>>>>> (BFD)", RFC 5880, June 2010. >>>>>>>=20 >>>>>>> [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow= , >>>>>>> "Bidirectional Forwarding Detection (BFD) for MPLS Lab= el >>>>>>> Switched Paths (LSPs)", RFC 5884, June 2010. >>>>>>>=20 >>>>>>> 20.2. Informative References >>>>>>>=20 >>>>>>> [I-D.ietf-pwe3-fat-pw] >>>>>>> Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Reg= an, >>>>>>> J., and S. Amante, "Flow Aware Transport of Pseudowire= s >>>>>>> over an MPLS Packet Switched Network", >>>>>>> draft-ietf-pwe3-fat-pw-07 (work in progress), July 201= 1. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 29] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> [ISO] ISO/IEC 10589:1992, "Intermediate system to Intermedia= te >>>>>>> system routeing information exchange protocol for use i= n >>>>>>> conjunction with the Protocol for providing the >>>>>>> Connectionless-mode Network Service (ISO 8473)". >>>>>>>=20 >>>>>>> [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP an= d >>>>>>> dual environments", RFC 1195, December 1990. >>>>>>>=20 >>>>>>> [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 199= 8. >>>>>>>=20 >>>>>>> [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color= >>>>>>> Marker", RFC 2697, September 1999. >>>>>>>=20 >>>>>>> [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boud= ec, >>>>>>> J., Courtney, W., Davari, S., Firoiu, V., and D. >>>>>>> Stiliadis, "An Expedited Forwarding PHB (Per-Hop >>>>>>> Behavior)", RFC 3246, March 2002. >>>>>>>=20 >>>>>>> [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Enginee= ring >>>>>>> (TE) Extensions to OSPF Version 2", RFC 3630, >>>>>>> September 2003. >>>>>>>=20 >>>>>>> [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermedia= te >>>>>>> System (IS-IS) Extensions for Traffic Engineering (TE)= ", >>>>>>> RFC 3784, June 2004. >>>>>>>=20 >>>>>>> [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S= . >>>>>>> Shaffer, "Extensions to OSPF for Advertising Optional >>>>>>> Router Capabilities", RFC 4970, July 2007. >>>>>>>=20 >>>>>>> [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate= >>>>>>> System to Intermediate System (IS-IS) Extensions for >>>>>>> Advertising Router Information", RFC 4971, July 2007. >>>>>>>=20 >>>>>>> [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 200= 8. >>>>>>>=20 >>>>>>> [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic >>>>>>> Engineering", RFC 5305, October 2008. >>>>>>>=20 >>>>>>> [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, >>>>>>> "Traffic Engineering Extensions to OSPF Version 3", >>>>>>> RFC 5329, September 2008. >>>>>>>=20 >>>>>>> [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSP= F >>>>>>> for IPv6", RFC 5340, July 2008. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 30] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Net= work >>>>>>> Time Protocol Version 4: Protocol and Algorithms >>>>>>> Specification", RFC 5905, June 2010. >>>>>>>=20 >>>>>>> [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Reg= an, >>>>>>> J., and S. Amante, "Flow-Aware Transport of Pseudowire= s >>>>>>> over an MPLS Packet Switched Network", RFC 6391, >>>>>>> November 2011. >>>>>>>=20 >>>>>>> [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., a= nd >>>>>>> L. Yong, "The Use of Entropy Labels in MPLS Forwarding= ", >>>>>>> RFC 6790, November 2012. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 31] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 1. Routing extensions for Timing-aware Routers >>>>>>>=20 >>>>>>> MPLS-TE routing relies on extensions to OSPF [RFC2328] [RFC5340] a= nd >>>>>>> IS-IS [ISO] [RFC1195] in order to advertise Traffic Engineering (= TE) >>>>>>> link information used for constraint-based routing. >>>>>>>=20 >>>>>>> Indeed, it is useful to advertise data plane TE router link >>>>>>> capabilities, such as the capability for a router to be Timing-aw= are. >>>>>>> This capability MUST then be taken into account during path >>>>>>> computation to prefer or even require links that advertise themse= lves >>>>>>> as Timing-aware. In this way the path can ensure the entry and e= xit >>>>>>> points into the LERs and, if desired, the links into the LSRs are= >>>>>>> able to perform port based time-stamping thus minimizing their im= pact >>>>>>> on the performance of the slave clock. >>>>>>>=20 >>>>>>> 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: >>>>>>>=20 >>>>>>> o Capable of processing PTP, NTP or other Timing flows >>>>>>>=20 >>>>>>> o Capable of performing Transparent Clock operation >>>>>>>=20 >>>>>>> o Capable of performing Boundary Clock operation >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 32] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> 2. Signaling Extensions for Creating Timing LSPs >>>>>>>=20 >>>>>>> RSVP-TE signaling MAY be used to setup the timing LSPs. When RSV= P-TE >>>>>>> is used to setup Timing LSPs, some information that indicates tha= t >>>>>>> the LSP is carrying Timing flows MUST be included in the new >>>>>>> Extensions to RSVP-TE: >>>>>>>=20 >>>>>>> The following information MAY also be included in the new Extensi= ons >>>>>>> to RSVP-TE: >>>>>>>=20 >>>>>>> o Offset from Bottom of Stack (BoS) to the start of the Time-sta= mp >>>>>>> field >>>>>>>=20 >>>>>>> o Number of VLANs in case of PW encapsulation >>>>>>>=20 >>>>>>> o Timestamp field Type >>>>>>>=20 >>>>>>> * Correction Field, Timestamp >>>>>>>=20 >>>>>>> o Timestamp Field format >>>>>>>=20 >>>>>>> * 64-bit PTPv1, 80-bit PTPv2, 32-bit NTP, 64-bit NTP, 128-bit= >>>>>>> NTP, etc. >>>>>>>=20 >>>>>>> Note that in case the above optional information is signaled with= >>>>>>> RSVP-TE for a Timing LSP, all the Timing packets carried in that L= SP >>>>>>> must have the same signaled characteristics. For example if >>>>>>> Timestamp format is signaled as 64-bit PTPv1, then all Timing pac= kets >>>>>>> must use 64-bit PTPv1 time-stamp. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 33] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> Authors' Addresses >>>>>>>=20 >>>>>>> Shahram Davari >>>>>>> Broadcom Corp. >>>>>>> San Jose, CA 95134 >>>>>>> USA >>>>>>>=20 >>>>>>> Email: davari@broadcom.com >>>>>>>=20 >>>>>>>=20 >>>>>>> Amit Oren >>>>>>> Broadcom Corp. >>>>>>> San Jose, CA 95134 >>>>>>> USA >>>>>>>=20 >>>>>>> Email: amito@broadcom.com >>>>>>>=20 >>>>>>>=20 >>>>>>> Manav Bhatia >>>>>>> Alcatel-Lucent >>>>>>> Bangalore, >>>>>>> India >>>>>>>=20 >>>>>>> Email: manav.bhatia@alcatel-lucent.com >>>>>>>=20 >>>>>>>=20 >>>>>>> Peter Roberts >>>>>>> Alcatel-Lucent >>>>>>> Kanata, >>>>>>> Canada >>>>>>>=20 >>>>>>> Email: peter.roberts@alcatel-lucent.com >>>>>>>=20 >>>>>>>=20 >>>>>>> Laurent Montini >>>>>>> Cisco Systems >>>>>>> San Jose CA >>>>>>> USA >>>>>>>=20 >>>>>>> Email: lmontini@cisco.com >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 34] >>>>>>> Internet-Draft Transporting Timing over MPLS June 2= 013 >>>>>>>=20 >>>>>>>=20 >>>>>>> Luca >>>>>>> Cisco Systems >>>>>>> San Jose CA >>>>>>> USA >>>>>>>=20 >>>>>>> Email: lmartini@cisco.com >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Davari, et al. Expires December 17, 2013 [Page= 35] >>>>>>> -- >>>>>>> For corporate legal information go to: >>>>>>>=20 >>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> TICTOC mailing list >>>>>>> TICTOC@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/tictoc >>>>>> This e-mail message is intended for the recipient only and contains >>>> information which is CONFIDENTIAL and which may be proprietary to ECI >>>> Telecom. If you have received this transmission in error, please inform= us by e- >>>> mail, phone or fax, and then delete the original and all copies thereof= . >>>>>> _______________________________________________ >>>>>> mpls mailing list >>>>>> mpls@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mpls >>>>> . >>>>=20 >>>> -- >>>> For corporate legal information go to: >>>>=20 >>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>=20 >>>> _______________________________________________ >>>> TICTOC mailing list >>>> TICTOC@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tictoc >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> TICTOC mailing list >>>> TICTOC@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tictoc >>>=20 >>> This e-mail message is intended for the recipient only and contains info= rmation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. >> . >=20 >=20 > -- > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 > This e-mail message is intended for the recipient only and contains inform= ation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If y= ou have received this transmission in error, please inform us by e-mail, pho= ne or fax, and then delete the original and all copies thereof. >=20