Network Working Group                                            Q. Wang
Internet-Draft                                                     X. Fu
Intended status: Standards Track                         ZTE Corporation
Expires: April 21, 2011                                     Oct 18, 2010


   GMPLS extensions to communicate latency as a TE performance metric
                 draft-wang-ccamp-latency-te-metric-00

Abstract

   Latency is such requirement that must be achieved according to the
   SLA signed between customers and service providers, so mechanism is
   needed to collect, compute and identify the latency by signaling and
   routing protocol.

   This document describes the requirement and method to compute and
   identify the latency by control plane in today's network which is
   consisted of packet transport network and optical transport network
   in order to meet the latency SLA of the customer.  This document also
   describes RSVP-TE signaling and OSPF routing extensions needed to
   support the computation and identification of latency.  These
   extensions are intended to advertise and convey the information of
   node latency and link latency as TE performance metric.

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 21, 2011.

Copyright Notice

   Copyright (c) 2010 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



Wang & Fu                Expires April 21, 2011                 [Page 1]


Internet-Draft     latency as a TE performance metric           Oct 2010


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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Conventions Used in This Document  . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  List of Acronyms . . . . . . . . . . . . . . . . . . . . .  5
   3.  Analysis of the Latency Measurement Mechanism  . . . . . . . .  5
     3.1.  Support of SLA . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Latency Value  . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Latency of Server Layer Network  . . . . . . . . . . . . .  7
     3.4.  Role of the Control Plane  . . . . . . . . . . . . . . . .  7
   4.  A New Latency Measurement Mechanism  . . . . . . . . . . . . .  8
     4.1.  Advertisement of the Latency Value . . . . . . . . . . . .  8
     4.2.  Latency Collection and Verification  . . . . . . . . . . .  8
   5.  Signaling and Routing Extensions to Support Latency
       Measurement  . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Routing Extensions to Support the Advertisement of
           Latency  . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.2.  Signaling Extensions to Support the Latency Measurement  . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
















Wang & Fu                Expires April 21, 2011                 [Page 2]


Internet-Draft     latency as a TE performance metric           Oct 2010


1.  Introduction

   In a network, latency, a synonym for delay, is an expression of how
   much time it takes for a packet of data to get from one designated
   point to another.  In some usages, latency is measured by sending a
   packet that is returned to the sender and the round-trip time is
   considered the latency.  In this document, we refer to the former
   expression.

   In many cases, latency is a sensitive topic.  For example, two stock
   exchanges, one in Beijing, which is a city of north China and another
   in Shenzhen, which is a city of south China.  Both of them need to
   synchronize with each other.  A little change may result in large
   loss.  So something SHOULD be assured that the network path latency
   MUST be limited to a value lower than the upper limit.  SLA contract
   which includes the requirement of latency is signed between service
   providers and customers.  In the future, latency demand will be
   needed by more and more customers.

   Measurement mechanism of link latency has been defined in many
   technologies.  For example, the measurement mechanism of link latency
   has been provided in ITU-T [G.8021] and [Y.1731] for Ethernet.  The
   link transit latency between two Ethernet equipments can be measured
   by using this mechanism.  Similarly, overhead byte and measurement
   mechanism of latency has been provided in OTN (i.e., ITU-T [G.709]).
   In order to measure the link latency between two OTN nodes, PM&TCM
   which include Path Latency Measurement field and flag used to
   indicate the beginning of measurement of latency is added to the
   overhead of ODUk.  The detailed measurement mechanism of link latency
   is out of scope of this document.  You can refer to ITU-T G.709 for
   more messages.  Technologies that do not support the measurement of
   latency SHOULD be developed to allow the measurement of link latency
   in scenario similar to the above.  This is out of scope of this
   document.  Node latency can also be recorded at each node by
   recording the process time at the beginning and at the end.  More
   detail of the node latency is described in section 3.2.

   Current operation and maintenance mode of latency measurement is high
   in cost and low in efficiency.  Only after the path needed by the
   customers' business is determined, signal can be sent to detect
   whether the latency of the path fit the requirement of the customers.
   If not, another path SHOULD be determined by the ingress node until
   one can.  So a low cost and high efficiency latency measurement
   method SHOULD be provided in order to support the SLA.  However, the
   control plane does not provide latency measure mechanism.  A new
   method is provided that the node latency, link latency and latency
   variation can be collected by control plane from the transport plane.
   Then node latency, link latency values and latency variation can be



