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

Versions: 00 01 02 03 04 05 06 07 draft-ietf-mpls-residence-time

MPLS Working Group                                             G. Mirsky
Internet-Draft                                                S. Ruffini
Intended status: Standards Track                                Ericsson
Expires: April 26, 2015                                         J. Drake
                                                        Juniper Networks
                                                               S. Bryant
                                                           Cisco Systems
                                                           A. Vainshtein
                                                             ECI Telecom
                                                        October 23, 2014


               Residence Time Measurement in MPLS network
                  draft-mirsky-mpls-residence-time-03

Abstract

   This document specifies G-ACh based Residence Time Measurement and
   how it can be used by time synchronization protocols being
   transported over MPLS domain.

Status of This Memo

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

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

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

   This Internet-Draft will expire on April 26, 2015.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Mirsky, et al.           Expires April 26, 2015                 [Page 1]


Internet-Draft         Residence Time Measurement           October 2014


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions used in this document . . . . . . . . . . . .   3
       1.1.1.  Terminology . . . . . . . . . . . . . . . . . . . . .   3
       1.1.2.  Requirements Language . . . . . . . . . . . . . . . .   3
   2.  Residence Time Measurement  . . . . . . . . . . . . . . . . .   3
   3.  G-ACh for Residence Time Measurement  . . . . . . . . . . . .   4
   4.  Control Plane Theory of Operation . . . . . . . . . . . . . .   5
     4.1.  RTM Capability sub-TLV  . . . . . . . . . . . . . . . . .   5
     4.2.  RTM Capability Advertisement in OSPFv2  . . . . . . . . .   6
     4.3.  RTM Capability Advertisement in OSPFv3  . . . . . . . . .   6
     4.4.  RTM Capability Advertisement in IS-IS . . . . . . . . . .   6
     4.5.  RSVP-TE Control Plane Operation to Support RTM  . . . . .   7
   5.  Data Plane Theory of Operation  . . . . . . . . . . . . . . .   8
   6.  Applicable PTP Scenarios  . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  New RTM G-ACh . . . . . . . . . . . . . . . . . . . . . .   8
     7.2.  New RTM TLV Registry  . . . . . . . . . . . . . . . . . .   9
     7.3.  RTM Capability sub-TLV  . . . . . . . . . . . . . . . . .   9
     7.4.  IS-IS RTM Application ID  . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     10.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Time synchronization protocols, Network Time Protocol version 4
   (NTPv4) [RFC5905] and Precision Time Protocol (PTP) Version 2, a.k.a.
   IEEE-1588 v.2, can be used to syncronized clocks across network
   domain.  In some scenarios calculation of time packet of time
   syncronization protocol spends within a node, called Residence Time,
   can improve accuracy of clock syncronization.  This document defines
   new Generalized Associated Channel (G-ACh) that can be used in Multi-
   Protocol Label Switching (MPLS) network to measure Residence Time
   over Label Switched Path (LSP).  Transport of packets of a time
   synchronization protocol over MPLS domain is outside of scope of this
   document.





Mirsky, et al.           Expires April 26, 2015                 [Page 2]


Internet-Draft         Residence Time Measurement           October 2014


1.1.  Conventions used in this document

1.1.1.  Terminology

   MPLS: Multi-Protocol Label Switching

   ACH: Associated Channel

   TTL: Time-to-Live

   G-ACh: Generic Associated Channel

   GAL: Generic Associated Channel Label

   NTP: Network Time Protocol

   ppm: part per million

   PTP: Precision Time Protocol

   LSP: Label Switched Path

   LSR: Label Switched Router

   OAM: Operations, Administration, and Maintenance

   RTM: Residence Time Measurement

   IGP: Internal Gateway Protocol

1.1.2.  Requirements Language

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

2.  Residence Time Measurement

   Packet Loss and Delay Measurement for MPLS Networks [RFC6374] can be
   used to measure one-way or two-way end-to-end propagation delay over
   LSP or PW.  But none of these metrics is useful for time
   syncronization across a network.  For example, PTPv2 uses "residence
   time", time it takes for a PTPv2 event packet to transit a node.  The
   residence times are accumulated in the correctionField of the PTP
   event messages or of the associated follow-up messages (or Delay_Resp
   message associated with the Delay_Req message) in case of two-step




Mirsky, et al.           Expires April 26, 2015                 [Page 3]


Internet-Draft         Residence Time Measurement           October 2014


   clocks.  The residence time values are specific to each output PTP
   port and message.

   Note the delay of propagation over a link connected to a port
   receiving the PTP event message is handled by IEEE 1588
   [IEEE.1588.2008] by means of specific messages, Pdelay_Req and
   Pdelay_Resp,or Delay_Req and Delay_Resp depending on the applicable
   delay mechanism, peer-to-peer or delay request-response mechanism
   respectively.

   This document proposes mechanism to accumulate packet residence time
   from all LSRs that support the mechanism across the particular LSP.

