<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC4655 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.xml">
<!ENTITY RFC5886 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5886.xml">
<!ENTITY RFC5440 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5440.xml">
<!ENTITY RFC5541 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5541.xml">
<!ENTITY RFC5557 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5557.xml">


<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-gonzalezdedios-pce-reservation-state-01" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="PCEP Ext for Reserv of Resources in PCE">PCEP Extensions for Temporary Reservation of Computed Path Resources
               and Support for Limited Context State in PCE</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Oscar Gonzalez de Dios" initials="O" role="editor"
            surname="Gonzalez de Dios">
      <organization>Telefonica I+D</organization>

      <address>
        <postal>
          <street>Don Ramon de la Cruz</street>
          <city>Madrid</city>
          <region></region>
          <code>28006</code>
          <country>Spain</country>
        </postal>

        <phone>+34 913328832</phone>

        <email>ogondio@tid.es</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
 
 <author fullname="Ramon Casellas" initials="R" 
      surname="Casellas">
      <organization>CTTC</organization>
      <address>
        <postal>
          <street>Av. Carl Friedrich Gauss n7</street>
          <!-- Reorder these if your country does things differently -->
          <city>Castelldefels</city>
          <region>Barcelona</region>
          <code>08860</code>
          <country>Spain</country>
        </postal>
        <phone></phone>

        <email>ramon.casellas@cttc.es</email>
        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
	 <author fullname="Cyril Margaria" initials="C." 
      surname="Margaria" >
      <organization>Nokia Siemens Networks</organization>
      <address>
        <postal>
          <street>St Martin Strasse 76</street>
          <!-- Reorder these if your country does things differently -->
          <city>Munich</city>
          <region></region>
          <code>81541</code>
          <country>Germany</country>
        </postal>
        <phone>+49 89 5159 16934</phone>
        <email>cyril.margaria@nsn.com</email>
        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
	 <author fullname="Young Lee" initials="Y." 
      surname="Lee" >
      <organization>Huawei</organization>
      <address>
        <postal>
          <street> 1700 Alma Drive, Suite 100</street>
          <!-- Reorder these if your country does things differently -->
          <city>Plano</city>
          <region>TX</region>
          <code>75075</code>
          <country>U.S.</country>
        </postal>
        <phone>(972) 509-5599</phone>

        <email>leeyoung@huawei.com</email>
        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
	
	
	
	 <author fullname="Fatai Zhang" initials="F." 
      surname="Zhang" >
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>F3-5-B RD Center</street>
          <!-- Reorder these if your country does things differently -->
          <city>Bantian, Longgang District</city>
          <region>Shenzhen</region>
          <code>518129</code>
          <country> P.R.China</country>
        </postal>
        <phone></phone>

        <email>zhangfatai@huawei.com</email>
        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date month="March" year="2012" day="9"/>

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

	<area>Routing</area>
    <workgroup>Network Working Group</workgroup>
	<keyword>PCE</keyword>
	<keyword>state</keyword>
    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->
    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
		<t>The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.</t>
		<t>A limited form of statefulness is useful to improve PCE functionality in situations in which the local TED might not be up to date, or in the case of concurrent requests where most of the LSPs are computed before the end of the set-up of the LSPs, when the TED is updated. The PCC is responsible to setup or not the TE-Path computed by the PCE. By providing an indication that it intends to use the resources on the TE-Path a PCC can help the PCE to get a more accurate dynamic TED view and thus the PCE can avoid suggesting the use of the same resources for subsequent TE LSPs.</t>
		<t>This document proposes an extension to the PCEP protocol to allow the PCC to indicate to the PCE to block or reserve the resources computed in a path request of a TE LSP for subsequent requests for a certain time and can help to reduce the number of crankbacks.</t>
	</abstract>
  </front>

  <middle>
    <section title="Introduction">
		<t>According to <xref target="RFC4655"></xref>, a PCE can be either stateful or stateless. In the former case, there is a strict synchronization between the PCE, the network state (in terms of topology and per link aggregated resource information such as unreserved bandwidth), and also the set of computed paths, active Label Switched Paths (LSPs) and resources in use in the network.</t>
		<t>In other words, a stateful PCE utilizes information from the TED as well as information about existing paths (for example, TE LSPs) in the network when processing new requests.  However, the maintenance and synchronization of a stateful LSP database (LSP-DB) can be non-trivial, not only because it should verify the actual establishment of computed paths, and because it might not be the unique element to compute paths.</t>
		<t>In addition, it can be argued that maintaining such a stateful database is not a function of the PCE, but rather of a Network Management System (NMS).</t>
		<t>On the other hand, a stateless PCE does not typically keep track of computed paths, and each set of request(s) is processed independently of each other, typically using a local copy of the TED.  Since a stateless PCE typically operates on a graph with computation constraints and without tracking the current state of paths, independent requests will be processed on the same TED graph, until the graph is updated.</t>
		<t>With a stateless PCE, there is a &rsquo;potential window of TED inaccuracy&rsquo;, where a stateless PCE may compute paths based on current TED information, which could be out-of-sync with the actual or potential network state changes given other recent PCE-computed paths.</t>
		<t>For example, some sources for this potential TED inaccuracy are:<list style="symbols">
			<t>Control Plane link latencies may increase due to several factors such as: a) the time required for a PCC to obtain the paths after a successful computation, requiring several Round-Trip-Times (RTT) as per TCP; b) the setup delay and c) the time it takes for the PCE to update the local TED given IGP update times.</t>
			<t>The routing and topology dissemination protocol (i.e&middot;&nbsp;OSPF-TE) ), which may operate with timers for LSA updates, to avoid excessive control plane overhead.</t>
			<t>Concurrent requests that arrive during the time window, between a response is sent and the LSP is setup and the topology changes flooded. Even for very fast networks with low latency, there may be &rsquo;batched&rsquo; requests: several path computation requests within a PCReq message or, in dynamic restoration without pre-planning, several LSPs that need to be rerouted avoiding a failed link.</t>
			<t>Local PCE contention, where the PCE needs to concurrently serve path computation requests and update the LSA (e.g. parsing OSPF-TE LSA updates)&middot;&nbsp;A PCE implementation may need to find a trade-off, when synchronizing access to the local TED: favor OSPF-TE parsing which means that some path computations are slightly delayed to allow an &rsquo;update&rsquo; to be processed, or give strict priority to computation requests.</t>
		</list></t>		
		<t>In consequence, a stateless PCE may assign the same (or a subset of the same) resources to several requests, which may result in contention and degraded network performance. The effects are detected late, typically during path signaling, causing path blocking and excessive crank-backs and retries.</t>
		<t>Note that, as per <xref target="RFC5440">RFC&nbsp;5440</xref>, a PCC may include a set of previously computed paths in A given request, in order to take them into account, for instance, to avoid double bandwidth accounting or to try to minimize changes (minimum perturbation problem).</t>
		<t>Section 6.8 of <xref target="RFC4655">RFC&nbsp;4655</xref> suggests that a limited form of statefulness might be applied within an otherwise stateless PCE. The PCE may retain some context from paths it has recently computed so that it avoids suggesting the use of the same resources for other TE LSPs, using heuristics / statistic or forecasting for improved resource (i.e. wavelength) allocation. In other words, a given PCE implementation may decide to perform additional book-keeping and management of resources, deploying policies that prevent sub-optimal allocations. For instance a PCE may compute the mean time used to update the TED based on the previous calculated TE-LSPs and TED updates. Those kinds of mechanisms may reduce the TED inaccuracy but in all cases they cannot infer the PCC use of the TE-path.</t>
		<t>This document proposes a set of extensions to the PCEP protocol to allow a PCC to request a PCE to block or reserve the resources associated with a path computation for a given path request. By reservation, it is implied that a set of resources which have been associated to such computation are excluded for subsequent path computations for a given time period. This time-based temporary reservation PCE system would be a compromise between a full-blown stateful PCE and a stateless PCE to achieve efficiency without costing and excessive resource commitment associated with the maintenance and synchronization of a stateful PCE system. Due to the fact that the PCC is explicitly indicating this reservation, the PCE can get a more accurate view of the dynamic of the TED and thus increase the accuracy of its routing. In addition having an explicit input may simplify how a PCE take into account the fact that the TED may be outdated.</t>
		<t>In the cases where the resource is uniquely identified in the topology update (such as receiving an OSPF-TE TE LSA with a bitmap encoded wavelength availability reflecting a change in the link status)), the reservation can still hold after a topology update, as there is a correspondence between the resource in both reservation and traffic engineering update, and the PCE can infer whether a given reserved resource has actually been committed.  Otherwise, when the traffic engineering update reaches the PCE, there is no way to distinguish the resource in the
   reservation among the resources shown in the TE update. Thus, to assure a coherent behavior, the general rule is that as soon as the PCE gets updated traffic engineering information, all the reservations are deleted, save the the cases where the resource is uniquely identified and the PCE can infer whether a given reserved resource has actually been committed.</t>
		<t>Examples of resources potentially subject to reservations are: the bandwidth computed for the path in PSC or L2SC layers, a specific time slot (SDH) or tributary slot (OTN ODU-k) in TDM networks or a given wavelength or regenerator (WSON or OTN OCh).</t>
		<t>This document also presents some illustrative use cases where the PCC would want the PCE to retain some context or state, like multiple LSP restoration, and counterexamples where the PCC does not have the intention to immediately set up the LSP, i.e., multidomain cases where the PCE is probing different paths to decide the sequence of domains.</t>
	
	</section>
	
	
    <section title="PCEP Requirements">
		<t>This section provides a set of requirements, both for PCCs and PCEs, to support context awareness.</t>
		<t>When requesting a path computation (PCReq) to a PCE, a PCC should be able to indicate:<list style="symbols">
			<t>Whether the resources computed in the request should be made unavailable for further requests.</t>
			<t>The amount of time the resources should be commited/reserved for the current computation request so that keeps subsequent requests from taking.</t>
			<t>The type and granularity of the resources to be blocked in the request. The type refers to the actual resources blocked such as path bandwidth or timeslot, wavelength, fiber&middot;&middot;&middot; The granularity refers to the possibility of not only reserving the resource computed for the path but whether the associated links/nodes/SRLGs may need to be reserved too.</t>
		</list></t>		
		<t>A PCE should be able to:<list style="symbols">
			<t>Apply policies whether a reservation request can be applied or not.</t> 
			<t>Compute one or more paths according to the request parameters and, based on the PCC indications, prevent (part of) the resources commited in the computed route from being used for subsequent computation requests for a given period.</t> 
			<t>If the request is allowed, the given reservation period SHOULD be no less than the requested period by the PCC (e.g. for the cases where the PCE is only able to reserve for multiples of a given value). This does not preclude the fact that, if configured by policy, a PCE MAY limit the period to a lower period. Alternatively, a PCE MAY be configured to reply with a PCEP_ERROR stating the cause of the failed computation/reservation.</t> 
			<t>The PCE MAY decide to apply a different granularity for the reservation request (e.g. block a given Time Slot or wavelength but not the TE links). In this case, the PCE MUST reply with the actual reservation.</t> 
		</list></t>		
		<t>Note that, the means by which a PCE can perform the reservation/commitment of the resources are out of the scope of the present document but could include, for example, marking the resources as &rsquo;reserved&rsquo;, applying internal exclude objects etc.</t> 
		<t> A PCE should be able to respond (PCRep) to the PCC the following:<list style="symbols">
			<t>If the resources have been effectively locked, and the effective allocated reservation period (if different from the requested one).</t>
			<t>The granularity of the reservation, which may be different from the requested one.</t>
			<t>Provide a means to allow a PCC to request the cancellation of an active reservation (for example an identification of the reservation to allow its cancellation).</t> 
		</list></t>		
		<t>The PCC should be able to request the cancellation of an active resource reservation.</t>
	</section>

