IETF Internet Draft PCE Working Group Jerry Ash (AT&T)
Proposed Status: Informational Editor
Expires: November 2005 J.L. Le Roux (France Telecom)
Editor
May 2005
draft-ash-pce-comm-protocol-gen-reqs-01.txt
PCE Communication Protocol Generic Requirements
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 26, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Constraint-based path computation is a fundamental building block for
traffic engineering systems such as multiprotocol label switching
(MPLS) and generalized multiprotocol label switching (GMPLS)
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
PCEs, and between PCEs where cooperation between PCEs is desirable.
Subsequent documents will specify application-specific requirements
for the PCE communication protocol.
PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-01.txt> [Page 1]
Internet Draft PCE Communication Protocol Generic Reqmnts May 2005
Table of Contents
1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . . . 3
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Overview of PCE Communication Protocol . . . . . . . . . . . . . 4
6. PCE Communication Protocol Generic Requirements . . . . . . . . . 5
6.1 Basic Protocol Requirements . . . . . . . . . . . . . . . . . 5
6.1.1 Client-Server Communication . . . . . . . . . . . . . . 6
6.1.2 PCC-PCE and PCE-PCE Communication . . . . . . . . . . . 7
6.1.3 Reliable Message Exchange . . . . . . . . . . . . . . . 7
6.1.4 Secure Message Exchange . . . . . . . . . . . . . . . . 8
6.1.5 Request Prioritization . . . . . . . . . . . . . . . . 8
6.1.6 Unsolicited Notifications . . . . . . . . . . . . . . . 8
6.1.7 Asynchronous Communication . . . . . . . . . . . . . . 8
6.1.8 Communication Overhead Minimization . . . . . . . . . . 9
6.1.9 Extensibility . . . . . . . . . . . . . . . . . . . . . 9
6.1.10 Scalability . . . . . . . . . . . . . . . . . . . . . 9
6.2 Deployment Support Requirements . . . . . . . . . . . . . . . 10
6.2.1 Support for Various Service Provider Environments and
Applications . . . . . . . . . . . . . . . . . . . . . 10
6.2.2 Confidentiality . . . . . . . . . . . . . . . . . . . . 10
6.3 Detection & Recovery Requirements . . . . . . . . . . . . . . 10
6.3.1 Aliveness Detection . . . . . . . . . . . . . . . . . . 10
6.3.2 PCC/PCE Failure Response . . . . . . . . . . . . . . . 10
6.3.3 Protocol Recovery . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Manageability Considerations . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
11. Normative References . . . . . . . . . . . . . . . . . . . . . . 12
12. Informational References . . . . . . . . . . . . . . . . . . . . 13
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
14. Intellectual Property Considerations . . . . . . . . . . . . . . 14
PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-01.txt> [Page 2]
Internet Draft PCE Communication Protocol Generic Reqmnts May 2005
1. Contributors
This document is the result of the PCE Working Group PCE
communication protocol requirements design team joint effort. The
following are the design team member authors that contributed to the
present document:
Jerry Ash (AT&T)
Alia Atlas (Avici)
Arthi Ayyangar (Juniper)
Nabil Bitar (Verizon)
Igor Bryskin (Independent Consultant)
Dean Cheng (Cisco)
Durga Gangisetti (MCI)
Kenji Kumaki (KDDI)
Jean-Louis Le Roux (France Telecom)
Eiji Oki (NTT)
Raymond Zhang (BT Infonet)
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Introduction
The path computation element (PCE) capability [PCE-ARCH] supports
requests for path computation issued by a path computation client
(PCC), which may be co-located or remote from a PCE. When the PCC is
remote from the PCE, a request/response communications protocol is
required to carry the path computation request and return the
response. In order for the PCC and PCE to communicate, the PCC must
discover the location of the PCE, as described in [PCE-DISC-REQ].
The PCE operates on a network graph in order to compute paths based
on the path computation request issued by the PCC, which will
normally include the source, destination, and a set of constraints.
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
communication protocol, where the PCE communications protocol
solution MUST satisfy these requirements. Application-specific
requirements are beyond the scope of this document, and will be
addressed in separate documents.
4. Terminology
Domain: any collection of network elements within a common sphere of
address management or path computational responsibility. Examples of
domains include IGP areas, Autonomous Systems (ASs), multiple ASs
PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-01.txt> [Page 3]
Internet Draft PCE Communication Protocol Generic Reqmnts May 2005
within a service provider network, or multiple ASs across multiple
service provider networks.
GMPLS: generalized multiprotocol label switching
LSP: MPLS Label Switched Path.
MPLS: multiprotocol label switching
PCC: Path Computation Client: any client application requesting a
Path computation to be performed by the PCE.
PCE: Path Computation Element: an entity (component, application or
network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints (see
further description in [PCE-ARCH]).
TED: Traffic Engineering Database, which contains the topology and
resource information of the network or network segment used by a PCE.
TE LSP: Traffic Engineering MPLS Label Switched Path.
See [PCE-ARCH] for further definitions of terms.
5. Overview of PCE Communication Protocol
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
the PCC and PCE are not co-located a request/response communications
protocol is required to carry the request and return the response. If
the PCC and PCE are co-located a communications protocol is not
required, but implementations may choose to utilize a protocol for
exchanges between the components.
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
discovery mechanism is out of scope of this document, but
requirements are documented in [PCE-DISC-REQ].
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
scope for the PCE Communications Protocol.
A path computation request issued by the PCC will include a
specification of the path(s) needed. The information supplied will
include at a minimum the source and destination for the path(s), but
may also include a set of further requirements (known as constraints)
as described in Section 6.
The response from the PCE may be positive in which case it will
include the paths that have been computed. If the computation fails
PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-01.txt> [Page 4]
Internet Draft PCE Communication Protocol Generic Reqmnts May 2005
or cannot be performed, a negative response is required with an
indication of the type of and reason(s) for the failure. A negative
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
path computation requests to another PCE and for the PCE to return
the path computation response. As described in [PCE-ARCH], there is
no reason to assume that two different protocols are needed, and this
document assumes that a single protocol will satisfy all requirements
for PCC-PCE and PCE-PCE communications.
[PCE-ARCH] describes four models of PCE: composite, external,
multiple PCE path computation and multiple PCE path computation with
inter-PCE communication. In all cases except the composite PCE
model, a communication protocol is required. The requirements
defined in this document therefore are applicable to all models
described in the [PCE-ARCH] except the composite PCE model.
6. PCE Communication Protocol Generic Requirements
The designers of a PCE communication protocol MUST take the
requirements set out in this 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.
6.1 Basic Protocol Requirements
6.1.1 Client-Server Communication
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
path request message to a PCE, and for a PCE to reply with a path
response message to the requesting PCC or PCE, once the path has been
computed. In addition to this request-response model, there may be
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
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-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,
PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-01.txt> [Page 5]
Internet Draft PCE Communication Protocol Generic Reqmnts May 2005
correlated or not, within the same path 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. 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
destination, and MAY include 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 path request message MUST support the ability to prefer/customize
various path computation objective functions, policies and
optimization criteria. For example, a PCC may be aware of and would
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
minimal subset of standard objective functions and functional
options. The requester SHOULD also be able to select a
vendor-specific or experimental objective function or functional
option. Furthermore, the requester MUST be allowed to customize the
objective function/options in use. That is, individual objective
functions will often have parameters to be set in the request from
PCC to PCE. Specification of objective functions and objective
function parameters is required in the protocol extensibility
specified in Section 6.1.9.
If a PCC selects an objective function that the PCE does not support,
the PCE response MUST be negative.
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,
and as long as those parameters are satisfied, the PCC MAY not care
about which objective function is used. Also, the PCE MAY execute
objective functions not advertised to the PCC, for example, policy
based routing path computation for load balancing instructed by the
management plane.
PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-01.txt> [Page 6]
Internet Draft PCE Communication Protocol Generic Reqmnts May 2005
A PCC or PCE MUST be able to cancel a pending request.
The path response message MUST allow returning various elements
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
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.3 Reliable Message Exchange
The PCE communication protocol MUST run on top of a reliable
transport protocol. In particular, it MUST allow for the detection
and recovery of lost messages to occur quickly and not impede the
operation of the communication protocol. Here the PCE communication
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
may simultaneously send a request to a PCE, leading potentially to a
saturation of request buffers on PCEs. The PCE communication
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:
- acknowledged message delivery with retransmission, as discussed in
Section 6.1.1
- in order message delivery. For the set of requests between a given
PCC and a PCE, the ordering is already there relying on the
reliable transport layer. For requests between a set of PCCs and a
given PCE, the ordering of responses SHOULD be based on the PCE's
own handling policy, as well as the priority of the requests.
- message corruption detection
- flow control and back-pressure, as specified above with the
throttling of requests.
These requirements SHOULD be satisfied by an existing reliable
transport protocol, and functionality SHOULD only be added where the
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.
PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-01.txt> [Page 7]
Internet Draft PCE Communication Protocol Generic Reqmnts May 2005
6.1.4 Secure Message Exchange
The PCC-PCE and PCE-PCE communication MUST be secure. In particular,
it MUST support mechanisms to prevent spoofing (e.g.,
authentication), snooping (e.g., encryption) and DOS attacks.
6.1.5 Request Prioritization
The communication protocol MUST support the notion of request
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
will take extended computation time (e.g., for full re-optimization
of 1000 protected LSPs through a complex algorithm), it is
RECOMMENDED that the low priority request to set up a new LSP be
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
if starvation can occur for particular priorities, whether that is
acceptable, and how that is handled.
6.1.6 Unsolicited Notifications
The PCE communication protocol SHOULD support unsolicited
notifications from PCE to PCC or from PCE to PCE. That is, the
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 PCC-PCE protocol MUST allow for asynchronous communication. A
client MUST NOT have to wait for a response to make another request.
Also it MUST be possible to have the order of some responses differ
from the order of their corresponding requests. This may occur, for
instance, when path request messages have distinct priorities (see
Requirement 6.1.5).
PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-01.txt> [Page 8]
Internet Draft PCE Communication Protocol Generic Reqmnts May 2005
6.1.8 Communication Overhead Minimization
The request and response messages SHOULD be designed so that the
communication overhead is minimized. Particular attention SHOULD be
given to the message size. Other considerations in overhead
minimization include the following:
- the number of messages exchanged to arrive at a computation answer
- the amount of background messages to keep the session up
- the processing cost at the PCE (or PCC) associated with
requests/responses.
6.1.9 Extensibility
The PCE communication protocol MUST provide a way for introduction of
new path computation constraints, diversity types, objective
functions, optimization methods and parameters, etc., without
requiring modifications in the protocol. In particular, the PCE
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
applications that have been currently identified and MAY be
identified in the future, such as:
- intra-area path computation
- inter-area path computation
- inter-AS intra provider and inter-AS inter-provider path
computation
- multi-layer and virtual network topology computation
Note that application specific requirements are out of the scope of
this document and will be addressed in separate requirements
documents.
6.1.10 Scalability
The PCE communication protocol MUST scale well with an increase of
any of the following parameters:
- number of PCCs
- number of PCEs
- number of PCCs communicating with a single PCE
- number of PCEs communicated to by a single PCC
- 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 path requests
- handling bursts of requests
PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-01.txt> [Page 9]
Internet Draft PCE Communication Protocol Generic Reqmnts May 2005
Bursts of requests may arise, for example, after a network outage
when multiple recomputations are requested as a result. It is
RECOMMENDED that the protocol handle the congestion in a graceful way
so that it does not unduly impact the rest of the network, and so
that it does not gate the ability of the PCE to perform computation.
6.2 Deployment Support Requirements
6.2.1 Support for Various Service Provider Environments and Applications
The communication protocol MUST operate in various service provider
network environments, where the IP control plane is deployed, such as
- MPLS-TE and GMPLS networks
- centralized and distributed PCE path computation
- single and multiple PCE path computation
Definitions of centralized, distributed, single, and multiple PCE
path computation can be found in [PCE-ARCH].
6.2.2 Confidentiality
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
requests, and include the ability for a PCE to reject requests with
sufficient detail to allow the PCC to determine the reason for
rejection or failure. For example, filtering could be required for
intra-AS PCE path computation such that all requests are rejected
that come from another AS. However, specific policy details
are left to application-specific communication protocol requirements.
Furthermore, the communication protocol MUST allow for the
notification of a policy violation. Actual policies, configuration
of policies, and applicability of policies are out of scope.
6.3 Detection & Recovery Requirements
6.3.1 Aliveness Detection
The PCE communication protocol MUST allow a PCC to check the
liveliness of PCEs it is using for path computation and a PCE to
check the liveliness of PCCs it is serving. The PCE communication
PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-01.txt> [Page 10]
Internet Draft PCE Communication Protocol Generic Reqmnts May 2005
protocol MUST provide partner failure detection.
Depending on the design, this requirement MAY be met by the PCE
communication protocol design or the transport protocol design.
6.3.2 PCC/PCE Failure Response
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
a PCE. That is, the PCC MAY cancel a previously-made path
computation request to a PCE.
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
when its buffer of requests is full. 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.
It is assumed that the underlying reliable communication mechanism
ensures reciprocal knowledge of PCE and PCC liveness. Therefore it
NOT possible for the PCC/PCE to believe that the PCE/PCC is
unreachable, but not vice versa.
6.3.3 Protocol Recovery
Information distributed in asynchronous/unsolicited messages SHOULD
be allowed to persist at the recipient in the event of the failure of
the sender or of the communications channel. Upon recovery, the
communications protocol MUST support resynchronization of information
between the sender and the receiver, and this SHOULD be arranged so
as to minimize repeat data transfer.
For example, the communication protocol SHOULD allow a stateful
PCE to resynchronize and recover states (e.g., LSP status, paths,
etc.) after a restart. Recovery would require the PCE communication
protocol to support recovery of state information in the PCE. This
would be of particular importance when local PCE recovery is not
supported or fails.
7. Security Considerations
The impact of the use of a PCE-based architecture MUST be considered
in the light of the impact that it has on the security of the
existing routing and signaling protocols and techniques in use within
the network. There is unlikely to be any impact on intra-domain
security, but an increase in inter-domain information flows and the
facilitation of inter-domain path establishment may increase the
vulnerability to security attacks.
Of particular relevance are the implications for confidentiality
PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-01.txt> [Page 11]
Internet Draft PCE Communication Protocol Generic Reqmnts May 2005
inherent in a PCE-based architecture for multi-domain networks. It
is not necessarily the case that a multi-domain PCE solution will
compromise security, but solutions MUST examine their impacts in this
area.
Applicability statements for particular combinations of signaling,
routing and path computation techniques are expected to contain
detailed security sections.
It should be observed that the use of a non-local PCE (that is, not
co-resident with the PCC) does introduce additional security issues.
Most notable amongst these are:
- interception of PCE requests or responses
- impersonation of PCE
- falsification of TE information
- denial of service attacks on PCE or PCE communication mechanisms
It is expected that PCE solutions will address these issues in detail
using authentication and security techniques.
8. Manageability Considerations
Manageability of the PCE communication protocol MUST address the
following considerations:
- need for a MIB module for control and monitoring
- need for built-in diagnostic tools (e.g., partner failure
detection, OAM, etc.)
- configuration implications for the protocol
9. IANA Considerations
This document makes no requests for IANA action.
10. Acknowledgements
The authors would like to extend their warmest thanks to (in
alphabetical order) Adrian Farrel, Thomas Morin, and JP Vasseur for
their review and suggestions.
11. Normative References
[PCE-ARCH] Farrel, A., Vasseur, JP, Ash, J., "Path Computation
Element (PCE) Architecture", work in progress.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3667, February 2004.
PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-01.txt> [Page 12]
Internet Draft PCE Communication Protocol Generic Reqmnts May 2005
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
12. Informational References
[PCE-DISC-REQ] Le Roux, JL, et. al., "Requirements for Path
Computation Element (PCE) Discovery," work in progress.
[RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels," RFC 3209, December 2001.
13. Authors' Addresses
Jerry Ash
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1-(732)-420-4578
Email: gash@att.com
Alia K. Atlas
Avici Systems, Inc.
101 Billerica Avenue
N. Billerica, MA 01862, USA
Phone: +1 978 964 2070
Email: aatlas@avici.com
Arthi Ayyangar
Juniper Networks, Inc.
1194 N.Mathilda Ave
Sunnyvale, CA 94089 USA
Email: arthi@juniper.net
Nabil Bitar
Verizon
40 Sylvan Road
Waltham, MA 02145
Email: nabil.bitar@verizon.com
Igor Bryskin
Independent Consultant
Email: i_bryskin@yahoo.com
Dean Cheng
Cisco Systems Inc.
3700 Cisco Way
San Jose CA 95134 USA
Phone: +1 408 527 0677
Email: dcheng@cisco.com
PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-01.txt> [Page 13]
Internet Draft PCE Communication Protocol Generic Reqmnts May 2005
Durga Gangisetti
MCI
Email: durga.gangisetti@mci.com
Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
Phone: +81-3-6678-3103
Email: ke-kumaki@kddi.com
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex, FRANCE
Email: jeanlouis.leroux@francetelecom.com
Eiji Oki
NTT
Midori-cho 3-9-11
Musashino-shi, Tokyo 180-8585, JAPAN
Email: oki.eiji@lab.ntt.co.jp
Raymond Zhang
BT INFONET Services Corporation
2160 E. Grand Ave.
El Segundo, CA 90245 USA
Email: Raymond_zhang@bt.infonet.com
14. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-01.txt> [Page 14]
Internet Draft PCE Communication Protocol Generic Reqmnts May 2005
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
PCE Design Team <draft-ash-pce-comm-protocol-gen-reqs-01.txt> [Page 15]