3.  G-ACh for Residence Time Measurement

   RFC 5586 [RFC5586] and RFC 6423 [RFC6423] extended applicability of
   PW Associated Channel (ACH) [RFC5085] to LSPs.  G-ACh presents
   mechanism to transport OAM and other control messages and trigger
   their processing by arbitrary transient LSRs through controlled use
   of Time-to-Live (TTL) value.

   Packet format for Residence Time Measurement (RTM) presented in
   Figure 1

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 1|Version|   Reserved    |          RTM Channel          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                     Scratch Pad                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Type               |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Value                             |
    ~                                                               ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 1: G-ACh packet format for Residence Time Measurement

   The Version field is set to 0, as defined in RFC 4385 [RFC4385].  The
   Reserved field must be set to 0 on transmit and ignored on receipt.
   The RTM G-ACh field, value to be allocated by IANA, identifies the
   packet as such.  The Scratch Pad field is 8 octets in length and is
   used to accumulate the residence time spent in LSRs transited by the
   packet on its path from ingress LSR to egress LSR.  Its format is
   IEEE double precision and its units are nanoseconds.



Mirsky, et al.           Expires April 26, 2015                 [Page 4]


Internet-Draft         Residence Time Measurement           October 2014


   The Type field identifies type of Value that the TLV carries.  IANA
   will be asked to create sub-registry in Generic Associated Channel
   (G-ACh) Parameters Registry called "MPLS RTM TLV Registry".  The
   Length field is number of octets of the Value field.  The optional
   Value field may be used to carry a packet of a given time
   synchronization protocol.  If the packet carried in the RTM message,
   then it accordingly identified by distinct Type, and may be NTP
   [RFC5905] or PTP [IEEE.1588.2008].  It is important to note that the
   packet may be authenticated or encrypted and carried over MPLS LSP
   edge to edge unchanged while residence time being accumulated in the
   Scratch Pad field.  The TLV MUST be included in the RTM.

4.  Control Plane Theory of Operation

   The operation of RTM depends upon TTL expiry to deliver an RTM packet
   from one RTM capable interface to the next along the path from
   ingress LSR to egress LSR, which means that an LSR with RTM capable
   interfaces needs to be able to compute a TTL which will cause the
   expiry of an RTM packet at the next LSR with RTM capable interfaces.

   However, because of Equal Cost Multipath, labels distributed by LDP
   do not instantiate a single path between a given ingress/egress LSR
   pair but rather a graph and different flows will take different paths
   through this graph.  This means one doesn't know the path that RTM
   packets will take or even if they all take the same path.  So, in an
   environment in which not all interfaces in an IGP domain support RTM,
   it is effectively impossible to use TTL expiry to deliver RTM packets
   and hence RTM cannot be used for LSPs instantiated using LDP.  In the
   special but important case of environment in which all interfaces in
   an IGP domain support RTM, setting the TTL to 1 will always cause the
   expiry of an RTM packet on the next RTM capable downstream LSR and
   hence in such an environment, RTM can be used for LSPs instantiated
   using LDP.

   Generally speaking, RTM is more useful for an LSP instantiated using
   RSVP-TE [RFC3209] because the LSP's path can be known.

4.1.  RTM Capability sub-TLV

   Format for RTM Capailities sub-TLV presented in Figure 2











Mirsky, et al.           Expires April 26, 2015                 [Page 5]


Internet-Draft         Residence Time Measurement           October 2014


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Type(TBA5)          |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | RTM |                       Reserved                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 2: RTM Capability sub-TLV

   o  Type value will be assigned by IANA from appropriate registries.

   o  Length MUST be set to 4.

   o  RTM is three bit long bit map field.

   o  Reserved field must e set to all zeroes on transmit and ignored on
      receive.

4.2.  RTM Capability Advertisement in OSPFv2

   The capability to support RTM on a particular link advertised in the
   OSPFv2 Extended Link Opaque LSA [I-D.ietf-ospf-prefix-link-attr] as
   RTM Capability sub-TLV, presented in Figure 2, of the OSPFv2 Extended
   Link TLV.

   Type value will be assigned by IANA from the OSPF Extended Link TLV
   Sub-TLVs registry that will be created per
   [I-D.ietf-ospf-prefix-link-attr] request.

4.3.  RTM Capability Advertisement in OSPFv3

   The capability to support RTM on a particular link in the OSPFv3 can
   be advertised by including RTM Capability sub-TLV defined in
   Section 4.2 in the following TLVs defined in
   [I-D.ietf-ospf-ospfv3-lsa-extend] Intra-Area-Prefix TLV, IPv6 Link-
   Local Address TLV, IPv4 Link-Local Address TLV when these are
   included in E-Link-LSA.

