PCE Working Group H. Pouyllau
Internet-Draft Alcatel-Lucent
Intended status: Standards Track R. Theillaud
Expires: January 13, 2011 Marben Products
J. Meuric
France Telecom Orange
July 12, 2010
Extension to the Path Computation Element Communication Protocol for
Enhanced Errors and Notifications
draft-pouyllau-pce-enhanced-errors-02.txt
Abstract
This document defines new error and notification types and codes for
the PCE Communication Protocol (PCEP) [RFC5440]. It identifies the
possible PCEP behaviors in case of error or notification. Thus, this
draft extends error and notification types in order to associate
predefined PCEP behaviors.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 13, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Pouyllau, et al. Expires January 13, 2011 [Page 1]
Internet-Draft Extension to PCEP for Enhanced errors July 2010
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 BSD License.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Error use-case . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. Notification use-case . . . . . . . . . . . . . . . . . . 5
2.2. PCEP Description . . . . . . . . . . . . . . . . . . . . . 5
2.3. PCEP Behaviors . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1. PCEP Behaviors in Case of Error . . . . . . . . . . . . . 6
2.3.2. PCEP Behaviors in Case of Notification . . . . . . . . . . 6
3. Conventions used in this document . . . . . . . . . . . . 8
4. Error and Notification Handling in PCEP . . . . . . . . . 9
4.1. Error definition . . . . . . . . . . . . . . . . . . . . . 9
4.2. Notification definition . . . . . . . . . . . . . . . . . 10
4.3. Propagation Restrictions . . . . . . . . . . . . . . . . . 10
4.3.1. Time-To-Live object . . . . . . . . . . . . . . . . . . . 11
4.3.2. DIFFUSION-LIST Object (DLO) . . . . . . . . . . . . . . . 11
5. Error and Notifications Scenarios . . . . . . . . . . . . 13
5.1. Error-type 16 Usage . . . . . . . . . . . . . . . . . . . 13
5.2. Error-type 17 Usage . . . . . . . . . . . . . . . . . . . 13
5.3. Error-type 18 Usage . . . . . . . . . . . . . . . . . . . 14
5.4. Error-type 19 Usage . . . . . . . . . . . . . . . . . . . 15
5.5. Notification-type 3 Usage . . . . . . . . . . . . . . . . 15
5.6. Notification-type 4 Usage . . . . . . . . . . . . . . . . 16
5.7. Notification-type 5 Usage . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . 19
7.1. New Error-Type . . . . . . . . . . . . . . . . . . . . . . 19
7.2. New Notification-Type . . . . . . . . . . . . . . . . . . 19
7.3. New TTL object . . . . . . . . . . . . . . . . . . . . . . 19
7.4. New DLO object . . . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informational References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 23
Pouyllau, et al. Expires January 13, 2011 [Page 2]
Internet-Draft Extension to PCEP for Enhanced errors July 2010
1. Terminology
PCE terminology is defined in [RFC4655].
PCEP Peer: An element involved in a PCEP session (i.e. a PCC or a
PCE).
Source PCC: the PCC which, for a given path computation query,
initiates the 1st PCEP request, which may trigger a chain of
successive requests.
Target PCE: a PCE within the scope of the egress node.
Pouyllau, et al. Expires January 13, 2011 [Page 3]
Internet-Draft Extension to PCEP for Enhanced errors July 2010
2. Introduction
The PCE Communication Protocol [RFC5440] is designed to be flexible
and extensible in order to allow future evolutions or specific
constraint support such as proposed in
[I-D.ietf-pce-vendor-constraints]. Crossing different PCE
implementations (e.g. from different providers or due to different
releases), a PCEP request may encounter unknown errors or
notification messages. In such a case, the PCEP RFC [RFC5440]
specifies to send a specific error code to the PCEP peer.
In the context of path computation crossing different routing domains
or autonomous systems, the number of different PCE system
specificities is potentially high, thus possibly leading to divergent
and unstable situations. Such phenomenon can also occur in
homogeneous cases since PCE systems have their own policies that can
introduce differences in requests treatment even for requests having
the same destination. Extending error and notification codes allow
generalizing PCEP behaviors over heterogeneous PCE systems. Dealing
with heterogeneity is a major challenge considering PCE
applicability, particularly in multi-domain contexts. Thus,
extending such error codes and PCEP behaviors accordingly would
improve interoperability among different PCEP implementations and
would solve some of these unstable issues. However, note that, some
of them would still remain (e.g. the divergences in request treatment
introduced by different policies).
The purpose of this draft is to specify some PCEP error codes in
order to generalize PCEP behaviors.
2.1. Examples
The two following scenarios underline the need for a normalization of
the PCEP behaviors according to the error or notification type.
2.1.1. Error use-case
PCE(i-1) has sent a request to PCE(i) which has also sent a request
to PCE(i+1). PCE(i-1) and PCE(i+1) have the same error semantic but
not PCE(i). If PCE(i+1) throws an error type and value unknown by
PCE(i). PCE(i) could then adopt any other behaviors and sends back
to PCE(i-1) an error of type 2 (Capability not supported), 3 (Unknown
Object) or 4 (Not supported Object) for instance. As a consequence,
the path request would be cancelled but the error has no meaning for
PCE(i-1) whereas a simple backward of the error sent by PCE(i+1)
would have been understandable by PCE(i-1).
Pouyllau, et al. Expires January 13, 2011 [Page 4]
Internet-Draft Extension to PCEP for Enhanced errors July 2010
2.1.2. Notification use-case
PCE(i-1) has sent a request to PCE(i) which has also sent a request
to PCE(i+1) but PCE(i+1) is overloaded. Without extensions, PCE(i+1)
should send a notification of type 2 and a value flag giving its
estimated congestion duration. PCE(i) can choose to stop the path
computation and send a NO_PATH reply to PCE(i-1). Hence, PCE(i-1)
ignores the congestion duration on PCE(i+1) and could seek it for
further requests.
2.2. PCEP Description
One of the purposes of the PCE architecture is to compute paths
across networks, but an added value is to compute such paths in
inter-area/layer/domain environments. The PCE Communication Protocol
[RFC5440] is based on the Transport Communication Protocol (TCP).
Thus, to compute a path within the PCE architecture, several TCP/PCEP
sessions have to be set up, in a peer-to-peer manner, along a set of
identified PCEs.
When the PCEP session is up for 2 PCEP peers, the PCC of the first
PCE System (the source PCC) sends a PCEReq message. If the PCC does
not receive any reply before the dead timer is out, then it goes back
to the idle state. A PCC can expect two kinds of replies: a PCERep
message containing one or more valid paths (EROs) or a negative
PCERep message containing a NO-PATH object.
Beside PCEReq and PCERep messages, notification and error messages,
named respectively PCNtf and PCErr, can be sent. There are two types
of notification messages: type 1 is for cancelling pending requests
and type 2 for signaling a congestion of the PCE. Several error
values are described in [RFC5440]. The error types concerning the
session phase begin at 2, error type 1 values are dedicated to the
initialization phase.
As the PCE Communication Protocol is built to work in a peer-to-peer
manner (i.e. supported by a TCP Connection), it supposes that the
''deadtimer'' of the source PCC is long enough to support the end-to-
end distributed path computation process.
2.3. PCEP Behaviors
The exchange of messages in the PCE Communication Protocol is
described in details when PCEP is in states OpenWait and KeepWait in
[RFC5440]. When the session is up, message exchange is defined in
[RFC5440] but detailed behavior is mostly let free to any specific
implementation. [RFC5441] describes the Backward Recursive Path
Computation (BRPC) procedure, and, because it considers an inter-
Pouyllau, et al. Expires January 13, 2011 [Page 5]
Internet-Draft Extension to PCEP for Enhanced errors July 2010
domain path computation, gives a bigger picture of the possible
behaviors when the session is up.
2.3.1. PCEP Behaviors in Case of Error
For a given request, on the reception of a PCErr, identified PCEP
behaviors are the followings:
o "Propagation": the received message requires to be propagated
forwardly or backwardly (depending on which PCEP peer has sent the
message); if the message is a notification, it might required to
be propagated to any known PCEP peers;
o "Status quo": the received message does not affect the PCEP
connection but the path computation request is cancelled;
o "Unrecoverable": the received message is an unrecoverable failure
leading to cancel the path computation and close the TCP
connection and release the PCEP resources;
Note that some the behavior ''propagation'' can be combined with the
others, thus leading to possibilities:
o "status quo",
o "unrecoverable",
o "propagation" and "status quo",
o "propagation" and "unrecoverable".
2.3.2. PCEP Behaviors in Case of Notification
Notification messages can be employed in two different manners:
during the treatment of a PCEP request, or independently from it to
advertise information (in [RFC5440] the request id list within a
PCNtf message is optional). Hence, three different behaviors can be
identified:
o "Status quo": the notification is or is not request-specific but
does not imply any forward or backward propagation of the message;
o "Request-specific Propagation": the received message requires to
be propagated forwardly or backwardly (depending on which peer has
sent the message) to the PCEP peers;
o "Non request-specific Propagation": the received message must be
propagated to any known peers (e.g. if PCE discovery is activated)
Pouyllau, et al. Expires January 13, 2011 [Page 6]
Internet-Draft Extension to PCEP for Enhanced errors July 2010
or to a list of identified peers.
Pouyllau, et al. Expires January 13, 2011 [Page 7]
Internet-Draft Extension to PCEP for Enhanced errors July 2010
3. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Pouyllau, et al. Expires January 13, 2011 [Page 8]
Internet-Draft Extension to PCEP for Enhanced errors July 2010
4. Error and Notification Handling in PCEP
This section describes error and notification messages with respect
to the PCEP behavior description defined in section 2.2. Note that
this document does not modify the ones previously defined in pre-
existing documents (e.g. [RFC5440], [RFC5441]...).
4.1. Error definition
Recall that Error-Type and Error-Value fields of a PCEP-ERROR Object
are both limited to 8 bits. PCE errors are also always request-
specific. To support specific behaviors, error types should be added
w.r.t. [RFC5440] definitions as ensued:
Error-type Error-value
16 0-255: The error is a non-failure error and can be
considered as a warning. The PCEP peer receiving
such an error can adopt any specific behavior but
its PCEP state MUST NOT change. The PCEP peer MUST
NOT propagate the message or close the TCP
connection because a response is still expected.
17 0-255: The error is a non-failure error and can be
considered as a warning. The PCEP peer receiving
such an error can adopt any specific behavior but
its PCEP state MUST NOT change. The PCEP peer MUST
backward (or forward depending on the request way
and state) the error message unless it is the source
PCC (or the target PCE respectively). The PCEP peer
MUST NOT close the TCP connection because a response
is still expected.
18 0-255: The error is a failure error. The PCEP peer
receiving such an error can adopt any specific
behavior but it MUST NOT propagate the message.
Finally, it MUST close the TCP connection, release
the PCEP resources and turns into ''Idle'' state.
19 0-255: The error is a failure error. The PCEP peer
receiving such an error can adopt any specific
behavior but, finally, it MUST backward (or forward,
depending on the request way and state) the error
message unless it is the source PCC (or the target
PCE respectively). Finally, it MUST close the TCP
connection, release the PCEP resources and turns to
"Idle" state.
Pouyllau, et al. Expires January 13, 2011 [Page 9]
Internet-Draft Extension to PCEP for Enhanced errors July 2010
4.2. Notification definition
Recall that Notification-Type and Notification-Value fields of a
NOTIFICATION object are both limited to 8 bits. To support specific
behaviors, notification types should be added with respect to
[RFC5440] definitions as ensued:
Notification-type Notification-value
3 0-255: The notification targets only one PCE. It
might be request-specific. Such a notification
MUST NOT be propagated.
4 0-255: The notification targets the set of PCEs
involved in one or a set of path computation
requests. The PCE which receives it MUST
backward (or forward, depending on the request
way and state) it, unless it is the request
initiator (or the target PCE respectively). This
type of notification is obviously request-
specific.
5 0-255: The notification MUST be forwarded to any
known PCEP peer or to a list of indicated PCEP
peers. To avoid flooding, such propagation could
be limited by fixing a maximal number of PCEP
peers and/or including a set of PCEP peers. This
type of notification is not request-specific and
might imply to open new PCEP sessions. But, a
PCEP peer MUST NOT forward such a notification
to the PCEP peer from which it received it.
4.3. Propagation Restrictions
In order to limit the propagation of errors and notifications, the
following mechanisms SHOULD be used:
A Time-To-Live object: to limit the number of PCEP peers that will
recursively receive the message;
A Diffusion List Object (DLO): to indicate the PCEP peer addresses
or domains of PCEP peers the message must be propagate to;
History mechanisms: if a PCEP peer keeps track of the messages it
has relayed, it could avoid propagating an error or notification
it already received.
Pouyllau, et al. Expires January 13, 2011 [Page 10]
Internet-Draft Extension to PCEP for Enhanced errors July 2010
Such mechanisms SHOULD be used jointly or independently depending the
error-type or notification-type they are associated to. Note that, a
message of notification-type 5 MUST include a DLO and SHOULD include
a TTL. The conditions of use for the TTL and Diffusion List Object
are described in sections below.
4.3.1. Time-To-Live object
The TTL value is set to any integer value to indicate the number of
PCEP peers that will recursively receive the message. This TTL
SHOULD be used with error-type 17 and 19 and notification-type 4 and
5. Each PCEP peer MUST decrement the TTL value before propagating
the message. When the TTL value is at 0, the message is no more
propagated.
If the message is request-specific (error-type 17 and 19, and
notification-type 4), and there is no TTL object included, the
message MUST reach the source PCC (or alternatively the target PCE).
4.3.2. DIFFUSION-LIST Object (DLO)
The DIFFUSION-LIST Object can be carried within a PCErr and a PCNtf
message and can either be used in a message sent by a PCC to a PCE or
by a PCE to a PCC. The DLO MAY be used with error-type 17 and 19 and
notification-type 4, and it MUST be used with notification-type 5.
DIFFUSION-LIST Object-Class is 25.
DIFFUSION-LIST Object-Type is 1.
The format of the DIFFUSION-LIST body object is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | TT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Sub-objects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved (8 bits): This field MUST be set to zero on transmission and
MUST be ignored on receipt.
Flags (16 bits): No flags are currently defined. Unassigned flags
Pouyllau, et al. Expires January 13, 2011 [Page 11]
Internet-Draft Extension to PCEP for Enhanced errors July 2010
MUST be set to zero on transmission and MUST be ignored on receipt.
TT (8 bits): The Target-type restricts the diffusion to certain
peers. The following values are currently defined:
0: Any PCEP peer indicated in the list must be reached.
1: Only PCEs must be reached (and not PCC).
2: All PCEP peers with which a session is still opened must be
reached
The DLO is made of sub-objects similar to the IRO defined in
[RFC5440]. The following sub-object types are supported.
Type Sub-object
1 IPv4 address
2 IPv6 address
4 Unnumbered Interface ID
5 OSPF area ID
32 Autonomous System number
33 Explicit eXclusion Route Sub-object (EXRS)
If the error or notification codes target specific PCEP peers, a
Diffusion list Object avoids partially flooding all PCEP peers. Any
PCEP peer receiving a message of error-type 17 or 19 or notification-
type 4 or 5 and where a DLO appears MUST remove from the DLO the
addresses of the PCEP peers to whom it will propagate the message,
before sending them the message. This is performed adding the PCEP
peer addresses to the Explicit eXclusion Route Sub-object of the DLO.
If a Diffusion List Object is empty, the PCEP peer MUST NOT propagate
the message to any peer.
Note that, a Diffusion List Object could contain strict or loose
addresses to refer to a network domain (e.g. an Autonomous System
number, an OSPF area, an IP address). Hence, the PCEP peers targeted
by the message would be the PCEP peers covering the corresponding
domain. If an address is loose, each time a PCEP peer forwards a
message to another PCEP peer of this address, it MUST add it to the
Explicit eXclusion Route Sub-object (EXRS) of the DLO for any
forwarded message. Hence, a PCE SHOULD avoid forwarding several
times the same message to the same set of peers. Finally, when an
address is loose, the forwarding SHOULD be restrained indicating what
type of PCEP peers are targeted (i.e. PCE and/or PCC). Hence, a
Target-Type is specified.
Pouyllau, et al. Expires January 13, 2011 [Page 12]
Internet-Draft Extension to PCEP for Enhanced errors July 2010
5. Error and Notifications Scenarios
This section illustrates how the error and notification types
described above can be used in a PCEP session. In the case of
notification-type 5, the usage of restrictions is also illustrated.
The origin of the errors or notifications is only illustrative and
has no normative purpose. Sometimes the PCE features behind may be
implementation-specific (e.g. detection of flooding).
5.1. Error-type 16 Usage
In this example, a PCE receiving a request does not understand a
parameter value. For instance, the request could have a METRIC
object of type 3 (hop count) with a bound value equal to -1. It
raises an error to the PCC with error-type 16. This error is not
critical, (the parameter will be ignored), hence the session is still
active and a response can still be expected.
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1) Path computation | |
event | |
2) PCE Selection | |
3) Path computation |---- PCReq message--->|
request X sent to | |4) Path computation
the selected PCE | | request queued
| |
| |5) A parameter value is
| | not understood
| |
|<--- PCErr message----|
| |
5.2. Error-type 17 Usage
In this example, a parameter is not supported by one of the PCE (e.g.
a METRIC object of type 4). The path computation request can thus be
treated but the parameter will be ignored. Hence, this error is not
critical but the source PCC should be informed of this fact. So, an
error of type 17 is raised and propagated backwardly to the source
PCC.
Pouyllau, et al. Expires January 13, 2011 [Page 13]
Internet-Draft Extension to PCEP for Enhanced errors July 2010
+-+-+ +-+-+-+-+ +-+-+
|PCC| |PCE|PCC| |PCE|
+-+-+ +-+-+-+-+ +-+-+
|---- PCReq message-->| |
| | |
| |---- PCReq message--->|
| | |
| | |1) Parameter is
| | | not supported
| | |
| |<--- PCErr message----|
|<--- PCErr message---| |
| | |
5.3. Error-type 18 Usage
In this example, the PCC sends a request that contains an IRO which
can not be satisfied by the next PCE. This problem is critical but
not due to a malformation in the request of the source PCC. Hence,
an error of type 18 is raised. The PCECP session is closed and PCE
resources realeased.
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1) Path computation | |
event | |
2) PCE Selection | |
3) Path computation |---- PCReq message--->|
request X sent to | |4) Path computation
the selected PCE | | request queued
| |
| |5) IRO can't
| | be satisfied
| |6) Path computation
| | request X
| | cancelled
|<--- PCErr message----|
| |
|<--- Close message----|
| |
Pouyllau, et al. Expires January 13, 2011 [Page 14]
Internet-Draft Extension to PCEP for Enhanced errors July 2010
5.4. Error-type 19 Usage
In this example, the next PCE in the path computation chain is no
more active (congested or deleted). The path can not be computed and
the source PCC should be informed - for further path computation
request - that one of the PCE is not reachable any more. Hence, an
error of type 19 is raised and propagated backwardly to the source
PCC. Consequently, PCECP sessions are closed and PCE resources
realeased.
+-+-+ +-+-+-+-+ +-+-+
|PCC| |PCE|PCC| |PCE|
+-+-+ +-+-+-+-+ +-+-+
|---- PCReq message-->| |
| | |
| |---- PCReq message--->|
| | |
| | |1) PCE does
| | | not exists
| | |
| | |2) Path
| | | computation
| | | request X
| | | cancelled
| |<--- PCErr message----|
|<--- PCErr message---| |
| |<--- Close message----|
|<--- Close message---| |
| | |
5.5. Notification-type 3 Usage
In this example, a PCE sends a request-specific notification
indicated that, due to multiple sendings (or for other reason),
further requests from this PCC will be ignored. Hence, a
notification of type 3 is sent to the PCC.
Pouyllau, et al. Expires January 13, 2011 [Page 15]
Internet-Draft Extension to PCEP for Enhanced errors July 2010
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1) Path computation | |
event | |
2) PCE Selection | |
3) Path computation |---- PCReq message--->|
request X sent to | |4) Path
the selected PCE | | computation
| | request queued
| |
| |5) Further requests
| | will be ignored
| |
|<--- PCNtf message----|
| |
5.6. Notification-type 4 Usage
In this example, a PCE receives a request but it is temporarly
congested. However, it can treat the request after few minutes which
might cause some time-out in the predecessor PCEs. Hence, a
notification of type 4 is send to the PCC and forward backwardly in
the PCE sequence. Such a notification could include an OVERLOAD
object as described in [RFC5886].
+-+-+ +-+-+-+-+ +-+-+
|PCC| |PCE|PCC| |PCE|
+-+-+ +-+-+-+-+ +-+-+
|---- PCReq message-->| |
| | |
| |---- PCReq message--->|
| | |
| | |1)PCE is busy but
| | | will answer to X
| | | in M minutes
| | | (time-out update)
| |<--- PCNtf message----|
|<--- PCNtf message---| |
5.7. Notification-type 5 Usage
This example is inspired by draft [I-D.king-pce-hierarchy-fwk] which
proposes a hierarchical architecture of PCE. The notification-type 5
could be used to disclose to external domains' PCEs (here PCEj and
Pouyllau, et al. Expires January 13, 2011 [Page 16]
Internet-Draft Extension to PCEP for Enhanced errors July 2010
PCEj') that the parent PCE of a domain (here PCEi) has changed. In
this case, the notification-type 5 is used as a complement of a
discovery feature.
+-+-+-+ +-+-+-+ +-+-+-+
|PCEj | |PCEj'| |PCEi |
+-+-+-+ +-+-+-+ +-+-+-+
| | |
| | |1) Parent PCE
| | | changes
| |<--- PCNtf message----|
|<--- PCNtf message---| |
Pouyllau, et al. Expires January 13, 2011 [Page 17]
Internet-Draft Extension to PCEP for Enhanced errors July 2010
6. Security Considerations
Within the introduced set of error-type and notification-type, error-
type 17 and 19, and notification-type 4 and 5 affects PCEP security
considerations since they induce propagation behaviors. Thus, a PCEP
implementation SHOULD activate stateful mechanism when receiving such
error-type or notification-type in order to avoid DoS attacks.
Pouyllau, et al. Expires January 13, 2011 [Page 18]
Internet-Draft Extension to PCEP for Enhanced errors July 2010
7. IANA Considerations
IANA maintains a registry of PCEP parameters. This includes a sub-
registry for PCEP Objects.
IANA is requested to make an allocation from the sub-registry as
follows. The values here are suggested for use by IANA.
7.1. New Error-Type
Error-type Meaning and Values Reference
16 Status quo error this document
0-255: Unassigned
17 Status quo error this document
to be propagated
0-255: Unassigned
18 Unrecoverable error this document
0-255: Unassigned
19 Unrecoverable error
to be propagated this document
0-255: Unassigned
7.2. New Notification-Type
Notification-type Meaning and Values Reference
3 Status quo notifications this document
0-255: Unassigned
4 Request-specific notification
to be propagated this document
0-255: Unassigned
5 General notification
to be propagated this document
0-255: Unassigned
7.3. New TTL object
TBC
Pouyllau, et al. Expires January 13, 2011 [Page 19]
Internet-Draft Extension to PCEP for Enhanced errors July 2010
7.4. New DLO object
Object-class Value Object-Type and Name Reference
25 1: Diffusion list object this document
Target-Type Value Meaning Reference
0 Any PCEP peers this document
1 PCEs but excludes
PCC-only peers this document
2 PCEs and PCCs this document
with which a session
is still opened
Subobjects Reference
1: IPv4 prefix this document
2: IPv6 prefix this document
4: Unnumbered Interface ID this document
5: OSPF Area ID this document
32: Autonomous system number this document
33: Explicit Exclusion Route subobject (EXRS) this document
Pouyllau, et al. Expires January 13, 2011 [Page 20]
Internet-Draft Extension to PCEP for Enhanced errors July 2010
8. Acknowledgements
This work has been inspired by the French Systematic project
CARRIOCAS and especially the contributors I. Hwang, A. Cavalli,
M.Lallali and D. Verchere for their work titled Modelling,
validation, and verification of PCEP using the IF language.
Pouyllau, et al. Expires January 13, 2011 [Page 21]
Internet-Draft Extension to PCEP for Enhanced errors July 2010
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
[RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A
Backward-Recursive PCE-Based Computation (BRPC) Procedure
to Compute Shortest Constrained Inter-Domain Traffic
Engineering Label Switched Paths", RFC 5441, April 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.
9.2. Informational References
[I-D.ietf-pce-vendor-constraints]
Farrel, A. and G. Bernstein, "Conveying Vendor-Specific
Constraints in the Path Computation Element Protocol",
draft-ietf-pce-vendor-constraints-01 (work in progress),
March 2010.
[I-D.king-pce-hierarchy-fwk]
King, D., Farrel, A., Zhao, Q., and F. Zhang, "The
Application of the Path Computation Element Architecture
to the Determination of a Sequence of Domains in MPLS &
GMPLS", draft-king-pce-hierarchy-fwk-04 (work in
progress), December 2009.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
Pouyllau, et al. Expires January 13, 2011 [Page 22]
Internet-Draft Extension to PCEP for Enhanced errors July 2010
Authors' Addresses
Helia Pouyllau
Alcatel-Lucent
Route de Villejust
NOZAY 91620
FRANCE
Phone: + 33 (0)1 30 77 63 11
Email: helia.pouyllau@alcatel-lucent.com
Remi Theillaud
Marben Products
176 rue Jean Jaures
Puteaux 92800
FRANCE
Phone: + 33 (0)1 79 62 10 22
Email: remi.theillaud@marben-products.com
Julien Meuric
France Telecom Orange
2, avenue Pierre Marzin
Lannion 22307
FRANCE
Email: julien.meuric@orange-ftgroup.com
Pouyllau, et al. Expires January 13, 2011 [Page 23]