<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
	<!ENTITY RFC3209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml">
	<!ENTITY RFC3473 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3473.xml">
	<!ENTITY RFC3477 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3477.xml">
	<!ENTITY RFC3630 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3630.xml">
	<!ENTITY RFC4203 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4203.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-fuxh-mpls-delay-loss-rsvp-te-ext-02" ipr="trust200902">
	<front>	
		<title abbrev="RSVP-TE for services aware MPLS">
		  RSVP-TE extensions for Loss and Delay Traffic Engineering
		</title>
		<author fullname="Xihua Fu" initials="X" surname="Fu">
			<organization>ZTE</organization>
			<address>				
				<email>fu.xihua@zte.com.cn</email>				
			</address>
		</author>	
		<author fullname="Malcolm Betts" initials="M" surname="Betts">	
			<organization>ZTE</organization>
			<address>				
				<email>malcolm.betts@zte.com.cn</email>				
			</address>
		</author>		
		<author fullname="Qilei Wang" initials="Q.L" surname="Wang">
			<organization>ZTE</organization>
			<address>				
				<email>wang.qilei@zte.com.cn</email>				
			</address>
		</author>	
		<author fullname="Dave McDysan" initials="D." surname="McDysan">
			<organization>Verizon</organization>
			<address>				
				<email>dave.mcdysan@verizon.com</email>
			</address>
		</author>	
		<author fullname="Andrew Malis" initials="A." surname="Malis">
			<organization>Verizon</organization>
			<address>				
				<email>andrew.g.malis@verizon.com</email>
			</address>
		</author>			
    <author fullname="Vishwas Manral" initials="V." surname="Manral">
      <organization>Hewlett-Packard Corp.</organization>
      <address>        
        <email>vishwas.manral@hp.com</email>
      </address>
    </author>			
		<date year="2012"/>		
		<area>Routing</area>
		<workgroup>Network Working Group</workgroup>
		<keyword>delay computation</keyword>
		<keyword>delay verification</keyword>
		<keyword>delay</keyword>
		<keyword>RSVP-TE</keyword>
		<keyword>OSPF-TE</keyword>
		<abstract>
			<t>
				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.			
			</t>
		</abstract>		
	</front>	
	<middle>		
	<section title="Introduction">		
		<t>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.
		</t>
		<t>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.	
       	
		</t>
		<t>
			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.

      <vspace blankLines="1"/>
      
      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.
		</t>
		<section title="Conventions Used in This Document">
		<t>
		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].
		</t>
		</section>
	</section>			
			<section title="Performance Accumulation and Verification">
				<t>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.
				</t>
				<t>
				   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.			 
		    </t> 
		    <t>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.		    	
		    </t>		    
				<t>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.	
				</t>				
				<section title="New RSVP ADSPEC sub-object">
					<t>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.
					</t>						
					<figure anchor="figure1" title="New RSVP ADSPEC sub-Object">
			  	<artwork align="center"><![CDATA[
 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            |   
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
					</artwork>
					</figure>
					<list style="symbols">
			  		<t>Type(TBD): It indicates performance accumulation from source to sink.</t>
			  		<t>Length: length of performance accumulation value.</t>
					</list>						
					<t>Accumulated Estimated Performance Value format is defined in the next picture.</t>
					<figure anchor="figure2" title="Format of Accumulated Estimated Performance Value">
			  	<artwork align="center"><![CDATA[
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                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
					</artwork>
					</figure>					
					<t>
						 <list style="symbols">
						  <t>Value Type:
						  	<list style="symbols">
						  		<t>0: It indicates Performance Accumulation Value is for end-to-end delay accumulation along the LSP.</t>
						  		<t>1: It indicates Performance Accumulation Value is for end-to-end jitter accumulation along the LSP.</t>
						  		<t>2: It indicates Performance Accumulation Value is for end-to-end loss accumulation along the LSP.</t>
						  	</list>
						  </t>						  
						  <t>Value:
						  	<list style="symbols">
						  		<t>If it is accumulated estimated delay value,
						  			 it MUST be quantified in units of micro-seconds and encoded as an float point value.
						  		</t>
						  		<t>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.
						  		</t>
						  		<t>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.
						  		</t>						  		
						  	</list>
						  </t>			            
	           </list>
          </t>		        
        </section>		        
        <section title="New RSVP SENDER_TSPEC sub-object">
        	<t>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.
        	</t>
        	<t>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.	        	   
        	</t>
					<figure anchor="figure3" title="New RSVP SENDER_TSPEC sub-object">
			  	<artwork align="center"><![CDATA[
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                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
					</artwork>
					</figure>		        
					<t>The Performance Requirement Value format is defined in the next picture.</t>
					<figure anchor="figure4" title="Format of Performance Requirement Value">
			  	<artwork align="center"><![CDATA[
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                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
					</artwork>
					</figure>					
					<t>
						 <list style="symbols">
						  <t>Value Type:
						  	<list style="symbols">
						  		<t>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.</t>
						  		<t>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.</t>
						  		<t>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.</t>
						  	</list>
						  </t>
						  <t>Value:
						  	<list style="symbols">
						  		<t>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.</t>
						  		<t>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.</t>
						  		<t>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.</t>
						  	</list>
						  </t>           
	           </list>
          </t>					 												        	
        </section>
        <section title ="New RSVP FLOWSPEC sub-object">
        	<t>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 [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.
        	</t>
        	<t>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.
        	</t>
        	<t>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.
        	</t>
        </section>
        <section title="Signaling Procedures">
        	<t>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.
        	</t>	        	
        	<t>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. 
        	</t>
        	<t>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.
        	</t>
        	<t>
        	   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 end-to-end performance requirement (TBD by IANA). 
        	</t>
        	<t>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). 
        	</t>	        		        	
	      	<t>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.
        	</t>
        	<t>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.	        	   
        	</t>
        	<t>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.
        	</t>
        	<t>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. 	        	   
        	</t>
        	<t>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).
					</t>
        	<t>After source node receive Resv message, it will get accumulated performance value,
        		it can confirm whether performance value meet SLA or not. 
        	</t>
  			</section>
			</section>		
  <section title="Performance SLA Parameters Conveying">
		<t>[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.
			 So it can select one of component links or trigger the creation of lower layer connection 
			 based on performance SLA parameter.						   
		</t>
		<t>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.
		</t>	 
		<t>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.
	  </t>		
		<t>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.
		</t>
		<section title="Performance SLA Parameters ERO sub-object">
			<t>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.
			   <list style="symbols">
			   	<t>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.					   	
			   	</t>
			   	<t>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.					   	    
			   	</t>
			   </list>
			</t>
			<t>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. 						   
			</t>
			<figure anchor="figure5" title="Format of Performance SLA Parameters TLV">
	  	<artwork align="center"><![CDATA[
 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        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
				</artwork>
				</figure>
				<t>Request Maximum Acceptable Performance Value format is defined in the next picture.
					<figure anchor="figure6" title="Format of Request Maximum Acceptable Performance Value">
			  	<artwork align="center"><![CDATA[
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                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
					</artwork>
					</figure>
			  	<list style="symbols">
					  <t>Value Type:
					  	<list style="symbols">
					  		<t>0: It is maximum acceptable delay value.</t>
					  		<t>1: It is maximum acceptable delay variation value.</t>
					  		<t>2: It is maximum acceptable loss value.</t>
					  	</list>
					  </t>
					  <t>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.
            </t>
            <t>Value:
            	<list style="symbols">
            	 <t>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.</t>
            	 <t>If it is maximum acceptable loss value, it MUST be quantified in units of the number of packets per million packets.</t>
            	</list>
            </t>
         	</list>
        </t>
        <t>Following is an example about how to use these parameters.
         	 Assume there are following component links within one composite link.
        	 <list style="symbols">
           	<t>Component link1: delay=50 ms, delay variation=15 ns, loss=8%</t>
            <t>Component link2: delay=100 ms, delay variation=6 ns, loss=9%</t>
            <t>Component link3: delay=200 ms, delay variation=3 ns, loss=8%</t>
            <t>Component link4: delay=300 ms, delay variation=1 ns, loss=7%</t>
           </list>
           
           <vspace blankLines="1"/>
           
           Assume there are following request information.
           <list style="symbols">
        	 	<t>Request minimum delay=FALSE</t>
        	 	<t>Request minimum delay variation=FALSE</t>
        	 	<t>Request minimum loss=FALSE</t>          	 	
        	 	<t>Maximum Acceptable delay Value=150 ms</t>
        	 	<t>Maximum Acceptable delay Variation Value=10 ns</t>
        	 	<t>Maximum Acceptable Loss Value=10%</t>
        	 	
           </list>
        	 Only Component link2 could be qualified.
          
           <vspace blankLines="1"/>
           
           <list style="symbols">    
        	 	<t>Request minimum delay=FALSE</t>
        	 	<t>Request minimum delay variation=FALSE</t>
        	 	<t>Request minimum loss=FALSE</t>  
        	 	<t>Maximum Acceptable Delay Value=350 ms</t>    
        	 	<t>Maximum Acceptable Delay Variation Value=10 ns</t>                 
        	 	<t>Maximum Acceptable Loss Value=8%</t>
        	 </list>
           Component link 3 and 4 could be qualified. Which component link is selected depends on local policy.
          
           <vspace blankLines="1"/>
           
           <list style="symbols">    
						<t>Request minimum delay=FALSE</t>
						<t>Request minimum delay variation=TRUE</t>
						<t>Request minimum loss=FALSE</t>  
						<t>Maximum Acceptable Delay Value=350 ms</t>
						<t>Maximum Acceptable Delay Variation Value=10 ns</t>
						<t>Maximum Acceptable Loss Value=10%</t>
        	 </list>
					 Only Component link4 could be qualified.	            	 
          
           <vspace blankLines="1"/>
            
           <list style="symbols">    
						<t>Request minimum delay=TRUE</t>
						<t>Request minimum delay variation=FALSE</t>
						<t>Request minimum loss=FALSE</t>  
						<t>Maximum Acceptable Delay Value=350 ms</t>
						<t>Maximum Acceptable Delay Variation Value=10 ns</t>
						<t>Maximum Acceptable Loss Value=10%</t>
        	 </list>
					 Only Component link2 could be qualified.	 
					 
					 <list style="symbols">    
						<t>Request minimum delay=FALSE</t>
						<t>Request minimum delay variation=FALSE</t>
						<t>Request minimum loss=TRUE</t>
						<t>Maximum Acceptable Delay Value= 350 ms</t>
						<t>Maximum Acceptable Delay Variation Value=10 ns</t>
						<t>Maximum Acceptable Loss Value=10%</t>
        	 </list>
					 Only Component link4 could be qualified.	              
         
        	 <list>
						<t>Request minimum delay=TRUE</t>
						<t>Request minimum delay variation=TRUE</t>
						<t>Request minimum loss=TRUE</t>
						<t>Maximum Acceptable delay Value=350 ms</t>
						<t>Maximum Acceptable delay Variation Value=10 ns</t>
						<t>Maximum Acceptable Loss Value=10%</t>
					 </list>         
					 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.
				</t>            	 
			</section>
			<section title="Signaling Procedure">
				<t> 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.
           
           <vspace blankLines="1"/>
				    
				    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).
				</t>
			</section>
	</section>
		
		
		<section title="Security Considerations">
		<t>
		This document raises no new security issues.
		</t>
		</section>
		
		<!--7th-->
		
		<section title="IANA Considerations">
		<t>
		TBD
		</t>
		</section>
	</middle>
	

	<!--<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~~<B>-->
	<!--<                                                                                              >-->
	<!--<                                           BACK MATTER                                        >-->
	<!--<                                                                                              >-->
	<!--<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~<B>~~<B>-->
	
	
	<back>
    <references title="Normative References">
      &RFC2119;
      &RFC3209;
      &RFC3473;
      &RFC3477;
      &RFC3630;
      &RFC4203;
    </references>
    
	<references title="Informative References">
		<reference anchor="CL-REQ">
			<front>
				<title>
				Requirements for MPLS Over a Composite Link 
				</title>
				<author surname="C. Villamizar">
				<organization>Infinera Corporation</organization>
			    </author>		
			</front>
			<seriesInfo name="draft-ietf-rtgwg-cl-requirement-07" value=""/>
		</reference>
		
		<reference anchor="DELAY-LOSS-FRAMEWORK">
			<front>
				<title>
				Loss and Delay Traffic Engineering Framework for MPLS
				</title>
				<author surname="X.Fu, D. McDysan et al.">
			    </author>		
			</front>
			<seriesInfo name="draft-fuxh-mpls-delay-loss-te-framework-05" value=""/>
		</reference>
		
		<reference anchor="LOSS-DELAY-PS">
			<front>
				<title>
				Delay and Loss Traffic Engineering Problem Statement for MPLS
				</title>
				<author surname="X.Fu, D. McDysan et al.">
			    </author>		
			</front>
			<seriesInfo name="draft-fuxh-mpls-delay-loss-te-problem-statement-00" value=""/>
		</reference>		
		
		<reference anchor="ietf-mpls-loss-delay">
			<front>
				<title>
				Packet Loss and Delay Measurement for MPLS Networks
				</title>
				<author surname="D. Frost">
				<organization>Cisco Systems</organization>
			    </author>		
			</front>
			<seriesInfo name="RFC6374" value=""/>
		</reference>

    <reference anchor="OSPF-TE-EXPRESS-PATH">
			<front>
				<title>
				OSPF Traffic Engineering (TE) Metric Extensions
				</title>
				<author surname="S. Giacalone">
				<organization>Thomson Reuters</organization>
			    </author>	
			</front>
			<seriesInfo name="draft-ietf-ospf-te-metric-extensions-01" value=""/>
		</reference>

    <reference anchor="ISIS-TE-EXPRESS-PATH">
			<front>
				<title>
				IS-IS Traffic Engineering (TE) Metric Extensions
				</title>
			  <author surname="S. Previdi">
				<organization>Cisco Systems</organization>
			  </author>		
			</front>
			<seriesInfo name="draft-previdi-isis-te-metric-extensions-01" value=""/>
		</reference>					

		<reference anchor="EXPRESS-PATH">
			<front>
				<title>
				Performance-based Path Selection for Explicitly Routed LSPs
				</title>
				<author surname="A. Atlas">
				<organization>Juniper Networks</organization>
			    </author>		
			</front>
			<seriesInfo name="draft-atlas-mpls-te-express-path-01" value=""/>
		</reference>
		
	</references>
	</back>
</rfc>
