Internet DRAFT - draft-fuxh-mpls-delay-loss-rsvp-te-ext

draft-fuxh-mpls-delay-loss-rsvp-te-ext






Network Working Group                                              X. Fu
Internet-Draft                                                  M. Betts
Intended status: Standards Track                                 Q. Wang
Expires: April 25, 2013                                              ZTE
                                                              D. McDysan
                                                                A. Malis
                                                                 Verizon
                                                               V. Manral
                                                   Hewlett-Packard Corp.
                                                        October 22, 2012


       RSVP-TE extensions for Loss and Delay Traffic Engineering
               draft-fuxh-mpls-delay-loss-rsvp-te-ext-02

Abstract

   With more and more enterprises using cloud based services, the
   distances between the user and the applications are growing.  For
   multiple applications such as High Performance Computing and
   Electronic Financial markets, the response times are critical as is
   packet loss, while other applications require more throughput.  For
   example, financial or trading companies are very focused on end-to-
   end private pipe line delay optimizations that improve things 2-3 ms.
   Delay, jitter, loss and SLA (Service Level Agreement) are key
   parameters that these "high value" customers use to select a private
   pipe line provider.  This document extends RSVP-TE protocol to
   promote SLA experince of delay and packet loss application.

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 25, 2013.

Copyright Notice




Fu, et al.               Expires April 25, 2013                 [Page 1]

Internet-Draft       RSVP-TE for services aware MPLS        October 2012


   Copyright (c) 2012 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
     1.1.  Conventions Used in This Document  . . . . . . . . . . . .  4
   2.  Performance Accumulation and Verification  . . . . . . . . . .  4
     2.1.  New RSVP ADSPEC sub-object . . . . . . . . . . . . . . . .  4
     2.2.  New RSVP SENDER_TSPEC sub-object . . . . . . . . . . . . .  6
     2.3.  New RSVP FLOWSPEC sub-object . . . . . . . . . . . . . . .  7
     2.4.  Signaling Procedures . . . . . . . . . . . . . . . . . . .  8
   3.  Performance SLA Parameters Conveying . . . . . . . . . . . . .  9
     3.1.  Performance SLA Parameters ERO sub-object  . . . . . . . . 10
     3.2.  Signaling Procedure  . . . . . . . . . . . . . . . . . . . 14
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16



















Fu, et al.               Expires April 25, 2013                 [Page 2]

Internet-Draft       RSVP-TE for services aware MPLS        October 2012


1.  Introduction

   End-to-end service optimization based on delay, jitter and loss is a
   key requirement for service provider.  So communicating delay, jitter
   and packet loss as traffic engineering performance metrics is a very
   important requirement.  [DELAY-LOSS-PS] describes the requirement of
   delay and loss traffic engineering application.  [DELAY-LOSS-
   FRAMEWORK] describes the framework and architecture to meet
   requirements.  Delay, jitter and loss metrics are sent in IGP
   protocol as defined in [OSPF-TE-EXPRESS-PATH] and [ISIS-TE-EXPRESS-
   PATH].  [EXPRESS-PATH] describes how to use these traffic engineering
   metrics to compute explicit paths at path computation entity.  So
   source node could predict end-to-end delay or loss performance before
   an end-to-end LSP is established.

   In the case of multi-domain (e.g., Inter-AS, Inter-Area or Multi-
   Layer), a full path of TE LSP can't be or is not determined at the
   ingress node of TE LSP.  This is most likely to arise owing to TE
   visibility limitations.  If not all domains support to communicate
   delay, jitter and loss as traffic engineering metric parameters, one
   end-to-end optimized path with performance constraint (e.g., less
   than 10 ms) may not be computed by BRPC [RFC5441] in PCE
   architecture.

   This document extend RSVP-TE to accumulate (e.g., sum) delay and loss
   information of links and nodes along one LSP across multi-domain
   (e.g., Inter-AS, Inter-Area or Multi-Layer) so that end points can
   verify whether total amount of delay or loss could meet the agreement
   between operator and his user.  When RSVP-TE signaling is used,
   source node can determine if delay and loss requirement is met much
   more rapidly than performing actual end-to-end performance
   measurement. delay, jitter and loss are part of service/QoS
   description/characterization and that as such belongs in a flowspec/
   tspec/adspec.  This document modify IntServ (as represented by
   RFC210) to provide new parameters.

   One end-to-end LSP may go across some Composite Links [CL-REQ].
   RSVP-TE message needs to carry a indication for selection of
   component links based on delay, jitter or loss constraint.  When one
   end-to-end LSP traverse a server layer, there will be some delay,
   jitter of loss constraint requirements for server layer.  So RSVP-TE
   message needs to carry a indication for FA selection or FA-LSP
   creation.  This document defines a new ERO sub-object to indicate
   that a component links, FA or FA-LSP should meet maximum acceptable
   delay, jitter or loss value.