Wang & Fu                Expires April 21, 2011                 [Page 3]


Internet-Draft     latency as a TE performance metric           Oct 2010


   used by service provider through control plane to provide a path
   correspond with the customers' requirement.  As there is demand from
   the customer, this method can be used to select a path correspond
   with customers' latency demand.  In this document, link latency
   refers to the latency of the link between two neighbor nodes or a FA-
   LSP.

   This document describes the requirement and method to compute and
   identify the latency by control plane in today's network which is
   consisted of packet transport network and optical transport network
   in order to meet the latency SLA of the customer.  This document also
   describes RSVP-TE signaling and OSPF routing extensions needed to
   support the computation and identification of latency.  Latency can
   be divided into two types as described above: node latency which is
   provided by the node as a result of process time at each node and
   link latency as a result of packet traverse between two neighbor
   nodes or a FA-LSP.  Latency variation is also a parameter that is
   used to indicate the variation range of the latency value.
   Extensions are also intended to advertise and convey the information
   of node latency, link latency and latency variation as TE performance
   metric.

   [RFC4203] details the OSPF extensions in support of Generalized
   Multi-Protocol Label Switching (GMPLS).  In order to support the
   advertisement of the attributes of the node latency, link latency and
   latency variation by routing, extensions SHOULD be made to [RFC4203]
   in this document.  Thus ingress node that is responsible for the
   creation of the path will have a good knowledge of the latency of the
   path.

   [RFC3473] details the Generalized Multi-Protocol Label Switching
   (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering
   (RSVP-TE) Extensions.  Extensions SHOULD be made to [RFC3473] to
   collect the node, link latency and latency variation along the path,
   so egress node can determine whether such a path is adaptive.  This
   extensions is not necessary unless there is a need.

1.1.  Conventions Used in This Document

   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].


2.  Terminology

   The reader is assumed to be familiar with the terminology in
   [RFC3473] and [RFC4203].



Wang & Fu                Expires April 21, 2011                 [Page 4]


Internet-Draft     latency as a TE performance metric           Oct 2010


   Frame Delay:
   The definition of Frame Delay in ITU-T Y.1731 can be seen below.
   Frame Delay can be specified as round-trip delay for a frame, where
   Frame Delay is defined as the time elapsed since the start of
   transmission of the first bit of the frame by a source node until the
   reception of the last bit of the loop backed frame by the same source
   node, when the loop back is performed at the frame's destination
   node.

   Frame Delay Variation:
   The definition of Frame Delay in ITU-T [Y.1731] can be seen below.
   Frame Delay Variation is a measure of the variations in the Frame
   Delay between a pair of service frames.

   Path Monitoring & Tandem Connection Monitoring:
   Path Monitoring & Tandem Connection Monitoring is a field contained
   in [G.709] OTN ODUk overhead, which can be used to support the
   measurement of latency between two OTN nodes.

   Service Level Agreement:
   A service level agreement is a part of a service contract where the
   level of service is formally defined between service providers and
   customers.

2.1.  List of Acronyms

   FD: Frame Delay
   FDV: Frame Delay Variation
   PM&TCM: Path Monitoring & Tandem Connection Monitoring
   SLA: Service Level Agreement


3.  Analysis of the Latency Measurement Mechanism

   As described in the Introduction section, latency is sensitive in
   many cases like finance, storage.  A little frame delay may result in
   large loss.  So network latency values MUST be strictly limited to a
   value lower than the upper limit described in the SLA.  Latency
   measurement mechanism is important to certain customers.  However,
   the control plane does not provide latency measure mechanism.  A
   method is provided that the node latency, link latency and latency
   variation can be collected by control plane from the latency
   measurement of the transport plane.  Then node latency, link latency
   values and latency variation can be used by service provider through
   control plane to provide a path correspond with the customers'
   demand.  In this document, link latency refers to the latency of the
   link between two neighbor nodes or a FA-LSP.  This section analyzes
   latency support for SLA contract signed between customers and



