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 E448C21F9AC4 for ; Sun, 4 Aug 2013 02:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 SbdV-VNsw74O for ; Sun, 4 Aug 2013 02:40:23 -0700 (PDT) Received: from nm48-vm2.bullet.mail.gq1.yahoo.com (nm48-vm2.bullet.mail.gq1.yahoo.com [67.195.87.190]) by ietfa.amsl.com (Postfix) with ESMTP id 41D4B21F9956 for ; Sun, 4 Aug 2013 02:40:18 -0700 (PDT) Received: from [98.137.12.63] by nm48.bullet.mail.gq1.yahoo.com with NNFMP; 04 Aug 2013 09:40:16 -0000 Received: from [98.136.164.77] by tm8.bullet.mail.gq1.yahoo.com with NNFMP; 04 Aug 2013 09:40:16 -0000 Received: from [127.0.0.1] by smtp239.mail.gq1.yahoo.com with NNFMP; 04 Aug 2013 09:40:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1375609216; bh=JyRw1/3tiObsThfCkXU5K0iKPNkWj626nUOoWjNweBY=; 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=D2XIbHKyq5RSyd62qy80wnlflXBkUd2GIAvz9iEtj+cekloqPfVdsMbO+Y0g3zfmTqX9Txrk5wInTDEEJE7ZM7GUm02xKlvftIGq3Q2cuoOjPFjfVY2XhYIC7uKHBw+kaofA8PN4g7SpXHHP+3+O0kTQN08O3OGDjSGjO9TSICI= X-Yahoo-Newman-Id: 288057.58595.bm@smtp239.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: SC5BptIVM1lCQhouG0U8uGHi65bxQXEUev1.flr0tBTrWtI z79mk8.GSMP6wU82FEGR7Vuwsljk2NFwmecWUrJ_d4mWOT_DKnclEClVY79G O1mqK_0uF0apW2rm2LaCPDN4WRaVJh2u6tgH2yB7gzlzT7cp03TYbrpJmw_I 39B6Z1qb1lORrhW7RNmCJ_uMOXgLT5_MPkQS8gQH9GHEOvJkq5mzxnnbjMgV KuCGSCTK5Fza3Hy00UYyOVh9n7.cv_edewfBErwwkj4uWWBfXGP8KPoo4dMr UJnk5qQ2WUGnLYSs65yTjdisamoCTxEazM_H4cJY6DyAay4NAhllOZ54fPOH NqH6x5fCodbSB3Svm149qi9OyxdjqbW2j7mNnnvvo9vmfFXC_fPCwMW0PuMr tdtlZNhJB.AK2GeffYOnUb36jrXEGK0K2t75jqKo9dS6N9DCwPnCcjIVn0HH pxHFOa2IxbD9jv_IEvezpcIR5UBrpLU6DpGZiyVJhKz5cDAZqpZh7CiaHXrd tR8hPudYClqChgLEunii0mnXiH9lkfQ4oM.hEOFI2w900ChU3iR32 X-Yahoo-SMTP: ygPrP9CswBCWPbPtKJlJyLY0KMlg X-Rocket-Received: from [192.168.0.103] (davarish@98.248.42.143 with ) by smtp239.mail.gq1.yahoo.com with SMTP; 04 Aug 2013 09:40:16 +0000 UTC References: <51FB7543.801@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: Sun, 4 Aug 2013 02:40:13 -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: Sun, 04 Aug 2013 09:40:28 -0000 Hi Sasha Perhaps you have not understood the draft well. The main reason that the dra= ft chose to use a dedicated LSP that is signaled via RSVPTE indicating it is= a timing LSP is to be backward compatible with non-1588 nodes. Such nodes s= imply 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 packet to CPU= . You can refer to the meeting notes. Regards, Shahram 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 "full int= eraction with MPLS architecture". >=20 > E.g., one of the objectives of the draft is to provide a technique that wo= uld be backward-compatible with old LSRs that cannot provide on-path support= 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 an= d hence require on-path support. >=20 > IMHO and FWIW, the MPLS data plane architecture allows just two methods fo= r making a transit LSR to provide special processing to a labeled packet: > - It would carry some kind of an "alert label" on top of the label stack a= nd, 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 the dra= ft looks somewhat in > E.g., I could not understand from the text whether BFD, LSP-Ping etc. OAM m= essages would be subjected to on-path support procedures for timing messages= or not. >=20 > My 2c, > Sasha >=20 >> -----Original Message----- >> From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf O= f >> 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.org; d= raft- >> 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. 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 >>=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 the >> easy identification of these PDUs at the port level to allow for port >>=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 MPLS >> 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 defined. >>=20 >> 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. >>=20 >> 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. >>=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 Internet- >> Drafts is at http://datatracker.ietf.org/drafts/current/. >>=20 >> 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." >>=20 >> This Internet-Draft will expire on December 17, 2013. >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 1] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=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 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. >>=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 [Page 2] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=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 [Page 3] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=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 [Page 4] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=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, 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. >>=20 >> [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. >>=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 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. >>=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 messages >> 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 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" >>=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 messages >> over MPLS. One is applicable to MPLS environment and the other one >> 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 [Page 5] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 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. >>=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 enable >> routers to distribute their Timing processing capabilities over MPLS >> to other routers. However such extensions are outside the scope of >> this document. >>=20 >> When signaling is used to setup the PTP LSP, Extensions to signaling >> 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 of >> 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 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. >>=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 6] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=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 Master >> 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 PTP >> 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 timing >> 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 (message >> type 0-3)that holds the accumulative transit time inside intermediate >> 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 [Page 7] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 3. Problem Statement >>=20 >> [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. >>=20 >> 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. >>=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 the >> 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 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. >>=20 >> 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. >>=20 >> SB> Needs a ref and I am sure many MPLS specialists will not understand >> 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 [Page 8] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=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 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. >>=20 >> Master/Slave clocks (OCs), Boundary Clocks (BC) and Transparent Clock >>=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 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. >>=20 >>=20 >> +--------+ +-------+ +-------+ +-------+ +--------+= >> |Switch, | | | | | | | |Switch, |= >> | Router |-----| LER |-----| LSR |-----| LER |-----| Router |= >> | | | OC | | TC | | OC | | |= >> +--------+ +-------+ +-------+ +-------+ +--------+= >> / \ >> +-------+ / \ +-------+ >> | LER | / \ | LER | >> | Master|---/ \---| Slave | >> | Clock | | Clock | >> +-------+ +-------+ >>=20 >> Figure (1) - Deployment example 1 of timing over MPLS network >>=20 >> 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. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 9] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> +--------+ +-------+ +-------+ +-------+ +--------+ >> |Switch, | | | | | | | |Switch, | >> | Router |-----| LER |-----| LSR |-----| LER |-----| Router | >> | OC/BC | | BC | | TC | | BC | | OC/BC | >> +--------+ +-------+ +-------+ +-------+ +--------+ >>=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 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. >>=20 >> +--------+ +-------+ +-------+ +-------+ +--------+= >> |Switch, | | | | | | | |Switch, |= >> | Router |-----| LER |-----| LSR |-----| LER |-----| Router |= >> |OC/TC/BC| | TC | | TC | | TC | |OC/TC/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 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. >>=20 >> +--------+ +-------+ +-------+ +-------+ +--------+ >> |Switch, | | | | | | | |Switch, | >> | Router |-----| LER |-----| LSR |-----| LER |-----| Router | >> | OC/BC | | BC | | BC | | BC | | OC/BC | >> +--------+ +-------+ +-------+ +-------+ +--------+ >>=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 services >> to multiple customers, each having their own Timing domain. >>=20 >> The Timing over MPLS architecture assumes full mesh of Timing LSPs >> 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 between >> two customer sites or a Multipoint Timing service between more than >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 10] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> two customer sites. >>=20 >> 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. >>=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 hardware >> 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 LSP >> 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] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=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 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. >>=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 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. >>=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 LERs >> MUST be co-routed. Alternatively, a single bidirectional co-routed >> 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 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. >>=20 >> 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. >>=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] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=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 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. >>=20 >> 6.1. Timing over UDP/IP over MPLS Encapsulation >>=20 >> 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. >>=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 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. >>=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 PTP >> MUST follow Annex F of [IEEE-1588]. >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 13] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=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 probably >> SB> simplify things by sayig that they are not used. >>=20 >> 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). >>=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, 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. >>=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] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=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 Timing >> 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 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). >>=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 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> SB> Are you saying that a timing P router has to be msg type sensitive? >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 15] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=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 yet! >>=20 >> In order to ensure continuous uninterrupted operation of slave >> clocks, usually as a general practice, slave clocks (or ports) track >> redundant master clocks. >>=20 >> 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). >>=20 >> 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. >>=20 >> 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. >>=20 >> 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). >>=20 >> 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. >>=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] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=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 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. >>=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] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 10. PHP >>=20 >> To ensure that the label on the top of the label stack is the Timing >> 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] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=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 inside >> 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] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 12. OAM, Control and Management >>=20 >> 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. >>=20 >> 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. >>=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 going >> 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] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 13. QoS Considerations >>=20 >> 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. >>=20 >> 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. >>=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] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 14. FCS and Checksum Recalculation >>=20 >> When time-stamp generation and timing packet adjustment is performed >> 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 checksum >> may be required as per UDP transport standards. >>=20 >> SB> You really need to be working on getting the IPv6 C?S computation >> 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 from >> upstream and recalculate the checksum completely on transmission to >> 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] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 15. Behavior of LER/LSR >>=20 >> Timing-capable/aware LERs and LSRs are routers that have one or more >>=20 >> SB> You mean physical interfaces? >>=20 >> 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. >>=20 >> 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. >>=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 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. >>=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 message >> 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 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. >>=20 >> 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. >>=20 >> 15.2. Behavior of Timing-capable/aware LSR >>=20 >> 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. >>=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 over >> another (or the same) MPLS interface. >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 23] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=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 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. >>=20 >> 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. >>=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] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=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/aware >> routers/ switches. This means that two adjacent LSRs may be engaged >> in a peer delay measurement. >>=20 >> 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. >>=20 >> 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. >>=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] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 17. Security Considerations >>=20 >> MPLS PW security considerations in general are discussed in [RFC3985] >> and [RFC4447],and those considerations also apply to this document. >>=20 >> 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. >>=20 >> 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. >>=20 >> Timing messages MAY be encrypted or authenticated, provided that the >> 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] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 18. Acknowledgements >>=20 >> 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. >>=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] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=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] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=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 Discovery >> 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 Label >> 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 MPLS >> 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 Circuit >> Connectivity Verification (VCCV): A Control Channel for >> Pseudowires", RFC 5085, December 2007. >>=20 >> [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection >> (BFD)", RFC 5880, June 2010. >>=20 >> [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 >> 20.2. Informative References >>=20 >> [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. >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 29] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> [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)". >>=20 >> [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and >> dual environments", RFC 1195, December 1990. >>=20 >> [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. >>=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 Boudec, >> 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 Engineering >> (TE) Extensions to OSPF Version 2", RFC 3630, >> September 2003. >>=20 >> [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate >> 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 2008. >>=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, "OSPF >> for IPv6", RFC 5340, July 2008. >>=20 >>=20 >>=20 >>=20 >> Davari, et al. Expires December 17, 2013 [Page 30] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network >> Time Protocol Version 4: Protocol and Algorithms >> Specification", RFC 5905, June 2010. >>=20 >> [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. >>=20 >> [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and >> 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] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 1. Routing extensions for Timing-aware Routers >>=20 >> 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. >>=20 >> 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. >>=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] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=20 >>=20 >> 2. Signaling Extensions for Creating Timing LSPs >>=20 >> 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: >>=20 >> The following information MAY also be included in the new Extensions >> to RSVP-TE: >>=20 >> o Offset from Bottom of Stack (BoS) to the start of the Time-stamp >> 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 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. >>=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] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=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] >=20 >> Internet-Draft Transporting Timing over MPLS June 2013 >>=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] >=20 >>=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 > 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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls