Network Working Group                                            Q. Wang
Internet-Draft                                              X. Fu
Internet-Draft                                                  M. Betts
Intended status: Standards Track                                 Q. Wang
Expires: August 21, 2011                                 ZTE Corporation
Expires: April 28,
                                                       February 17, 2011                                     Oct 25, 2010

    GMPLS extensions to communicate latency as a TE traffic engineering
                           performance metric
                 draft-wang-ccamp-latency-te-metric-01
                 draft-wang-ccamp-latency-te-metric-02

Abstract

   Latency is such requirement that must be achieved according to the
   SLA signed
   Service Level Agreement (SLA) between customers and service providers, so mechanism
   providers.  A SLA is
   needed a part of a service contract where the level of
   service is formally defined between service providers and customers.
   For example, the service level includes platinum, golden, silver and
   bronze.  Different service level may associate with different
   protection/restoration requirement.  Latency can also be associated
   with different service level.  The user may select a private line
   provider based on the ability to collect, compute meet a latency SLA.

   The key driver for latency is stock/commodity trading applications
   that use data base mirroring.  A few milli seconds can impact a
   transaction.  Financial or trading companies are very focused on end-
   to-end private pipe line latency optimizations that improve things
   2-3 ms.  Latency and identify latency SLA is one of the key parameters that
   these "high value" customers use to select a private pipe line
   provider.  Other key applications like video gaming, conferencing and
   storage area networks require stringent latency by signaling and
   routing protocol. bandwidth.

   This document describes the requirement requirements and method mechanisms to compute and
   identify the
   communicate latency by control plane as a traffic engineering performance metric in
   today's network which is
   consisted consisting of potentially multiple layers of
   packet transport network and optical transport network in order to
   meet the latency SLA of the customer. between service provider and his customers.
   This document also
   describes extends RSVP-TE signaling and OSPF routing extensions needed IGP to support the computation and identification of latency. these
   requirement.  These extensions are intended to advertise and convey
   the latency information of
   node latency nodes and link latency links as TE traffic engineering
   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 28, August 21, 2011.

Copyright Notice

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

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

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3  4
     1.1.  Conventions Used in This Document  . . . . . . . . . . . .  4  5
   2.  Terminology  Identification of Requirements . . . . . . . . . . . . . . . .  5
   3.  Control Plane Solution . . . . . . . . .  4
     2.1.  List of Acronyms . . . . . . . . . . .  9
     3.1.  Latency Advertisement  . . . . . . . . . .  5
   3.  Analysis of the Latency Measurement Mechanism . . . . . . . .  5
     3.1.  Support of SLA  9
       3.1.1.  Routing Extensions . . . . . . . . . . . . . . . . . . 10
         3.1.1.1.  OSPF-TE Extension  . . . .  6
     3.2.  Latency Value . . . . . . . . . . . . 10
         3.1.1.2.  IS-IS-TE Extension . . . . . . . . . .  6
     3.3.  Latency of Server Layer Network . . . . . . 10
     3.2.  Latency SLA Parameters Conveying . . . . . . .  7
     3.4.  Role of the Control Plane . . . . . . 10
       3.2.1.  Signaling Extensions . . . . . . . . . .  7
     3.5.  Impact of the Change of Link Latency . . . . . . . . . . .  8
   4.  A New 10
         3.2.1.1.  Latency Measurement Mechanism SLA Parameters ERO subobject . . . . . . . 11
         3.2.1.2.  Signaling Procedure  . . . . . .  8
     4.1.  Advertisement of the Latency Value . . . . . . . . . . . .  8
     4.2. 12
     3.3.  Latency Collection Accumulation and Verification  . . . . . . . . . . .  9
   5. 12
       3.3.1.  Signaling and Routing Extensions to Support Latency
       Measurement . . . . . . . . . . . . . . . . . 12
         3.3.1.1.  Latency Accumulation Object  . . . . . . . .  9
     5.1.  Routing Extensions to Support the Advertisement of . . . 12
         3.3.1.2.  Latency Accumulation sub-TLV . . . . . . . . . . . 13
         3.3.1.3.  Signaling Procedures . . . . . . . . . . . . . . 10
     5.2.  Signaling Extensions to Support the Latency Measurement . 11
   6. 14
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   7. 15
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   8. 15
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1. 15
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     8.2. 15
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 12 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 16

1.  Introduction

   In a network, latency, a synonym for delay, is an expression of how
   much time it takes for a packet packet/frame of data to get from one
   designated point to another.  In some usages, latency is measured by
   sending a
   packet packet/frame that is returned to the sender and the round-trip round-
   trip time is considered the latency.  In this document, we refer latency of bidirectional co-routed or
   associated LSP.  One way time is considered as the latency of
   unidirectional LSP.  The one way latency may not be half of the
   round-trip latency in the case that the transmit and receive
   directions of the path are of unequal lengths.

   Latency on a connection has two sources: Node latency which is caused
   by the node as a result of process time in each node and: Link
   latency as a result of packet/frame transit time between two
   neighbouring nodes or a FA-LSP/Composit Link [CL-REQ].  Latency
   variation is a parameter that is used to indicate the variation range
   of the latency value.  These values should be made available to the
   control plane and management plane prior to path computation.  This
   allows path computation to select a path that will meet the former
   expression. latency
   SLA.

   In many cases, latency is a sensitive topic.  For example, two stock
   exchanges, one
   exchanges (e.g.,one in Beijing, which is a city of north China Chicago and another in Shenzhen, which is a city of south China.  Both of them New York) need to
   synchronize
   communicate with each other.  A little change may few ms can result in large
   loss.  So something SHOULD be assured that impact on
   service.  Some customers would pay for the network path latency
   MUST be limited to a value lower than the upper limit. performance.  SLA
   contract which includes the requirement of latency is signed between
   service providers and customers.  Service provider should assure that
   the network path latency MUST be limited to a value lower than the
   upper limit.  In the future, latency demand optimization will be needed by
   more and more customers.  For example, some customers pay for a
   private pipe line with latency constraint (e.g., less than 10 ms)
   which connects to Data Center.  If this "provisioned" latency of this
   private pipe line couldn't meet the SLA, service provider may
   transfer customer's service to other Data Centers.  Service provider
   may have many layers of pre-defined restoration for this transfer,
   but they have to duplicate restoration resources at significant cost.
   So service provider needs some mechanisms to avoid the duplicate
   restoration and reduce the network cost.

   Measurement mechanism of for link latency has been defined in many
   technologies.  For example, the measurement mechanism of for 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 between the beginning and at the end.  More
   detail  The
   measurement mechanism of the node latency links and nodes is described in section 3.2. out scope of this
   document.

   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  The latency can only be sent to detect
   whether the latency of the path fit the requirement of measured
   after the customers.
   If not, another path SHOULD be determined by connection has been established, if 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
   indicates that the node latency, link latency SLA is not met then another path is
   computed, set up and latency
   variation can be collected by control plane from the transport plane.
   Then node latency, link latency values measured.  This "trial and latency variation can be
   used by service provider through control plane to provide a path
   correspond with the customers' requirement.  As there error" process is demand from
   the customer,
   very inefficient.  To avoid this method can be used to select problem a path correspond
   with customers' latency demand.  In this document, link latency
   refers to the latency means of the link between two neighbor nodes or making an
   accurate prediction of latency before a FA-
   LSP. path is establish is
   required.

   This document describes the requirement requirements and method mechanisms to compute and
   identify the
   communicate latency by control plane as a traffic engineering performance metric in
   today's network which is
   consisted consisting of potentially multiple layers of
   packet transport network and optical transport network in order to
   meet the latency SLA of the customer. between service provider and his customers.
   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 extends IGP to advertise and convey the information
   of node latency, link latency
   attributes and latency variation as TE traffic engineering 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 computation entity can have a good knowledge of
   the latency traffic engineering database.

   This document extends RSVP-TE protocol to accumulate (e.g., sum)
   latency information of the
   path.

   [RFC3473] details the Generalized Multi-Protocol Label Switching
   (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering
   (RSVP-TE) Extensions.  Extensions SHOULD links and nodes along one LSP across multi-
   domain (e.g., Inter-AS, Inter-Area or Multi-Layer) so that an latency
   verification can be made to [RFC3473] to
   collect the node, link latency at source node.  One-way and round-trip
   latency variation collection along the path,
   so egress node LSP by signaling protocol can determine be
   supported.  So the end points of this LSP can verify whether such a path is adaptive.  This
   extensions is not necessary unless there is a need. the
   total amount of latency could meet the latency agreement between
   operator and his user.

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

   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  Identification of Requirements

   End-to-end 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 optimization based on latency between two OTN nodes.

   Service Level Agreement:
   A service level agreement (e.g., minimum
   latency) is a part of a key requirement for service contract where the
   level provider.  This type of
   function will be adopted by their "premium" 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  They
   would 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 pay for this "premium" service.  After these premium
   services are deployed, they will also expand to certain their own customers.  However,
   the control plane does not provide

   Following key requirements associated with latency measure mechanism.  A
   method is provided that the node latency, link latency and latency
   variation can be collected by control plane from the identified.

   o  Communication latency
   measurement of the transport plane.  Then node latency, link links and nodes including minimum latency
   values
      and latency variation can as a traffic engineering performance metric
      is a very important requirement.  The latency performance metric
      MUST be used advertised into path computation entity by service provider through
   control plane IGP(etc.,
      OSPF-TE or IS-IS-TE) to provide a path correspond with the customers'
   demand. perform route computation and network
      planning based on latecny SLA target.  Latency characteristics of
      these links may change dynamically.  In this document, link latency refers order 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 control IGP
      messaging and
   providers, analysis of avoid being unstable when the mechanism of latency measurement, and latency
   of the server layer network
      variation value changes, a threshold and role a limit on rate of the change
      MUST be configured to control plane.

      *  Data 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 responsible for measuring 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 (e.g.,
         minimum 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 variation).  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. by different technologies.  This can information
         will be seen in provided to the 4th section and 5th section.

3.2.  Latency Value

   The mechanism of latency measurement can be sorted into two types. Control Plane.  In order to monitor the
         performance, pro-active latency measurement is required.
         Generally, every 15 minutes or 24 hours, the value of
   FD latency
         and FDV SHOULD latency variation 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  The method used to another in measure the same composite link between a set latency
         of links and nodes (or sites), it MUST be processed in a minimally disruptive
   manner.  When is out scope of this document.

      *  Control plane is responsible for advertising and collecting the
         latency value of links and nodes by IGP (i.e., OSPF-TE/
         IS-IS-TE).

   o  End-to-end service optimization based on latency (e.g., minimum
      latency) is a traffic flow moves from key requirement for service provider.  Latency on a current link
      route level will help carriers' customers to a target
   link with different latency, reordering can occur if make his provider
      selection decision.  Path computation entity MUST have the target link
      capability to compute one end-to-end path with latency is constraint.
      For example, it MUST have the capability to compute a route with x
      amount bandwidth and less than that y ms of latency limit based on the current
      latency traffic engineering database.  It should also support
      combined routing constraints with pre-defined priorities, e.g.,
      SRLG diversity, latency and clumping can occur cost.

   o  One end-to-end LSP may be across some Composite Links [CL-REQ].
      Even if
   target link the transport technology (e.g., OTN) implementing the
      component links is identical, the latency characteristics of the
      component links may differ.  When the composite link is more than that advertised
      into IGP, the latency of composite link should be the current.  Therefore, maximum
      latency value of all component links.

      In order to assigne the LSP to one of component links with
      different latency characteristics, RSVP-TE message MUST convey
      latency SLA parameter (e.g., minimum latency) to the end points of
      Composite Links where it can select one of component links or
      trigger the creation of lower layer connection which MUST meet
      latency SLA parameter.  Following related requirements are from
      [CL-REQ].

      *  The solution SHALL provide a means to indicate that a traffic
         flow shall select a component link with the minimum latency
         value.

      *  The solution SHALL provide a means to indicate that a traffic
         flow shall select a component link with a maximum acceptable
         latency value and as specified by protocol.

      *  The solution SHALL provide a means to indicate that a traffic
         flow shall select a component link with a maximum acceptable
         latency value.

   Similarly, the variation value of as specified by protocol.

      The RSVP-TE message needs to carry minimum latency, maximum
      acceptable latency is not fixed because of different
   signal process technology (The packet transport network use
   statistical multiplexing and maximum acceptable delay variation for the optical transport network use time
   division multiplex).  For example,
      component link selection or creation.  The composite link will
      take these parameters into account when assigning traffic of LSP
      to a component link.

   o  One end-to-end LSP (e.g., in statistical multiplexing
   business, latency for every business IP/MPLS or MPLS-TP network) may
      traverse a FA-LSP of server layer (e.g., OTN rings).  The boundary
      nodes of the FA-LSP SHOULD be different because aware of the
   existence latency information of buffering and priority.  At
      this time, average FA-LSP (e.g., minimum latency
   value is needed when refer to node latency.  Average and latency value of
   node can be derived through the computation of variation).  If the node or management
   plane configuration.

   latency varation
      FA-LSP 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 able to ITU-T [G.8021],
   [Y.1731] and [G.709] for more information.

3.3.  Latency of Server Layer Network

   When form a LSP traverses routing adjacency and/or as a server layer FA-LSP, TE link in
      the client network, the latency information value of the FA-LSP SHOULD can be provided by signaling protocol message if
   needed.  Extension as an
      input to a transformation that results in a FA traffic engineering
      metric and advertised into the current signaling protocol is done to carry client layer routing instances.
      Note that this metric will include the latency information of the server layer FA-LSP.  This is
   described in section 4 links and section 5.

   The boundary
      nodes of the FA-LSP SHOULD be aware of that the latency
   information of this FA-LSP (i.e., minimum latency, maximum latency,
   average latency). trail traverses.

      If the latency information of the FA-LSP changes, changes (e.g., due to a
      maintenance action or failure in OTN rings), the ingress boundary node of
      the FA-LSP will receive the TE link information advertisement
      including the latency value which is already changed, changed and if it is
      over than the threshold and a limit on rate of change, then it
      will compute the total latency value of the FA-LSP again.  If
   this the
      total latency value of FA-LSP changes, the client layer of the FA-LSP MUST also
      be notified about the total latest value of the latency. FA.  The ingress node or egress node of the FA-LSP client layer can advertise
      then decide if it will accept the total
   value of increased latency or request a
      new path that meets the latency to requirement.

      When one end-to-end LSP traverse a server layer, there will be
      some latency constraint requirement for the client layer nodes connecting segment route in
      server layer.  So RSVP-TE message needs to carry minimum latency,
      maximum acceptable latency and maximum acceptable delay variation
      for the
   ingress node or egress node through signaling protocol message (e.g.,
   notify message FA selection 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 creation.  The boundary nodes of the
      FA-LSP can be used as TE link metric and advertised will take these parameters into
   the client layer routing instances account for FA selection or PCE.

3.4.  Role of the Control Plane

   Current mechanism of latency
      FA-LSP creation.

   o  Standardized measurement should be a goal for SLA validation.  It
      is provided by transport
   plane instead out scope of this document.  RSPV-TE should support the
      accumulation (e.g., sum) of control plane.  The latency information between two
   specified of links and nodes will be detected if there is
      along one LSP across multi-domain (e.g., Inter-AS, Inter-Area or
      Multi-Layer) so that an latency demand of the
   path between validation decision can be made at
      the two nodes.  This is low in efficiency source node.  One-way and high in
   cost if the round-trip latency information does not correspond with collection along
      the
   customers' demand.

   A new method of latency measurement mechanism is provided LSP by
   collecting signaling protocol and latency verification at the node end
      of LSP should be supported.

   o  Restoration, protection and equipment variations can impact
      "provisioned" latency value, link (e.g., latency value between two
   neighbor nodes or a FA-LSP and increase).  The change of one
      end-to-end LSP latency variation, then these values
   is provided to the control plane.  Control plane performance MUST be known by source and/or
      sink node.  So it can compute inform the higher layer network of a path
   correspond with customers' demand with these latency values.

3.5.  Impact
      change.  The latency change of the Change links and nodes will affect one
      end-to-end LSP's total amount of Link Latency latency.  Applications can fail
      beyond an application-specific threshold.  Some remedy mechanism
      could be used.

      *  Congestion in packet network can affect the latency.  If the link
         latency of a provisioned end-to-end LSP which have a latency value corresponds
   with customers' demand changes, the ingress node or PCE will be aware
   of could not meet the
         latency value change agreement between operator and his user again, a
         mechanism may cause the LSPs for some traffic flows to move to
         some points in the network.  Total latency value network that is not congested.  It is out
         scope of this document.

      *  Some customers may insist on having the ability to re-route if
         the latency SLA is not being met.  If a "provisioned" end-to-
         end LSP affected by latency could not meet the latency value change will agreement (e.g.,
         minimum latency or latency variation) between operator and his
         user, then re-routing could be re-computed
   through triggered based on the ingress node local
         policy.  Pre-defined or PCE.  Client service SHOULD dynamic re-routing could be switched triggered
         to a new LSP which have a handle this case.  The latency value corresponds with customers'
   demand if current changed performance of pre-defined or
         dynamic re-routing LSP MUST meet the latency value is invalid.  This is much
   like SLA parameter.  In
         the recovery, but not recovery.  All case of predefined re-routing, the LSPs affected by this
   latency change large amounts of
         redundant capacity may not be rerouted to find appropriate LSPs if they
   still have appropriate latency values.  All a significant negative impact on
         the LSPs affected will be
   rerouted overall network cost.  Dynamic re-routing also has to find a recovery path if there is a link failure. face
         the risk of resource limitation.  So the choice of mechanism
         MUST be based on SLA or policy.

      *  As a result of the change of link links and nodes latency in the
         LSP, current LSP may be frequently switched to a new LSP with a
         appropriate latency value.  In order to avoid this, the
         solution SHOULD indicate the switchover of the LSP according to
         maximum acceptable value of the customers.

4.  A New Latency Measurement Mechanism

   This new change latency measurement can be divided into two value.

3.  Control Plane Solution

   In order to meet the requirements which have been identified in
   section 3, this document defines following four phases.

   o  The first phase is the advertisement of the latency information by
      routing protocol, protocol (i.e., OSPF-TE/IS-IS-TE), including node latency, link latency between two
   neighbor of
      nodes or and links, a FA-LSP or Composite Link [CL-REQ] between two
      neighbour and latency variation, so every node in
   the network path computation entity can be
      aware of the latency of every node nodes and link.  The links.

   o  In the second phase, path computation entity is responsible for
      end-to-end path computation with latency constraint (e.g., less
      than 10 ms) combining other routing constraint parameters (e.g.,
      SRLG, cost and bandwidth).

   o  The third phase is to convey the latency SLA parameters for the
      selection or creation of component link or FA/FA-LSP.  One end-to-
      end LSP may be across some Composite Links or server layers, so it
      can convey latency SLA parameters by RSVP-TE message.

   o  The last phase is the latency collection and verification verification.  This
      stage could be optional.  It could accumulate (e.g., sum) latency
      information along the
   path from the ingress node to the egress node LSP across multi-domain (e.g., Inter-AS,
      Inter-Area or Multi-Layer) by RSVP-TE signaling protocol,
   so an adaptive LSP can be found out and verified.

4.1.  Advertisement of message to verify
      the Latency Value

   As described in total latency at the introduction section, a end of path.

3.1.  Latency Advertisement

   A node in the packet transport network or optical transport network
   can detect link the latency value of link which has connection with connects to 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
   TE links, Composit Links [CL-REQ] or FAs, latency values of nodes and
   latency variation as
   attributes of the TE link are notified to the other nodes in the routing domain or
   PCE by routing protocol. IGP and/or PCE.  If any latency
   values change and over than the threshold and a limit on rate of
   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. IGP and/or PCE again.
   As a result, control plane instances and PCE path computation entity 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 its view 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 network, and latency variation along the
   path.  When the path signaling message reaches the egress node, the
   egress node
   it can verify whether the value of the latency is applicable
   by comparing the LSP latency with the latency demand parameter
   carried in the compute one end-to-end 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 with latency
   values from the egress node constraint.  It needs
   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 extend IGP 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. OSPF-TE/IS-IS-TE).

3.1.1.  Routing Extensions to Support

   Following is the Advertisement of Latency

   Some extensions to the existing OSPF-TE routing protocol OSPF-TE/IS-IS-TE 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.
   variation.

3.1.1.1.  OSPF-TE Extension

   OSPF-TE routing protocol can be used to carry latency information performance
   metric 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  Latency sub-TLV of node
   and link latency sub-TLV can be is added behind the top-level TLV.  The link latency sub-TLV
   has the same format as node latency TLV. sub-TLV.  They both include these parameters like
   minimum latency value, minimum and latency variation value, maximum value.  Following is the
   Latency sub-TLV format.

      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(IANA)             |           Length              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Minimum Latency Value                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Latency Variation Value                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 1: Format of the Latency sub-TLV

   o  Minimum Latency Value: a value indicates the minumum latency value, of
      link or node.

   o  Latency Variation Value: a value indicates the variation range of
      the minimum latency value.

3.1.1.2.  IS-IS-TE Extension

   TBD

3.2.  Latency SLA Parameters Conveying

3.2.1.  Signaling Extensions

   This document defines extensions to and describes the use of RSVP-TE
   [RFC3209], [RFC3471], [RFC3473] to explicitly convey the latency SLA
   parameter for the selection or creation of component link or FA/
   FA-LSP.  Specifically, in this document, Latency SLA Parameters TLV
   are defined and added into ERO as a subobject.

3.2.1.1.  Latency SLA Parameters ERO subobject

   A new OPTIONAL subobject of the EXPLICIT_ROUTE Object (ERO) is used
   to specify the latency SLA parameters including minimum latency,
   maximum acceptable latency
   variation value, average and maximum acceptable latency value, average variation.
   It can be used for the following scenarios.

   o  One end-to-end LSP may traverse a server layer FA-LSP.  This
      subobject of ERO can indicate that FA selection or FA-LSP creation
      shall be based on this latency variation
   value. constraint.  The format boundary nodes of the sub-TLV
      multi-layer will take these parameters into account for FA
      selection or FA-LSP creation.

   o  One end-to-end LSP may be across some Composite Links [CL-REQ].
      This subobject of ERO can indicate that a traffic flow shall
      select a component link with some latency constraint values as
      specified in this subobject.

   This Latency SLA Parameters ERO subobject has the following format.
   It follows a subobject containing the IP address, or the link
   identifier [RFC3477], associated with the TE link on which it is to
   be seen below. used.

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

              Figure 1: 2: Format of the sub-TLV

   - Latency SLA Parameters TLV

   o  Minimum Latency Value: a value indicates that a traffic flow shall
      select a component link with the boundary of the node minimum latency value [CL-REQ].
      It can also indicate one end-to-end LSP shall select a FA or link latency along
      trigger a FA-LSP creation with maximum the minimum latency value.

   - value when it
      traverse a server layer.

   o  Maximum Acceptable Latency Value: a value indicates the boundary of the node
      latency or that a traffic
      flow shall select a component link with a maximum acceptable
      latency along value [CL-REQ].  It can also indicate one end-to-end LSP
      shall select a FA or trigger a FA-LSP creation with a maximum
      acceptable latency value.

   -  Average value when it traverse a server layer.

   o  Maximum Acceptable Latency Variation Value: a value indicates that
      a traffic flow shall select a component link with a maximum
      acceptable latency variation value [CL-REQ].  It can also indicate
      one end-to-end LSP shall select a FA or trigger a FA-LSP creation
      with a maximum acceptable latency variation value when it traverse
      a server layer.

3.2.1.2.  Signaling Procedure

   When a intermediate node receives a PATH message containing ERO and
   finds that there is a Latency SLA Parameters ERO subobject
   immediately behind the average of IP address or link address sub-object related
   to itself, if the node determines that it's a region edge node of FA-
   LSP or an end point of a composite link [CL-REQ], then, this node
   extracts latency SLA parameters (i.e., minimum, maximum acceptable
   and maximum acceptable latency variation value) from Latency SLA
   Parameters ERO subobject.  This node used these latency parameters
   for FA selection, FA-LSP creation or component link latency.

   - selection.  If
   the intermediate node couldn't support the latency SLA, it MUST
   generate a PathErr message with a "Latency SLA unsupported"
   indication (TBD by INNA).  If the intermediate node couldn't select a
   FA or component link, or create a FA-LSP which meet the latency
   constraint defined in Latency Variation Value: SLA Parameters ERO subobject, it must
   generate a value indicates PathErr message with a "Latency SLA parameters couldn't be
   met" indication (TBD by INNA).

3.3.  Latency Accumulation and Verification

   Latency accumulation and verification applies where the variation range full path of
   an multi-domain (e.g., Inter-AS, Inter-Area or Multi-Layer) TE LSP
   can't be or is not determined at the ingress node of the minimum latency value, maximum TE LSP.
   This is most likely to arise owing to TE visibility limitations.  If
   all domains support to communicate latency value or average as a traffic engineering
   metric parameter, one end-to-end optimized path with delay constraint
   (e.g., less than 10 ms) which satisfies latency value.

5.2.  Signaling Extensions SLAs parameter could
   be computed by BRPC [RFC5441] in PCE.  Otherwise, it could use the
   mechanism defined in this section to Support accumulat the latency of each
   links and nodes along the path which is across multi-domain.  Latency Measurement

   Extensions SHOULD
   accumulation and verification also be done to applies where not all domains
   could support the RSVP-TE signaling protocol communication latency as a traffic engineering
   metric parameter.

3.3.1.  Signaling Extensions

3.3.1.1.  Latency Accumulation Object

   An Latency Accumulation Object is defined in this document to support
   the collection accumulation and verification of the latency measurement. latency.  This object which
   can be achieved base on carried in a Path/Resv message may includes two sub-TLVs.
   Latency Accumulation Object has the following format.

      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(IANA)             |           Length              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Latency Accumulation sub-TLV (from source to sink)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Latency Accumulation sub-TLV (from sink to source)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 3: Format of Accumulated Latency Object

   o  Latency Accumulation sub-TLV (from source to sink):It is used to
      accumulate the extension latency from source to sink along the RRO
      unidirectional or bidirectional LSP.  A Path message for
      unidirectional and bidirectional LSP must includes this sub-TLV.
      When sink node receives the Path message including this sub-TLV,
      it must copy this sub-TLV into Resv message.  So the source node
      can receive the latency accumulated value (i.e., sum) from itself
      to sink node which can be used for latency verification.

   o  Latency Accumulation sub-TLV (from sink to source):It is
   defined in [RFC3209] by adding an interface ID used to
      accumulate the latency from sink to source along the bidirectional
      LSP.  A Resv message for the bidirectional LSP must includes this
      sub-TLV.  So the source node can get the latency accumulated value
      (i.e., IP Address) or
   interface identifier sum) of round-trip which can be used for latency
      verification.