Fu, et al.               Expires April 25, 2013                 [Page 3]

Internet-Draft       RSVP-TE for services aware MPLS        October 2012


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.  Performance Accumulation and Verification

   Delay, jitter and loss accumulation and verification applies where a
   full path of multi-domain (e.g., Inter-AS, Inter-Area or Multi-Layer)
   TE LSP can't be or is not determined at ingress node of the TE LSP.
   This is most likely to arise owing to TE visibility limitations.  If
   all domains support to communicate delay, jitter and loss as traffic
   engineering metric parameters, one end-to-end optimized path with
   performance constraint (e.g., less than 10 ms) could be computed by
   BRPC [RFC5441] in PCE.  Otherwise, it could use the mechanism defined
   in this section to accumulat delay, jitter and loss along a path
   which goes across multi-domain.

   E2E performance requirement (e.g., delay isn't larger than 10ms)
   could be signaled by RSVP-TE (e.g., Path and Resv message).
   Intermediate nodes could reject the request (Path or Resv message) if
   the accumulated delay, jitter or loss is not achievable.  This is
   essential in multiple AS use cases, but may not be needed in a single
   IGP level/area if the IGP is extended to convey delay, jitter and
   loss information.

   Node delay for a WAN could be ignored or even an average, however
   that was not true for the LAN cases.  Whether the node delay should
   be accumulated or not depends on the implementation.

   One domain may need to know that other domains support performance
   accumulation.  It could be discovered in some automatic way.  PCEs in
   different domains may play a role here.  It is for further study.

2.1.  New RSVP ADSPEC sub-object

   This document defines a new RSVP ADSPEC [RFC2210] sub-object to
   support end-to-end accumulation of delay, jitter or loss.  The new
   RSVP ADSPEC sub-object has the following format.










Fu, et al.               Expires April 25, 2013                 [Page 4]

Internet-Draft       RSVP-TE for services aware MPLS        October 2012


      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              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Accumulated Estimated Performance Value 1            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Accumulated Estimated Performance Value n            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 1: New RSVP ADSPEC sub-Object

   o  Type(TBD): It indicates performance accumulation from source to
      sink.

   o  Length: length of performance accumulation value.

   Accumulated Estimated Performance Value format is defined in 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Value Type  |                     Reserved                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               Value                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 2: Format of Accumulated Estimated Performance Value

   o  Value Type:

      *  0: It indicates Performance Accumulation Value is for end-to-
         end delay accumulation along the LSP.

      *  1: It indicates Performance Accumulation Value is for end-to-
         end jitter accumulation along the LSP.

      *  2: It indicates Performance Accumulation Value is for end-to-
         end loss accumulation along the LSP.

   o  Value:

      *  If it is accumulated estimated delay value, it MUST be
         quantified in units of micro-seconds and encoded as an float
         point value.



Fu, et al.               Expires April 25, 2013                 [Page 5]

Internet-Draft       RSVP-TE for services aware MPLS        October 2012


      *  If it is accumulated estimated delay variation value, it MUST
         be quantified in units of micro-seconds and encoded as an float
         point value.  Since latecny variation is accumulated non-
         linearly, delay variation accumulatoin should be in a lower
         priority.

      *  If it is accumulated estimated loss value, it MUST be
         quantified in units of the number of packets per million
         packets.  For link loss, the path loss is not the sum of the
         used links' losses.   Instead, the path loss percentage is (100
         - loss_L1)*(100 - loss_L2)*...*(100 - loss_Ln), where the links
         along the path are L1 to Ln.  For example, assume packet loss
         is 10% for two hops of a link.  The measurements will come to
         19% total packet loss.  Because of 10% loss on the first link
         only 90% packet reach the second link where another 10% of 90%
         are lost, which is 9% of total packets.

