PCE Working Group                                               D. Dhody
Internet-Draft                         Huawei Technologies India Pvt Ltd
Intended status: Standards Track                               V. Manral
Expires: March 12, 2012                            Hewlett-Packard Corp.
                                                       September 9, 2011


Extensions to the Path Computation Element Communication Protocol (PCEP)
          to compute service aware Label Switched Path (LSP).
                 draft-dhody-pce-pcep-service-aware-01

Abstract

   In certain networks like financial information network (stock/
   commodity trading) and enterprises using cloud based applications,
   Latency (delay), Latency-Variation (jitter) and Packet loss is
   becoming a key requirement for path computation along with other
   constraints and metrics.  Latency, Latency-Variation and Packet Loss
   is associated with the Service Level Agreement (SLA) between
   customers and service providers.

   [MPLS-SERVICE] describes MPLS architecture to allow latency, loss and
   jittering as properties.  [OSPF-TE-EXPRESS] describes mechanisms with
   which network performance information is distributed via OSPF.  This
   document describes the extension to PCEP to carry Latency, Latency-
   Variation and Loss as constraints for end to end path computation.

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.




Dhody & Manral           Expires March 12, 2012                 [Page 1]


Internet-Draft                SERVICE-AWARE               September 2011


   This Internet-Draft will expire on March 12, 2012.

Copyright Notice

   Copyright (c) 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 BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Requirement for PCEP  . . . . . . . . . . . . . . . . . . . . . 4
   4.  Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     4.1.  Latency (Delay) Metric  . . . . . . . . . . . . . . . . . . 5
     4.2.  Latency Variation (Jitter) Metric . . . . . . . . . . . . . 6
     4.3.  Packet Loss Metric  . . . . . . . . . . . . . . . . . . . . 6
     4.4.  Non-Understanding / Non-Support of Service Aware Path
           Computation . . . . . . . . . . . . . . . . . . . . . . . . 7
     4.5.  Mode of Operation . . . . . . . . . . . . . . . . . . . . . 7
       4.5.1.  Examples  . . . . . . . . . . . . . . . . . . . . . . . 8
   5.  Protocol Consideration  . . . . . . . . . . . . . . . . . . . . 8
     5.1.  Inter domain Consideration  . . . . . . . . . . . . . . . . 8
       5.1.1.  Inter-AS Link . . . . . . . . . . . . . . . . . . . . . 8
       5.1.2.  Inter-Layer Consideration . . . . . . . . . . . . . . . 8
     5.2.  Reoptimization Consideration  . . . . . . . . . . . . . . . 8
     5.3.  Policy Consideration  . . . . . . . . . . . . . . . . . . . 9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 9
   8.  Manageability Considerations  . . . . . . . . . . . . . . . . . 9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 9
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 9








Dhody & Manral           Expires March 12, 2012                 [Page 2]


Internet-Draft                SERVICE-AWARE               September 2011


1.  Introduction

   Real time Network Performance is becoming a critical in the path
   computation in some networks.  There exist mechanism described in
   [MPLS-LOSS-DELAY] to measure latency, latency-Variation and packet
   loss after the LSP has been established, which is inefficient.  It's
   important that latency, latency-variation and packet loss are
   considered during path selection process itself.

   TED is populated with network performance information like link
   latency, latency variation and packet loss through [OSPF-TE-EXPRESS].
   Path Computation Client (PCC) can request Path Computation Element
   (PCE) to provide a path meeting end to end network performance
   criteria.  This document extends Path Computation Element
   Communication Protocol (PCEP) [RFC 5440] to handle network
   performance constraint.

1.1.  Requirements Language

   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 following terminology is used in this document.

   IGP:  Interior Gateway Protocol.  Either of the two routing
      protocols, Open Shortest Path First (OSPF) or Intermediate System
      to Intermediate System (IS-IS).

   IS-IS:  Intermediate System to Intermediate System.

   OSPF:  Open Shortest Path First.

   PCC:  Path Computation Client: any client application requesting a
      path computation to be performed by a Path Computation Element.

   PCE:  Path Computation Element.  An entity (component, application,
      or network node) that is capable of computing a network path or
      route based on a network graph and applying computational
      constraints.

   TE:  Traffic Engineering.







