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]