2.2.  New RSVP SENDER_TSPEC sub-object

   This document defines a new RSVP SENDER_TSPEC [RFC2210] sub-object
   which indicates end-to-end latecny, jitter or loss performance
   requirement.  Intermediate nodes could reject the request (Path or
   Resv message) if the accumulated delay, jitter or loss value exceeds
   required performance value in the SENDER_TSPEC sub-object.

   If the accumulated delay, jitter or loss is not achievable, there is
   no necessary to accumulate delay, jitter or loss for remaining domain
   or nodes.

     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              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Performance Requirement Value 1                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Performance Requirement Value n                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 3: New RSVP SENDER_TSPEC sub-object

   The Performance Requirement Value format is defined in the next
   picture.






Fu, et al.               Expires April 25, 2013                 [Page 6]

Internet-Draft       RSVP-TE for services aware MPLS        October 2012


     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Value Type  |                     Reserved                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Value                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 4: Format of Performance Requirement Value

   o  Value Type:

      *  0: It indicates Performance Value is end-to-end delay
         requirement.  The accumulated estimated delay value should not
         exceed this value.  It MUST be quantified in units of micro-
         seconds and encoded as an float point value.

      *  1: It indicates Performance Value is end-to-end jitter
         requirement.  The accumulated estimated delay variation value
         should not exceed this value.  It MUST be quantified in units
         of micro-seconds and encoded as an float point value.

      *  2: It indicateds Performance Value is end-to-end loss
         requirement.  The accumulated estimated loss value should not
         exceed this value.  It MUST be quantified in units of the
         number of packets per million packets.

   o  Value:

      *  If it is end-to-end delay requirement, accumulated estimated
         delay value should not exceed this value.  It MUST be
         quantified in units of micro-seconds and encoded as an float
         point value.

      *  If it is end-to-end jitter requirement, accumulated estimated
         delay variation value should not exceed this value.  It MUST be
         quantified in units of micro-seconds and encoded as an float
         point value.

      *  If it is end-to-end loss requirement, the accumulated estimated
         loss value should not exceed this value.  It MUST be quantified
         in units of the number of packets per million packets.

2.3.  New RSVP FLOWSPEC sub-object

   In order to make source node get performance accumulation result from
   source to sink in multi-domain (e.g., Inter-AS, Inter-Area or Multi-
   Layer) application, this document defines a new RSVP FLOWSPEC



Fu, et al.               Expires April 25, 2013                 [Page 7]

Internet-Draft       RSVP-TE for services aware MPLS        October 2012


   [RFC2210] sub-object.  It has the same format and TLV Type as defined
   in section "2.1 New RSVP ADSPEC sub-object".  When sink node receive
   Path message, it must copy the accumulation result from ADSPEC to
   FLOWSPEC.

   When LSP goes across a Composite Links [CL-REQ], traffic from LSR A
   to B and B to A may go across different Component Links so that
   performance from sink to source may not be indentical to the one from
   source to sink.  This document defines another new RSVP FLOWSPEC
   [RFC2210] sub-object.  It has the same format as defined in section
   "2.1 New RSVP ADSPEC sub-object" except a different TLV Type which
   indicates performance accumulation from sink to source.  So source
   node can get performance accumulated value from sink to source.

   This document also defined a new FLOWSPEC sub-object which has the
   same format, TLV Type and value as defined in section "2.2 New RSVP
   SENDER_TSPEC sub-object".  It indicates end-to-end delay, jitter or
   loss performance requirement.