Wang & Fu                Expires April 21, 2011                 [Page 5]


Internet-Draft     latency as a TE performance metric           Oct 2010


   providers, analysis of the mechanism of latency measurement, latency
   of the server layer network and role of the control plane in this new
   latency measurement mechanism.

3.1.  Support of SLA

   In today's network (e.g., DWDM), latency measurement is required by
   many service providers because of the demand from the customers.
   Latency is especially important for the customers who provide service
   like finance, storage.  As a result of the demand, SLA contract which
   includes the demand of latency is signed between service providers
   and customers.  According to the definition in section 2, SLA (i.e.,
   Service Level Agreement) is a part of a service contract where the
   level of service is formally defined between service providers and
   customers.  Service providers MUST provide accurate latency
   measurement result to the customers per SLA levels.  Latency to
   different customers can be different per SLA levels.

   However, current operation and maintenance mode of latency
   measurement through transport plane is high in cost and low in
   efficiency.  Only after the path needed by the customers' business is
   determined, signal can be sent to detect whether the latency of the
   path fit the requirement of the customers.  A new method described in
   this document is provided to support a low cost and high efficiency
   latency measurement mechanism in order to support the SLA.  This can
   be seen in the 4th section and 5th section.

3.2.  Latency Value

   The mechanism of latency measurement can be sorted into two types.
   In order to monitor the performance, pro-active latency measurement
   is required.  Generally, every 15 minutes or 24 hours, the value of
   FD and FDV SHOULD be collected.  Similarly, on demand latency
   measurement is required due to the goal of maintenance.  This can be
   done every fixed time interval (e.g., 5 minutes or 1 hour).

   As described in [CL-REQ], when a traffic flow moves from one
   component link to another in the same composite link between a set of
   nodes (or sites), it MUST be processed in a minimally disruptive
   manner.  When a traffic flow moves from a current link to a target
   link with different latency, reordering can occur if the target link
   latency is less than that of the current and clumping can occur if
   target link latency is more than that of the current.  Therefore, the
   solution SHALL provide a means to indicate that a traffic flow shall
   select a component link with the minimum latency value and a maximum
   acceptable latency value.

   Similarly, the value of latency is not fixed because of different



Wang & Fu                Expires April 21, 2011                 [Page 6]


Internet-Draft     latency as a TE performance metric           Oct 2010


   signal process technology (The packet transport network use
   statistical multiplexing and the optical transport network use time
   division multiplex).  For example, in statistical multiplexing
   business, latency for every business may be different because of the
   existence of buffering and priority.  At this time, average latency
   value is needed when refer to node latency.  Average latency value of
   node can be derived through the computation of the node or management
   plane configuration.

   latency varation is also needed in the case the latency value of, for
   example, average latency value's variation range.

   Measurement mechanism of link latency has been defined in many
   technologies like Ethernet, OTN.  You can refer to ITU-T [G.8021],
   [Y.1731] and [G.709] for more information.

3.3.  Latency of Server Layer Network

   When a LSP traverses a server layer FA-LSP, the latency information
   of the FA-LSP SHOULD be provided by signaling protocol message if
   needed.  Extension to the current signaling protocol is done to carry
   the latency information of the server layer FA-LSP.  This is
   described in section 4 and section 5.

   The boundary nodes of the FA-LSP SHOULD be aware of the latency
   information of this FA-LSP (i.e., minimum latency, maximum latency,
   average latency).  If the latency information of the FA-LSP changes,
   the ingress node of the FA-LSP will receive the TE link information
   advertisement including the latency value which is already changed,
   then it will compute the total latency value of the FA-LSP again.  If
   this value changes, the client layer of the FA-LSP MUST also be
   notified about the total value of the latency.

   The ingress node or egress node of the FA-LSP can advertise the total
   value of the latency to the client layer nodes connecting to the
   ingress node or egress node through signaling protocol message (e.g.,
   notify message or refresh message).  If the FA-LSP is able to form a
   routing adjacency and/or as a TE link in the client network, the
   value of the FA-LSP can be used as TE link metric and advertised into
   the client layer routing instances or PCE.