3.3.1.2.  Latency Accumulation sub-TLV

   The Sub-TLV format is defined in [RFC3477], then adding the next picture.

     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              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Accumulated Minimum Latency Value                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Accumulated Latency Variation Value                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 4: Format of Latency Accumulation sub-TLV
   which has

   o  Type: sub-TLV type

      *  0: It indicates the same format with that described above.  When a node
   receives sub-TLV is for the path message, latency accumulation
         from source to sink node along the LSP.

      *  1: It indicates the sub-TLV is for the latency value, link accumulation
         from sink to source node along the LSP.

   o  Length: length of the sub-TLV value in bytes.

   o  Accumulated Minimum Latency Value: a value indicates the sum of
      each links and nodes' minumum latency along one direction of LSP.

   o  Accumulated Latency Variation Value: a value indicates the sume of
      each links and nodes' minumum latency variation along one
      direction of LSP.

3.3.1.3.  Signaling Procedures

   When the path which has correlation source node desires to accumulate (i.e., sum) the node
   will total
   latency of one end-to-end LSP, the "Latency Accumulating desired"
   flag (value TBD) should be added behind set in the interface identifier and LSP_ATTRIBUTES object of Path/
   Resv message, object that is defined in [RFC5420].

   A source node ID sub-object.
   At initiates latency accumulation for a given LSP by
   adding Latency Accumulation object to the same time, Path message.  The Latency
   Accumulation object only includes one sub-TLV (sub-TLV type=0) where
   it is going to accumulate the latency values requirement value of each links and nodes
   along path from source to sink.

   When the ingress downstream node receives Path message and if the "Latency
   Accumulating desired" is set in the LSP_ATTRIBUTES, it accumulates
   the latency of link and node based on the accumulated latency value
   of the sub-TLV (sub-TLV type=0) in Latency Accumulation object before
   it sends Path message to downsteam.

   If the egress intermediate node have been added into couldn't support the TE metric TLV. latency accumulation
   function, it MUST generate a PathErr message with a "Latency
   Accumulation unsupported" indication (TBD by INNA).

   When the egress sink node of LSP receives the path message, Path message and the "Latency
   Accumulating desired" is set in the LSP_ATTRIBUTES, it copy the
   latency value in the Latency Accumulation sub-TLV (sub-TLV type=0) of
   Path message into the
   LSP can Resv message which will be compute forwarded hop by hop
   in the upstream direction until it arrives the source node.  Then
   source node can get the latency value, link latency sum value from source to sink for
   unidirectional and
   latency variation carried behind RRO. bidirectional LSP.

   If the total latency value
   does not meet LSP is a bidirectional one and the requirement of "Latency Accumulating
   desired" is set in the customer, patherr LSP_ATTRIBUTES, it adds another Latency
   Accumulation sub-TLV (sub-TLV type=1) into the Latency Accumulation
   object of Resv message SHOULD
   be created where latency of each links and return nodes along
   path will be accumulated from sink to source into this sub-TLV.

   When the ingress node.  Recv upstream node receives Resv message can be used
   to collect and verify if the latency information "Latency
   Accumulating desired" is set in the reverse
   direction in LSP_ATTRIBUTES, it accumulates
   the same way.

   The signaling format latency of link and node based on 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 latency value in ERBO sub-TLV
   (sub-TLV type=1) before it continues to indicate sends Resv message.

   After source node receive Resv message, it can get the total latency information
   value of one way or round-trip from Latency Accumulation object.  So
   it can confirm whether the FA-LSP if there are requirement of latency value meet the
   server layer.

6. latency SLA or not.

4.  Security Considerations

   TBD

7.

5.  IANA Considerations

   TBD

8.

6.  References
8.1.

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

8.2.

6.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/

   Malcolm Betts
   ZTE Corporation

   Email: malcolm.betts@zte.com.cn

   Qilei Wang
   ZTE Corporation

   Email: wang.qilei@zte.com.cn