draft-ietf-pce-comm-protocol-gen-reqs-00.txt   draft-ietf-pce-comm-protocol-gen-reqs-01.txt 
IETF Internet Draft PCE Working Group Jerry Ash (AT&T) IETF Internet Draft PCE Working Group Jerry Ash (AT&T)
Proposed Status: Informational Editor Proposed Status: Informational Editor
Expires: November 2005 J.L. Le Roux (France Telecom) Expires: January 2006 J.L. Le Roux (France Telecom)
Editor Editor
May 2005 July 2005
draft-ietf-pce-comm-protocol-gen-reqs-00.txt draft-ietf-pce-comm-protocol-gen-reqs-01.txt
PCE Communication Protocol Generic Requirements PCE Communication Protocol Generic Requirements
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 26, 2005. This Internet-Draft will expire on November 26, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
Constraint-based path computation is a fundamental building block for The PCE model is described in the "PCE Architecture" document and
traffic engineering systems such as multiprotocol label switching facilitates path computation requests from Path Computation Clients
(MPLS) and generalized multiprotocol label switching (GMPLS) (PCCs) to Path Computation Elements (PCEs). This document specifies
networks. Path computation in large, multi-domain or multi-layer
networks is highly complex and may require special computational
components and cooperation between the different network domains.
There are multiple components in the Path Computation Element (PCE)-
based path computation model, including PCE discovery and the PCE
communication protocol. The PCE model is described in the "PCE
Architecture" document and facilitates path computation requests from
Path Computation Clients (PCCs) to PCEs. This document specifies
generic requirements for a communication protocol between PCCs and generic requirements for a communication protocol between PCCs and
PCEs, and between PCEs where cooperation between PCEs is desirable. PCEs, and also between PCEs where cooperation between PCEs is
Subsequent documents will specify application-specific requirements desirable. Subsequent documents will specify application-specific
for the PCE communication protocol. requirements for the PCE communication protocol.
Table of Contents Table of Contents
1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Overview of PCE Communication Protocol . . . . . . . . . . . . . 4 5. Overview of PCE Communication Protocol (PCEP) . . . . . . . . . . 4
6. PCE Communication Protocol Generic Requirements . . . . . . . . . 5 6. PCE Communication Protocol Generic Requirements . . . . . . . . . 5
6.1 Basic Protocol Requirements . . . . . . . . . . . . . . . . . 5 6.1 Basic Protocol Requirements . . . . . . . . . . . . . . . . . 8
6.1.1 Client-Server Communication . . . . . . . . . . . . . . 6 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication . . . 8
6.1.2 PCC-PCE and PCE-PCE Communication . . . . . . . . . . . 7 6.1.2 Client-Server Communication . . . . . . . . . . . . . . 8
6.1.3 Reliable Message Exchange . . . . . . . . . . . . . . . 7 6.1.3 Transport . . . . . . . . . . . . . . . . . . . . . . . 8
6.1.4 Secure Message Exchange . . . . . . . . . . . . . . . . 8 6.1.4 Path Computation Requests . . . . . . . . . . . . . . . 8
6.1.5 Request Prioritization . . . . . . . . . . . . . . . . 8 6.1.5 Path Computation Responses . . . . . . . . . . . . . . 9
6.1.6 Unsolicited Notifications . . . . . . . . . . . . . . . 8 6.1.6 Cancellation of Pending Requests . . . . . . . . . . . 10
6.1.7 Asynchronous Communication . . . . . . . . . . . . . . 8 6.1.7 Multiple Requests and Responses . . . . . . . . . . . . 10
6.1.8 Communication Overhead Minimization . . . . . . . . . . 9 6.1.8 Reliable Message Exchange . . . . . . . . . . . . . . . 11
6.1.9 Extensibility . . . . . . . . . . . . . . . . . . . . . 9 6.1.9 Secure Message Exchange . . . . . . . . . . . . . . . . 11
6.1.10 Scalability . . . . . . . . . . . . . . . . . . . . . 9 6.1.10 Request Prioritization . . . . . . . . . . . . . . . . 11
6.2 Deployment Support Requirements . . . . . . . . . . . . . . . 10 6.1.11 Unsolicited Notifications . . . . . . . . . . . . . . 12
6.2.1 Support for Various Service Provider Environments and 6.1.12 Asynchronous Communication . . . . . . . . . . . . . . 12
Applications . . . . . . . . . . . . . . . . . . . . . 10 6.1.13 Communication Overhead Minimization . . . . . . . . . 12
6.2.2 Confidentiality . . . . . . . . . . . . . . . . . . . . 10 6.1.14 Extensibility . . . . . . . . . . . . . . . . . . . . 12
6.3 Detection & Recovery Requirements . . . . . . . . . . . . . . 10 6.1.15 Scalability . . . . . . . . . . . . . . . . . . . . . 13
6.3.1 Aliveness Detection . . . . . . . . . . . . . . . . . . 10 6.1.16 Constraints . . . . . . . . . . . . . . . . . . . . . 13
6.3.2 PCC/PCE Failure Response . . . . . . . . . . . . . . . 10 6.2 Deployment Support Requirements . . . . . . . . . . . . . . . 14
6.3.3 Protocol Recovery . . . . . . . . . . . . . . . . . . . 11 6.2.1 Support for Different Service Provider Environments . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 11 6.2.2 Policy Support . . . . . . . . . . . . . . . . . . . . 14
8. Manageability Considerations . . . . . . . . . . . . . . . . . . 11 6.3 Detection & Recovery Requirements . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 12 6.3.1 Aliveness Detection . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 6.3.2 PCC/PCE Failure Response . . . . . . . . . . . . . . . 15
11. Normative References . . . . . . . . . . . . . . . . . . . . . . 12 6.3.3 Protocol Recovery . . . . . . . . . . . . . . . . . . . 15
12. Informational References . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 15
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 8. Manageability Considerations . . . . . . . . . . . . . . . . . . 16
14. Intellectual Property Considerations . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
11. Normative References . . . . . . . . . . . . . . . . . . . . . . 16
12. Informational References . . . . . . . . . . . . . . . . . . . . 17
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property Statement . . . . . . . . . . . . . . . . . . 18
Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . . 18
Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Contributors 1. Contributors
This document is the result of the PCE Working Group PCE This document is the result of the PCE Working Group PCE
communication protocol requirements design team joint effort. The communication protocol (PCEP) requirements design team joint effort.
following are the design team member authors that contributed to the The following are the design team member authors that contributed to
present document: the present document:
Jerry Ash (AT&T) Jerry Ash (AT&T)
Alia Atlas (Avici) Alia Atlas (Avici)
Arthi Ayyangar (Juniper) Arthi Ayyangar (Juniper)
Nabil Bitar (Verizon) Nabil Bitar (Verizon)
Igor Bryskin (Independent Consultant) Igor Bryskin (Independent Consultant)
Dean Cheng (Cisco) Dean Cheng (Cisco)
Durga Gangisetti (MCI) Durga Gangisetti (MCI)
Kenji Kumaki (KDDI) Kenji Kumaki (KDDI)
Jean-Louis Le Roux (France Telecom) Jean-Louis Le Roux (France Telecom)
skipping to change at page 3, line 32 skipping to change at page 3, line 32
Raymond Zhang (BT Infonet) Raymond Zhang (BT Infonet)
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Introduction 3. Introduction
The path computation element (PCE) capability [PCE-ARCH] supports The path computation element (PCE) [PCE-ARCH] supports requests for
requests for path computation issued by a path computation client path computation issued by a path computation client (PCC), which may
(PCC), which may be co-located or remote from a PCE. When the PCC is be 'composite' (co-located) or 'external' (remote) from a PCE. When
remote from the PCE, a request/response communications protocol is the PCC is external from the PCE, a request/response communication
required to carry the path computation request and return the protocol is required to carry the path computation request and return
response. In order for the PCC and PCE to communicate, the PCC must the response. In order for the PCC and PCE to communicate, the PCC
discover the location of the PCE, as described in [PCE-DISC-REQ]. must know the location of the PCE: PCE discovery is described in
The PCE operates on a network graph in order to compute paths based [PCE-DISC-REQ]. The PCE operates on a network graph in order to
on the path computation request issued by the PCC, which will compute paths based on the path computation request issued by the
normally include the source, destination, and a set of constraints. PCC. The path computation request will normally include the source
The PCE response includes the computed paths or the reason for a and destination of the paths to be computed, and a set of constraints
failed computation. to be applied during the computation. The PCE response includes the
computed paths or the reason for a failed computation.
This document lists a set of generic requirements for the PCE This document lists a set of generic requirements for the PCEP.
communication protocol, where the PCE communications protocol Application-specific requirements are beyond the scope of this
solution MUST satisfy these requirements. Application-specific document, and will be addressed in separate documents.
requirements are beyond the scope of this document, and will be
addressed in separate documents.
4. Terminology 4. Terminology
Domain: any collection of network elements within a common sphere of Domain: any collection of network elements within a common sphere of
address management or path computational responsibility. Examples of address management or path computational responsibility. Examples of
domains include IGP areas, Autonomous Systems (ASs), multiple ASs domains include IGP areas, Autonomous Systems (ASs), multiple ASs
within a service provider network, or multiple ASs across multiple within a service provider network, or multiple ASs across multiple
service provider networks. service provider networks.
GMPLS: generalized multiprotocol label switching GMPLS: Generalized Multiprotocol Label Switching
LSP: MPLS Label Switched Path. LSP: MPLS Label Switched Path.
MPLS: multiprotocol label switching MPLS: multiprotocol label switching
PCC: Path Computation Client: any client application requesting a PCC: Path Computation Client: any client application requesting a
Path computation to be performed by the PCE. Path computation to be performed by the PCE.
PCE: Path Computation Element: an entity (component, application or PCE: Path Computation Element: an entity (component, application or
network node) that is capable of computing a network path or route network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints (see based on a network graph and applying computational constraints (see
further description in [PCE-ARCH]). further description in [PCE-ARCH]).
TED: Traffic Engineering Database, which contains the topology and TED: Traffic Engineering Database, which contains the topology and
resource information of the network or network segment used by a PCE. resource information of the network or network segment used by a PCE.
TE LSP: Traffic Engineering MPLS Label Switched Path. TE LSP: Traffic Engineering MPLS Label Switched Path.
See [PCE-ARCH] for further definitions of terms. See [PCE-ARCH] for further definitions of terms.
5. Overview of PCE Communication Protocol 5. Overview of PCE Communication Protocol (PCEP)
In the PCE model, path computation requests are issued by a PCC In the PCE model, path computation requests are issued by a PCC
to a PCE that may be co-located or situated at a remote site. If to a PCE that may be composite (co-located) or external (remote).
the PCC and PCE are not co-located a request/response communications If the PCC and PCE are not composite, a request/response
protocol is required to carry the request and return the response. If communication protocol is required to carry the request and return
the PCC and PCE are co-located a communications protocol is not the response. If the PCC and PCE are composite, a communication
required, but implementations may choose to utilize a protocol for protocol is not required, but implementations may choose to utilize
exchanges between the components. a protocol for exchanges between the components.
In order that a PCC and PCE can communicate, the PCC must know the In order that a PCC and PCE can communicate, the PCC must know the
location of the PCE. This can be configured or discovered. The PCE location of the PCE. This can be configured or discovered. The PCE
discovery mechanism is out of scope of this document, but discovery mechanism is out of scope of this document, but
requirements are documented in [PCE-DISC-REQ]. requirements are documented in [PCE-DISC-REQ].
The PCE operates on a network graph built from the TED in order to The PCE operates on a network graph built from the TED in order to
compute paths. The mechanism by which the TED is populated is out of compute paths. The mechanism by which the TED is populated is out of
scope for the PCE Communications Protocol. scope for the PCEP.
A path computation request issued by the PCC will include a A path computation request issued by the PCC includes a specification
specification of the path(s) needed. The information supplied will of the path(s) needed. The information supplied includes, at a
include at a minimum the source and destination for the path(s), but minimum, the source and destination for the paths, but may also
may also include a set of further requirements (known as constraints) include a set of further requirements (known as constraints) as
as described in Section 6. described in Section 6.
The response from the PCE may be positive in which case it will The response from the PCE may be positive in which case it will
include the paths that have been computed. If the computation fails include the paths that have been computed. If the computation fails
or cannot be performed, a negative response is required with an or cannot be performed, a negative response is required with an
indication of the type of and reason(s) for the failure. A negative indication of the type of failure.
response may also include further details of the reason(s) for the
failure, and potentially advice about which constraints might be
relaxed to be more likely to achieve a positive result. That is, the
PCE SHOULD provide sufficient information for the PCC to know whether
it has to relax constraints or query another PCE.
A request/response protocol is also required for a PCE to communicate A request/response protocol is also required for a PCE to communicate
path computation requests to another PCE and for the PCE to return path computation requests to another PCE and for that PCE to return
the path computation response. As described in [PCE-ARCH], there is the path computation response. As described in [PCE-ARCH], there is
no reason to assume that two different protocols are needed, and this no reason to assume that two different protocols are needed, and this
document assumes that a single protocol will satisfy all requirements document assumes that a single protocol will satisfy all requirements
for PCC-PCE and PCE-PCE communications. for PCC-PCE and PCE-PCE communication.
[PCE-ARCH] describes four models of PCE: composite, external, [PCE-ARCH] describes four models of PCE: composite, external,
multiple PCE path computation and multiple PCE path computation with multiple PCE path computation, and multiple PCE path computation with
inter-PCE communication. In all cases except the composite PCE inter-PCE communication. In all cases except the composite PCE model,
model, a communication protocol is required. The requirements a PCEP is required. The requirements defined in this document are
defined in this document therefore are applicable to all models applicable to all models described in the [PCE-ARCH] except the
described in the [PCE-ARCH] except the composite PCE model. composite PCE model.
6. PCE Communication Protocol Generic Requirements 6. PCE Communication Protocol Generic Requirements
The designers of a PCE communication protocol MUST take the [This paragraph to be deleted after successful completion and before
requirements set out in this document and discuss them widely within publication as an RFC.]
the IETF and particularly within the Applications Area to determine
whether a suitable protocol already exists. The results of this The designers of a PCEP MUST take the requirements set out in this
investigation MUST be published on the PCE mailing list. document and discuss them widely within the IETF and particularly
within the Applications Area to determine whether a suitable protocol
already exists. The results of this investigation MUST be published
on the PCE mailing list.
The following is a summary of the requirements in Section 6:
Requirement Necessity Ref.
------------------------------------------------------------------
Commonality of PCC-PCE and PCE-PCE Communication MUST 6.1.1
Client-Server Communication MUST 6.1.2
Support PCC/PCE request message to request path
computation MUST 6.1.2
Support PCE response message with computed path MUST 6.1.2
Support unsolicited communication PCE-PCC SHOULD 6.1.2
Maintain PCC-PCE session NON-RQMT 6.1.2
Use of Existing Transport Protocol MAY 6.1.3
Transport protocol satisfy reliability & security
requirements MAY 6.1.3
Transport Protocol Limits Size of Message MUST NOT 6.1.3
Support Path Computation Requests MUST 6.1.4
Include source & destination
Support path constraints (e.g., bandwidth, hops,
affinities) to include/exclude MUST 6.1.4
Support path reoptimization & inclusion of a
previously computed path MUST 6.1.4
Allow to select/prefer from advertised list of
standard objective functions/options MUST 6.1.4
Allow to customize objective function/options MUST 6.1.4
Request a less-constrained path MAY 6.1.4
Support request for less-constrained path,
including constraint-relaxation policy's SHOULD 6.1.4
Support Path Computation Responses MUST 6.1.5
Negative response support reasons for failure,
constraints to relax to achieve positive result,
less-constrained path reflecting
constraint-relaxation policy's SHOULD 6.1.5
Cancellation of Pending Requests MUST 6.1.6
Multiple Requests and Responses MUST 6.1.7
Limit by configuration number of requests within
a message MUST 6.1.7
Support multiple computed paths in response MUST 6.1.7
Support "continuation correlation" where related
requests or computed paths cannot fit within one
message MUST 6.1.7
Maximum message size & maximum number of requests
per message exchanged through PCE messages to PCC,
or indicated in request message MAY 6.1.7
Reliable Message Exchange (achieved by PCEP
itself or transport protocol MUST 6.1.8
Allow detection & recovery of lost messages to
occur quickly & not impede operation of PCEP MUST 6.1.8
Handle overload situations without significant
decrease in performance, e.g., through throttling
of requests MUST 6.1.8
Provide acknowledged message delivery with
retransmission, in order message delivery or
facility to restore order, message corruption
detection, flow control & back-pressure to
throttle requests, rapid partner failure
detection, informed rapidly of failure of PCE-PCC
connection MUST 6.1.8
Functionality added to PCEP if transport protocol
provides it SHOULD NOT 6.1.8
Secure Message Exchange (provided by PCEP or
transport protocol MUST 6.1.9
Support mechanisms to prevent spoofing (e.g.,
authentication), snooping (e.g., encryption),
DOS attacks MUST 6.1.9
Request Prioritization MUST 6.1.10
Unsolicited Notifications SHOULD 6.1.11
Allow Asynchronous Communication MUST 6.1.12
PCC Has to Wait for Response Before Making
Another Request MUST NOT 6.1.12
Allow order of responses differ from order of
Requests MUST 6.1.12
Communication Overhead Minimization SHOULD 6.1.13
Give particular attention to message size SHOULD 6.1.13
Extensibility without requiring modifications to
the protocol MUST 6.1.14
Easily extensible to support intra-area,
inter-area, inter-AS intra provider, inter-AS
inter-provider, multi-layer path & virtual network
topology path computation MUST 6.1.14
Easily extensible to support future applications
not in scope (e.g., P2MP path computations) SHOULD 6.1.14
Scalability at least linearly with increase in
number of PCCs, PCEs, PCCs communicating with a
single PCE, PCEs communicated to by a single PCC,
PCEs communicated to by another PCE, domains, path
requests, handling bursts of requests MUST 6.1.15
Support Path Computation Constraints MUST 6.1.16
Support Different Service Provider Environments
(e.g., MPLS-TE and GMPLS networks, centralized &
distributed PCE path computation, single &
multiple PCE path computation) MUST 6.2.1
Policy Support for policies to accept/reject
requests, PCC to determine reason for rejection,
notification of policy violation MUST 6.2.2
Aliveness Detection of PCCs/PCEs, partner failure
Detection MUST 6.3.1
PCC/PCE Failure Response procedures defined for
PCE/PCC failures, PCC able to clear pending
Request MUST 6.3.2
PCC select another PCE upon detection of PCE
failure MUST 6.3.2
PCE able to clear pending requests from a PCC
(e.g. when it detects PCC failure or request
buffer full) MUST 6.3.2
Protocol Recovery support resynchronization of
information & requests between sender & receiver MUST 6.3.3
Minimize repeat data transfer, allow PCE to
respond to computation requests issued before
failure without requests being re-issued SHOULD 6.3.3
Stateful PCE able to resynchronize/recover
states (e.g., LSP status, paths) after restart SHOULD 6.3.3
6.1 Basic Protocol Requirements 6.1 Basic Protocol Requirements
6.1.1 Client-Server Communication 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication
A single protocol MUST be defined for PCC-PCE and PCE-PCE
communication. A PCE requesting a path from another PCE can be
considered as a PCC.
6.1.2 Client-Server Communication
PCC-PCE and PCE-PCE communication is by nature client-server based. PCC-PCE and PCE-PCE communication is by nature client-server based.
The communication protocol MUST allow for a PCC or a PCE to send a The PCEP MUST allow for a PCC or a PCE to send a request message to a
path request message to a PCE, and for a PCE to reply with a path PCE to request path computation, and for a PCE to reply with a
response message to the requesting PCC or PCE, once the path has been response message to the requesting PCC or PCE, once the path has been
computed. In addition to this request-response model, there may be computed.
cases where there is unsolicited communication from the PCE to PCC
(see Requirement 6.1.6).
The protocol MUST be capable of returning any explicit path that In addition to this request-response mode, there may be cases where
would be acceptable for use for MPLS and GMPLS LSPs once converted to there is unsolicited communication from the PCE to PCC (see
an Explicit Route Object for use in RSVP-TE signaling. Note that the Requirement 6.1.6).
resultant path(s) may be made up of a set of strict or loose hops, or
any combination of strict and loose hops. Moreover, a hop may have
the form of a non-explicit abstract node. See RFC 3209 for the
definition of strict hop, loose hop, and abstract node.
It MUST be possible to send multiple path computation requests, There is no requirement to maintain a session or association between
correlated or not, within the same path request message. There are communicating PCC and PCE, nor between communicating PCEs. The
various motivations for doing so (optimality, path diversity, etc.). request/response exchange defines a limited association between
requester and responder.
It MUST be possible to limit by configuration the number of requests 6.1.3 Transport
that can be carried within a single message. The transport protocol
MUST allow sending unlimited size messages, but MUST be able to limit
message size, to avoid a big message from unduly delaying a small
message. Maximum message size MAY be negotiated at session
initialization. If the number of correlated requests exceeds the
maximum message size, then separate messages MAY be sent with an
indication that they are correlated.
The path request message MUST include, at least, a source and a The PCEP may utilize an existing transport protocol or operate
destination, and MAY include a set of one or more path constraints, directly over IP.
such as the requested bandwidth or resources (hops, affinities, etc.)
to include/exclude (e.g., a PCC requests the PCE to exclude points of
failure in the computation of the new path if an LSP setup fails).
The path request message MUST support the ability to prefer/customize If a transport protocol is used, it may be used to satisfy some
various path computation objective functions, policies and requirements stated in other sections of this document (for example,
optimization criteria. For example, a PCC may be aware of and would reliability and security).
like to choose from among various objective functions that a PCE may
offer, and the PCE communication protocol SHOULD allow this to be
specified per path computation request. This capability to prefer
certain objective functions depends on the fact that the PCE
advertises this to a PCC or that the PCC requests one of a set of
objective functions defined as a minimal subset that MUST be
supported by any PCE.
The requester MUST be allowed to select from the advertised list or If a transport protocol is used, it MUST NOT limit the size of the
minimal subset of standard objective functions and functional message used by the PCEP.
Where requirements expressed in this document match the function of
existing transport protocols, consideration MUST be given to the use
of those protocols.
6.1.4 Path Computation Requests
The request message MUST include, at least, a source and a
destination. The message MUST support the inclusion of a set of one
or more path constraints, such as the requested bandwidth or
resources (hops, affinities, etc.) to include/exclude (e.g., a PCC
requests the PCE to exclude points of failure in the computation of
the new path if an LSP setup fails). The actual inclusion of
constraints is a choice for the PCC issuing the request.
A list of core constraints that MUST be supported by the PCEP is
supplied in Section 6.1.16. Specification of constraints must be
future-proofed as described in Section 6.1.14.
The path computation request message MUST support TE LSP path
reoptimization and the inclusion of a previously computed path. This
will help ensure optimal routing of a reoptimized path, since it will
allow the PCE to avoid double bandwidth accounting and help reduce
blocking issues.
The requester MUST be allowed to select or prefer from an advertised
list or minimal subset of standard objective functions and functional
options. The requester SHOULD also be able to select a options. The requester SHOULD also be able to select a
vendor-specific or experimental objective function or functional vendor-specific or experimental objective function or functional
option. Furthermore, the requester MUST be allowed to customize the option. Furthermore, the requester MUST be allowed to customize the
objective function/options in use. That is, individual objective objective function/options in use. That is, individual objective
functions will often have parameters to be set in the request from functions will often have parameters to be set in the request from
PCC to PCE. Specification of objective functions and objective PCC to PCE. Specification of objective functions and objective
function parameters is required in the protocol extensibility function parameters is required in the protocol extensibility
specified in Section 6.1.9. specified in Section 6.1.14.
If a PCC selects an objective function that the PCE does not support, If a PCC selects an objective function that the PCE does not support,
the PCE response MUST be negative. the PCE response MUST be negative.
Note that a PCC MAY send a request that is based on the set of TE Note that a PCC MAY send a request that is based on the set of TE
parameters carried by the MPLS/GMPLS LSP setup signaling protocol, parameters carried by the MPLS/GMPLS LSP setup signaling protocol,
and as long as those parameters are satisfied, the PCC MAY not care and as long as those parameters are satisfied, the PCC MAY not care
about which objective function is used. Also, the PCE MAY execute about which objective function is used. Also, the PCE MAY execute
objective functions not advertised to the PCC, for example, policy objective functions not advertised to the PCC, for example, policy
based routing path computation for load balancing instructed by the based routing path computation for load balancing instructed by the
management plane. management plane.
As also discussed in Section 6.1.5 (Path Computation Responses), a
PCC MAY request a less-constrained TE LSP path, and the path
computation request MAY include one or more constraint-relaxation
policy's. The Request message SHOULD support the inclusion of a
request for a less-constrained path, including one or more
constraint-relaxation policy's.
6.1.5 Path Computation Responses
The response message MUST allow returning various elements including,
at least, the computed path(s).
The protocol MUST be capable of returning any explicit path that
would be acceptable for use for MPLS and GMPLS LSPs once converted to
an Explicit Route Object for use in RSVP-TE signaling. Note that the
resultant path(s) may be made up of a set of strict or loose hops, or
any combination of strict and loose hops. Moreover, a hop may have
the form of a non-simple abstract node. See RFC 3209 for the
definition of strict hop, loose hop, and abstract node.
A positive response from the PCE will include the paths that have
been computed. When a Path satisfying the constraints cannot be
found, or if the computation fails or cannot be performed, a
negative response MUST be sent. This response MAY include further
details of the reason(s) for the failure, and potentially advice
about which constraints might be relaxed to be more likely to achieve
a positive result. Optionally the PCE MAY provide a
less-constrained path taking into account one or more relaxation
policy's that could potentially be provided by the PCC in the
request. As discussed in Section 6.1.4, a PCC MAY optionally
request a less-constrained TE LSP path, and the path computation
request MAY also include one or more constraint-relaxation policy's.
Hence the Response message SHOULD support the inclusion of the
reasons for a failure, and the inclusion of less-constrained path.
The Request message SHOULD support the inclusion of a request for a
less-constrained path, including one or more constraint-relaxation
policy's.
6.1.6 Cancellation of Pending Requests
A PCC or PCE MUST be able to cancel a pending request. A PCC or PCE MUST be able to cancel a pending request.
The path response message MUST allow returning various elements 6.1.7 Multiple Requests and Responses
including, at least, the computed path. It MUST be possible to
return multiple paths within the same path response message,
corresponding either to the same request (e.g. load balancing) or to
distinct requests of the same path request message or distinct path
request messages.
6.1.2 PCC-PCE and PCE-PCE Communication It MUST be possible to send multiple path computation requests,
correlated or not, within the same request message. There are
various motivations for doing so (optimality, path diversity, etc.).
It MUST be possible to limit by configuration the number of requests
that can be carried within a single message.
A single protocol MUST be defined for PCC-PCE and PCE-PCE Similarly, it MUST be possible to return multiple computed paths
communication. A PCE requesting a path from another PCE can be within the same response message, corresponding either to the same
considered as a PCC. request (e.g. load balancing) or to distinct requests, correlated or
not, of the same request message or distinct request messages.
6.1.3 Reliable Message Exchange It MUST be possible to provide "continuation correlation" where all
related requests or computed paths cannot fit within one message.
The PCE communication protocol MUST run on top of a reliable Maximum acceptable message sizes and the maximum number of requests
transport protocol. In particular, it MUST allow for the detection per message supported by a PCE MAY form part of PCE capabilities
and recovery of lost messages to occur quickly and not impede the advertisement [PCE-DISC-REQ], or MAY be exchanged through information
operation of the communication protocol. Here the PCE communication messages from the PCE as part of the protocol described here.
protocol includes a number of application-specific capabilities, all
of which run on top of a common, reliable transport protocol layer.
In some particular cases (e.g. link failure), a large number of PCCs Maximum acceptable message sizes and the maximum number of computed
may simultaneously send a request to a PCE, leading potentially to a paths per message supported by a PCC MAY be indicated in the request
saturation of request buffers on PCEs. The PCE communication message.
protocol MUST properly handle such overload situations without a
significant decrease in performance, such as through throttling of
such requests.
The PCE communication-protocol transport MUST provide: An implementation MAY choose to limit message size to avoid a big
message from unduly delaying a small message.
- acknowledged message delivery with retransmission, as discussed in 6.1.8 Reliable Message Exchange
Section 6.1.1
- in order message delivery. For the set of requests between a given The PCEP MUST include reliability. This may form part of the
PCC and a PCE, the ordering is already there relying on the protocol itself or may be achieved by the selection of a suitable
reliable transport layer. For requests between a set of PCCs and a transport protocol (see Section 6.1.3).
given PCE, the ordering of responses SHOULD be based on the PCE's
own handling policy, as well as the priority of the requests. In particular, it MUST allow for the detection and recovery of lost
- message corruption detection messages to occur quickly and not impede the operation of the PCEP.
- flow control and back-pressure, as specified above with the
In some cases (e.g. after link failure), a large number of PCCs may
simultaneously send requests to a PCE, leading to a potential
saturation of the PCEs. The PCEP or the transport protocol it uses
MUST properly handle such overload situations without a significant
decrease in performance, such as through throttling of such requests.
The PCEP or the transport protocol it uses MUST provide:
- Acknowledged message delivery with retransmission.
- In order message delivery or the facility (such as message
numbering) to restore the order of received messages.
- Message corruption detection.
- Flow control and back-pressure, as specified above with the
throttling of requests. throttling of requests.
- Rapid partner failure detection. The PCC/PCE MUST be informed of
the failure of any PCE/PCC or PCC-PCE connection rapidly after
the failure happens.
These requirements SHOULD be satisfied by an existing reliable Functionality SHOULD NOT be added to the PCEP where the chosen
transport protocol, and functionality SHOULD only be added where the transport protocol already provides it.
transport protocol does not provide it (e.g., rapid partner failure
detection). With regard to the rapid partner failure detection, the
PCC MUST be informed of any failed PCE (or PCE connection) when it
happens.
6.1.4 Secure Message Exchange 6.1.9 Secure Message Exchange
The PCC-PCE and PCE-PCE communication MUST be secure. In particular, The PCC-PCE and PCE-PCE communication MUST be secure. In particular,
it MUST support mechanisms to prevent spoofing (e.g., it MUST support mechanisms to prevent spoofing (e.g.,
authentication), snooping (e.g., encryption) and DOS attacks. authentication), snooping (e.g., encryption) and DOS attacks.
6.1.5 Request Prioritization This function may be provided by the transport protocol or directly
by the PCEP.
The communication protocol MUST support the notion of request 6.1.10 Request Prioritization
priority, allowing a PCC to specify the degree of urgency of a
particular request. This is used to serve some requests before
others, and would require global prioritization. That is, a request
from one PCC can have a higher priority than a request from another
PCC to the same PCE. However, there is no intention or need for a
PCE to preempt (i.e., discard) a given request from one PCC if it
receives a higher-priority request from another PCC; the PCE just
delays the lower-priority request.
If, for example, the PCE is processing a low priority request that The PCEP MUST allow a PCC to specify the priority of a computation
will take extended computation time (e.g., for full re-optimization request. This priority is used by a PCE to service high priority
of 1000 protected LSPs through a complex algorithm), it is requests before lower priority requests considering all requests
RECOMMENDED that the low priority request to set up a new LSP be received and queued by a single PCE from all PCCs.
suspended/interrupted until the high priority request can be
completed. The PCE must consider, however, in addition to the
priority of the path computations, the PCE policy based on its system
resources, configurations, etc. That is, the handling of priority on
the PCE is not entirely in the purview of the PCE communication
protocol design.
The PCE communication protocol design MUST consider whether request Implementation of priority-based activity within a PCE is subject to
if starvation can occur for particular priorities, whether that is implementation and local policy. This application processing is out
acceptable, and how that is handled. of scope of the PCEP.
6.1.6 Unsolicited Notifications 6.1.11 Unsolicited Notifications
The PCE communication protocol SHOULD support unsolicited The normal operational mode is for the PCC to make path computation
notifications from PCE to PCC or from PCE to PCE. That is, the requests to the PCE, and for the PCE to respond.
normal mode is for the PCC to make path computation requests to the
PCE. This requirement includes cases of PCEs computing paths without
being asked by a PCC, and the PCE sending those unsolicited paths to
PCCs. This could also include PCE overload notifications.
6.1.7 Asynchronous Communication The PCEP SHOULD support unsolicited notifications from PCE to PCC,
PCE to PCE, or PCC to PCE. This requirement facilitates the
unsolicited communication of information, updated paths, and alerts
between PCCs and PCEs and between PCEs.
6.1.12 Asynchronous Communication
The PCC-PCE protocol MUST allow for asynchronous communication. A The PCC-PCE protocol MUST allow for asynchronous communication. A
client MUST NOT have to wait for a response to make another request. PCC MUST NOT have to wait for a response before it can make another
Also it MUST be possible to have the order of some responses differ request.
from the order of their corresponding requests. This may occur, for
instance, when path request messages have distinct priorities (see
Requirement 6.1.5).
6.1.8 Communication Overhead Minimization It MUST also be possible to have the order of responses differ from
the order of the corresponding requests. This may occur, for
instance, when path request messages have different priorities (see
Requirement 6.1.10).
6.1.13 Communication Overhead Minimization
The request and response messages SHOULD be designed so that the The request and response messages SHOULD be designed so that the
communication overhead is minimized. Particular attention SHOULD be communication overhead is minimized. Particular attention SHOULD be
given to the message size. Other considerations in overhead given to the message size. Other considerations in overhead
minimization include the following: minimization include the following:
- the number of messages exchanged to arrive at a computation answer - the number of messages exchanged to arrive at a computation answer
- the amount of background messages to keep the session up - the amount of background messages used by the protocol or its
transport protocol to keep alive any session or association
between the PCE and PCC
- the processing cost at the PCE (or PCC) associated with - the processing cost at the PCE (or PCC) associated with
requests/responses. request/response messages (as distinct from processing the
computation requests themselves).
6.1.9 Extensibility 6.1.14 Extensibility
The PCE communication protocol MUST provide a way for introduction of The PCEP MUST provide a way for the introduction of new path
new path computation constraints, diversity types, objective computation constraints, diversity types, objective functions,
functions, optimization methods and parameters, etc., without optimization methods and parameters, etc., without requiring
requiring modifications in the protocol. In particular, the PCE modifications in the protocol.
communication protocol SHOULD allow supporting future applications
not currently in the scope of the PCE working group, such as, for
instance, P2MP path computations.
The communication protocol MUST allow supporting various PCE based The PCEP MUST be easily extensible to support various PCE based
applications that have been currently identified and MAY be applications that have been currently identified including:
identified in the future, such as:
- intra-area path computation - intra-area path computation
- inter-area path computation - inter-area path computation
- inter-AS intra provider and inter-AS inter-provider path - inter-AS intra provider and inter-AS inter-provider path
computation computation
- multi-layer and virtual network topology computation The PCEP MUST also allow extensions as more PCE applications will be
introduced in the future. For example, the protocol may be extended
to support PCE-based multi-layer path computation and virtual network
topology computation/reconfiguration.
The PCEP SHOULD also be easily extensible to support future
applications not currently in the scope of the PCE working group,
such as, for instance, P2MP path computations, etc.
Note that application specific requirements are out of the scope of Note that application specific requirements are out of the scope of
this document and will be addressed in separate requirements this document and will be addressed in separate requirements
documents. documents.
6.1.10 Scalability 6.1.15 Scalability
The PCE communication protocol MUST scale well with an increase of The PCEP MUST scale well, at least as good as linearly, with an
any of the following parameters: increase of any of the following parameters:
- number of PCCs - number of PCCs
- number of PCEs - number of PCEs
- number of PCCs communicating with a single PCE - number of PCCs communicating with a single PCE
- number of PCEs communicated to by a single PCC - number of PCEs communicated to by a single PCC
- number of PCEs communicated to by another PCE. - number of PCEs communicated to by another PCE
- TED size (number of links/nodes, which may drive up path
computation time)
- number of domains - number of domains
- number of path requests - number of path requests
- handling bursts of requests - handling bursts of requests.
Bursts of requests may arise, for example, after a network outage Bursts of requests may arise, for example, after a network outage
when multiple recomputations are requested as a result. It is when multiple recomputations are requested. It is RECOMMENDED that
RECOMMENDED that the protocol handle the congestion in a graceful way the protocol handle the congestion in a graceful way so that it does
so that it does not unduly impact the rest of the network, and so not unduly impact the rest of the network, and so that it does not
that it does not gate the ability of the PCE to perform computation. gate the ability of the PCE to perform computation.
6.1.16 Constraints
This section provides a list of generic constraints that MUST be
supported by the PCEP. Other constraints may be added to service
specific applications as identified by separate application-specific
requirements documents.
Note that the absence of a constraint in this list does not mean that
that constraint must not be supported. Note also that the provisions
of Section 6.1.14 mean that new constraints can be added to this list
without impacting the protocol.
Here is the list of generic constraints that MUST be supported:
o MPLS-TE and GMPLS generic constraints:
- Bandwidth
- Affinities inclusion/exclusion
- Link, Node, SRLG inclusion/exclusion
- Maximum end-to-end delay metrics
- Hop Count
o MPLS-TE specific constraints
- Class-Type
o GMPLS specific constraints
- Switching Type, Encoding Type
- Protection type
o TBD
6.2 Deployment Support Requirements 6.2 Deployment Support Requirements
6.2.1 Support for Various Service Provider Environments and Applications 6.2.1 Support for Different Service Provider Environments
The communication protocol MUST operate in various service provider The PCEP MUST operate in various different service provider network
network environments, where the IP control plane is deployed, such as environments that utilize an IP-based control plane, such as
- MPLS-TE and GMPLS networks - MPLS-TE and GMPLS networks
- centralized and distributed PCE path computation - centralized and distributed PCE path computation
- single and multiple PCE path computation - single and multiple PCE path computation
Definitions of centralized, distributed, single, and multiple PCE Definitions of centralized, distributed, single, and multiple PCE
path computation can be found in [PCE-ARCH]. path computation can be found in [PCE-ARCH].
6.2.2 Confidentiality 6.2.2 Policy Support
The communication protocol MUST allow minimizing the amount of
topological information exchanged between a PCC and PCE, and between
PCEs. This is of particular importance in inter-PCE communication,
where the PCEs are located in distinct service-provider domains.
For example, the protocol design SHOULD enable policies to be
implemented such that domain-specific topology information is
excluded on inter-PCE, inter-domain communication.
6.2.3 Policy Support
The communication protocol MUST allow for policies to accept/reject The PCEP MUST allow for policies to accept/reject requests, and
requests, and include the ability for a PCE to reject requests with include the ability for a PCE to reject requests with sufficient
sufficient detail to allow the PCC to determine the reason for detail to allow the PCC to determine the reason for rejection or
rejection or failure. For example, filtering could be required for failure. For example, filtering could be required for intra-AS PCE
intra-AS PCE path computation such that all requests are rejected path computation such that all requests are rejected that come from
that come from another AS. However, specific policy details another AS. However, specific policy details are left to
are left to application-specific communication protocol requirements. application-specific PCEP requirements. Furthermore, the PCEP MUST
Furthermore, the communication protocol MUST allow for the allow for the notification of a policy violation. Actual policies,
notification of a policy violation. Actual policies, configuration configuration of policies, and applicability of policies are out of
of policies, and applicability of policies are out of scope. scope.
6.3 Detection & Recovery Requirements 6.3 Detection & Recovery Requirements
6.3.1 Aliveness Detection 6.3.1 Aliveness Detection
The PCE communication protocol MUST allow a PCC to check the The PCEP MUST allow a PCC to check the liveliness of PCEs it is using
liveliness of PCEs it is using for path computation and a PCE to for path computation, and a PCE to check the liveliness of PCCs it is
check the liveliness of PCCs it is serving. The PCE communication serving. The PCEP MUST provide partner failure detection.
protocol MUST provide partner failure detection.
Depending on the design, this requirement MAY be met by the PCE Depending on the solution, this requirement MAY be met by the PCEP
communication protocol design or the transport protocol design. design or the transport protocol design.
6.3.2 PCC/PCE Failure Response 6.3.2 PCC/PCE Failure Response
Appropriate PCC and PCE procedures MUST be defined to deal with PCE Appropriate PCC and PCE procedures MUST be defined to deal with PCE
and PCC failures. A PCC MUST be able to clear any pending request to and PCC failures. A PCC must be able to clear any pending request to
a PCE. That is, the PCC MAY cancel a previously-made path a PCE so that it is no longer waiting for a response. Clearing a
computation request to a PCE. pending request does not imply any message exchange; this differs
from pending request cancellation (Section 6.1.6), which requires
message exchange. It is RECOMMENDED that a PCC select another PCE
upon detection of PCE failure or unreachability of a PCE but note
that PCE selection procedure are out of the scope of this document.
Similarly, a PCE MUST be able to clear pending requests from a PCC, Similarly, a PCE must be able to clear pending requests from a PCC,
for instance, when it detects the failure of the requesting PCC or for instance, when it detects the failure of the requesting PCC or
when its buffer of requests is full. It is RECOMMENDED that a PCC when its buffer of requests is full. Clearing a pending request does
select another PCE upon detection of PCE failure or unreachability of not imply any message exchange.
a PCE but note that PCE selection procedure are out of the scope of
this document.
It is assumed that the underlying reliable communication mechanism It is assumed that the aliveness detection mechanism (see Section
ensures reciprocal knowledge of PCE and PCC liveness. Therefore it 6.3.1) ensures reciprocal knowledge of PCE and PCC liveness.
NOT possible for the PCC/PCE to believe that the PCE/PCC is
unreachable, but not vice versa.
6.3.3 Protocol Recovery 6.3.3 Protocol Recovery
Information distributed in asynchronous/unsolicited messages SHOULD Information distributed in asynchronous/unsolicited messages MAY
be allowed to persist at the recipient in the event of the failure of persist at the recipient in the event of the failure of the sender or
the sender or of the communications channel. Upon recovery, the of the communication channel. Upon recovery, the Communication
communications protocol MUST support resynchronization of information Protocol MUST support resynchronization of information and requests
between the sender and the receiver, and this SHOULD be arranged so between the sender and the receiver, and this SHOULD be arranged so
as to minimize repeat data transfer. as to minimize repeat data transfer.
For example, the communication protocol SHOULD allow a stateful For example, the PCEP SHOULD allow a PCE to respond to computation
PCE to resynchronize and recover states (e.g., LSP status, paths, requests issued before the failure without the requests being
etc.) after a restart. Recovery would require the PCE communication re-issued.
protocol to support recovery of state information in the PCE. This
would be of particular importance when local PCE recovery is not Similarly, a stateful PCE SHOULD be able to resynchronize and recover
supported or fails. states (e.g., LSP status, paths, etc.) after a restart.
7. Security Considerations 7. Security Considerations
The impact of the use of a PCE-based architecture MUST be considered The impact of the use of a PCEP MUST be considered in the light of
in the light of the impact that it has on the security of the the impact that it has on the security of the existing routing and
existing routing and signaling protocols and techniques in use within signaling protocols and techniques in use within the network. There
the network. There is unlikely to be any impact on intra-domain is unlikely to be any impact on intra-domain security, but an
security, but an increase in inter-domain information flows and the increase in inter-domain information flows and the facilitation of
facilitation of inter-domain path establishment may increase the inter-domain path establishment may increase the vulnerability to
vulnerability to security attacks. security attacks.
Of particular relevance are the implications for confidentiality Of particular relevance are the implications for confidentiality
inherent in a PCE-based architecture for multi-domain networks. It inherent in a PCEP for multi-domain networks. It is not necessarily
is not necessarily the case that a multi-domain PCE solution will the case that a multi-domain PCE solution will compromise security,
compromise security, but solutions MUST examine their impacts in this but solutions MUST examine their impacts in this area.
area.
Applicability statements for particular combinations of signaling, Applicability statements for particular combinations of signaling,
routing and path computation techniques are expected to contain routing and path computation techniques are expected to contain
detailed security sections. detailed security sections.
It should be observed that the use of a non-local PCE (that is, not It should be observed that the use of an external PCE does introduce
co-resident with the PCC) does introduce additional security issues. additional security issues. Most notable amongst these are:
Most notable amongst these are:
- interception of PCE requests or responses - interception of PCE requests or responses
- impersonation of PCE - impersonation of PCE
- falsification of TE information - falsification of TE information
- denial of service attacks on PCE or PCE communication mechanisms - denial of service attacks on PCE or PCE communication mechanisms
It is expected that PCE solutions will address these issues in detail It is expected that the PCEP will address these issues in detail
using authentication and security techniques. using authentication and security techniques. See also Section
6.1.9.
8. Manageability Considerations 8. Manageability Considerations
Manageability of the PCE communication protocol MUST address the Manageability of the PCEP MUST address the following considerations:
following considerations:
- need for a MIB module for control and monitoring - need for a MIB module for control and monitoring
- need for built-in diagnostic tools (e.g., partner failure - need for built-in diagnostic tools (e.g., partner failure
detection, OAM, etc.) detection, OAM, etc.)
- configuration implications for the protocol - configuration implications for the protocol
9. IANA Considerations 9. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
skipping to change at page 14, line 34 skipping to change at page 18, line 30
Midori-cho 3-9-11 Midori-cho 3-9-11
Musashino-shi, Tokyo 180-8585, JAPAN Musashino-shi, Tokyo 180-8585, JAPAN
Email: oki.eiji@lab.ntt.co.jp Email: oki.eiji@lab.ntt.co.jp
Raymond Zhang Raymond Zhang
BT INFONET Services Corporation BT INFONET Services Corporation
2160 E. Grand Ave. 2160 E. Grand Ave.
El Segundo, CA 90245 USA El Segundo, CA 90245 USA
Email: Raymond_zhang@bt.infonet.com Email: Raymond_zhang@bt.infonet.com
14. Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/