Dhody & Manral           Expires March 12, 2012                 [Page 3]


Internet-Draft                SERVICE-AWARE               September 2011


3.  Requirement for PCEP

   End-to-end service optimization based on latency, latency-variation
   and packet loss is a key requirement for service provider.  Following
   key requirements associated with latency, latency-variation and loss
   is identified for PCEP:

   1.  Path Computation Element (PCE) supporting this draft MUST have
       the capability to compute end-to-end path with latency, latency-
       variation and packet loss constraints.  It MUST also support the
       combination of network performance constraint (latency, latency-
       variation, loss...) with existing constraints (cost, hop-
       limit...)

   2.  Path Computation Client (PCC) supporting this draft MUST be able
       to request for network performance constraint in path request
       message as the key constraint to be optimized or to suggest
       boundary condition that should not be crossed.

   3.  PCEs are not required to support service aware path computation.
       Therefore, it MUST be possible for a PCE to reject a Path
       Computation Request message with a reason code that indicates no
       support for service-aware path computation.

   4.  PCEP supporting this draft SHOULD provide a means to return end
       to end network performance information of the computed path in
       the reply message.

   5.  PCEP supporting this draft SHOULD provide mechanism to compute
       multi-domain (e.g., Inter-AS, Inter-Area or Multi-Layer) service
       aware paths.

   It must be understood that such constraints are only meaningful if
   used consistently: for instance, if the delay of a computed path
   segment is exchanged between two PCEs residing in different domains,
   consistent ways of defining the delay must be used.

4.  Objects

   This section defines PCEP extensions (see [RFC5440]) so as to support
   network performance and service aware path computation.

   [RFC5440] defines the optional METRIC object for several purposes.
   In a PCReq message, a PCC MAY insert one or more METRIC objects to
   indicate the metric that MUST be optimized or to indicate a bound on
   the path that MUST NOT be exceeded for the path to be considered as
   acceptable by the PCC.  In a PCRep message, the METRIC object MAY be
   inserted so as to provide the value for the computed path.  It MAY



Dhody & Manral           Expires March 12, 2012                 [Page 4]


Internet-Draft                SERVICE-AWARE               September 2011


   also be inserted within a PCRep with the NO-PATH object to indicate
   that the metric constraint could not be satisfied.

   As per [RFC5440] the format of the METRIC object body is as follows:
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Reserved             |    Flags  |C|B|       T       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          metric-value                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         T (Type - 8 bits):  Specifies the metric type.
         Three values are currently defined:
         *  T=1: IGP metric
         *  T=2: TE metric
         *  T=3: Hop Counts

   Based on the section 3, PCEP is extended to define new METRIC types
   for network performance constraints.

4.1.  Latency (Delay) Metric

   The end to end Latency (Delay) for the path is represented by this
   metric.

   * T=13(IANA): Latency metric

   PCC MAY use this latency metric In PCReq to request a path meeting
   the end to end latency requirement.  In this case B bit MUST be set
   to suggest a bound (a maximum) for the path latency metric that must
   not be exceeded for the PCC to consider the computed path as
   acceptable.  The path metric must be less than or equal to the value
   specified in the metric-value field.

   PCC MAY also use this metric to ask PCE to optimize delay during path
   computation, in this case B flag will be cleared.

   PCE MAY use this latency metric In PCRep along with NO-PATH object
   incase PCE cannot compute a path meeting this constraint.  PCE MAY
   also use this metric to reply the computed end to end latency metric
   to PCC.

   The metric value represents the end to end Latency (delay) measured
   in milliseconds.






Dhody & Manral           Expires March 12, 2012                 [Page 5]


Internet-Draft                SERVICE-AWARE               September 2011


