PCE Working Group H. Pouyllau
Internet-Draft Alcatel-Lucent
Intended status: Standards Track R. Theillaud
Expires: January 4, 2017 Marben Products
J. Meuric
France Telecom Orange
X. Zhang (Editor)
Huawei Technologies
July 3, 2016
Extensions to the Path Computation Element Communication Protocol for
Enhanced Errors and Notifications
draft-ietf-pce-enhanced-errors-02.txt
Abstract
his document defines new error and notification TLVs for the PCE
Communication Protocol (PCEP) [RFC5440]. It identifies the possible
PCEP behaviors in case of error or notification. Thus, this draft
defines types of errors and notifications and how they are disclosed
to other PCEs in order to support predefined PCEP behaviors.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2017.
Copyright Notice
Copyright (c) 2016 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
Pouyllau, et al. Expires January 4, 2017 [Page 1]
Internet-Draft Extensions to PCEP for Enhanced errors July 2016
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Error use-case . . . . . . . . . . . . . . . . . . . . . 4
3.1.2. Notification use-case . . . . . . . . . . . . . . . . . . 4
4. PCEP Behaviors . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. PCEP Behaviors in Case of Error . . . . . . . . . . . . . . 5
4.2. PCEP Behaviors in Case of Notification . . . . . . . . . . 6
4.3. PCE Peer Identification . . . . . . . . . . . . . . . . . . 6
5. PCEP Extensions for Error and Notification Handling . . . . . 6
5.1. Propagation TLV . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Error-criticality TLV . . . . . . . . . . . . . . . . . . . 7
5.3. Notification type TLV . . . . . . . . . . . . . . . . . . . 7
5.4. Behaviors and TLV combinations . . . . . . . . . . . . . . 8
5.5. Propagation Restrictions Objects . . . . . . . . . . . . . 9
5.5.1. Time-To-Live Object (TTL) . . . . . . . . . . . . . . . . 10
5.5.2. DIFFUSION-LIST Object (DLO) . . . . . . . . . . . . . . . 10
5.5.3. Rules Applied to Existing Errors and Notifications . . . 12
6. Error and Notification Scenarios . . . . . . . . . . . . . . 15
6.1. Error Behavior Type 1 . . . . . . . . . . . . . . . . . . . 15
6.2. Error Behavior Type 2 . . . . . . . . . . . . . . . . . . . 16
6.3. Error Behavior Type 4 . . . . . . . . . . . . . . . . . . . 16
6.4. Error Behavior Type 5 . . . . . . . . . . . . . . . . . . . 17
6.5. Notification Behavior Type 1 . . . . . . . . . . . . . . . 18
6.6. Notification Behavior Type 2 . . . . . . . . . . . . . . . 18
6.7. Notification Behavior Type 3 . . . . . . . . . . . . . . . 19
6.8. Notification Behavior Type 4 . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 20
8.2. New DLO object . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informational References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
Pouyllau, et al. Expires January 4, 2017 [Page 2]
Internet-Draft Extensions to PCEP for Enhanced errors July 2016
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, for a given path computation query, initiating
the first PCEP request, which may then trigger a chain of successive
requests.
Target PCE: the PCE that can compute a path to the destination
without having to query any other PCE.
2. 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].
3. 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. In order to generalize PCEP behaviors in the
case of heterogeneous PCE systems, new objects have to be defined.
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, some of them
would still remain (e.g. the divergences in request treatment
introduced by different policies).
Pouyllau, et al. Expires January 4, 2017 [Page 3]
Internet-Draft Extensions to PCEP for Enhanced errors July 2016
The purpose of this draft is to identify and specify new optional
TLVs and objects in order to generalize PCEP behaviors.
3.1. Examples
The two following scenarios underline the need for a normalization of
the PCEP behaviors according to existing error or notification types.
3.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 if PCE(i) had simply forwarded the error sent by
PCE(i+1), it would have been understood by PCE(i-1).
3.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.
4. PCEP Behaviors
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 two PCEP peers, the PCC of the first
PCE System (the source PCC) sends a PCReq 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 PCRep
message containing one or more valid paths (EROs) or a negative PCRep
message containing a NO-PATH object.
Pouyllau, et al. Expires January 4, 2017 [Page 4]
Internet-Draft Extensions to PCEP for Enhanced errors July 2016
Beside PCReq and PCRep 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.
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]. [RFC5441] describes the Backward Recursive Path
Computation (BRPC) procedure, and, because it considers an inter-
domain path computation, gives a bigger picture of the possible
behaviors when the session is up. Detailed behavior is mostly let
free to any specific implementation. The following sections
identifies the PCEP behaviors in case of error or notification and
also introduce the requirement of PCEP peer identification in both
cases.
4.1. PCEP Behaviors in Case of Error
[RFC5440] specifies that "a PCEP Error message is sent in several
situations: when a protocol error condition is met or the request is
not compliant with the PCEP specification". On this basis, and
according to the other RFCs, the 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) to a set of PCEP peers;
o "Criticality level": in different RFCs, error-types affects the
state of the PCEP request or session in different manners; hence,
different level of criticality can be observed:
o
* Low-level of criticality: the received message does not affect
the PCEP connection and further answer can still be expected;
Pouyllau, et al. Expires January 4, 2017 [Page 5]
Internet-Draft Extensions to PCEP for Enhanced errors July 2016
* Medium-level of criticality: the received message does not
affect the PCEP connection but the request(s) is(are)
cancelled;
* High-level of criticality: the received message indicates that
the PCEP peer will close the session with its peer (and so
pending requests associated by the error, if any, are
cancelled.)
The high-level of criticality has been extracted from [RFC5440] which
associates such a behavior to error-type of 1 (errors raised during
the PCEP session establishment). Hence, such errors are quite
specific. For the sake of completeness, they have been included in
this document.
4.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 types of
behaviors can be identified:
o "Local": the notification 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)
or to a list of identified peers.
4.3. PCE Peer Identification
The propagation of errors and notifications affects the state of the
PCEP peers along the chain. In some cases, for instance a
notification that a PCE is overloaded, the identification of the PCEP
peer - or that the sender PCE is not the direct neighbor - might be
an important information for the PCEP peers receiving the message.
5. PCEP Extensions for Error and Notification Handling
This section describes extensions to support error and notification
with respect to the PCEP behavior description defined in Section 4.
This document does not intend to modify errors and notification types
Pouyllau, et al. Expires January 4, 2017 [Page 6]
Internet-Draft Extensions to PCEP for Enhanced errors July 2016
previously defined in existing documents (e.g. [RFC5440], [RFC5441],
etc.).
5.1. Propagation TLV
To support the propagation behavior mentioned in Section 4.1 and
Section 4.2, a new optional TLV is defined, which can be carried in
PCEP-ERROR and NOTIFICATION objects, to indicate whether a message
has to be propagateed or not. The allocation from the "PCEP TLV Type
Indicators" sub-registry will be assigned by IANA and the request is
documented in Section 8.
The description is "Propagation", the length value is 2 bytes and the
value field is 1 byte. The value field is set to default value 0
meaning that the message MUST NOT be propagated. If the value field
is set to 1, the message MUST be propagated. Section 5.5 specifies
the destination and to limit the number of messages.
5.2. Error-criticality TLV
To support the shutdown behavior mentioned in Section 4.1, we extend
the PCEP-ERROR object by creating a new optional TLV to indicate
whether an error is recoverable or not. The allocation from the
"PCEP TLV Type Indicators" sub-registry will be assigned by IANA and
the request is documented in Section 8.
The description is "Error-criticality", the length value is 2 bytes
and the value field is 1 byte. The value field is set to default
value 0 meaning that the error has a low-level of criticality (so
further messages can be expected for this request). If the value
field is set to 1, the error has a medium-level of criticality and
requests whose identifiers appear in the same message MUST be
cancelled (so no further messages can be expected for these
requests). If the value field is set to 2, the error has a high-
level of criticality, the connection for this PCEP session is closed
by the sender PCE peer.
5.3. Notification type TLV
To support the request-specific behavior mentioned in Section 4.2, we
extend the NOTIFICATION object by creating a new optional TLV to
indicate whether the notification is request-specific or not. The
allocation from the "PCEP TLV Type Indicators" sub-registry will be
assigned by IANA and the request is documented in Section 8.
The description is "Notification Type", the length value is 2 bytes
and the value field is 1 byte. The value field is set to default
Pouyllau, et al. Expires January 4, 2017 [Page 7]
Internet-Draft Extensions to PCEP for Enhanced errors July 2016
value 0 meaning that the notification is not request-specific. If
the value field is set to 1, the notification is request-specific.
If according to RFC5440 a notification contains a request-id, then
the value field of the Notification type TLV MUST be set to 1.
5.4. Behaviors and TLV combinations
The propagation behavior MAY be combined with all criticality levels,
thus leading to 6 different behaviors. In the case of a criticality
level of 2, the session is closed by the PCE peer which sends the
message. Hence, the criticality level is purely informative for the
PCE peer which receives the message. If it is combined with a
propagation behavior, then the PCE propagating the message MUST
indicate the same level of criticality if it closes the session.
Otherwise, it MUST use a criticality level of 1 if it does not close
the session.
For a PCErr message, all the possible behaviors described in
Section 4.1 can be covered with TLVs included in a PCEP-ERROR object.
The following table captures all combinations of error behaviors:
| Error \Propogation| 0 | 1 |
| criticallity\ Value | ( No |(Propogation |
| value \ | Propagation) | Required) |
|------------------------------------------------------|
| 0 (low) | Type 1 | Type 4 |
| 1 (medium) | Type 2 | Type 5 |
| 2 (high) | Type 3 | Type 6 |
|------------------------------------------------------|
o "Error Behavior Type 1" : Local Error with a low level of
criticality;
o "Error Behavior Type 2": Local Error with a medium level of
criticality;
o "Error Behavior Type 3": Local Error with a high level of
criticality;
o "Error Behavior Type 4": Propagated Error with a low level of
criticality;
o "Error Behavior Type 5": Propagated Error with a medium level of
criticality;
Pouyllau, et al. Expires January 4, 2017 [Page 8]
Internet-Draft Extensions to PCEP for Enhanced errors July 2016
o "Error Behavior Type 6": Propagated Error with a high level of
criticality;
For a notification message, the behaviors are covered as ensued, with
TLVs included in a NOTIFICATION object:
| \Propogation | 0 | 1 |
| Notification\ Value | (No | (Propogation |
| type value \ | Propagation) | Required) |
|--------------------------------------------------------|
| 0 (non request-specific)| Type 1 | Type 3 |
| 1 (request-specific) | Type 2 | Type 4 |
|--------------------------------------------------------|
o "Notification Behavior Type 1": TLV "Propagation" with value 0 and
TLV "Notification Type" with value 0;
o "Notification Behavior Type 2": TLV "Propagation" with value 0 and
TLV "Notification Type" with value 1;
o "Notification Behavior Type 3": TLV "Propagation" with value 1 and
TLV "Notification Type" with value 0;
o "Notification Behavior Type 4": TLV "Propagation" with value 1 and
TLV "Notification Type" with value 1;
5.5. Propagation Restrictions Objects
In order to limit the propagation of errors and notifications, the
following mechanisms SHOULD be used:
A Time-To-Live(TTL) object: to limit the number of PCEP peers that
will recursively receive the message;
A DIFFUSION-LIST object (DLO): to specify the PCEP peer addresses
or domains of PCEP peers the message must be propagate to;
History mechanism: if a PCEP peer keeps track of the messages it
has relayed, it could avoid propagating an error or notification
it has already received.
Such mechanisms SHOULD be used jointly or independently depending the
error or notification behaviors they are associated to. Note that, a
non request-specific propagated notification (i.e., "Notification
Behavior Type 3") MUST include a DLO and SHOULD include a TTL. The
Pouyllau, et al. Expires January 4, 2017 [Page 9]
Internet-Draft Extensions to PCEP for Enhanced errors July 2016
conditions of use for the TTL and DIFFUSION-LIST object are described
in sections below.
5.5.1. Time-To-Live Object (TTL)
The TTL value is set to any integer value to indicate the number of
PCEP peers that will recursively receive the message. The TLL object
SHOULD be used with propagated errors or notifications ("Propagation"
TLV with value 1 in PCEP-ERROR or NOTIFICATION objects). Each PCEP
peer MUST decrement the TTL value before propagating the message.
When the TTL value becomes 0, the message is no more propagated.
If the message to be propagated is request-specific ("Propagation"
TLV with value 1 in PCEP-ERROR or NOTIFICATION objects, and
"Notification Type" TLV with value 1 in a NOTIFICATION object), and
there is no TTL or DIFFUSION-LIST object included, the message MUST
reach the source PCC (or alternatively the target PCE).
5.5.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
vice versa. The DLO MAY be used with propagated errors (TLV
"Propagation"at value 1 in PCEP-ERROR object) and request-specific
propagated notifications (i.e., "Notification Behavior Type 4").
Furtheremore, it MUST be used with non request-specific propagated
notifications (i.e., "Notification Behavior Type 3").
DIFFUSION-LIST Object-Class is 25.
DIFFUSION-LIST Object-Type is 1.
The format of the DIFFUSION-LIST object body 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 | Target-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Sub-objects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved (8 bits): This field MUST be set to zero on transmission and
MUST be ignored on receipt.
Pouyllau, et al. Expires January 4, 2017 [Page 10]
Internet-Draft Extensions to PCEP for Enhanced errors July 2016
Flags (16 bits): No flags are currently defined. Unassigned flags
MUST be set to zero on transmission and MUST be ignored on receipt.
Target-type (8 bits): 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 PCErr or PCNTf message containing a PCEP-ERROR
or a NOTIFICATION object with a TLV "Propagation" at value 1 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 by 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 own
address to the Explicit eXclusion Route Sub-object (EXRS) of the DLO
for any forwarded messages. Hence, a PCE SHOULD avoid forwarding the
same message repeated to the same set of peers. Finally, when an
address is loose, the forwarding SHOULD be restrained indicating what
Pouyllau, et al. Expires January 4, 2017 [Page 11]
Internet-Draft Extensions to PCEP for Enhanced errors July 2016
type of PCEP peers are targeted (i.e. PCE and/or PCC). Hence, a
Target-Type is specified.
5.5.3. Rules Applied to Existing Errors and Notifications
Many existing normative references states on error definitions (see
for instance [RFC5440], [RFC5441],[RFC5455], [RFC5521], [RFC5557],
[RFC5886], [RFC6006]). According to the definitions provided in this
document, the follwoing rules are applicable:
Error-type 1, described in [RFC5440], relates to PCEP session
establishement failures. All errors of this type are local (not
to be propagated). Hence, if a "Propagation" TLV is added to the
error message it MUST be set to value 0. Error-values 1,2,6,7
have a high level of criticality. Hence, if the "Error-
criticality" TLV is included within a PCErr message of type 1 and
value 1,2,6 or 7, it MUST have a value of 2.
Error-type 2,3,4, "Capability not supported", "Unknown object" and
"Not supported object" respectively, described in [RFC5440]:
errors of this type MAY be propagated using the TLV "Propagation".
Their level of criticality is defined as leading to cancel the
path computation request (cf. [RFC5440]). Hence, if the "Error-
criticality" TLV is included, it MUST have a value of 1. The
error-value 4 of error-type 4 ("Unsupported parameter") associated
to the BRPC procedure [RFC5441] SHOULD contain the "Propagation"
TLV with a DIFFUSION-LIST object requesting a propagation to the
PCC at the origin of the request.
Error-type 5 refers to "Policy violation", error values for this
type have been defined in [RFC5440], [RFC5541], [RFC5557],
[RFC5886] and [RFC6006]. In [RFC5440], it is specified that the
path computation request MUST be cancelled when an error of type 5
occurs. Hence, if the "Error-criticality" TLV is included, it
MUST have a value of 1. As such errors might be conveyed to
several PCEs, the "Propagation" TLV MAY be used.
Error-type 6 described as "Mandatory object missing" in [RFC5440],
leads to the cancellation of the path computation request. Hence,
if the "Error-criticality" TLV is included, it MUST have a value
of 1. The "Propagation" TLV MAY be used with such errors. The
error-value of 4 for Monitoring object missing defined in
[RFC5886] is no exception to the rule.
Error-type 7 is described as "synchronized path computation
request missing". In [RFC5440], it is specified that the reffered
synchronized path computation request MUST be cancelled when an
error of type 5 occurs. Hence, if the "Error-criticality" TLV is
Pouyllau, et al. Expires January 4, 2017 [Page 12]
Internet-Draft Extensions to PCEP for Enhanced errors July 2016
included, it MUST have a value of 1. The "Propagation" TLV MAY be
used with such errors.
Error-type 8 is raised when a PCE receives a PCRep with an unknown
request reference. If the "Propagation" TLV is used with error-
type 8, it SHOULD be set at a value of 0. The "Error-criticality"
TLV is not particularly relevant for error-type 8. Hence, if it
used, it MUST have the value of 0.
Error-type 9 is raised when a PCE attempts to establish a second
PCEP session. The existing session must be preserved. Hence, if
the "Error-criticality" TLV is included, it MUST have a value of
0. By definition, such an error message SHOULD NOT be propagated.
Thus, if the "Propagation" TLV is used with error-type 9, it
SHOULD be set at a value of 0.
Error-type 10 which refers to the reception of an invalid object
as described in [RFC5440] no indication is provided on the
cancellation of the path computation request. Hence, if the
"Error-criticality" TLV is included, it MUST have a value of 0.
The "Propagation" TLV MAY be used with such errors with any value
depending on the expected behavior.
Error-type 11 relates to "Unrecognized EXRS subobject" and is
described in [RFC5521]. No path computation request cancellation
is required by [RFC5521]. Hence, if the "Error-criticality" TLV
is included, it MUST have a value of 0. The "Propagation" TLV MAY
be used with such errors with any value depending on the expected
behavior.
Error-type 12 refers to "Diffserv-aware TE error" and is described
in [RFC5455]. Such errors are raised when the CLASSTYPE object of
a PCReq is recognized but not supported by a PCE. [RFC5455] does
not state about the path computation request when such errors are
met. Hence, both "Propagation" and "Error-criticality" TLVs COULD
be used within such error-types' messages and set to any specified
values.
Error-type 13 on "BRPC procedure completion failure" is described
in [RFC5441]. [RFC5441] states that in such cases, the PCErr
message MUST be relayed to the PCC. Hence, such messages SHOULD
contain a "Propagation" TLV and a DIFFUSION-LIST object with a
Target-Type of 0 and corresponding adresses or with a Target-Type
of 2. It is not specified in [RFC5441] whether the path
computation request should be canceled or not. If the procedure
is not supported, it does not necessarily imply to cancel the path
computation request if another procedure is able to read and write
Pouyllau, et al. Expires January 4, 2017 [Page 13]
Internet-Draft Extensions to PCEP for Enhanced errors July 2016
VSPT objects. Thus, the "Error-criticality" TLV MAY be used with
any value depending on the expected behavior.
Error-type 15 refers to "Global Concurrent Optimization Error"
defined in [RFC5557]. [RFC5557] states that the corresponding
global concurrent path optimization MUST be cancelled at the PCC.
Hence, if the "Error-criticality" TLV is included, it MUST have a
value of 1. The "Propagation" TLV MAY be used with such errors.
Error-type 16 relates to "P2MP Capability Error" defined in
[RFC6006]. Such errors lead to the cancellation of the path
computation request. Hence, if the "Error-criticality" TLV is
included, it MUST have a value of 1. The "Propagation" TLV MAY be
used with such errors.
Error-type 17, titled "P2MP END-POINTS Error" is defined
[RFC6006]. Such errors are thrown when a PCE tries to add or
prune nodes to or from a P2MP Tree. [RFC6006] does not specify if
such errors lead to cancel the path computation request. Hence,
the "Error-criticality" and "Propagation" TLVs MAY be used with
this type of error with any value depending on the expected
behavior.
Error-type 18 of "P2MP Fragmentation Error" is described [RFC6006]
which does not specify whether the path computation request should
be cancelled. But, as messages are fragmented, it is natural to
think that the PCE should wait at least a bit for further
messages. The "Error-criticality" TLV MAY be included in such
error messages and is particularly adapted to differ the semantic
of the same error-type message: if it is included with a value of
0 then the PCE will still wait for further fragmented messages,
when this waiting time ends, the TLV can be included with a value
of 1 in order to finally cancel the request. The "Propagation"
TLV MAY also be used with such errors.
Among the existing normative references, only the [RFC5440] defines
some notification-types and values. The recommendations with respect
to the TLVs definitions provided in this document are the followings:
Notitification-type=1, Notification-value=1 or 2: a PCC,
respectively a PCE, cancels a set of pending requests, such a
notification SHOULD be propagated to the list of PCEP peers which
were implied in the path computation requests. Hence, the
NOTIFICATION object SHOULD contains the "Propagation" TLV with
value 1 and the "Notification Type" TLV with value 1, together
with a DIFFUSION-LIST object containing the list of PCEP peers.
Pouyllau, et al. Expires January 4, 2017 [Page 14]
Internet-Draft Extensions to PCEP for Enhanced errors July 2016
Notitification-type=2, Notification-value=1 or 2: indicates to the
PCC that the PCE is, respectively is no longer, in an overloaded
state. Such a notification can be propagated or stay local. It
is therefore RECOMMENDED to specify this behavior using the
"Propagation" TLV and associated restriction mechanims.
6. Error and Notification Scenarios
This section provides some examples depicting how the error and
notification types described above can be used in a PCEP session.
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). This section
does not provide scenarios for errors with a high-level of critcity
(i.e., Error behaviors 3 and 6) since such errors are very specific
and until now have been normalized only during the session
establishment (error-type of 1).
6.1. Error Behavior Type 1
In this example, a PCC attempts to establish a second PCEP session
with the same PCE for another request. Consequently the PCE sends
back an error message with error-type 9. This error stays local and
does not affect the former session. The second session is ignored.
If the "Propagation" TLV and "Error-criticality" TLV are used, they
should be both set to value 0.
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1) Path computation | |
event | |
2) PCE selection |----- Open Message--->|
|<--- Open message ----|
3) Path computation |---- PCReq message--->|
request X sent to | |4) Path computation
the selected PCE | | request queued
| |
5) Path computation | |
event | |
6) PCE selection | |
|----- Open Message--->|8) Session already
| |opened
|<--- PCErr message----| Error-type=9
| |
Pouyllau, et al. Expires January 4, 2017 [Page 15]
Internet-Draft Extensions to PCEP for Enhanced errors July 2016
6.2. Error Behavior Type 2
In this example, the PCC sends a DiffServ-aware path computation
request. If the PCE receiving the request does not support the
indicated class-type, it thus sends back a PCErr message with error-
type=12 and error-value=1. If the "Propagation" TLV and "Error-
criticality" TLV are present, they should carry value 0 and value 1
respectively. Consequently, the request is cancelled.
+-+-+ +-+-+
|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) DiffServ class-type
| | not supported
| |6) Path computation
| | request X
| | cancelled
|<--- PCErr message----| Error-type=12
| |
6.3. Error Behavior Type 4
In this example, a PCC sends a path computation requests with no P
flag set (e.g. END-POINT object with P-flag cleared). This is
detected by another PCE in the sequence. The path computation
request can thus be treated but the P-Flag will be ignored. Hence,
this error is not critical but the source PCC should be informed of
this fact. So, a PCErr message with error-type 10 ("Reception of an
invalid object"). The PCEP-ERROR object of the message contains a
"Propagation" TLV at value 1 and a "Error-criticality" TLV at value
0. It is hence propagated backwardly to the source PCC.
Pouyllau, et al. Expires January 4, 2017 [Page 16]
Internet-Draft Extensions to PCEP for Enhanced errors July 2016
+-+-+ +-+-+-+-+ +-+-+
|PCC| |PCE|PCC| |PCE|
+-+-+ +-+-+-+-+ +-+-+
|---- PCReq message-->| |
| | |
| |---- PCReq message--->|
| | |
| | |1) Parameter is
| | | not supported
| | |
| |<--- PCErr message----| Error-type=10
|<--- PCErr message---| |
| | |
6.4. Error Behavior Type 5
In this example, PCEs are using the BRPC procedure to treat a path
computation request [RFC5441]. However, one of the PCEs does not
support a parameter of the request. Hence, a PCErr message with
error-type 4 and error-value 4 is sent by this PCE and has to be
forwarded to the source PCC. The PCEP-ERROR object includes a
"Propagation" TLV at value 1 and "Error-criticality" TLV at value 1
and the message is propagated backwardly to the source PCC.
Consequently, the request is cancelled.
+-+-+ +-+-+-+-+ +-+-+
|PCC| |PCE|PCC| |PCE|
+-+-+ +-+-+-+-+ +-+-+
|---- PCReq message-->| |
| | |
| |---- PCReq message--->|
| | |
| | |1) Unsupported
| | | Parameter BRPC
| | |2) Path
| | | computation
| | | request X
| | | cancelled
| |<--- PCErr message----| Error-type=4
|<--- PCErr message---| |
| | |
Pouyllau, et al. Expires January 4, 2017 [Page 17]
Internet-Draft Extensions to PCEP for Enhanced errors July 2016
6.5. Notification Behavior Type 1
In this example, a PCE sends a non request-specific notification
indicating that, due to multiple sendings (or for other reasons),
further requests from this PCC will be ignored. Hence, a PCNtf
message is sent to the PCC with a NOTIFICATION object including the
"Propagation" TLV at value 0 and a "Notification Type" TLV at value
0.
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| |1) Further requests
| | will be ignored
| |
|<--- PCNtf message----|
| |
6.6. Notification Behavior Type 2
In this example, a PCE sends a request-specific notification
indicating that, a set of pending requests are cancelled (e.g.
notification-type=1, notification-value=1 as described in [RFC5440]).
Hence, a PCNtf message is sent to the PCC with a NOTIFICATION object
including a "Propagation" TLV at value 0 and a "Notification Type"
TLV at value 1.
+-+-+ +-+-+
|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) Pending requests
| | cancelled
| |
|<--- PCNtf message----|Notification-Type=1
| |
Pouyllau, et al. Expires January 4, 2017 [Page 18]
Internet-Draft Extensions to PCEP for Enhanced errors July 2016
6.7. Notification Behavior Type 3
In this example, a PCE is temporarily congested. A PCNtf message
with a NOTIFICATION object containing a "Propagation" TLV at value 1
and a "Notification Type" TLV at value 0 is send to a PCEP peer.
This notification messge is propagated to a sequence of PCEs if
necessary. Here, PCEk is congested and send a PCNtf message to PCEi
with the approapriate TLVs, an OVERLOAD object as described in
[RFC5886], and a DIFFUSION-LIST object indicating PCEj as a target of
the notification.
+-+--+ +-+--+ +-+--+
|PCEj| |PCEi| |PCEk|
+-+--+ +-+--+ +-+--+
| | |
| | |1)PCE is busy
| | | for M minutes
| | | (time-out update)
| |<--- PCNtf message----| Notification-type=2
|<--- PCNtf message---| |
6.8. Notification Behavior Type 4
In this example, a PCE receives a request but it is temporarily
congested. However, it can treat the request after few minutes which
might cause some time-out in the predecessor PCE(s). Hence, a PCNtf
message with a NOTIFICATION object containing a "Propagation" TLV at
value 1 and a "Notification Type" TLV at value 1 is sent to the PCC
and propagated backwardly in the 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----| Notification-type=2
|<--- PCNtf message---| |
Pouyllau, et al. Expires January 4, 2017 [Page 19]
Internet-Draft Extensions to PCEP for Enhanced errors July 2016
7. Security Considerations
Within the introduced set of TLVs, the "Propagation" TLV affects PCEP
security considerations since it forces propagation behaviors. Thus,
a PCEP implementation SHOULD activate stateful mechanism when
receiving PCEP-ERROR or NOTIFICATION object including this TLV in
order to avoid DoS attacks.
8. 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.
8.1. PCEP TLV Type Indicators
As described in Section 5.5 the newly defined TLVs allows a PCE to
enforce specific error and notification behaviors within PCEP-ERROR
and NOTIFICATION objects. IANA is requested to make the following
allocations from the "PCEP TLV Type Indicators" sub-registry.
Value Description Reference
7 Propagation this document
8 Error-criticality this document
9 Notification type this document
8.2. New DLO object
Pouyllau, et al. Expires January 4, 2017 [Page 20]
Internet-Draft Extensions to PCEP for Enhanced errors July 2016
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
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>.
[RFC5441] Vasseur, JP., Ed., 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,
DOI 10.17487/RFC5441, April 2009,
<http://www.rfc-editor.org/info/rfc5441>.
Pouyllau, et al. Expires January 4, 2017 [Page 21]
Internet-Draft Extensions to PCEP for Enhanced errors July 2016
[RFC5455] Sivabalan, S., Ed., Parker, J., Boutros, S., and K.
Kumaki, "Diffserv-Aware Class-Type Object for the Path
Computation Element Communication Protocol", RFC 5455,
DOI 10.17487/RFC5455, March 2009,
<http://www.rfc-editor.org/info/rfc5455>.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Path Computation Element Communication Protocol (PCEP) for
Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April
2009, <http://www.rfc-editor.org/info/rfc5521>.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541,
DOI 10.17487/RFC5541, June 2009,
<http://www.rfc-editor.org/info/rfc5541>.
[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, DOI 10.17487/RFC5557,
July 2009, <http://www.rfc-editor.org/info/rfc5557>.
[RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of
Monitoring Tools for Path Computation Element (PCE)-Based
Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010,
<http://www.rfc-editor.org/info/rfc5886>.
[RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T.,
Ali, Z., and J. Meuric, "Extensions to the Path
Computation Element Communication Protocol (PCEP) for
Point-to-Multipoint Traffic Engineering Label Switched
Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010,
<http://www.rfc-editor.org/info/rfc6006>.
9.2. Informational References
[I-D.ietf-pce-vendor-constraints]
Zhang, F., Farrel, A., and G. Bernstein, "Conveying
Vendor-Specific Constraints in the Path Computation
Element Protocol", draft-ietf-pce-vendor-constraints-05
(work in progress), December 2011.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<http://www.rfc-editor.org/info/rfc4655>.
Pouyllau, et al. Expires January 4, 2017 [Page 22]
Internet-Draft Extensions to PCEP for Enhanced errors July 2016
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
Xian Zhang (Editor)
Huawei Technologies
F3-5-B R&D Center, Huawei Base Bantian, Longgang District
Shenzhen, Guangdong 518129
P.R.China
Email: zhang.xian@huawei.com
Pouyllau, et al. Expires January 4, 2017 [Page 23]