2.4.  Signaling Procedures

   When source node desires to accumulate delay, jitter or loss of one
   end-to-end LSP, "Delay Accumulating desired", "Jitter Accumulation
   desired" or "Loss Accumulation desired" flag (value TBD) should be
   set in LSP_ATTRIBUTES object of Path/Resv message [RFC5420].  If
   source node makes intermediate node have the capability to verify
   accumulated performance, "Delay Verifying desired", "Jitter Verifying
   desired" or "Loss Verifying desired" flag (value TBD) should be also
   set in LSP_ATTRIBUTES object of Path/Resv message.

   A source node initiates performance accumulation for a given LSP by
   adding a new ADSPEC sub-object as defined in section 2.1 to Path
   message.  If performance verifying is desired, source node also adds
   a new SENDER_TSPEC sub-object as defined in section 2.2 to Path
   message.

   When downstream node receives Path message and if performance (e.g.,
   delay, jitter or loss) accumulating desired is set in the
   LSP_ATTRIBUTES, it accumulates delay, jitter or loss and updates
   ADSPEC sub-object before it sends Path message to downsteam.

   If performance verifying desired is set in LSP_ATTRIBUTES, downstream
   node will check whether accumulated estimated performance value
   exceeds the value carried in SENDER_TSPEC sub-object.  If the
   accumulated performance is not achievable, there is no necessary to
   accumulate performance for remaining domain or nodes.  It MUST
   generate a error message with a indication which means that
   accumulated performance (i.e., delay, jitter or loss) couldn't meet



Fu, et al.               Expires April 25, 2013                 [Page 8]

Internet-Draft       RSVP-TE for services aware MPLS        October 2012


   end-to-end performance requirement (TBD by IANA).

   If intermediate node (e.g., entry node of one domain) couldn't
   support performance accumulation function, it MUST generate a error
   message with a indication which means that performance accumulation
   is unsupported (TBD by IANA).

   When sink node of LSP receives Path message and performance
   accumulating desired is set in LSP_ATTRIBUTES, it copy accumulated
   estimated performance value from ADSPEC to FLOWSPEC before it send
   Resv message to upstream.  Then source node can get performance
   accumulated value from source to sink for unidirectional and
   bidirectional LSP.

   If LSP is a bidirectional one and performance accumulating desired is
   set in LSP_ATTRIBUTES, it adds a FLOWSPEC sub-object as defined in
   section 2.3 to accumulate end-to-end performance value from sink to
   source.

   If LSP is a bidirectional one and performance verifying desired is
   set in LSP_ATTRIBUTES, it copy end-to-end performance requirement
   value from SENDER_TSPEC sub-oject to FLOWSPEC sub-object.

   When upstream node receives Resv message and if performance
   accumulating desired is set in LSP_ATTRIBUTES, it accumulates
   performance of each hops and updates FLOWSPEC sub-object (i.e., from
   sink to source) before it sends Resv message to upstream.

   If performance verifying desired is set in LSP_ATTRIBUTES, it will
   check whether accumulated estimated performance value from sink to
   source exceeds end-to-end performance requirement value.  If
   accumulated performance is not achievable, there is no necessary to
   accumulate performance for remaining domain or nodes.  It MUST
   generate a error message with a indication which means that
   accumulated performance couldn't meet end-to-end performance
   requirement (TBD by IANA).

   After source node receive Resv message, it will get accumulated
   performance value, it can confirm whether performance value meet SLA
   or not.


3.  Performance SLA Parameters Conveying

   [CL-REQ] introduces Composite Link into MPLS network.  In order to
   assign LSP to one of component links with different performance
   characteristics (e.g., delay, jitter and loss), RSVP-TE message MUST
   convey performance SLA parameter to end points of Composite Links.



Fu, et al.               Expires April 25, 2013                 [Page 9]

Internet-Draft       RSVP-TE for services aware MPLS        October 2012


   So it can select one of component links or trigger the creation of
   lower layer connection based on performance SLA parameter.

   One end-to-end LSP (e.g., in IP/MPLS or MPLS-TP network) may traverse
   a FA-LSP of server layer (e.g., OTN rings).  There will be some
   performance constraint requirement for server layer.  RSVP-TE message
   also needs to carry a indication for FA selection or FA-LSP creation.

   So this document extend RSVP-TE to carry a indication of request
   maximum acceptable delay, jitter of loss value.  The end point will
   take these parameters into account for selection or creation of
   component link, FA selection or FA-LSP.

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

