< draft-ietf-pce-lsp-setup-type-07.txt   draft-ietf-pce-lsp-setup-type-08.txt >
PCE Working Group S. Sivabalan PCE Working Group S. Sivabalan
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track J. Tantsura Intended status: Standards Track J. Tantsura
Expires: June 22, 2018 Individual Expires: July 19, 2018 Individual
I. Minei I. Minei
Google, Inc. Google, Inc.
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
J. Hardwick J. Hardwick
Metaswitch Networks Metaswitch Networks
December 19, 2017 January 15, 2018
Conveying path setup type in PCEP messages Conveying path setup type in PCEP messages
draft-ietf-pce-lsp-setup-type-07 draft-ietf-pce-lsp-setup-type-08
Abstract Abstract
A Path Computation Element can compute Traffic Engineering paths (TE A Path Computation Element can compute Traffic Engineering (TE) paths
paths) through a network that are subject to various constraints. through a network that are subject to various constraints.
Currently, TE paths are Label Switched Paths (LSPs) which are set up Currently, TE paths are Label Switched Paths (LSPs) which are set up
using the RSVP-TE signaling protocol. However, other TE path setup using the RSVP-TE signaling protocol. However, other TE path setup
methods are possible within the PCE architecture. This document methods are possible within the PCE architecture. This document
proposes an extension to PCEP to allow support for different path proposes an extension to PCEP to allow support for different path
setup methods over a given PCEP session. setup methods over a given PCEP session.
Requirements Language
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].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 June 22, 2018. This Internet-Draft will expire on July 19, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Path Setup Type Capability TLV . . . . . . . . . . . . . . . 4 3. Path Setup Type Capability TLV . . . . . . . . . . . . . . . 4
4. Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . . 5 4. Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . . 5
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 7 7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 7
7.2. New Path Setup Type Registry . . . . . . . . . . . . . . 8 7.2. New Path Setup Type Registry . . . . . . . . . . . . . . 8
7.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 8 7.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 8
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
skipping to change at page 3, line 4 skipping to change at page 2, line 49
(PCC) and a Path Computation Element (PCE), or between a PCE and a (PCC) and a Path Computation Element (PCE), or between a PCE and a
PCE. A PCC requests a path subject to various constraints and PCE. A PCC requests a path subject to various constraints and
optimization criteria from a PCE. The PCE responds to the PCC with a optimization criteria from a PCE. The PCE responds to the PCC with a
hop-by-hop path in an Explicit Route Object (ERO). The PCC uses the hop-by-hop path in an Explicit Route Object (ERO). The PCC uses the
ERO to set up the path in the network. ERO to set up the path in the network.
[RFC8231] specifies extensions to PCEP that allow a PCC to delegate [RFC8231] specifies extensions to PCEP that allow a PCC to delegate
its LSPs to a PCE. The PCE can then update the state of LSPs its LSPs to a PCE. The PCE can then update the state of LSPs
delegated to it. In particular, the PCE may modify the path of an delegated to it. In particular, the PCE may modify the path of an
LSP by sending a new ERO. The PCC uses this ERO to re-route the LSP LSP by sending a new ERO. The PCC uses this ERO to re-route the LSP
in a make-before-break fashion. [I-D.ietf-pce-pce-initiated-lsp] in a make-before-break fashion. [RFC8281] specifies a mechanism
specifies a mechanism allowing a PCE to dynamically instantiate an allowing a PCE to dynamically instantiate an LSP on a PCC by sending
LSP on a PCC by sending the ERO and characteristics of the LSP. The the ERO and the characteristics of the LSP. The PCC creates the LSP
PCC creates the LSP using the ERO and other attributes sent by the using the ERO and other attributes sent by the PCE.
PCE.
So far, PCEP and its extensions have assumed that the TE paths are So far, PCEP and its extensions have assumed that the TE paths are
label switched and are established via the RSVP-TE protocol. label switched and are established via the RSVP-TE protocol.
However, other methods of LSP setup are possible in the PCE However, other methods of LSP setup are possible in the PCE
architecture (see [RFC4655] and [RFC4657]). This document introduces architecture (see [RFC4655] and [RFC4657]). This document
a TLV called "PATH-SETUP-TYPE-CAPABILITY" which allows a PCEP speaker generalizes PCEP to allow other LSP setup methods to be used. It
to announce the path setup types it supports when the PCEP session is defines two new TLVs and specifies the base procedures to facilitate
established. When a new path setup type (other than RSVP-TE) is this, as follows.
introduced for setting up a path, a path setup type code and,
optionally, a sub-TLV pertaining to the new path setup type will be
defined by the document that specifies the new path setup type.
When multiple path setup types are deployed in a network, a given o The PATH-SETUP-TYPE-CAPABILITY TLV, which allows a PCEP speaker to
PCEP session may have to simultaneously support more than one path announce which LSP setup methods it supports when the PCEP session
setup type. In this case, the intended path setup type needs to be is established.
explicitly indicated in the appropriate PCEP messages, unless the
path setup type is RSVP-TE (which is assumed to be the path setup o The PATH-SETUP-TYPE TLV, which allows a PCEP speaker to specify
type if no other setup type is indicated). This is so that both the which setup method should be used for a given LSP. When multiple
PCC and the PCE can take the necessary steps to set up the path. path setup types are deployed in a network, a given PCEP session
This document introduces a generic TLV called "PATH-SETUP-TYPE TLV" may have to simultaneously support more than one path setup type.
and specifies the base procedures to facilitate this operational A PCEP speaker uses the PATH-SETUP-TYPE TLV to explicitly indicate
model. the intended path setup type in the appropriate PCEP messages,
unless the path setup type is RSVP-TE (which is assumed to be the
path setup type if no other setup type is indicated). This is so
that both the PCC and the PCE can take the necessary steps to set
up the path.
This document defines a path setup type code for RSVP-TE. When a new
path setup type (other than RSVP-TE) is introduced for setting up a
path, a path setup type code and, optionally, a sub-TLV pertaining to
the new path setup type will be defined by the document that
specifies the new path setup type.
1.1. Requirements Language
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].
2. Terminology 2. Terminology
The following terminologies are used in this document: The following terminologies are used in this document:
ERO: Explicit Route Object. ERO: Explicit Route Object.
LSR: Label Switching Router. LSR: Label Switching Router.
PCC: Path Computation Client. PCC: Path Computation Client.
skipping to change at page 4, line 17 skipping to change at page 4, line 21
A PCEP speaker indicates which PSTs it supports during the PCEP A PCEP speaker indicates which PSTs it supports during the PCEP
initialization phase, as follows. When the PCEP session is created, initialization phase, as follows. When the PCEP session is created,
it sends an Open message with an OPEN object containing the PATH- it sends an Open message with an OPEN object containing the PATH-
SETUP-TYPE-CAPABILITY TLV. The format of this TLV is as follows. SETUP-TYPE-CAPABILITY TLV. The format of this TLV is as follows.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD1) | Length | | Type (TBD1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | PST length | | Reserved | Num of PSTs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | PST#1 | ... | PST#N | Padding |
// List of PSTs padded to 4-byte alignment (variable) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional sub-TLVs (variable) // // Optional sub-TLVs (variable) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PATH-SETUP-TYPE-CAPABILITY TLV Figure 1: PATH-SETUP-TYPE-CAPABILITY TLV
The TLV type is TBD1 (to be assigned by IANA). Its reserved field The TLV type is TBD1 (to be assigned by IANA). Its reserved field
MUST be set to zero. The other fields in the TLV are as follows. MUST be set to zero. The other fields in the TLV are as follows.
PST length: The length of the list of supported PSTs, in bytes, Length: The total length of the remainder of the TLV, that is,
excluding padding. excluding the Type and Length fields.
Number of PSTs: The number of PSTs in the following list, excluding
padding.
List of PSTs: A list of the PSTs that the PCEP speaker supports. List of PSTs: A list of the PSTs that the PCEP speaker supports.
Each PST is a single byte in length. Duplicate entries in this Each PST is a single byte in length. Duplicate entries in this
list MUST be ignored. The PCEP speaker MUST pad the list with list MUST be ignored. The PCEP speaker MUST pad the list with
zeros so that it is a muliple of four bytes in length. zeros so that it is a muliple of four bytes in length. This
document defines the following PST value:
* PST = 0: Path is setup using the RSVP-TE signaling protocol.
Optional sub-TLVs: A list of sub-TLVs associated with the supported Optional sub-TLVs: A list of sub-TLVs associated with the supported
PSTs. Each sub-TLV MUST obey the rules for TLV formatting defined PSTs. Each sub-TLV MUST obey the rules for TLV formatting defined
in ([RFC5440]). That is, each sub-TLV MUST be padded to a four in ([RFC5440]). That is, each sub-TLV MUST be padded to a four
byte alignment, and the length field of each sub-TLV MUST NOT byte alignment, and the length field of each sub-TLV MUST NOT
include the padding bytes. This document does not define any sub- include the padding bytes. This document does not define any sub-
TLVs. TLVs.
This document defines the following PST value: A PCEP speaker MUST check that this TLV is correctly formatted, as
follows. The TLV Length field MUST be equal to the size of the
o PST = 0: Path is setup using the RSVP-TE signaling protocol. appended sub-TLVs plus the size of the PST list (rounded up to the
nearest multiple of four) plus four bytes. The Number of PSTs field
The overall TLV length MUST be equal to the size of the appended sub- MUST be greater than zero. If a PCEP speaker receives a PATH-SETUP-
TLVs plus the PST length (rounded up to the nearest multiple of four) TYPE-CAPABILITY TLV which violates these rules, then the PCEP speaker
plus four bytes for the reserved field and PST length field. The PST MUST send a PCErr message with Error-Type = 10 (Reception of an
length field MUST be greater than zero. If a PCEP speaker receives a invalid object) and Error-Value = 11 (Malformed object) and MUST
PATH-SETUP-TYPE-CAPABILITY TLV which violates these rules, then the close the PCEP session. The PCEP speaker MAY include the malformed
PCEP speaker MUST send a PCErr message with Error-Type = 10 OPEN object in the PCErr message as well.
(Reception of an invalid object) and Error-Value = 11 (Malformed
object) and MUST close the PCEP session. The PCEP speaker MAY
include the malformed OPEN object in the PCErr message as well.
If a PCEP speaker receives an OPEN object with more than one PATH- If a PCEP speaker receives an OPEN object with more than one PATH-
SETUP-TYPE-CAPABILITY TLV then it MUST ignore all but the first SETUP-TYPE-CAPABILITY TLV then it MUST ignore all but the first
instance of this TLV. instance of this TLV.
The absence of the PATH-SETUP-TYPE-CAPABILITY TLV from the OPEN The absence of the PATH-SETUP-TYPE-CAPABILITY TLV from the OPEN
object is equivalent to a PATH-SETUP-TYPE-CAPABILITY TLV containing a object is equivalent to a PATH-SETUP-TYPE-CAPABILITY TLV containing a
single PST of 0 (RSVP-TE signaling protocol) and no sub-TLVs. A PCEP single PST of 0 (RSVP-TE signaling protocol) and no sub-TLVs. A PCEP
speaker MAY omit the PATH-SETUP-TYPE-CAPABILITY TLV if the only PST speaker MAY omit the PATH-SETUP-TYPE-CAPABILITY TLV if the only PST
it supports is RSVP-TE. If a PCEP speaker supports other PSTs it supports is RSVP-TE. If a PCEP speaker supports other PSTs
skipping to change at page 6, line 49 skipping to change at page 7, line 6
RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. If the RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. If the
PCE does not support the intended PST, it MUST send a PCErr message PCE does not support the intended PST, it MUST send a PCErr message
with Error-Type = 21 (Invalid traffic engineering path setup type) with Error-Type = 21 (Invalid traffic engineering path setup type)
and Error-Value = 1 (Unsupported path setup type) and close the PCEP and Error-Value = 1 (Unsupported path setup type) and close the PCEP
session. If the PSTs corresponding to the PCReq and PCRep messages session. If the PSTs corresponding to the PCReq and PCRep messages
do not match, the PCC MUST send a PCErr message with Error-Type = 21 do not match, the PCC MUST send a PCErr message with Error-Type = 21
(Invalid traffic engineering path setup type) and Error-Value = 2 (Invalid traffic engineering path setup type) and Error-Value = 2
(Mismatched path setup type) and close the PCEP session. (Mismatched path setup type) and close the PCEP session.
When a stateful PCE sends a PCUpd message ([RFC8231]) or a PCInitiate When a stateful PCE sends a PCUpd message ([RFC8231]) or a PCInitiate
message ([I-D.ietf-pce-pce-initiated-lsp]) to a PCC, it MUST include message ([RFC8281]) to a PCC, it MUST include the PATH-SETUP-TYPE TLV
the PATH-SETUP-TYPE TLV in the SRP object, unless the intended PST is in the SRP object, unless the intended PST is RSVP-TE, in which case
RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. If the it MAY omit the PATH-SETUP-TYPE TLV. If the PCC does not support the
PCC does not support the PST associated with the PCUpd or PCInitiate PST associated with the PCUpd or PCInitiate message, it MUST send a
message, it MUST send a PCErr message with Error-Type = 21 (Invalid PCErr message with Error-Type = 21 (Invalid traffic engineering path
traffic engineering path setup type) and Error-Value = 1 (Unsupported setup type) and Error-Value = 1 (Unsupported path setup type) and
path setup type) and close the PCEP session. close the PCEP session.
When a PCC sends a PCRpt message to a stateful PCE ([RFC8231]), it When a PCC sends a PCRpt message to a stateful PCE ([RFC8231]), it
MUST include the PATH-SETUP-TYPE TLV in the SRP object, unless the MUST include the PATH-SETUP-TYPE TLV in the SRP object, unless the
PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV.
The PCC MUST include the SRP object in the PCRpt message if the PST The PCC MUST include the SRP object in the PCRpt message if the PST
is not RSVP-TE, even when the SRP-ID-number is the reserved value of is not RSVP-TE, even when the SRP-ID-number is the reserved value of
0x00000000. If the PCRpt message is triggered by a PCUpd or 0x00000000. If the PCRpt message is triggered by a PCUpd or
PCInitiate message, then the PST that the PCC indicates in the PCRpt PCInitiate message, then the PST that the PCC indicates in the PCRpt
MUST match the PST that the stateful PCE intended in the PCUpd or MUST match the PST that the stateful PCE intended in the PCUpd or
PCInitiate. If it does not, then the PCE MUST send a PCErr message PCInitiate. If it does not, then the PCE MUST send a PCErr message
with Error-Type = 21 (Invalid traffic engineering path setup type) with Error-Type = 21 (Invalid traffic engineering path setup type)
and Error-Value = 2 (Mismatched path setup type) and close the PCEP and Error-Value = 2 (Mismatched path setup type) and close the PCEP
session. session.
6. Security Considerations 6. Security Considerations
The security considerations described in [RFC5440] and The security considerations described in [RFC5440] and [RFC8281] are
[I-D.ietf-pce-pce-initiated-lsp] are applicable to this applicable to this specification. No additional security measure is
specification. No additional security measure is required. required.
7. IANA Considerations 7. IANA Considerations
7.1. PCEP TLV Type Indicators 7.1. PCEP TLV Type Indicators
IANA is requested to confirm the early allocation of the following IANA is requested to confirm the early allocation of the following
code point in the PCEP TLV Type Indicators registry. code point in the PCEP TLV Type Indicators registry.
Value Description Reference Value Description Reference
skipping to change at page 9, line 13 skipping to change at page 9, line 13
- Edward Crabbe - Edward Crabbe
9. Acknowledgements 9. Acknowledgements
We like to thank Marek Zavodsky for valuable comments. We like to thank Marek Zavodsky for valuable comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-pce-pce-initiated-lsp]
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", draft-ietf-pce-pce-initiated-lsp-11 (work in
progress), October 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>. <https://www.rfc-editor.org/info/rfc5440>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231, Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017, DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>. <https://www.rfc-editor.org/info/rfc8231>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
10.2. Informative References 10.2. Informative References
[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>.
[RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, DOI 10.17487/RFC4657, September Requirements", RFC 4657, DOI 10.17487/RFC4657, September
 End of changes. 20 change blocks. 
71 lines changed or deleted 79 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/