4.2.  Latency Variation (Jitter) Metric

   The end to end Latency Variation (Jitter) for the path is represented
   by this metric.

   * T=14(IANA): Latency Variation metric

   PCC MAY use this latency variation metric In PCReq to request a path
   meeting the end to end latency variation requirement.  In this case B
   bit MUST be set to suggest a bound (a maximum) for the path latency
   variation metric that must not be exceeded for the PCC to consider
   the computed path as acceptable.  The path metric must be less than
   or equal to the value specified in the metric-value field.

   PCC MAY also use this metric to ask PCE to optimize jitter during
   path computation, in this case B flag will be cleared.

   PCE MAY use this latency variation metric In PCRep along with NO-PATH
   object incase PCE cannot compute a path meeting this constraint.  PCE
   MAY also use this metric to reply the computed end to end latency
   variation metric to PCC.

   The metric value represents the end to end Latency variation (jitter)
   measured in microseconds.

4.3.  Packet Loss Metric

   The end to end Packet Loss for the path is represented by this
   metric.

   * T=15(IANA): Packet Loss metric

   PCC MAY use this packet loss metric In PCReq to request a path
   meeting the end to end packet loss requirement.  In this case B bit
   MUST be set to suggest a bound (a maximum) for the path packet loss
   metric that must not be exceeded for the PCC to consider the computed
   path as acceptable.  The path metric must be less than or equal to
   the value specified in the metric-value field.

   PCC MAY also use this metric to ask PCE to optimize packet loss
   during path computation, in this case B flag will be cleared.

   PCE MAY use this packet loss metric In PCRep along with NO-PATH
   object incase PCE cannot compute a path meeting this constraint.  PCE
   MAY also use this metric to reply the computed end to end packet loss
   metric to PCC.

   The metric value represents the end to end packet loss measured as a



Dhody & Manral           Expires March 12, 2012                 [Page 6]


Internet-Draft                SERVICE-AWARE               September 2011


   percentage and represented in 32 bit floating point.

4.4.  Non-Understanding / Non-Support of Service Aware Path Computation

   If the P bit is clear in the object header and PCE doesn't understand
   or doesn't support service aware path computation it SHOULD simply
   ignore this METRIC.

   If the P Bit is set in the object header and PCE receives new METRIC
   type in path request and it understands the METRIC type, but the PCE
   is not capable of service aware path computation, the PCE MUST send a
   PCErr message with a PCEP-ERROR Object Error-Type = 4 (Not supported
   object) [RFC5440].  The path computation request MUST then be
   cancelled.

   If the PCE does not understand the new METRIC type, then the PCE MUST
   send a PCErr message with a PCEP-ERROR Object Error-Type = 3 (Unknown
   object) [RFC5440].

4.5.  Mode of Operation

   As explained in [RFC5440], The METRIC object is optional and can be
   used for several purposes.  In a PCReq message, a PCC MAY insert one
   or more METRIC objects:

   o  To indicate the metric that MUST be optimized by the path
      computation algorithm (Latency, Latency-Variation or Loss)

   o  To indicate a bound on the path METRIC (Latency, Latency-Variation
      or Loss) that MUST NOT be exceeded for the path to be considered
      as acceptable by the PCC.

   In a PCRep message, the METRIC object MAY be inserted so as to
   provide the METRIC (Latency, Latency-Variation or Loss) for the
   computed path.  It MAY also be inserted within a PCRep with the NO-
   PATH object to indicate that the metric constraint could not be
   satisfied.

   The path computation algorithmic aspects used by the PCE to optimize
   a path with respect to a specific metric are outside the scope of
   this document.

   All the rules of processing METRIC object as explained in [RFC5440]
   are applicable to the new metric types as well.







Dhody & Manral           Expires March 12, 2012                 [Page 7]


Internet-Draft                SERVICE-AWARE               September 2011


4.5.1.  Examples

   If a PCC sends a path computation request to a PCE where the metric
   to optimize is the latency and the packet loss must not exceed the
   value of M, two METRIC objects are inserted in the PCReq message:

   o  First METRIC object with B=0, T=13, C=1, metric-value=0x0000

   o  Second METRIC object with B=1, T=15, metric-value=M

   If a path satisfying the set of constraints can be found by the PCE
   and there is no policy that prevents the return of the computed
   metric, the PCE inserts one METRIC object with B=0, T=13, metric-
   value= computed end to end latency.  Additionally, the PCE may insert
   a second METRIC object with B=1, T=15, metric-value= computed end to
   end packet loss.