4.4.  RTM Capability Advertisement in IS-IS

   The RTM capability logically belongs to a group of parameters
   characterized as "generic information not directly related to the
   operation of the IS-IS protocol" [RFC6823].  Hence the capability to
   process RTM messages can be advertised by including RTM Capability
   sub-TLV in GENINFO TLV [RFC6823].  The S bit of Flags MUST be cleared
   to prevent the RTM Capability sub-TLV from leaking between levels.
   The D bit of the Flags field MUST be cleared as well.  The I bit and



Mirsky, et al.           Expires April 26, 2015                 [Page 6]


Internet-Draft         Residence Time Measurement           October 2014


   the V bit MUST be set accordingly depending on whether RTM capability
   being advertised for IPv4 or IPv6 interface of the node.  Application
   ID (TBA6) will be assigned from the Application Identifiers for TLV
   251 IANA registry.  The RTM Capability sub-TLV, presented in
   Figure 2, MUST be included in GENINFO TLV in Application Specific
   Information.

4.5.  RSVP-TE Control Plane Operation to Support RTM

   Though RTM capability is per interface throughout this document we
   will refer to an LSR as RTM capable LSR when:

   o  ingress LSR's LSP interface is RTM capable;

   o  transient LSR's ingress and egress interfaces for the given LSP
      are RTM capable;

   o  egress LSR's egress interface is RTM capable.

   An ingress LSR that wishes to perform RTM along a path through an
   MPLS network to an egress LSR verifies that the selected egress LSR
   has an interface that supports RTM via the egress LSR's advertisement
   of the RTM Capability sub-TLV.  In the Path message that the ingress
   LSR uses to instantiate the LSP to that egress LSR it places
   initialized Record Route and RTM Set (see below) Objects, which tell
   the egress LSR that RTM is desired for this LSP.

   In the Resv message that the egress LSR sends in response to the
   received Path message, it includes initialized Record Route and RTM
   Set objects.  The latter object will be defined in a subsequent
   version of this document and it contains an ordered list, from egress
   LSR to ingress LSR, of the RTM capable LSRs along the LSP's path.
   Each such LSR will use the ID of the first LSR in the RTM Set Object
   in conjunction with the Record Route Object to compute the hop count
   to its downstream LSR with reacheable RTM capable interface.  It will
   also insert its ID at the beginning of the RTM Set Object before
   forwarding the Resv upstream.

   After the ingress LSR receives the Resv, it will begin sending RTM
   packets to the first RTM capable LSR on the LSP's path.  Each RTM
   packet has its Scratch Pad field initialized and its TTL set to
   expire on that LSR.

   It should be noted that RTM can also be used for LSPs instantiated
   using [RFC3209] in an environment in which all interfaces in an IGP
   support RTM.  In this case the RTM Set Object is not used.





Mirsky, et al.           Expires April 26, 2015                 [Page 7]


Internet-Draft         Residence Time Measurement           October 2014


5.  Data Plane Theory of Operation

   After instantiating an LSP for a path using RSVP-TE [RFC3209] as
   described in Section 4.5 or if this is the special case of
   homogeneous RTM-capable IP/MPLS domain discussed in the last
   paragraph of Section 4, ingress LSR MAY begin sending RTM packets to
   the first downstream RTM capable LSR on that path.  Each RTM packet
   has its Scratch Pad field initialized and its TTL set to expire on
   the next downstream RTM capable LSR.  Each RTM capable LSR on the
   explicit path receives an RTM packet and records the time at which it
   receives that packet as well as the time at which it transmits that
   packet; this should be done as close to the physical layer as
   possible.  Just prior to sending that packet, it takes the difference
   between those two times and adds it to the value in the Scratch Pad
   field.  Note, for the purpose of calculating a residence time, a free
   running clock may be sufficient, as, for example, 4.6 ppm accuracy
   leads to 4,6 ns error for residence time in the order of 1 ms.

   The RTM capable LSR also sets the RTM packet's TTL to expire on the
   next downstream RTM capable LSR.

   The egress LSR may then use the value in the Scratch Pad field to
   perform time correction.  For example, the egress LSR may be a PTP
   Boundary Clock synchronized to a Master Clock and will use the value
   in the Scratch Pad Field to update PTP's Correction Field.

6.  Applicable PTP Scenarios

   The proposed approach can be directly integrated in a PTP network
   based on delay request-response mechanism.  The RTM capable LSR nodes
   act as end-to-end transparent clocks, and typically boundary clocks,
   at the edges of the MPLS network, use the value in the Scratch Pad
   field to update the correctionField of the corresponding PTP event
   packet prior to performing the usual PTP processing.

   Under certain assumptions the proposed solution in a network where
   peer delay mechanism is used is also possible.  The solution in this
   case requires the definition of a specific protocol to be used to
   calculate the link delays according to a peer delay link measurement
   approach.  This is not described in this version of the draft.