<section title="PCEP Extensions (Encoding)">
	<section title="Requesting a Reservation of Resources">
		<t>EDITORS NOTE: OPTION WITH PCC-ID-REQ</t>
		<t>A PCC that wants to indicate a PCE to temporarily reserve or block resources does so by including a RESERVATION object along with a client PCC_ID_REQ in a request within a PCReq message.</t> 
		<t>Analogously to <xref target="RFC5886"></xref> the PCC-ID-REQ object is used to specify the IP address of the requesting PCC. The PCC-ID-REQ MUST be inserted within a PCReq message to specify the IP address of the requesting PCC. In [RFC5886] two PCC-ID-REQ objects (for IPv4 and IPv6) are defined.</t> 
		<t>EDITORS NOTE: OPTION WITHOUT PCC-ID-REQ</t>
		<t>A PCC that wants to indicate a PCE to temporarily reserve or block resources does so by including a RESERVATION object in a request within a PCReq message.</t> 
		<t>A PCE that processes a PCEP request with a RESERVATION object MUST act according to the P-bit in the object header:  if the P-bit is set, the object MUST be treated as mandatory and the request must either be processed using the contents of the object or rejected as defined in [RFC5440]. If the P-bit is clear, the object MAY be used by the PCE or MAY be ignored.</t>
		<t>The RESERVATION object is optional in a PCEP request.  Multiple instances of the object MUST NOT be used on a single PCEP request and if a PCE finds multiple instances of the object it MUST use the first one and discard the rest (Editors note: alternatively, it could send a PCErr, OR it could allow several RESERVATION objects, and let the PCE choose which one will be used).  The RESERVATION object may appear either at an individual request level or within a SVEC. The latter means that the RESERVATION object applies to all requests involved in the SVEC object.</t>
		<t>The PCReq (<xref target="RFC5440"></xref><xref target="RFC5541"></xref><xref target="RFC5557"></xref>) message is</t>
		 <figure>
          <artwork><![CDATA[ 
          <PCReq Message> ::= <Common Header>

                            [svec_list]

                            <request-list>]]></artwork> 
		  </figure>
		  <t>where</t>
		 <figure>
          <artwork><![CDATA[ 
            <svec-list> ::= <SVEC>

                            [<OF>]

                            [<GC>]

                            [<XRO>]

                            [<metric-list>]

                           [<PCC-REQ-ID> <RESERVATION>]

                            [<svec-list>]

            <metric-list> ::= <METRIC>

                             [<metric-list>]

            <request-list>::= <request>

                              [<request-list>]

            <request>::= <RP>

                         <END-POINTS>

                         [<LSPA>]

                         [<BANDWIDTH>]

                         [<metric-list>]

                         [<OF>]

                         [<PCC_REQ_ID> <RESERVATION>]

                         [<RRO> [<BANDWIDTH>]]

                         [<IRO>]

                         [<LOAD-BALANCING>]]]></artwork> 
		  </figure>		  
	</section>
	<section title="Replying a reservation status">
		<t>If the PCE that receives the request applies the reservation, it indicates so using a RESERVATION_CONF object in the PCRep message.</t>
		<t>EDITOR'S NOTE: Alternatively a RESERVATION object can be used in the PCReq message</t>
		<t>The PCRep message is extended with regard to the one defined in <xref target="RFC5440"></xref> as follows:</t>
				 <figure>
          <artwork><![CDATA[ 

<attribute-list>::=[<LSPA>]

                          [<BANDWIDTH>]

                          [<metric-list>]

                          [<IRO>]

                          [<RESERVATION_CONF>]		  
		  ]]></artwork> 
		  </figure>		  
		<t>Note that the reservation applies at PATH level, and a RESERVATION_CONF object is included within every  path in a given PCEP response. This means distinct reservations for each path, which can be cancelled independently (Editor&apos;s Note: TDB, the PCC could indicate whether to have a single reservation or multiple reservation).</t>
		<t>It is RECOMMENDED that the RESERVATION_CONF object appears the last attribute for a Path (or as an optional object in the attribute&dash;list associated to a NO_PATH object.</t>
	</section>
	<section title="Cancelling a Reservation">
		<t>A PCC that wishes to cancel a reservation may send an unsolicited notification to the PCE, including the identifier of the reservation.</t>
		<t>The PCNtf message used for one or more cancellations has no RP object. As with <xref target="RFC5440"></xref>, the PCNtf message MUST carry at least one NOTIFICATION object and MAY contain several NOTIFICATION objects should the PCE or the PCC intend to notify of multiple events:</t>
				 <figure>
          <artwork><![CDATA[ 
		  
<PCNtf Message>::=<Common Header>

                     <notify-list>

      <notify-list>::=<notify> [<notify-list>]

      <notify>::= <notification-list>

      <notification-list>::=<NOTIFICATION>[<notification-list>]]]></artwork> 
		  </figure>		
		<t>NOTIFICATION objects used for the purposes of cancelling an active reservation MUST include the RESERVATION_ID TLV. It is RECOMMENDED to use dedicated PCNtf messages for the purposes of cancelling reservations.</t>
		<t>Both the Notification-type and Notification-value are TBD by IANA</t>
		<t>The following Notification-type and Notification-value values are currently defined:</t>
		<t><list style="symbols">
		<t>Notification-type=TBD: Pending Reservation cancelled</t>
		<t>Notification-value=TBD (sug 1): PCC cancels a set of reservation requests.</t>
		</list></t>
	</section>
	<section title="RESERVATION object format">
		<t>RESERVATION Object-Class is to be assigned by IANA.</t>
		<t>RESERVATION Object-Type is to be assigned by IANA (recommended value=1)</t>
		<t>The RESERVATION object indicates the intention of the PCC to set up the requested path and request the PCE to reserve the resources of the computed path to avoid being used by other requests.</t> 		  
				 <figure>
          <artwork><![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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Timer                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |S N L|                  Resource Type                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Optional TLVs                           |
     ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> 
		  </figure>		
		  <t><list style="symbols">
			<t>Timer is the value in ms of the time that the resources should be blocked, encoded as a 32 bit unsigned integer.</t> 
			<t>Resource Type indicates the type of resource to be reserved. A value of 0 means the default resource type:<list style="symbols">
				<t>Bandwidth (PSC, L2SC, ...)</t>
				<t>Time Slot (Sonet/SDH TDM)</t>
				<t>Tributary Slot (G709 OTN ODU-k TDM)</t>
				<t>Wavelength (G709 OTN OCh or WSON LSC)</t>
			</list></t>
			<t>Bit L: if set, TE Links should be part of the reservation, and excluded from subsequent request.</t>
			<t>Bit N: if set, Nodes should be part of the reservation.</t>
			<t>Bit S: if set, the set of SRLG (Shared Risk Link Group) deduced from the associated resources (i.e., the union of SRLGs of the links) should be part of the reservation.</t>
		</list></t>	
		<t>Currently no TLVs are defined.</t>
	</section>		
	<section title="RESERVATION_CONF object format">
		<t>The RESERVATION_CONF object is optional. The RESERVATION_CONF object indicates that the PCE has reserved the resources of computed path to avoid being used by other requests. The RESERVATION_CONF object is sent in the PCRep.</t>
		<t>The RESERVATION_CONF Object-Class is to be assigned by IANA.</t>
		<t>The RESERVATION_CONF Object-Type is to be assigned by IANA (recommended value=1)</t>
		<t>The format of the RESERVATION_CONF object body is:</t>
			 <figure>
			 <artwork><![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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Reservation ID                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Reservation timer                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |S N L|             Reservation Type                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> 
		  </figure>	
		<t>Timer is the value in ms of the time that the resources are blocked. The PCE May decide to apply a different value that the one requested by the PCC. </t>
		<t>A PCC MUST NOT send a RESERVE_RESPONSE object if the client has not requested a RESERVATION in the PCReq message. A PCE MAY apply reservations as a means of internal policy and/or operation.</t>
	</section>		
	<section title="RESERVATION_ID TLV">
		<t>The TLV indicates the reservation ID (Type TBA by IANA).</t>  
 <figure>
			 <artwork><![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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Reservation ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		  
		  ]]></artwork> 
		  </figure>		
		</section>
</section>


<section title="Procedures">
	<t>A client that wishes to request a path computation with reservation shall:<list style="symbols">
		<t>Include a PCC_REQ_ID and RESERVATION objects in the involved Request within the PCReq message.</t>
		<t>Specify what level of reservation to apply after the request.</t>
	</list></t>
	<t> Upon receiving a PCReq with a Resource Reservation object, the PCE may:<list style="symbols">
		<t>Perform the Path Computation using the local Traffic Engineering Database which has been extended to account for resources that have been marked reserved or blocked and which SHOULD not be used while blocked. This includes both synchronized / dependent path computations via SVEC or individual Path Computations requested in the request_list.</t>
		<t>For the successful path computations, and for all paths corresponding to a given Request, determine the type of resources to be blocked (marked as reserved) with the granularity requested by the client once mapped to PCE policies.</t>
		<t>It will start a local timer associated with this blocking action.</t>
		<t>Send the Responses (successful or not) using PCRep message(s) and, where appropriate, indicate the level of reservation and associated period.</t>
		<t>For subsequent requests, perform path computation as detailed above, updating the local TED with potential new reservations.</t>
	</list></t>
		<t>Whenever a timer expires, the PCE will:<list style="symbols">
			<t>Remove the reservation status / blocking that affected the reservation (e.g. add the previously substracted unreserved bandwidth, mark the label, wavelength or time slot as available, etc).</t>
			<t>Delete any data related with this blocking action.</t>
		</list></t>
		<t>Whenever a traffic engineering update reaches the PCE, the PCE will:<list style="symbols">
			<t>If the reserved resource can be uniquely identified in the traffic engineering update, keep the reservation</t>
			<t>If the reserved resource cannot be uniquely identified in the traffic engineering update, delete the reservation</t>
		</list></t>
</section>

<section title="Use cases">
	<t>This section aims to show the use cases of the proposed possibility to activate the limited context awareness.</t>
	<section title="Multiple LSP restoration in a WSON network">
		<t>One of the most challenging scenarios for a PCE-based architecture is the one of PCE-based dynamic multiple LSP restoration in a WSON network without pre-planning. In the event of a network failure affecting a high number of LSPs (e.g. a fiber cut), a PCE could potentially receive a significant amount of restoration requests in a short period of time from different PCCs.</t>
		<t>One of the various challenges in this scenario is the fact that the PCE needs to sequentially perform multiple independent path computations including routing and wavelength assignment. In this scenario, a stateless PCE would rely on TED information, which could potentially be up-to-date before the first incoming request (e.g. in case the routing algorithm has disseminated the failure event), but will definitely be outdated for subsequent requests.</t>
		<t>It might be expected that the paths calculated for different connections would rely on the same nodes, TE links or even labels (lambdas). It might occur at the signaling phase that multiple connection requests are contending for the same resources. After the eventual failure in the establishment of some of the connections, subsequent requests to the PCE would be triggered. After a number of loops, the PCE-based restoration would be eventually solved, but the potential number of retries could be significantly high.</t>
		<t>The main issue is that the stateless PCE relied on an outdated TED to perform path computation. As the subsequent connection request is expected to be computed immediately, there is either no time for the routing algorithm to update the TED after a successful signaling or for the signaling process to successfully finish.</t>
		<t>In this context, the availability of a limited context aware PCE could potentially solve the issue in a graceful fashion. Each of the restoration path requests will have an associated Resource Reservation object, which will state the kind of resources and the amount of time they should be blocked.</t>
		<t>The PCE will then temporarily &rsquo;mark&rsquo; the resources as blocked, so as not to consider them in subsequent connection requests, and thus avoiding the contention at the signaling phase. The timer should be in line with the LSP set up time and TED time to update.</t>
		<t>This use case might be solved in the PCE by having a policy to implicitly pre-reserve the resources for a given time, which can be based on the mean time between a PCRep and a TED update indicating that the labels are not available. The drawback of this implicit reservation is that path establishment time may depend and a variety of factor that may be strongly depend on the chosen path and technology used (e.g. power equalization algorithms). In this case the PCC have a better view on those aspects and can provide more accurate view on when the TED will be updated.</t>
	</section>
	<section title="Domain path selection">
		<t>When selecting the set of domains of a multidomain path, a PCE may request paths to several PCEs of different domains. Thus, the intention of the request is not to establish a LSP, but to obtain a hint on the domain path. Thus, in this case, no Reservation Object would be sent.</t>
		<t>Here implicit policies in PCE will be inaccurate as they cannot determine if the PCC will setup the path or not.</t>
	</section>
	<section title="Multidomain path computation">
		<t>Once the domain path is known, when computing the actual path, the reservation object can be used. Note that multidomain paths may take a long time to be established, as it involves several AS or domains with different behavior and policies. Thus, it is a way to guarantee the availability of resources.</t>
	</section>
</section>

<section title="Manageability Considerations">
	<t>Standard PCEP <xref target="RFC5440"></xref> describes various manageability considerations in PCEP, and most of the manageability requirements are already covered there. Specific aspects are detailed in this section.</t>
	<section title="Control of Function and Policy">
		<t>In addition to PCE configuration parameters listed in [RFC5440], the following additional parameters might be required:<list style="symbols">
			<t>The ability to enable or disable reservations on the PCE.</t>
			<t>The ability to retrieve a list of reservations currently active in the PCE.</t>
			<t>The ability to configure which PCCs are allowed to perform reservations and the ability to configure limits on the timer periods requested. This includes, for example, the configuration of IP based access lists for PCCs.</t>
			<t>The ability to configure which PCCs are allowed to perform reservations for single-domain and multi-domain scenarios, typically according to pre-defined agreements.</t>
			<t>The ability to configure which reservation granularity a given PCC group is able to request, and the associated action (error or downgrade).</t>
			<t>TDB: Advertisements of capabilities via IGP and configurability</t>
		</list></t>
	</section>
	<section title="Information and Data Models">
		<t>A number of MIB objects have been defined for general PCEP control and monitoring of P2P computations in [PCEP-MIB]. For the time being, no extra models are considered although it could be possible that current means to retrieve information from the PCE be extended to include eventual resource reservations.</t>
	</section>
	<section title="Liveness Detection and Monitoring">
		<t>Other than the considerations expressed in <xref target="RFC5440"></xref>, a PCE could provide extensions to [MONITORING] to verify reservation status, and to obtain statistics on the system.</t>
	</section>
	<section title="Verifying Correct Operation">
		<t>There are no additional requirements for verifying the correct operation of the PCEP sessions. Future MIB objects could facilitate verification of correct operation and reporting of reservations and errors.</t>
	</section>
	<section title="Requirements for Other Protocols and Functional Components">
		<t>The method for the PCC to obtain information about a PCE capable of reservation may include extensions to IGP protocols.</t>
	</section>
	<section title="Impact on Network Operation">
		<t>It is expected that the use of PCEP extensions specified in this document will not significantly increase the level of operational traffic. However, mis-configured, excessive reservation requests, excessive reservation periods, or excessive granularity may increase the number of failed requests or cause the PCE to provide sub-optimal routes due to existing reservations. Coarse reservations may also limit the resources that are available for a a PCE in order to serve requests.</t>
		<t>An excessive number of reservation requests and reservation cancellations may degrade server performance. A PCE SHOULD provide a means to control the rate of messages with reservation, extending the proposed mechanism of <xref target="RFC5440"></xref>.</t>
	</section>
</section>

<section title="Security Considerations">
	<t>In the event of an unauthorized path computation request with mandatory resource reservation, or in case of a (distributed) denial of service attack, the subsequent state/context managed within the PCE may be disruptive to the network, resulting in performance degradation or sub-optimal computed routes.  Implementations should conform to the relevant security requirements of <xref target="RFC5440"></xref> that specifically help to control unauthorized requests. These mechanisms include securing the PCEP session requests and responses using TCP security techniques, authenticating the PCEP requests and responses to ensure the message is intact and sent from an authorized node, providing policy control by explicitly defining which PCCs are allowed to perform resource reservations to the PCE and disallowing reservation requests that may block an excessive amount of resources.</t>
</section>

<section title="IANA Considerations">
	<t>IANA maintains a registry of PCEP parameters.  A number of IANA considerations have been highlighted in previous sections of this document.</t>
	<section title="RESERVATION object"> 
	</section>
	<section title="RESERVATION_CONF object">
	</section>
	<section title="RESERVATION_ID TLV">
	</section>
	<section title="PCEP Errors">
	<t>For the RESERVATION object, the default error procedures regarding supported unknown objects defined in <xref target="RFC5440"></xref> apply<list style="symbols">
		<t>Unsupported Reservation Option</t> 
		<t>Reservation Forbidden by Policy</t>
		<t>Unknown Reservation Request</t>
	</list></t>
	</section>
</section>
<section title="Contributing Authors">
<t>Telefonica I+D</t>
<t>Victor Lopez</t>
<t>Don Ramon de la Cruz</t>
<t>email: vlopez@tid.es</t>
<t>Francisco Javier Jiménez Chico</t>
</section>
 <section title="Acknowledgements">
      <t>The authors thank Meral Sherazipur for the discussions and suggestions in the topic.</t>
    </section>
</middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
	 &RFC4655;
	 
	 &RFC5886;
	 
	 &RFC5440;
	 
	 &RFC5541;
	 
	 &RFC5557;
	</references>
     

  </back>
</rfc>