5.  Protocol Consideration

   There is no change in the message format of Path Request and Reply
   Message.

5.1.  Inter domain Consideration

   [RFC5441] describes the BRPC procedure to compute end to end
   optimized inter domain path by cooperating PCEs.  The network
   performance constraints can be applied end to end in similar manner
   as IGP or TE cost.

5.1.1.  Inter-AS Link

   The IGP in each neighbor domain can advertise its inter-domain TE
   link capabilities, this has been described in [RFC5316] (ISIS) and
   [RFC5392] (OSPF).  The network performance link properties are
   described in [OSPF-TE-EXPRESS], the same properties must be
   advertised using the mechanism described in [RFC5392] (OSPF).

5.1.2.  Inter-Layer Consideration

   TBD

5.2.  Reoptimization Consideration

   TBD







Dhody & Manral           Expires March 12, 2012                 [Page 8]


Internet-Draft                SERVICE-AWARE               September 2011


5.3.  Policy Consideration

   TBD

6.  IANA Considerations

   IANA has defined a registry for new METRIC type.

                 Type        Meaning
                 13(TBD)     Latency (delay) metric
                 14(TBD)     Latency Variation (jitter) metric
                 15(TBD)     Packet Loss metric

7.  Security Considerations

   TBD

8.  Manageability Considerations

   TBD

9.  References

9.1.  Normative References

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

9.2.  Informative References

   [MPLS-LOSS-DELAY]  Frost, D. and S. Bryant, "Packet Loss and Delay
                      Measurement for MPLS Networks
                      [draft-ietf-mpls-loss-delay-04]", July 2011.

   [MPLS-SERVICE]     Manral, V., "Traffic Engineering architecture for
                      services aware MPLS
                      [draft-manral-mpls-service-01]", July 2011.

   [OSPF-TE-EXPRESS]  Giacalone, S., Ward, D., Drake, J., Atlas, A., and
                      V. Previdi, "OSPF Traffic Engineering (TE) Express
                      Path [draft-giacalone-ospf-te-express-path-01]",
                      May 2011.

   [RFC4655]          Ash, J., Vasseur, JP., and A. Farrel, "A Path
                      Computation Element (PCE)-Based Architecture",
                      Aug 2006.

   [RFC4657]          Ash, J. and JL. Le Roux, "Path Computation Element



Dhody & Manral           Expires March 12, 2012                 [Page 9]


Internet-Draft                SERVICE-AWARE               September 2011


                      (PCE) Communication Protocol Generic
                      Requirements", Sept 2006.

   [RFC5316]          M Chen, M., Zhang, R., and X. Duan, "ISIS
                      Extensions in Support of Inter-Autonomous System
                      (AS) MPLS and GMPLS Traffic Engineering",
                      December 2008.

   [RFC5392]          M Chen, M., Zhang, R., and X. Duan, "OSPF
                      Extensions in Support of Inter-Autonomous System
                      (AS) MPLS and GMPLS Traffic Engineering",
                      January 2009.

   [RFC5440]          Ayyangar, A ., Farrel, A ., Oki, E., Atlas, A.,
                      Dolganow, A., Ikejiri, Y., Kumaki, K., Vasseur,
                      J., and J. Roux, "Path Computation Element (PCE)
                      communication Protocol (PCEP)", March 2009.

   [RFC5441]          Vasseur, JP., Zhang, R., Bitar, N., and JL. Le
                      Roux, "A Backward-Recursive PCE-Based Computation
                      (BRPC) Procedure to Compute Shortest Constrained
                      Inter-Domain Traffic Engineering Label Switched
                      Paths", April 2009.

Authors' Addresses

    Dhruv Dhody
   Huawei Technologies India Pvt Ltd
   Leela Palace
   Bangalore, Karnataka  560008
   INDIA

   EMail: dhruv.dhody@huawei.com


   Vishwas Manral
   Hewlett-Packard Corp.
   191111 Pruneridge Ave.
   Cupertino, CA  95014
   USA

   EMail: vishwas.manral@hp.com









Dhody & Manral           Expires March 12, 2012                [Page 10]