3.1.  Performance SLA Parameters ERO sub-object

   A new OPTIONAL sub-object of EXPLICIT_ROUTE Object (ERO) is used to
   specify performance SLA parameters including a indication of request
   maximum acceptable delay, jitter or loss value.  It can be used for
   following scenarios.

   o  One end-to-end LSP may traverse a server layer FA-LSP.  This sub-
      object of ERO can indicate that FA selection or FA-LSP creation
      shall be based on delay, jitter or loss constraint.  The boundary
      nodes of 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 delay, jitter of loss constraint
      values as specified in this subobject.

   Performance 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 used.










Fu, et al.               Expires April 25, 2013                [Page 10]

Internet-Draft       RSVP-TE for services aware MPLS        October 2012


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L| Type(IANA)  |     Length    |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Request Maximum Acceptable Performance Value 1        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Request Maximum Acceptable Performance Value n        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 5: Format of Performance SLA Parameters TLV

   Request Maximum Acceptable Performance Value format is defined in 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Value Type  |M|                   Reserved                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               Value                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 6: Format of Request Maximum Acceptable Performance Value

   o  Value Type:

      *  0: It is maximum acceptable delay value.

      *  1: It is maximum acceptable delay variation value.

      *  2: It is maximum acceptable loss value.

   o  M bit: a one bit field indicates whether a traffic flow shall
      select a component link with minimum performance (i.e., delay,
      jitter or loss) value or not.  It can also indicate whether one
      end-to-end LSP shall select a FA with minimum performance value or
      not when it traverse a server layer.

   o  Value:

      *  If it is maximum acceptable delay or jitter value, it MUST be
         quantified in units of micro-seconds and encoded as an float
         point value.





Fu, et al.               Expires April 25, 2013                [Page 11]

Internet-Draft       RSVP-TE for services aware MPLS        October 2012


      *  If it is maximum acceptable loss value, it MUST be quantified
         in units of the number of packets per million packets.

   Following is an example about how to use these parameters.  Assume
   there are following component links within one composite link.

   o  Component link1: delay=50 ms, delay variation=15 ns, loss=8%

   o  Component link2: delay=100 ms, delay variation=6 ns, loss=9%

   o  Component link3: delay=200 ms, delay variation=3 ns, loss=8%

   o  Component link4: delay=300 ms, delay variation=1 ns, loss=7%


   Assume there are following request information.

   o  Request minimum delay=FALSE

   o  Request minimum delay variation=FALSE

   o  Request minimum loss=FALSE

   o  Maximum Acceptable delay Value=150 ms

   o  Maximum Acceptable delay Variation Value=10 ns

   o  Maximum Acceptable Loss Value=10%

   Only Component link2 could be qualified.


   o  Request minimum delay=FALSE

   o  Request minimum delay variation=FALSE

   o  Request minimum loss=FALSE

   o  Maximum Acceptable Delay Value=350 ms

   o  Maximum Acceptable Delay Variation Value=10 ns

   o  Maximum Acceptable Loss Value=8%

   Component link 3 and 4 could be qualified.  Which component link is
   selected depends on local policy.





Fu, et al.               Expires April 25, 2013                [Page 12]

Internet-Draft       RSVP-TE for services aware MPLS        October 2012


   o  Request minimum delay=FALSE

   o  Request minimum delay variation=TRUE

   o  Request minimum loss=FALSE

   o  Maximum Acceptable Delay Value=350 ms

   o  Maximum Acceptable Delay Variation Value=10 ns

   o  Maximum Acceptable Loss Value=10%

   Only Component link4 could be qualified.


   o  Request minimum delay=TRUE

   o  Request minimum delay variation=FALSE

   o  Request minimum loss=FALSE

   o  Maximum Acceptable Delay Value=350 ms

   o  Maximum Acceptable Delay Variation Value=10 ns

   o  Maximum Acceptable Loss Value=10%

   Only Component link2 could be qualified.

   o  Request minimum delay=FALSE

   o  Request minimum delay variation=FALSE

   o  Request minimum loss=TRUE

   o  Maximum Acceptable Delay Value= 350 ms

   o  Maximum Acceptable Delay Variation Value=10 ns

   o  Maximum Acceptable Loss Value=10%

   Only Component link4 could be qualified.

      Request minimum delay=TRUE

      Request minimum delay variation=TRUE