3.4.  Role of the Control Plane

   Current mechanism of latency measurement is provided by transport
   plane instead of control plane.  The latency information between two
   specified nodes will be detected if there is latency demand of the
   path between the two nodes.  This is low in efficiency and high in
   cost if the latency information does not correspond with the



Wang & Fu                Expires April 21, 2011                 [Page 7]


Internet-Draft     latency as a TE performance metric           Oct 2010


   customers' demand.

   A new method of latency measurement mechanism is provided by
   collecting the node latency value, link latency value between two
   neighbor nodes or a FA-LSP and latency variation, then these values
   is provided to the control plane.  Control plane can compute a path
   correspond with customers' demand with these latency values.


4.  A New Latency Measurement Mechanism

   This new latency measurement can be divided into two phases.  The
   first phase is the advertisement of the latency information by
   routing protocol, including node latency, link latency between two
   neighbor nodes or a FA-LSP and latency variation, so every node in
   the network can be aware of the latency of every node and link.  The
   second phase is the latency collection and verification along the
   path from the ingress node to the egress node by signaling protocol,
   so an adaptive LSP can be found out and verified.

4.1.  Advertisement of the Latency Value

   As described in the introduction section, a node in the packet
   transport network or optical transport network can detect link
   latency value which has connection with it.  Also the node latency
   can be recorded at every node.  Then these link latency values of the
   neighbor nodes, node latency and latency variation is notified to the
   control plane.  The control plane instances then advertise these link
   latency values, node latency values and latency variation as
   attributes of the TE link to the other nodes in the routing domain or
   PCE by routing protocol.  If any latency values change, then the
   change MUST be notified to the control plane instances, then
   advertise by routing protocol in the routing domain or to the PCE.
   As a result, control plane instances and PCE can have every node
   latency values, link latency values and latency variation in the
   network.

4.2.  Latency Collection and Verification

   When the PCE receives the request which indicates the demand of
   latency, PCE can compute a path which satisfies customers' latency
   demand with the node latency values, link latency values and latency
   variation in the network.  The ingress node initializes the creation
   of the LSP with path signaling message which includes the latency
   demand parameter.  The path signaling message collects the node
   latency value, link latency value and latency variation along the
   path.  When the path signaling message reaches the egress node, the
   egress node can verify whether the value of the latency is applicable



Wang & Fu                Expires April 21, 2011                 [Page 8]


Internet-Draft     latency as a TE performance metric           Oct 2010


   by comparing the LSP latency with the latency demand parameter
   carried in the path message.  Similarly, when egress node returns
   recv signaling message to ingress node, node latency values, link
   latency values and latency variation will also be gathered in the
   reverse direction.  The ingress node verifies whether the latency
   values from the egress node to the ingress node is applicable.This
   extensions is not necessary unless there is a need.

   When a LSP traverses a server layer FA-LSP, the latency information
   of the FA-LSP is advertised by routing protocol and carried in the
   signaling message.  The latency information of the server layer FA-
   LSP can be carried in the ERBO object which is defined in
   [draft-fuxh-ccamp-boundary-explicit-control-ext].  Region boundaries
   carried in ERBO contain one pair or multiple pair of nodes.  One pair
   of boundary nodes indicates the head node and the end node of the FA-
   LSP (i.e., the region boundary).  The latency values information of
   the FA-LSP between two boundary nodes is carried in the signaling
   message directly behind a pair of boundary nodes in the ERBO.
   Ingress node will re-compute the total latency value of the FA-LSP if
   the total latency value of the FA-LSP changes.  The latency value of
   the FA-LSP SHOULD be announced to the client layer of the FA-LSP,
   also advertised in the routing domain.


5.  Signaling and Routing Extensions to Support Latency Measurement

   Extensions SHOULD be done to existing OSPF-TE routing protocol and
   RSVP-TE routing protocol, in order to support the advertisement, the
   collection and the verification of the latency values.  In this
   section, routing extensions and signaling extensions will be
   described.

