PCE Working Group D. Dhody Internet-Draft Huawei Technologies India Pvt Intended status: Standards Track Ltd Expires: June 17, 2012 V. Manral Hewlett-Packard Corp. December 15, 2011 Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP). draft-dhody-pce-pcep-service-aware-02 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-DELAY-FWK] describes MPLS architecture to allow latency, loss and jittering as properties. [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS] describes mechanisms with which network performance information is distributed via OSPF and ISIS respectivily. 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 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 June 17, 2012. Copyright Notice Dhody & Manral Expires June 17, 2012 [Page 1] Internet-Draft SERVICE-AWARE December 2011 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 Simplified 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 . . . . . . . . . . . . . . . 9 5.3. P2MP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Manageability Considerations . . . . . . . . . . . . . . . . . 9 8.1. Control of Function and Policy . . . . . . . . . . . . . . 9 8.2. Information and Data Models . . . . . . . . . . . . . . . 9 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 10 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 10 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 10 8.6. Impact On Network Operations . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 Dhody & Manral Expires June 17, 2012 [Page 2] Internet-Draft SERVICE-AWARE December 2011 1. Introduction Real time Network Performance is becoming a critical in the path computation in some networks. There exist mechanism described in [RFC6374] 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] or [ISIS-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) [RFC5440] 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 June 17, 2012 [Page 3] Internet-Draft SERVICE-AWARE December 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 June 17, 2012 [Page 4] Internet-Draft SERVICE-AWARE December 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 June 17, 2012 [Page 5] Internet-Draft SERVICE-AWARE December 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 June 17, 2012 [Page 6] Internet-Draft SERVICE-AWARE December 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 June 17, 2012 [Page 7] Internet-Draft SERVICE-AWARE December 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. All domains should have the same understanding of the METRIC (Latency-Variation etc) for end-to-end inter-domain path computation to make sense. Otherwise some form of Metric Normalization as described in [RFC5441] MAY need to be applied. 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] and [ISIS-TE-EXPRESS], the same properties must be advertised using the mechanism described in [RFC5392] (OSPF) and [RFC5316] (ISIS). 5.1.2. Inter-Layer Consideration PCEP supporting this draft SHOULD provide mechanism to support differnt Metric requirements for different Layers. This is important as the network performance metric would be different for Packet and Dhody & Manral Expires June 17, 2012 [Page 8] Internet-Draft SERVICE-AWARE December 2011 Optical (TDM, LSC etc) Layers. In order to allow different Metric- Value to be applied within different network layers, multiple METRIC objects of the same type MAY be present. In such a case, the first METRIC object specifies an metric for the higher-layer network, and subsequent METRIC objects specify objection functions of the subsequent lower-layer networks. 5.2. Reoptimization Consideration PCC can monitor the setup LSPs and incase of degradation of network performance constraints, it MAY ask PCE for reoptimization as per [RFC5440]. 5.3. P2MP The scope of the network performance constraints as listed in this document needs to be described in terms of P2MP TE LSPs. This section needs further discussions. 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 This document defines three new METRIC Types with does not add any new security concerns to PCEP protocol. 8. Manageability Considerations 8.1. Control of Function and Policy The only configurable item is the support of the new service-aware METRICS on a PCE which MAY be controlled by a policy module. If the new METRIC is not supported/allowed on a PCE, it MUST send a PCErr message as specified in Section 4.4. 8.2. Information and Data Models [PCEP-MIB] describes the PCEP MIB, there are no new MIB Objects for this document. Dhody & Manral Expires June 17, 2012 [Page 9] Internet-Draft SERVICE-AWARE December 2011 8.3. Liveness Detection and Monitoring Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440]. 8.4. Verify Correct Operations Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440]. 8.5. Requirements On Other Protocols PCE requires the TED to be populated with network performance information like link latency, latency variation and packet loss. This mechanims is described in [OSPF-TE-EXPRESS] or [ISIS-TE-EXPRESS]. 8.6. Impact On Network Operations Mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440]. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. 9.2. Informative References [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006. [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation Dhody & Manral Expires June 17, 2012 [Page 10] Internet-Draft SERVICE-AWARE December 2011 (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009. [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, December 2008. [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, January 2009. [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011. [MPLS-DELAY-FWK] Fu, X., Manral, V., McDysan, D., Malis, A., Giacalone, S., Betts, M., Wang, Q., and J. Drake, "Traffic Engineering architecture for services aware MPLS [draft-fuxh-mpls-delay-loss-te-framework]", Oct 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]", Sept 2011. [ISIS-TE-EXPRESS] Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas, A., and C. Filsfils, "IS-IS Traffic Engineering (TE) Metric Extensions [draft-previdi-isis-te-metric-extensions]", Oct 2011. [PCEP-MIB] Kiran Koushik, A S., Stephan, E., Zhao, Q., and D. King, "PCE communication protocol(PCEP) Management Information Base", July 2010. Dhody & Manral Expires June 17, 2012 [Page 11] Internet-Draft SERVICE-AWARE December 2011 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 June 17, 2012 [Page 12]