draft-ietf-pce-enhanced-errors-07.txt   draft-ietf-pce-enhanced-errors-08.txt 
PCE Working Group H. Pouyllau PCE Working Group H. Pouyllau
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Updates: 5440 (if approved) R. Theillaud Updates: 5440 (if approved) R. Theillaud
Intended status: Standards Track Marben Products Intended status: Standards Track Marben Products
Expires: August 11, 2020 J. Meuric Expires: February 18, 2021 J. Meuric
Orange Orange
H. Zheng (Editor) H. Zheng (Editor)
X. Zhang X. Zhang
Huawei Technologies Huawei Technologies
February 8, 2020 August 17, 2020
Extensions to the Path Computation Element Communication Protocol for Extensions to the Path Computation Element Communication Protocol for
Enhanced Errors and Notifications Enhanced Errors and Notifications
draft-ietf-pce-enhanced-errors-07 draft-ietf-pce-enhanced-errors-08
Abstract Abstract
This document defines new error and notification TLVs for the PCE This document defines new error and notification TLVs for the PCE
Communication Protocol (PCEP) specified in RFC5440, and will update Communication Protocol (PCEP) specified in RFC5440, and will update
it. It identifies the possible PCEP behaviors in case of error or it. It identifies the possible PCEP behaviors in case of error or
notification. Thus, this draft defines types of errors and how they notification. Thus, this draft defines types of errors and how they
are disclosed to other PCEs in order to support predefined PCEP are disclosed to other PCEs in order to support predefined PCEP
behaviors. behaviors.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 11, 2020. This Internet-Draft will expire on February 18, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Error use-case . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Error use-case . . . . . . . . . . . . . . . . . . . . . 4
3.1.2. Notification use-case . . . . . . . . . . . . . . . . . . 4 3.1.2. Notification use-case . . . . . . . . . . . . . . . . . . 4
4. PCEP Behaviors . . . . . . . . . . . . . . . . . . . . . . . 4 4. PCEP Behaviors . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. PCEP Behaviors in Case of Error . . . . . . . . . . . . . . 5 4.1. PCEP Behaviors in Case of Error . . . . . . . . . . . . . . 5
4.2. PCEP Behaviors in Case of Notification . . . . . . . . . . 6 4.2. PCEP Behaviors in Case of Notification . . . . . . . . . . 6
4.3. PCE Peer Identification . . . . . . . . . . . . . . . . . . 6 4.3. PCE Peer Identification . . . . . . . . . . . . . . . . . . 6
5. PCEP Extensions for Error and Notification Handling . . . . . 7 5. PCEP Extensions for Error and Notification Handling . . . . . 6
5.1. Propagation TLV . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Propagation TLV . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Error-criticality TLV . . . . . . . . . . . . . . . . . . . 7 5.2. Error-criticality TLV . . . . . . . . . . . . . . . . . . . 7
5.3. Behaviors and TLV combinations . . . . . . . . . . . . . . 8 5.3. Behaviors and TLV combinations . . . . . . . . . . . . . . 7
5.4. Propagation Restrictions TLVs . . . . . . . . . . . . . . . 9 5.4. Propagation Restrictions TLVs . . . . . . . . . . . . . . . 8
5.4.1. Time-To-Live (TTL) TLV . . . . . . . . . . . . . . . . . 9 5.4.1. Time-To-Live (TTL) TLV . . . . . . . . . . . . . . . . . 9
5.4.2. DIFFUSION-LIST TLV . . . . . . . . . . . . . . . . . . . 9 5.4.2. DIFFUSION-LIST TLV . . . . . . . . . . . . . . . . . . . 9
5.4.3. Rules Applied to Existing Errors and Notifications . . . 11 5.4.3. Rules Applied to Existing Errors and Notifications . . . 10
6. Future Extension Guidelines . . . . . . . . . . . . . . . . . 15 6. Error Handling Guidelines for Future PCEP Extension . . . . . 14
7. Backward Compatibility Consideration . . . . . . . . . . . . 15 7. Backward Compatibility Consideration . . . . . . . . . . . . 15
8. Error and Notification Scenarios . . . . . . . . . . . . . . 15 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
8.1. Error Behavior Type 1 . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8.2. Error Behavior Type 2 . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.3. Error Behavior Type 4 . . . . . . . . . . . . . . . . . . . 17 10.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 16
8.4. Error Behavior Type 5 . . . . . . . . . . . . . . . . . . . 17 10.2. New DIFFUSION-LIST TLV . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 18 11.2. Informational References . . . . . . . . . . . . . . . . . 19
10.2. New DIFFUSION-LIST TLV . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
11.2. Informational References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Terminology 1. Terminology
PCE terminology is defined in [RFC4655]. PCE terminology is defined in [RFC4655].
PCEP Peer: An element involved in a PCEP session (i.e. a PCC or a PCEP Peer: An element involved in a PCEP session (i.e. a PCC or a
PCE). PCE).
Source PCC: the PCC, for a given path computation query, initiating Source PCC: the PCC, for a given path computation query, initiating
the first PCEP request, which may then trigger a chain of successive the first PCEP request, which may then trigger a chain of successive
skipping to change at page 3, line 47 skipping to change at page 3, line 40
In the context of path computation crossing different routing domains In the context of path computation crossing different routing domains
or autonomous systems, the number of different PCE system or autonomous systems, the number of different PCE system
specificities is potentially high, thus possibly leading to divergent specificities is potentially high, thus possibly leading to divergent
and unstable situations. Such phenomenon can also occur in and unstable situations. Such phenomenon can also occur in
homogeneous cases since PCE systems have their own policies that can homogeneous cases since PCE systems have their own policies that can
introduce differences in requests treatment even for requests having introduce differences in requests treatment even for requests having
the same destination. In order to generalize PCEP behaviors in the the same destination. In order to generalize PCEP behaviors in the
case of heterogeneous PCE systems, new objects have to be defined. case of heterogeneous PCE systems, new objects have to be defined.
Dealing with heterogeneity is a major challenge considering PCE Dealing with heterogeneity is a major challenge considering PCE
applicability, particularly in multi-layer, multi-domain and H-PCE applicability, particularly in multi-layer, multi-domain and H-PCE
contexts [I-D.ietf-pce-stateful-hpce]. Thus, extending such error contexts [RFC8751]. Thus, extending such error codes and PCEP
codes and PCEP behaviors accordingly would improve interoperability behaviors accordingly would improve interoperability among different
among different PCEP implementations and would solve some of these PCEP implementations and would solve some of these issues. However,
issues. However, some of them would still remain (e.g. the some of them would still remain (e.g. the divergences in request
divergences in request treatment introduced by different policies). treatment introduced by different policies).
The purpose of this draft is to identify and specify new optional The purpose of this draft is to identify and specify new optional
TLVs and objects in order to generalize PCEP behaviors. TLVs and objects in order to generalize PCEP behaviors.
3.1. Examples 3.1. Examples
The two following scenarios underline the need for a normalization of The two following scenarios underline the need for a normalization of
the PCEP behaviors according to existing error or notification types. the PCEP behaviors according to existing error or notification types.
3.1.1. Error use-case 3.1.1. Error use-case
skipping to change at page 13, line 9 skipping to change at page 12, line 40
a PCReq is recognized but not supported by a PCE. [RFC5455] does a PCReq is recognized but not supported by a PCE. [RFC5455] does
not state about the path computation request when such errors are not state about the path computation request when such errors are
met. Hence, both "Propagation" and "Error-criticality" TLVs COULD met. Hence, both "Propagation" and "Error-criticality" TLVs COULD
be used within such error-types' messages and set to any specified be used within such error-types' messages and set to any specified
values. values.
Error-type 13 on "BRPC procedure completion failure" is described Error-type 13 on "BRPC procedure completion failure" is described
in [RFC5441]. [RFC5441] states that in such cases, the PCErr in [RFC5441]. [RFC5441] states that in such cases, the PCErr
message MUST be relayed to the PCC. Hence, such messages SHOULD message MUST be relayed to the PCC. Hence, such messages SHOULD
contain a "Propagation" TLV and a DIFFUSION-LIST with a Target- contain a "Propagation" TLV and a DIFFUSION-LIST with a Target-
Type of 0 and corresponding adresses or with a Target-Type of 2. Type of 0 and corresponding addresses or with a Target-Type of 2.
It is not specified in [RFC5441] whether the path computation It is not specified in [RFC5441] whether the path computation
request should be canceled or not. If the procedure is not request should be canceled or not. If the procedure is not
supported, it does not necessarily imply to cancel the path supported, it does not necessarily imply to cancel the path
computation request if another procedure is able to read and write computation request if another procedure is able to read and write
VSPT objects. Thus, the "Error-criticality" TLV MAY be used with VSPT objects. Thus, the "Error-criticality" TLV MAY be used with
any value depending on the expected behavior. any value depending on the expected behavior.
Error-type 15 refers to "Global Concurrent Optimization Error" Error-type 15 refers to "Global Concurrent Optimization Error"
defined in [RFC5557]. [RFC5557] states that the corresponding defined in [RFC5557]. [RFC5557] states that the corresponding
global concurrent path optimization MUST be cancelled at the PCC. global concurrent path optimization MUST be cancelled at the PCC.
skipping to change at page 15, line 5 skipping to change at page 14, line 35
MAY also be used with such errors, depending on the detailed MAY also be used with such errors, depending on the detailed
security conditions. security conditions.
Error-type 26 of "Association Error " is described in [RFC8697] . Error-type 26 of "Association Error " is described in [RFC8697] .
Such errors occur when there is problem for LSP association. In Such errors occur when there is problem for LSP association. In
this case, the "Error-criticality" TLV should be set to either 0 this case, the "Error-criticality" TLV should be set to either 0
or 1 to indicate whether the request is still valid, with the PCEP or 1 to indicate whether the request is still valid, with the PCEP
session open. The "Propagation" TLV MAY also be used with such session open. The "Propagation" TLV MAY also be used with such
errors. errors.
6. Future Extension Guidelines 6. Error Handling Guidelines for Future PCEP Extension
Error and Notification handling in this document should be considered Error and Notification handling in this document should be considered
in PCE documents that include new errors and notifications. A in PCE documents that include new errors and notifications. A
requirement for the authors of these drafts is to evaluate the requirement for the authors of these drafts is to evaluate the
applicability of the procedure in this document and provide details applicability of the procedure in this document and provide details
about the "Error-criticality" TLV and "Propagation" TLV for errors about the "Error-criticality" TLV and "Propagation" TLV for errors
and notifications defined in the draft. Examples of this can be and notifications defined in the draft. Example text is provided as
found in section 5.4.3 of this document. follow.
Error-type XX (fill in value of the Error-type) of " XXXX " (fill in
name of the Error-type) is described in [RFCYYYY] (fill in the
document reference of the Error-type). Such errors occur when ZZZZ
(fill in typical scenario). In this case, the "Error-criticality"
TLV should be set to X (fill in the recommended value) to indicate
whether the request is still valid, with the PCEP session open. The
error messages SHOULD/MAY (select the mandatory level) contain a
"Propagation" TLV and a DIFFUSION-LIST with a Target-Type of A(fill
in the recommended value).
7. Backward Compatibility Consideration 7. Backward Compatibility Consideration
There would be backward compatibility issue if there are multiple There would be backward compatibility issue if there are multiple
PCEs with different level understanding of error message. In a PCEs with different level understanding of error message. In a
scenario that PCE(i) propagate the error message to PCE (i+1), it is scenario that PCE(i) propagate the error message to PCE (i+1), it is
possible that PCE (i+1) is not capable to extract the message possible that PCE (i+1) is not capable to extract the message
correctly, then such error message would be ignored and not be correctly, then such error message would be ignored and not be
further propagated. further propagated.
There can be potential approach to avoid these problem, such as There can be potential approach to avoid these problem, such as
recognizing the incapable PCE and avoiding propagation. However, recognizing the incapable PCE and avoiding propagation. However,
these approach is not in the scope of this document. these approach is not in the scope of this document.
8. Error and Notification Scenarios 8. Implementation Status
[Editor Note] This section will be moved to appendix for publication.
This section provides some examples depicting how the error 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).
8.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
| |
8.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
| |
8.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.
+-+-+ +-+-+-+-+ +-+-+ [NOTE TO RFC EDITOR : This whole section and the reference to
|PCC| |PCE|PCC| |PCE| [RFC7942] is to be removed before publication as an RFC]
+-+-+ +-+-+-+-+ +-+-+
|---- PCReq message-->| |
| | |
| |---- PCReq message--->|
| | |
| | |1) Parameter is
| | | not supported
| | |
| |<--- PCErr message----| Error-type=10
|<--- PCErr message---| |
| | |
8.4. Error Behavior Type 5 This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
In this example, PCEs are using the BRPC procedure to treat a path According to [RFC7942], "this will allow reviewers and working groups
computation request [RFC5441]. However, one of the PCEs does not to assign due consideration to documents that have the benefit of
support a parameter of the request. Hence, a PCErr message with running code, which may serve as evidence of valuable experimentation
error-type 4 and error-value 4 is sent by this PCE and has to be and feedback that have made the implemented protocols more mature.
forwarded to the source PCC. The PCEP-ERROR object includes a It is up to the individual working groups to use this information as
"Propagation" TLV at value 1 and "Error-criticality" TLV at value 1 they see fit".
and the message is propagated backwardly to the source PCC.
Consequently, the request is cancelled.
+-+-+ +-+-+-+-+ +-+-+ At the time of posting the -08 version of this document, there are no
|PCC| |PCE|PCC| |PCE| known implementations of this mechanism. It is believed that two
+-+-+ +-+-+-+-+ +-+-+ vendors are considering prototype implementations, but these plans
|---- PCReq message-->| | are too vague to make any further assertions.
| | |
| |---- PCReq message--->|
| | |
| | |1) Unsupported
| | | Parameter BRPC
| | |2) Path
| | | computation
| | | request X
| | | cancelled
| |<--- PCErr message----| Error-type=4
|<--- PCErr message---| |
| | |
9. Security Considerations 9. Security Considerations
Within the introduced set of TLVs, the "Propagation" TLV affects PCEP Within the introduced set of TLVs, the "Propagation" TLV affects PCEP
security considerations since it forces propagation behaviors. Thus, security considerations since it forces propagation behaviors. Thus,
a PCEP implementation SHOULD activate stateful mechanism when a PCEP implementation SHOULD activate stateful mechanism when
receiving PCEP-ERROR or NOTIFICATION object including this TLV in receiving PCEP-ERROR or NOTIFICATION object including this TLV in
order to avoid DoS attacks. order to avoid DoS attacks.
10. IANA Considerations 10. IANA Considerations
skipping to change at page 21, line 32 skipping to change at page 19, line 26
[RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
Dhody, D., and Y. Tanaka, "Path Computation Element Dhody, D., and Y. Tanaka, "Path Computation Element
Communication Protocol (PCEP) Extensions for Establishing Communication Protocol (PCEP) Extensions for Establishing
Relationships between Sets of Label Switched Paths Relationships between Sets of Label Switched Paths
(LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020,
<https://www.rfc-editor.org/info/rfc8697>. <https://www.rfc-editor.org/info/rfc8697>.
11.2. Informational References 11.2. Informational References
[I-D.ietf-pce-stateful-hpce]
Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King,
"Hierarchical Stateful Path Computation Element (PCE)",
draft-ietf-pce-stateful-hpce-15 (work in progress),
October 2019.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
[RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific
Constraints in the Path Computation Element Communication Constraints in the Path Computation Element Communication
Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015,
<https://www.rfc-editor.org/info/rfc7470>. <https://www.rfc-editor.org/info/rfc7470>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8751] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King,
"Hierarchical Stateful Path Computation Element (PCE)",
RFC 8751, DOI 10.17487/RFC8751, March 2020,
<https://www.rfc-editor.org/info/rfc8751>.
Appendix A. Error and Notification Scenarios
This section provides some examples depicting how the error 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).
A.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
| |
A.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
| |
A.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.
+-+-+ +-+-+-+-+ +-+-+
|PCC| |PCE|PCC| |PCE|
+-+-+ +-+-+-+-+ +-+-+
|---- PCReq message-->| |
| | |
| |---- PCReq message--->|
| | |
| | |1) Parameter is
| | | not supported
| | |
| |<--- PCErr message----| Error-type=10
|<--- PCErr message---| |
| | |
A.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---| |
| | |
Authors' Addresses Authors' Addresses
Helia Pouyllau Helia Pouyllau
Alcatel-Lucent Alcatel-Lucent
Route de Villejust Route de Villejust
NOZAY 91620 NOZAY 91620
FRANCE FRANCE
Phone: + 33 (0)1 30 77 63 11 Phone: + 33 (0)1 30 77 63 11
Email: helia.pouyllau@alcatel-lucent.com Email: helia.pouyllau@alcatel-lucent.com
Remi Theillaud Remi Theillaud
Marben Products Marben Products
176 rue Jean Jaures 176 rue Jean Jaures
Puteaux 92800 Puteaux 92800
FRANCE FRANCE
Phone: + 33 (0)1 79 62 10 22 Phone: + 33 (0)1 79 62 10 22
Email: remi.theillaud@marben-products.com Email: remi.theillaud@marben-products.com
Julien Meuric Julien Meuric
skipping to change at page 22, line 32 skipping to change at page 23, line 23
Julien Meuric Julien Meuric
Orange Orange
2, avenue Pierre Marzin 2, avenue Pierre Marzin
Lannion 22307 Lannion 22307
FRANCE FRANCE
Email: julien.meuric@orange.com Email: julien.meuric@orange.com
Haomian Zheng (Editor) Haomian Zheng (Editor)
Huawei Technologies Huawei Technologies
H1-1-A043S Huawei Industrial Base, Songshanhu H1, Xiliu Beipo Village, Songshan Lake,
Dongguan, Guangdong 523808 Dongguan, Guangdong 523808
P.R.China China
Email: zhenghaomian@huawei.com Email: zhenghaomian@huawei.com
Xian Zhang Xian Zhang
Huawei Technologies Huawei Technologies
G1-2, Huawei Industrial Base, Bantian, Longgang District A10, Huawei Industrial Base, Bantian, Longgang District
Shenzhen, Guangdong 518129 Shenzhen, Guangdong 518129
P.R.China P.R.China
Email: zhang.xian@huawei.com Email: zhang.xian@huawei.com
 End of changes. 25 change blocks. 
160 lines changed or deleted 198 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/