5.1.  Routing Extensions to Support the Advertisement of Latency

   Some extensions to the existing OSPF-TE routing protocol to support
   the advertisement of the node latency value, link latency and latency
   variation value in the routing domain or to the PCE as TE metric.
   OSPF-TE routing protocol can be used to carry latency information by
   adding a sub-TLV to the TE link which is defined in [RFC4203].  The
   latency value can be used as constraint for routing computation and
   as a factor impacting the node and link performance.

   As defined in [RFC3630] and [RFC4203], the top-level TLV can take one
   of two values (1) Router address or (2) Link.  Node latency sub-TLV
   and link latency sub-TLV can be added behind the top-level TLV.  The
   link latency sub-TLV has the same format as node latency TLV.  They
   both include these parameters like minimum latency value, minimum
   latency variation value, maximum latency value, maximum latency



Wang & Fu                Expires April 21, 2011                 [Page 9]


Internet-Draft     latency as a TE performance metric           Oct 2010


   variation value, average latency value, average latency variation
   value.  The format of the sub-TLV can be seen below.

      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             |           Length              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Minimum Latency Value      |    Latency Variation Value    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Maximum Latency Value      |    Latency Variation Value    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Average Latency Value      |    Latency Variation Value    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                      Figure 1: Format of the sub-TLV

   -  Minimum Latency Value: a value indicates the boundary of the node
      latency or link latency along with maximum latency value.

   -  Maximum Latency Value: a value indicates the boundary of the node
      latency or link latency along with maximum latency value.

   -  Average Latency Value: a value indicates the average of the node
      latency or link latency.

   -  Latency Variation Value: a value indicates the variation range of
      the minimum latency value, maximum latency value or average
      latency value.

5.2.  Signaling Extensions to Support the Latency Measurement

   Extensions SHOULD also be done to the RSVP-TE signaling protocol to
   support the collection and verification of the latency measurement.
   This can be achieved base on the extension to the RRO which is
   defined in [RFC3209] by adding an interface ID (i.e., IP Address) or
   interface identifier defined in [RFC3477], then adding the sub-TLV
   which has the same format with that described above.  When a node
   receives the path message, node latency value, link latency value and
   latency variation along the path which has correlation to the node
   will be added behind the interface identifier and node ID sub-object.
   At the same time, the latency values requirement from the ingress
   node to the egress node have been added into the TE metric TLV.  When
   the egress node receives the path message, the latency value of the
   LSP can be compute by the node latency value, link latency value and
   latency variation carried behind RRO.  If the total latency value
   does not meet the requirement of the customer, patherr message SHOULD



Wang & Fu                Expires April 21, 2011                [Page 10]


Internet-Draft     latency as a TE performance metric           Oct 2010


   be created and return to the ingress node.  Recv message can be used
   to collect and verify the latency information in the reverse
   direction in the same way.

   The signaling format of the sub-TLV has the same format as that
   described in the section 5.1.  This format can also been used behind
   a pair of boundary nodes which are carried in ERBO to indicate the
   latency information of the FA-LSP if there are requirement of the
   server layer.


6.  Security Considerations

   TBD


7.  IANA Considerations

   TBD


8.  References

8.1.  Normative References

   [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.

   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

   [RFC3477]  Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
              in Resource ReSerVation Protocol - Traffic Engineering
              (RSVP-TE)", RFC 3477, January 2003.

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

   [RFC4203]  Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
              of Generalized Multi-Protocol Label Switching (GMPLS)",
              RFC 4203, October 2005.




Wang & Fu                Expires April 21, 2011                [Page 11]


Internet-Draft     latency as a TE performance metric           Oct 2010


8.2.  Informative References

   [CL-REQ]   C. Villamizar, "Requirements for MPLS Over a Composite
              Link", draft-ietf-rtgwg-cl-requirement-02 .

   [G.709]    ITU-T Recommendation G.709, "Interfaces for the Optical
              Transport Network (OTN)", December 2009.


Authors' Addresses

   Qilei Wang
   ZTE Corporation
   No.68 ZiJingHua Road,Yuhuatai District
   Nanjing  210012
   P.R.China

   Email: wang.qilei@zte.com.cn
   URI:   http://wwwen.zte.com.cn/


   Xihua Fu
   ZTE Corporation
   West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District
   Xi An  710065
   P.R.China

   Phone: +8613798412242
   Email: fu.xihua@zte.com.cn
   URI:   http://wwwen.zte.com.cn/





















Wang & Fu                Expires April 21, 2011                [Page 12]