7.  IANA Considerations

7.1.  New RTM G-ACh

   IANA is requested to reserve a new G-ACh as follows:





Mirsky, et al.           Expires April 26, 2015                 [Page 8]


Internet-Draft         Residence Time Measurement           October 2014


          +-------+----------------------------+---------------+
          | Value |        Description         | Reference     |
          +-------+----------------------------+---------------+
          | TBA1  | Residence Time Measurement | This document |
          +-------+----------------------------+---------------+

                  Table 1: New Residence Time Measurement

7.2.  New RTM TLV Registry

   IANA is requested to create sub-registry in Generic Associated
   Channel (G-ACh) Parameters Registry called "MPLS RTM TLV Registry".
   All code points within this registry shall be allocated according to
   the "IETF Review" procedure as specified in [RFC5226] This document
   defines the following new values RTM TLV type

                  +-------+-------------+---------------+
                  | Value | Description | Reference     |
                  +-------+-------------+---------------+
                  | 0     |   Reserved  | This document |
                  | TBA2  |  No payload | This document |
                  | TBA3  |    PTPv2    | This document |
                  | TBA4  |     NTP     | This document |
                  +-------+-------------+---------------+

                           Table 2: RTM TLV Type

7.3.  RTM Capability sub-TLV

   IANA is requested to assign a new type for RTM Capability sub-TLV
   from future OSPF Extended Link TLV Sub-TLVs registry as follows:

                +-------+----------------+---------------+
                | Value |  Description   | Reference     |
                +-------+----------------+---------------+
                | TBA5  | RTM Capability | This document |
                +-------+----------------+---------------+

                      Table 3: RTM Capability sub-TLV

7.4.  IS-IS RTM Application ID

   IANA is requested to assign a new Application ID for RTM from the
   Application Identifiers for TLV 251 registry as follows:







Mirsky, et al.           Expires April 26, 2015                 [Page 9]


Internet-Draft         Residence Time Measurement           October 2014


                  +-------+-------------+---------------+
                  | Value | Description | Reference     |
                  +-------+-------------+---------------+
                  | TBA6  |     RTM     | This document |
                  +-------+-------------+---------------+

                     Table 4: IS-IS RTM Application ID

8.  Security Considerations

   Routers that support Residence Time Measurement are subject to the
   same security considerations as defined in [RFC5586] and [RFC6423].

9.  Acknowledgements

   TBD

10.  References

10.1.  Normative References

   [I-D.ietf-ospf-ospfv3-lsa-extend]
              Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3
              LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-04
              (work in progress), September 2014.

   [I-D.ietf-ospf-prefix-link-attr]
              Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
              Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
              Advertisement", draft-ietf-ospf-prefix-link-attr-01 (work
              in progress), September 2014.

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

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

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
              (TE) Extensions to OSPF Version 2", RFC 3630, September
              2003.




Mirsky, et al.           Expires April 26, 2015                [Page 10]


Internet-Draft         Residence Time Measurement           October 2014


   [RFC3784]  Smit, H. and T. Li, "Intermediate System to Intermediate
              System (IS-IS) Extensions for Traffic Engineering (TE)",
              RFC 3784, June 2004.

   [RFC4385]  Bryant, S., Swallow, G., Martini, L., and D. McPherson,
              "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
              Use over an MPLS PSN", RFC 4385, February 2006.

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

   [RFC5329]  Ishiguro, K., Manral, V., Davey, A., and A. Lindem,
              "Traffic Engineering Extensions to OSPF Version 3", RFC
              5329, September 2008.

   [RFC5586]  Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
              Associated Channel", RFC 5586, June 2009.

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

   [RFC6423]  Li, H., Martini, L., He, J., and F. Huang, "Using the
              Generic Associated Channel Label for Pseudowire in the
              MPLS Transport Profile (MPLS-TP)", RFC 6423, November
              2011.

   [RFC6823]  Ginsberg, L., Previdi, S., and M. Shand, "Advertising
              Generic Information in IS-IS", RFC 6823, December 2012.

10.2.  Informative References

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", RFC 6374, September 2011.

Authors' Addresses

   Greg Mirsky
   Ericsson

   Email: gregory.mirsky@ericsson.com





Mirsky, et al.           Expires April 26, 2015                [Page 11]


Internet-Draft         Residence Time Measurement           October 2014


   Stefano Ruffini
   Ericsson

   Email: stefano.ruffini@ericsson.com


   John Drake
   Juniper Networks

   Email: jdrake@juniper.net


   Stewart Bryant
   Cisco Systems

   Email: stbryant@cisco.com


   Alexander Vainshtein
   ECI Telecom

   Email: Alexander.Vainshtein@ecitele.com





























Mirsky, et al.           Expires April 26, 2015                [Page 12]


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