Fu, et al.               Expires April 25, 2013                [Page 13]

Internet-Draft       RSVP-TE for services aware MPLS        October 2012


      Request minimum loss=TRUE

      Maximum Acceptable delay Value=350 ms

      Maximum Acceptable delay Variation Value=10 ns

      Maximum Acceptable Loss Value=10%

   In this case, there is no any qualified component links.  But
   priority may be used for delay and variation, so one of component
   links could be still selected.

3.2.  Signaling Procedure

   When a intermediate node receives a PATH message containing ERO and
   finds that there is a Performance SLA Parameters ERO sub-object
   immediately behind the 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 Performance SLA parameters (i.e., request maximum acceptable
   delay, jitter and loss value) from Performance SLA Parameters ERO
   sub-object.  This node used these performance parameters for FA
   selection, FA-LSP creation or component link selection.

   If intermediate node couldn't support performance SLA, it MUST
   generate a PathErr message with a "Performance SLA unsupported"
   indication (TBD by IANA).  If intermediate node couldn't select a FA
   or component link, or create a FA-LSP which meet performance
   constraint defined in Performance SLA Parameters ERO sub-object, it
   must generate a PathErr message with a "Performance SLA parameters
   couldn't be met" indication (TBD by IANA).


4.  Security Considerations

   This document raises no new security issues.


5.  IANA Considerations

   TBD


6.  References







Fu, et al.               Expires April 25, 2013                [Page 14]

Internet-Draft       RSVP-TE for services aware MPLS        October 2012


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.

6.2.  Informative References

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

   [DELAY-LOSS-FRAMEWORK]
              X.Fu, D. McDysan et al., "Loss and Delay Traffic
              Engineering Framework for MPLS",
              draft-fuxh-mpls-delay-loss-te-framework-05 .

   [EXPRESS-PATH]
              A. Atlas, "Performance-based Path Selection for Explicitly
              Routed LSPs", draft-atlas-mpls-te-express-path-01 .

   [ISIS-TE-EXPRESS-PATH]
              S. Previdi, "IS-IS Traffic Engineering (TE) Metric
              Extensions", draft-previdi-isis-te-metric-extensions-01 .

   [LOSS-DELAY-PS]
              X.Fu, D. McDysan et al., "Delay and Loss Traffic
              Engineering Problem Statement for MPLS",
              draft-fuxh-mpls-delay-loss-te-problem-statement-00 .




Fu, et al.               Expires April 25, 2013                [Page 15]

Internet-Draft       RSVP-TE for services aware MPLS        October 2012


   [OSPF-TE-EXPRESS-PATH]
              S. Giacalone, "OSPF Traffic Engineering (TE) Metric
              Extensions", draft-ietf-ospf-te-metric-extensions-01 .

   [ietf-mpls-loss-delay]
              D. Frost, "Packet Loss and Delay Measurement for MPLS
              Networks", RFC6374 .


Authors' Addresses

   Xihua Fu
   ZTE

   Email: fu.xihua@zte.com.cn


   Malcolm Betts
   ZTE

   Email: malcolm.betts@zte.com.cn


   Qilei Wang
   ZTE

   Email: wang.qilei@zte.com.cn


   Dave McDysan
   Verizon

   Email: dave.mcdysan@verizon.com


   Andrew Malis
   Verizon

   Email: andrew.g.malis@verizon.com


   Vishwas Manral
   Hewlett-Packard Corp.

   Email: vishwas.manral@hp.com






Fu, et al.               Expires April 25, 2013                [Page 16]