Network Working Group O. Gonzalez de Dios, Ed.
Internet-Draft Telefonica Investigacion y
Intended status: Standards Track Desarrollo
Expires: April 18, 2011 R. Casellas
CTTC - Centre Tecnologic de
Telecomunicacions de Catalunya
F. Jimenez Chico
Telefonica Investigacion y
Desarrollo
October 15, 2010
PCEP Extensions for Temporary Reservation of Computed Path Resources and
Support for Limited Context State in PCE
draft-gonzalezdedios-pce-reservation-state-00
Abstract
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.
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 PCE can retain some context from the resources assigned to Path
Requests during a certain period of time, so that it avoids
suggesting the use of the same resources for subsequent TE LSPs.
This document proposes an extension to the PCEP protocol to allow the
PCC to request the PCE to block or reserve the resources computed in
a path request of a TE LSP for subsequent requests for a certain
time.
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
Gonzalez de Dios, et al. Expires April 18, 2011 [Page 1]
Internet-Draft PCEP Ext for Reserv of Resources in PCE October 2010
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2011.
Copyright Notice
Copyright (c) 2010 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.
Gonzalez de Dios, et al. Expires April 18, 2011 [Page 2]
Internet-Draft PCEP Ext for Reserv of Resources in PCE October 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 6
3. PCEP Extensions (Encoding) . . . . . . . . . . . . . . . . . . 7
3.1. Requesting a Reservation of Resources . . . . . . . . . . 7
3.2. Replying a reservation status . . . . . . . . . . . . . . 9
3.3. Cancelling a Reservation . . . . . . . . . . . . . . . . . 9
3.4. RESERVATION object format . . . . . . . . . . . . . . . . 10
3.5. RESERVATION_CONF object format . . . . . . . . . . . . . . 11
3.6. RESERVATION_ID TLV . . . . . . . . . . . . . . . . . . . . 12
4. Protocol procedures . . . . . . . . . . . . . . . . . . . . . 12
5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Multiple LSP restoration . . . . . . . . . . . . . . . . . 13
5.2. Domain path selection . . . . . . . . . . . . . . . . . . 14
5.3. Multidomain path computation . . . . . . . . . . . . . . . 14
6. Manageability Considerations . . . . . . . . . . . . . . . . . 14
6.1. Control of Function and Policy . . . . . . . . . . . . . . 14
6.2. Information and Data Models . . . . . . . . . . . . . . . 15
6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 15
6.4. Verifying Correct Operation . . . . . . . . . . . . . . . 15
6.5. Requirements for Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 15
6.6. Impact on Network Operation . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. RESERVATION object . . . . . . . . . . . . . . . . . . . . 16
8.2. RESERVATION_CONF object . . . . . . . . . . . . . . . . . 16
8.3. RESERVATION_ID TLV . . . . . . . . . . . . . . . . . . . . 16
8.4. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
10. Normative References . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Gonzalez de Dios, et al. Expires April 18, 2011 [Page 3]
Internet-Draft PCEP Ext for Reserv of Resources in PCE October 2010
1. Introduction
According to [RFC4655], a PCE can be either stateful or stateless.
In the former case, there is a strict synchronization between the PCE
and not only the network states (in term of topology and resource
information), but also the set of computed paths and reserved
resources in use in the network.
In other words, the 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 database can be non-trivial, not only
because it should verify the actual establishment of the computed
paths, but also because it might not be the unique element to compute
paths. Moreover, maintaining such a stateful database is not a
function of the PCE, but rather of an NMS.
On the other hand, a stateless PCE does not keep track of any
computed path, 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 without tracking the state or history of path
computations, independent requests will be processed on the same TED
graph, until the graph is updated.
With a stateless PCE, there is a 'potential window of TED
inaccuracy', where a stateless PCEs may compute paths based on
current TED information, which could be out of sync with actual or
potential network state changes given other recent PCE-computed
paths.
For example, some sources for this potential TED inaccuracy are:
o Control Plane link latencies, increasing: 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.
o IGP (i.e. OSPF-TE) may operate with timers for LSA updates, to
avoid excessive control plane overhead.
o 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 'batched' requests: several path computation requests within a
PCReq message or, in dynamic restoration without pre-planning,
several LSPs need to be rerouted avoiding a failed link.
Gonzalez de Dios, et al. Expires April 18, 2011 [Page 4]
Internet-Draft PCEP Ext for Reserv of Resources in PCE October 2010
o Local PCE contention, where the PCE needs to concurrently serve
path computation requests and update the LSA (e.g. parsing OSPF-TE
LSA updates). 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 'update' to be processed, or give strict priority to
computation requests.
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.
Note that a PCC may include a set of previously computed paths in its
request, in order to take them into account, for instance, to avoid
double bandwidth accounting or to try to minimize changes (minimum
perturbation problem).
Section 6.8 of RFC 4655 [RFC4655] 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 / forecasting for improved resource (i.e.
wavelength) allocation.
This document proposes a set of extensions to the PCEP protocol to
allow the PCC to request the PCE to block or reserve the resources
associated to 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.
Associated resources include (but not limit to): 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).
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.
Gonzalez de Dios, et al. Expires April 18, 2011 [Page 5]
Internet-Draft PCEP Ext for Reserv of Resources in PCE October 2010
2. PCEP Requirements
This section provides the set of requirements, both for PCCs and
PCEs, to support context awareness.
When requesting a path computation (PCReq) to a PCE, the PCC should
be able to indicate:
o Whether the resources computed in the request should be blocked
for further requests.
o The amount of time the resources should be blocked, i.e. not used
for subsequent requests.
o 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... 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.
The PCE should be able to:
o Apply policies whether a reservation request can be applied or
not.
o Compute one or more paths according to the request parameters and,
based on the PCC indications, prevent that (part of) the resources
involved in the computed route be used in subsequent computations
for a given period.
o 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.
o 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.
Note that, the means by which a PCE can perform this are out of the
scope of the present document but could include, for example, marking
the resources as 'reserved', applying internal exclude objects etc.
Gonzalez de Dios, et al. Expires April 18, 2011 [Page 6]
Internet-Draft PCEP Ext for Reserv of Resources in PCE October 2010
The PCE should be able to respond (PCRep) to the PCC the following:
o If the resources have been effectively blocked, and the final
allocated reservation period, which may be different from the
requested one.
o The granularity of the reservation, which may be different from
the requested one.
o 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).
The PCC should be able to request the cancellation of an active
resource reservation.
3. PCEP Extensions (Encoding)
3.1. Requesting a Reservation of Resources
A PCC that wants to request a PCE to temporarily reserve or block
resources does so by including a RESERVATION object along with a
client PCC_ID_REQ in the PCReq message.
Analogously to [RFC5886] 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.
A PCE that receives a PCReq message 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.
The RESERVATION object is optional in a PCReq message. Multiple
instances of the object MUST NOT be used on a single PCReq message
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). 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.
The PCReq ([RFC5440][RFC5541][RFC5557]) message is
Gonzalez de Dios, et al. Expires April 18, 2011 [Page 7]
Internet-Draft PCEP Ext for Reserv of Resources in PCE October 2010
<PCReq Message> ::= <Common Header>
[svec_list]
<request-list>
where
<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>]
Gonzalez de Dios, et al. Expires April 18, 2011 [Page 8]
Internet-Draft PCEP Ext for Reserv of Resources in PCE October 2010
[<LOAD-BALANCING>]
3.2. Replying a reservation status
If the PCE that receives the request applies the reservation, it
indicates so using a RESERVATION_CONF object in the PCRep message.
The PCRep message is extended with regard to the one defined in
[RFC5440] as follows:
<attribute-list>::=[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
[<RESERVATION_CONF>]
Note that the reservation applies at PATH level, and a
RESERVATION_CONF object is included for all paths in a given
response. This means distinct reservations for each path, which can
be cancelled independently (Editor's Note: TDB, the PCC could
indicate whether to have a single reservation or multiple
reservation).
It is RECOMMENDED that the RESERVATION_CONF object appears the last
attribute for a Path (or as an optional object in the attribute-list
associated to a NO_PATH object.
3.3. Cancelling a Reservation
A PCC that wishes to cancel a reservation may send an unsolicited
notification to the PCE, including the identifier of the reservation.
The PCNtf message used for one or more cancellations has no RP
object. As with [RFC5440], 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:
Gonzalez de Dios, et al. Expires April 18, 2011 [Page 9]
Internet-Draft PCEP Ext for Reserv of Resources in PCE October 2010
<PCNtf Message>::=<Common Header>
<notify-list>
<notify-list>::=<notify> [<notify-list>]
<notify>::= <notification-list>
<notification-list>::=<NOTIFICATION>[<notification-list>]
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.
Both the Notification-type and Notification-value are TBD by IANA
The following Notification-type and Notification-value values are
currently defined:
o Notification-type=TBD: Pending Reservation cancelled
o Notification-value=TBD (sug 1): PCC cancels a set of reservation
requests.
3.4. RESERVATION object format
RESERVATION Object-Class is to be assigned by IANA.
RESERVATION Object-Type is to be assigned by IANA (recommended
value=1)
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.
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 |
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Gonzalez de Dios, et al. Expires April 18, 2011 [Page 10]
Internet-Draft PCEP Ext for Reserv of Resources in PCE October 2010
o Timer is the value in ms of the time that the resources should be
blocked, encoded as a 32 bit unsigned integer.
o Resource Type indicates the type of resource to be reserved. A
value of 0 means the default resource type:
* Bandwidth (PSC, L2SC, ...)
* Time Slot (Sonet/SDH TDM)
* Tributary Slot (G709 OTN ODU-k TDM)
* Wavelength (G709 OTN OCh or WSON LSC)
o Bit L: if set, TE Links should be part of the reservation, and
excluded from subsequent request.
o Bit N: if set, Nodes should be part of the reservation.
o 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.
Currently no TLVs are defined.
3.5. RESERVATION_CONF object format
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.
The RESERVATION_CONF Object-Class is to be assigned by IANA.
The RESERVATION_CONF Object-Type is to be assigned by IANA
(recommended value=1)
The format of the RESERVATION_CONF object body is:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Gonzalez de Dios, et al. Expires April 18, 2011 [Page 11]
Internet-Draft PCEP Ext for Reserv of Resources in PCE October 2010
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.
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.
3.6. RESERVATION_ID TLV
The TLV indicates the reservation ID (Type TBA by IANA).
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. Protocol procedures
A client that wishes to request a path computation with reservation
shall:
o Include a PCC_REQ_ID and RESERVATION objects in the involved
Request within the PCReq message.
o Specify what level of reservation to apply after the request.
Upon receiving a PCReq with a Resource Reservation object, the PCE
will:
o 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.
o 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.
o It will start a local timer associated with this blocking action.
Gonzalez de Dios, et al. Expires April 18, 2011 [Page 12]
Internet-Draft PCEP Ext for Reserv of Resources in PCE October 2010
o Send the Responses (successful or not) using PCRep message(s) and,
where appropriate, indicate the level of reservation and
associated period.
o For subsequent requests, perform path computation as detailed
above, updating the local TED with potential new reservations.
Whenever a timer expires, the PCE will:
o 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).
o Delete any data related with this blocking action.
5. Use cases
This section aims to show the use cases of the proposed possibility
to activate the limited context awareness.
5.1. Multiple LSP restoration
One of the most challenging scenarios for a PCE-based architecture is
the one of PCE-based dynamic multiple LSP restoration without pre-
planning. In the event of a network failure affecting a high number
of LSPs (e.g. a fibre cut), a PCE could potentially receive a
significant amount of restoration requests in a short period of time
from different PCCs.
One of the various challenges in this scenario is the fact that the
PCE needs to sequentially perform multiple independent path
computations. 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.
It might be expected that the paths calculated for different
connections would rely on the same nodes, TE links or even labels.
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.
Gonzalez de Dios, et al. Expires April 18, 2011 [Page 13]
Internet-Draft PCEP Ext for Reserv of Resources in PCE October 2010
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.
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.
The PCE will then temporarily 'mark' 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.
5.2. Domain path selection
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.
5.3. Multidomain path computation
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.
6. Manageability Considerations
Standard PCEP [RFC5440] describes various manageability
considerations in PCEP, and most of the manageability requirements
are already covered there. Specific aspects are detailed in this
section.
6.1. Control of Function and Policy
In addition to PCE configuration parameters listed in [RFC5440], the
following additional parameters might be required:
o The ability to enable or disable reservations on the PCE.
Gonzalez de Dios, et al. Expires April 18, 2011 [Page 14]
Internet-Draft PCEP Ext for Reserv of Resources in PCE October 2010
o The ability to retrieve a list of reservations currently active in
the PCE.
o 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.
o The ability to configure which PCCs are allowed to perform
reservations for single-domain and multi-domain scenarios,
typically according to pre-defined agreements.
o The ability to configure which reservation granularity a given PCC
group is able to request, and the associated action (error or
downgrade).
o TDB: Advertisements of capabilities via IGP and configurability
6.2. Information and Data Models
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.
6.3. Liveness Detection and Monitoring
Other than the considerations expressed in [RFC5440], a PCE could
provide extensions to [MONITORING] to verify reservation status, and
to obtain statistics on the system.
6.4. Verifying Correct Operation
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.
6.5. Requirements for Other Protocols and Functional Components
The method for the PCC to obtain information about a PCE capable of
reservation may include extensions to IGP protocols.
6.6. Impact on Network Operation
It is expected that the use of PCEP extensions specified in this
document will not significantly increase the level of operational
Gonzalez de Dios, et al. Expires April 18, 2011 [Page 15]
Internet-Draft PCEP Ext for Reserv of Resources in PCE October 2010
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.
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 [RFC5440].
7. Security Considerations
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 [RFC5440] 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.
8. IANA Considerations
IANA maintains a registry of PCEP parameters. A number of IANA
considerations have been highlighted in previous sections of this
document.
8.1. RESERVATION object
8.2. RESERVATION_CONF object
8.3. RESERVATION_ID TLV
8.4. PCEP Errors
For the RESERVATION object, the default error procedures regarding
supported unknown objects defined in [RFC5440] apply
Gonzalez de Dios, et al. Expires April 18, 2011 [Page 16]
Internet-Draft PCEP Ext for Reserv of Resources in PCE October 2010
o Unsupported Reservation Option
o Reservation Forbidden by Policy
o Unknown Reservation Request
9. Acknowledgements
The authors thank Cyril Margaria for the discussions and suggestions
in the topic.
10. Normative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541, June 2009.
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
Computation Element Communication Protocol (PCEP)
Requirements and Protocol Extensions in Support of Global
Concurrent Optimization", RFC 5557, July 2009.
[RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of
Monitoring Tools for Path Computation Element (PCE)-Based
Architecture", RFC 5886, June 2010.
Authors' Addresses
Oscar Gonzalez de Dios (editor)
Telefonica Investigacion y Desarrollo
Emilio Vargas 6
Madrid, 28045
Spain
Phone: +34 913374013
Email: ogondio@tid.es
Gonzalez de Dios, et al. Expires April 18, 2011 [Page 17]
Internet-Draft PCEP Ext for Reserv of Resources in PCE October 2010
Ramon Casellas
CTTC - Centre Tecnologic de Telecomunicacions de Catalunya
Av. Carl Friedrich Gauss n7
Castelldefels, Barcelona 08860
Spain
Phone:
Email: ramon.casellas@cttc.es
Francisco Javier Jimenez Chico
Telefonica Investigacion y Desarrollo
Emilio Vargas 6
Madrid, 28043
Spain
Phone: +34 91 3379037
Email: fjjc@tid.es
Gonzalez de Dios, et al. Expires April 18, 2011 [Page 18]