< draft-ietf-pce-comm-protocol-gen-reqs-06.txt   draft-ietf-pce-comm-protocol-gen-reqs-07.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: December 2006 J.L. Le Roux (France Telecom) Expires: December 2006 J.L. Le Roux (France Telecom)
Editor Editor
May 2006 June 2006
draft-ietf-pce-comm-protocol-gen-reqs-06.txt draft-ietf-pce-comm-protocol-gen-reqs-07.txt
PCE Communication Protocol Generic Requirements Path Computation Element (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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 38
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 18, 2006. This Internet-Draft will expire on December 23, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
The PCE model is described in the "PCE Architecture" document and The PCE model is described in the "PCE Architecture" document and
facilitates path computation requests from Path Computation Clients facilitates path computation requests from Path Computation Clients
(PCCs) to Path Computation Elements (PCEs). This document specifies (PCCs) to Path Computation Elements (PCEs). This document specifies
generic requirements for a communication protocol between PCCs and generic requirements for a communication protocol between PCCs and
PCEs, and also between PCEs where cooperation between PCEs is PCEs, and also between PCEs where cooperation between PCEs is
desirable. Subsequent documents will specify application-specific desirable. Subsequent documents will specify application-specific
requirements for the PCE communication protocol. requirements for the PCE communication protocol.
Table of Contents Table of Contents
1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . . 4
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Overview of PCE Communication Protocol (PCECP) . . . . . . . . . 4 5. Overview of PCE Communication Protocol (PCECP) . . . . . . . . . 5
6. PCE Communication Protocol Generic Requirements . . . . . . . . . 5 6. PCE Communication Protocol Generic Requirements . . . . . . . . . 6
6.1 Basic Protocol Requirements . . . . . . . . . . . . . . . . . 5 6.1 Basic Protocol Requirements . . . . . . . . . . . . . . . . . 6
6.1.1 Commonality of PCC-PCE and PCE-PCE Communication . . . 5 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication . . . 6
6.1.2 Client-Server Communication . . . . . . . . . . . . . . 5 6.1.2 Client-Server Communication . . . . . . . . . . . . . . 6
6.1.3 Transport . . . . . . . . . . . . . . . . . . . . . . . 5 6.1.3 Transport . . . . . . . . . . . . . . . . . . . . . . . 6
6.1.4 Path Computation Requests . . . . . . . . . . . . . . . 6 6.1.4 Path Computation Requests . . . . . . . . . . . . . . . 6
6.1.5 Path Computation Responses . . . . . . . . . . . . . . 7 6.1.5 Path Computation Responses . . . . . . . . . . . . . . 8
6.1.6 Cancellation of Pending Requests . . . . . . . . . . . 8 6.1.6 Cancellation of Pending Requests . . . . . . . . . . . 8
6.1.7 Multiple Requests and Responses . . . . . . . . . . . . 8 6.1.7 Multiple Requests and Responses . . . . . . . . . . . . 8
6.1.8 Reliable Message Exchange . . . . . . . . . . . . . . . 8 6.1.8 Reliable Message Exchange . . . . . . . . . . . . . . . 9
6.1.9 Secure Message Exchange . . . . . . . . . . . . . . . . 9 6.1.9 Secure Message Exchange . . . . . . . . . . . . . . . . 10
6.1.10 Request Prioritization . . . . . . . . . . . . . . . . 9 6.1.10 Request Prioritization . . . . . . . . . . . . . . . . 10
6.1.11 Unsolicited Notifications . . . . . . . . . . . . . . 10 6.1.11 Unsolicited Notifications . . . . . . . . . . . . . . 11
6.1.12 Asynchronous Communication . . . . . . . . . . . . . . 10 6.1.12 Asynchronous Communication . . . . . . . . . . . . . . 11
6.1.13 Communication Overhead Minimization . . . . . . . . . 10 6.1.13 Communication Overhead Minimization . . . . . . . . . 11
6.1.14 Extensibility . . . . . . . . . . . . . . . . . . . . 10 6.1.14 Extensibility . . . . . . . . . . . . . . . . . . . . 11
6.1.15 Scalability . . . . . . . . . . . . . . . . . . . . . 11 6.1.15 Scalability . . . . . . . . . . . . . . . . . . . . . 12
6.1.16 Constraints . . . . . . . . . . . . . . . . . . . . . 12 6.1.16 Constraints . . . . . . . . . . . . . . . . . . . . . 13
6.1.17 Objective Functions Supported . . . . . . . . . . . . 12 6.1.17 Objective Functions Supported . . . . . . . . . . . . 13
6.2 Deployment Support Requirements . . . . . . . . . . . . . . . 13 6.2 Deployment Support Requirements . . . . . . . . . . . . . . . 14
6.2.1 Support for Different Service Provider Environments . . 13 6.2.1 Support for Different Service Provider Environments . . 14
6.2.2 Policy Support . . . . . . . . . . . . . . . . . . . . 13 6.2.2 Policy Support . . . . . . . . . . . . . . . . . . . . 14
6.3 Aliveness Detection & Recovery Requirements . . . . . . . . . 13 6.3 Aliveness Detection & Recovery Requirements . . . . . . . . . 14
6.3.1 Aliveness Detection . . . . . . . . . . . . . . . . . . 13 6.3.1 Aliveness Detection . . . . . . . . . . . . . . . . . . 14
6.3.2 Protocol Recovery . . . . . . . . . . . . . . . . . . . 14 6.3.2 Protocol Recovery . . . . . . . . . . . . . . . . . . . 15
6.3.3 LSP Rerouting & Reoptimization . . . . . . . . . . . . 14 6.3.3 LSP Rerouting & Reoptimization . . . . . . . . . . . . 15
6.4 Requirements Summary . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. Manageability Considerations . . . . . . . . . . . . . . . . . . 16
8. Manageability Considerations . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Normative References . . . . . . . . . . . . . . . . . . . . . . 17
11. Normative References . . . . . . . . . . . . . . . . . . . . . . 18 12. Informational References . . . . . . . . . . . . . . . . . . . . 17
12. Informational References . . . . . . . . . . . . . . . . . . . . 18 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
13. Authors' & Contributors' Addresses . . . . . . . . . . . . . . . 19 Intellectual Property Statement . . . . . . . . . . . . . . . . . . 18
Intellectual Property Statement . . . . . . . . . . . . . . . . . . 20 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . . 19
Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . . . . 21 Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . . 19
Copyright Statement . . . . . . . . . . . . . . . . . . . . . . . . 21
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 (PCECP) requirements design team joint effort. Communication Protocol (PCECP) requirements design team joint effort.
The following are the design team member authors that contributed to In addition to the authors/editors listed in Section 13, the
the present document: following are the design team members who contributed to the
document:
Jerry Ash (AT&T) Alia K. Atlas
Alia Atlas (Google, Inc.) Google Inc.
Arthi Ayyangar (Juniper) 1600 Amphitheatre Parkway
Nabil Bitar (Verizon) Mountain View, CA 94043
Igor Bryskin (Independent Consultant) Email: akatlas@alum.mit.edu
Dean Cheng (Cisco)
Durga Gangisetti (MCI) Arthi Ayyangar
Kenji Kumaki (KDDI) Juniper Networks, Inc.
Jean-Louis Le Roux (France Telecom) 1194 N.Mathilda Ave
Eiji Oki (NTT) Sunnyvale, CA 94089 USA
Raymond Zhang (BT Infonet) 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: 408 527 0677
Email: dcheng@cisco.com
Durga Gangisetti
MCI
Email: durga.gangisetti@mci.com
Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
Phone: 3-6678-3103
Email: ke-kumaki@kddi.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
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
A Path Computation Element (PCE) [PCE-ARCH] supports requests for A Path Computation Element (PCE) [PCE-ARCH] supports requests for
skipping to change at page 5, line 25 skipping to change at page 6, line 14
for PCC-PCE and PCE-PCE communication. 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 model, inter-PCE communication. In all cases except the composite PCE model,
a PCECP is required. The requirements defined in this document are a PCECP is required. The requirements defined in this document are
applicable to all models described in the [PCE-ARCH]. applicable to all models described in the [PCE-ARCH].
6. PCE Communication Protocol Generic Requirements 6. PCE Communication Protocol Generic Requirements
Section 6.4 contains a summary of the requirements in this section.
6.1 Basic Protocol Requirements 6.1 Basic Protocol Requirements
6.1.1 Commonality of PCC-PCE and PCE-PCE Communication 6.1.1 Commonality of PCC-PCE and PCE-PCE Communication
A single protocol MUST be defined for PCC-PCE and PCE-PCE A single protocol MUST be defined for PCC-PCE and PCE-PCE
communication. A PCE requesting a path from another PCE can be communication. A PCE requesting a path from another PCE can be
considered as a PCC, and in the remainder of this document we refer considered as a PCC, and in the remainder of this document we refer
to all communications as PCC-PCE regardless of whether they are to all communications as PCC-PCE regardless of whether they are
PCC-PCE or PCE-PCE. PCC-PCE or PCE-PCE.
skipping to change at page 5, line 50 skipping to change at page 6, line 37
MUST allow a PCC to send a request message to a PCE to request path MUST allow a PCC to send a request message to a PCE to request path
computation, and for a PCE to reply with a response message to the computation, and for a PCE to reply with a response message to the
requesting PCC once the path has been computed. requesting PCC once the path has been computed.
In addition to this request-response mode, there are cases where In addition to this request-response mode, there are cases where
there is unsolicited communication from the PCE to the PCC (see there is unsolicited communication from the PCE to the PCC (see
Section 6.1.11). Section 6.1.11).
6.1.3 Transport 6.1.3 Transport
The PCECP may utilize an existing transport protocol or operate The PCECP SHOULD utilize an existing transport protocol that supports
directly over IP. congestion control. This transport protocol may also be used to
satisfy some requirements in other sections of this document, such as
If a transport protocol is used, it MAY be used to satisfy some reliability. The PCECP SHOULD be defined for one transport protocol
requirements stated in other sections of this document (for example, only in order to ensure interoperability. The transport protocol
reliability and security). Where requirements expressed in this MUST NOT limit the size of the message used by the PCECP.
document match the function of existing transport protocols,
consideration MUST be given to the use of those protocols.
If a transport protocol is used, it MUST NOT limit the size of the
message used by the PCECP.
6.1.4 Path Computation Requests 6.1.4 Path Computation Requests
The path computation request message MUST include at least the source The path computation request message MUST include at least the source
and destination. Note that the path computation request is for an and destination. Note that the path computation request is for an
LSP or LSP segment, and the source and destination supplied are the LSP or LSP segment, and the source and destination supplied are the
start and end of the computation being requested (i.e. of the LSP start and end of the computation being requested (i.e. of the LSP
segment). segment).
The path computation request message MUST support the inclusion of a The path computation request message MUST support the inclusion of a
skipping to change at page 7, line 36 skipping to change at page 8, line 19
The path computation response message MUST allow the PCE to return The path computation response message MUST allow the PCE to return
various elements including, at least, the computed path(s). various elements including, at least, the computed path(s).
The protocol MUST be capable of returning any explicit path that The protocol MUST be capable of returning any explicit path that
would be acceptable for use for MPLS and GMPLS LSPs once converted to would be acceptable for use for MPLS and GMPLS LSPs once converted to
an Explicit Route Object for use in RSVP-TE signaling. In addition, an Explicit Route Object for use in RSVP-TE signaling. In addition,
anything that can be expressed in an Explicit Route Object MUST be anything that can be expressed in an Explicit Route Object MUST be
capable of being returned in the computed path. Note that the capable of being returned in the computed path. Note that the
resultant path(s) may be made up of a set of strict or loose hops, or 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 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 the form of a non-simple abstract node. See [RFC3209] for the
definition of strict hop, loose hop, and abstract node. definition of strict hop, loose hop, and abstract node.
A positive response from the PCE MUST include the paths that have A positive response from the PCE MUST include the paths that have
been computed. A positive PCECP computation response MUST support been computed. A positive PCECP computation response MUST support
the inclusion of a set of attributes of the computed path, such as the inclusion of a set of attributes of the computed path, such as
the path costs (e.g., cumulative link TE metrics and cumulative link the path costs (e.g., cumulative link TE metrics and cumulative link
IGP metrics) and the computed bandwidth. The latter is useful when a IGP metrics) and the computed bandwidth. The latter is useful when a
single path cannot serve the requested bandwidth and load balancing single path cannot serve the requested bandwidth and load balancing
is applied. is applied.
skipping to change at page 8, line 8 skipping to change at page 8, line 42
sent. This response MAY include further details of the reason(s) for sent. This response MAY include further details of the reason(s) for
the failure, and MAY include advice about which constraints might be the failure, and MAY include advice about which constraints might be
relaxed to be more likely to achieve a positive result. relaxed to be more likely to achieve a positive result.
The PCECP response message MUST support the inclusion of the set of The PCECP response message MUST support the inclusion of the set of
computed paths of a load-balancing path group, as well as their computed paths of a load-balancing path group, as well as their
respective bandwidths. respective bandwidths.
6.1.6 Cancellation of Pending Requests 6.1.6 Cancellation of Pending Requests
A PCC MUST be able to cancel a pending request using a notification A PCC MUST be able to cancel a pending request using an appropriate
message. A PCC that has sent a request to a PCE and no longer needs message. A PCC that has sent a request to a PCE and no longer needs
a response, for instance because it no longer wants to set up the a response, for instance because it no longer wants to set up the
associated service, MUST be able to notify the PCE that it can clear associated service, MUST be able to notify the PCE that it can clear
the request (i.e. stop the computation if already started, and clear the request (i.e. stop the computation if already started, and clear
the context). The PCE may also wish to cancel a pending request the context). The PCE may also wish to cancel a pending request
because of some congested state. because of some congested state.
6.1.7 Multiple Requests and Responses 6.1.7 Multiple Requests and Responses
It MUST be possible to send multiple path computation requests It MUST be possible to send multiple path computation requests
skipping to change at page 9, line 13 skipping to change at page 9, line 47
In particular, it MUST allow for the detection and recovery of lost In particular, it MUST allow for the detection and recovery of lost
messages to occur quickly and not impede the operation of the PCECP. messages to occur quickly and not impede the operation of the PCECP.
In some cases (e.g. after link failure), a large number of PCCs may In some cases (e.g. after link failure), a large number of PCCs may
simultaneously send requests to a PCE, leading to a potential simultaneously send requests to a PCE, leading to a potential
saturation of the PCEs. The PCECP MUST support indication of saturation of the PCEs. The PCECP MUST support indication of
congestion state and rate limitation state. This should enable, for congestion state and rate limitation state. This should enable, for
example, a PCE to limit the rate of incoming request messages if the example, a PCE to limit the rate of incoming request messages if the
request rate is too high. request rate is too high.
The PCECP MUST provide: The PCECP or its transport protocol MUST provide:
- Detection and report of lost or corrupted messages - Detection and report of lost or corrupted messages
- Automatic attempts to retransmit lost messages without reference to - Automatic attempts to retransmit lost messages without reference to
the application the application
- Handling of out-of-order messages - Handling of out-of-order messages
- Handling of duplicate messages - Handling of duplicate messages
- Flow control and back-pressure to enable throttling of requests and - Flow control and back-pressure to enable throttling of requests and
responses responses
- Rapid PCECP communication failure detection - Rapid PCECP communication failure detection
- Distinction between partner failure and communication channel - Distinction between partner failure and communication channel
skipping to change at page 9, line 37 skipping to change at page 10, line 20
in the chosen transport mechanisms, these functions SHOULD be based in the chosen transport mechanisms, these functions SHOULD be based
on and re-use where possible techniques developed in other protocols on and re-use where possible techniques developed in other protocols
to overcome the same shortcomings. Functionality MUST NOT be added to overcome the same shortcomings. Functionality MUST NOT be added
to the PCECP where the chosen transport protocol already provides it. to the PCECP where the chosen transport protocol already provides it.
6.1.9 Secure Message Exchange 6.1.9 Secure Message Exchange
The PCC-PCE communication protocol MUST include provisions to ensure The PCC-PCE communication protocol MUST include provisions to ensure
the security of the exchanges between the entities. In particular, the security of the exchanges between the entities. 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 (e.g., authentication), snooping (e.g., preservation of confidentiality of
packet filtering, rate limiting, no promiscuous listening). Where information through techniques such as encryption) and DOS attacks
the PCE-PCC communication takes place entirely within one limited (e.g., packet filtering, rate limiting, no promiscuous listening).
domain, the use of a private address space which is not available to Once a PCC is identified and authenticated, it has the same
customer systems MAY be used to help protect the information privileges as all other PCCs.
exchange, but other mechanisms MUST also be available.
This function may be provided by the transport protocol or directly To ensure confidentiality, the PCECP SHOULD allow local policy to be
by the PCECP. configured on the PCE to not provide explicit path(s). If a PCC
requests an explicit path when this is not allowed, the PCE MUST
return an error message to the requesting PCC and the pending path
computation request MUST be discarded.
See Section 7 for further discussion of security considerations. Authorization requirements [RFC3127] include reject capability,
reauthorization on demand, support for access rules and filters, and
unsolicited disconnect.
Where the PCE-PCC communication takes place entirely within one
limited domain, the use of a private address space which is not
available to customer systems MAY be used to help protect the
information exchange, but other mechanisms MUST also be available.
These functions may be provided by the transport protocol or directly
by the PCECP. See Section 7 for further discussion of security
considerations.
6.1.10 Request Prioritization 6.1.10 Request Prioritization
The PCECP MUST allow a PCC to specify the priority of a computation The PCECP MUST allow a PCC to specify the priority of a computation
request. request.
Implementation of priority-based activity within a PCE is subject to Implementation of priority-based activity within a PCE is subject to
implementation and local policy. This application processing is out implementation and local policy. This application processing is out
of scope of the PCECP. of scope of the PCECP.
6.1.11 Unsolicited Notifications 6.1.11 Unsolicited Notifications
The normal operational mode is for the PCC to make path computation The normal operational mode is for the PCC to make path computation
requests to the PCE, and for the PCE to respond. requests to the PCE, and for the PCE to respond.
The PCECP MUST support unsolicited notifications from PCE to PCC, or The PCECP MUST support unsolicited notifications from PCE to PCC, or
PCC to PCE. This requirement facilitates the unsolicited PCC to PCE. This requirement facilitates the unsolicited
communication of information and alerts between PCCs and PCEs. communication of information and alerts between PCCs and PCEs. As
specified in Section 6.1.8, these notification messages must be
supported by a reliable transmission protocol. The PCECP MAY also
support response messages to the unsolicited notification messages.
6.1.12 Asynchronous Communication 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
PCC MUST NOT have to wait for a response to one request before it can PCC MUST NOT have to wait for a response to one request before it can
make another request. make another request.
It MUST also be possible to have the order of responses differ from It MUST also be possible to have the order of responses differ from
the order of the corresponding requests. This may occur, for the order of the corresponding requests. This may occur, for
instance, when path request messages have different priorities (see instance, when path request messages have different priorities (see
skipping to change at page 11, line 6 skipping to change at page 11, line 52
request/response messages (as distinct from processing the request/response messages (as distinct from processing the
computation requests themselves). computation requests themselves).
6.1.14 Extensibility 6.1.14 Extensibility
The PCECP MUST provide a way for the introduction of new path The PCECP MUST provide a way for the introduction of new path
computation constraints, diversity types, objective functions, computation constraints, diversity types, objective functions,
optimization methods and parameters, etc., without requiring optimization methods and parameters, etc., without requiring
major modifications in the protocol. major modifications in the protocol.
The PCECP MUST be easily extensible to support various PCE based For example, the PCECP MUST be extensible to support various PCE
applications that have been currently identified including: based applications, such as the following:
- intra-area path computation [PCECP-INTER-AREA] - intra-area path computation
- inter-area path computation - inter-area path computation [PCECP-INTER-AREA]
- inter-AS intra provider and inter-AS inter-provider path - inter-AS intra provider and inter-AS inter-provider path
computation computation
- inter-layer path computation [PCECP-INTER-LAYER] - inter-layer path computation [PCECP-INTER-LAYER]
The PCECP MUST support the requirements specified in the The PCECP MUST support the requirements specified in the
application-specific requirements documents. The PCECP MUST also application-specific requirements documents. The PCECP MUST also
allow extensions as more PCE applications will be introduced in the allow extensions as more PCE applications will be introduced in the
future. future.
The PCECP SHOULD also be extensible to support future applications The PCECP SHOULD also be extensible to support future applications
skipping to change at page 11, line 32 skipping to change at page 12, line 26
instance, point-to-multipoint path computations, multi-hop pseudowire instance, point-to-multipoint path computations, multi-hop pseudowire
path computation, etc. path computation, 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.15 Scalability 6.1.15 Scalability
The PCECP MUST scale well, at least as good as linearly, with an The PCECP MUST scale well, at least as good as linearly, with an
increase of any of the following parameters (note, minimum order of increase of any of the following parameters. Minimum order of
magnitude estimates of what the PCECP should support are given in magnitude estimates of what the PCECP should support are given in
parenthesis): parenthesis (note: these are requirements on the PCECP, not a PCE):
- number of PCCs (1000/domain) - number of PCCs (1000/domain)
- number of PCEs (100/domain) - number of PCEs (100/domain)
- number of PCCs communicating with a single PCE (1000) - number of PCCs communicating with a single PCE (1000)
- number of PCEs communicated to by a single PCC (100) - number of PCEs communicated to by a single PCC (100)
- number of domains (20) - number of domains (20)
- number of path request messages (average of 10/second/PCE) - number of path request messages (average of 10/second/PCE)
- handling bursts of requests (burst of 100/second/PCE within a 10- - handling bursts of requests (burst of 100/second/PCE within a 10-
second interval). second interval).
skipping to change at page 12, line 10 skipping to change at page 12, line 54
when multiple recomputations are requested. The PCECP MUST handle when multiple recomputations are requested. The PCECP MUST handle
the congestion in a graceful way so that it does not unduly impact 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 rest of the network, and so that it does not gate the ability of
the PCE to perform computation. the PCE to perform computation.
6.1.16 Constraints 6.1.16 Constraints
This section provides a list of generic constraints that MUST be This section provides a list of generic constraints that MUST be
supported by the PCECP. Other constraints may be added to service supported by the PCECP. Other constraints may be added to service
specific applications as identified by separate application-specific specific applications as identified by separate application-specific
requirements documents. requirements documents. Note that the provisions of Section 6.1.14
mean that new constraints can be added to this list without impacting
Note that the absence of a constraint in this list does not mean that the protocol to a level that requires major protocol changes.
the 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 to a level that requires major
protocol changes.
Here is the list of generic constraints that MUST be supported: The set of supported generic constraints MUST include at the least
The following:
o MPLS-TE and GMPLS generic constraints: o MPLS-TE and GMPLS generic constraints:
- Bandwidth - Bandwidth
- Affinities inclusion/exclusion - Affinities inclusion/exclusion
- Link, Node, SRLG inclusion/exclusion - Link, Node, SRLG inclusion/exclusion
- Maximum end-to-end IGP metric - Maximum end-to-end IGP metric
- Maximum Hop Count - Maximum Hop Count
- Maximum end-to-end TE metric - Maximum end-to-end TE metric
- Degree of paths disjointess (Link, Node, SRLG) - Degree of paths disjointness (Link, Node, SRLG)
o MPLS-TE specific constraints o MPLS-TE specific constraints
- Class-type - Class-type
- Local protection - Local protection
- Node protection - Node protection
- Bandwidth protection - Bandwidth protection
o GMPLS specific constraints o GMPLS specific constraints
- Switching type, encoding type - Switching type, encoding type
- Link protection type - Link protection type
6.1.17 Objective Functions Supported 6.1.17 Objective Functions Supported
This section provides a list of generic objective functions that MUST This section provides a list of generic objective functions that MUST
be supported by the PCECP. Other objectives functions MAY be added be supported by the PCECP. Other objectives functions MAY be added
to service specific applications as identified by separate to service specific applications as identified by separate
application-specific requirements documents. application-specific requirements documents. Note that the
provisions of Section 6.1.14 mean that new objective functions MAY be
Note that the absence of an objective function in this list does not added to this list without impacting the protocol.
mean that the objective function may not be supported. Note also
that the provisions of Section 6.1.14 mean that new objective
functions MAY be added to this list without impacting the protocol.
The PCECP MUST support the following "unsynchronized" objective The PCECP MUST support at least the following "unsynchronized"
functions: functions:
- Minimum cost path with respect to a specified metric(shortest path) - Minimum cost path with respect to a specified metric(shortest path)
- Least loaded path - Least loaded path
- Maximum available bandwidth path - Maximum available bandwidth path
Also the PCECP MUST support the following "synchronized" objective Also the PCECP MUST support at least the following "synchronized"
functions: objective functions:
- Minimize aggregate bandwidth consumption on all links - Minimize aggregate bandwidth consumption on all links
- Maximize the residual bandwidth on the most loaded link - Maximize the residual bandwidth on the most loaded link
- Minimize the cumulative cost of a set of diverse paths. - Minimize the cumulative cost of a set of diverse paths.
6.2 Deployment Support Requirements 6.2 Deployment Support Requirements
6.2.1 Support for Different Service Provider Environments 6.2.1 Support for Different Service Provider Environments
The PCECP MUST operate in various different service provider network The PCECP must at least support the following environments:
environments that utilize an IP-based control plane, including
- MPLS-TE and GMPLS networks - MPLS-TE and GMPLS networks
- packet and non-packet networks - packet and non-packet 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 For example, PCECP is possibly applicable to packet networks (e.g.,
path computation can be found in [PCE-ARCH]. IP networks), non-packet networks (e.g., TDM transport), and perhaps
to multi-layer GMPLS control plane environments. Definitions of
centralized, distributed, single, and multiple PCE path computation
can be found in [PCE-ARCH].
6.2.2 Policy Support 6.2.2 Policy Support
The PCECP MUST allow for the use of policies to accept/reject The PCECP MUST allow for the use of policies to accept/reject
requests, and include the ability for a PCE to supply sufficient requests. It MUST include the ability for a PCE to supply sufficient
detail when it rejects a request for policy reasons to allow the PCC detail when it rejects a request for policy reasons to allow the PCC
to determine the reason for rejection or failure. For example, to determine the reason for rejection or failure. For example,
filtering could be required for a PCE that serves one domain (perhaps filtering could be required for a PCE that serves one domain (perhaps
an AS) such that all requests that come from another domain (AS) are an AS) such that all requests that come from another domain (AS) are
rejected. However, specific policy details are left to rejected. However, specific policy details are left to
application-specific PCECP requirements. Actual policies, application-specific PCECP requirements. Actual policies,
configuration of policies, and applicability of policies are out of configuration of policies, and applicability of policies are out of
scope. scope.
Note that work on supported policy models and the corresponding Note that work on supported policy models and the corresponding
skipping to change at page 14, line 15 skipping to change at page 15, line 9
- distinguish PCC/PCE node failures from PCC-PCE connectivity - distinguish PCC/PCE node failures from PCC-PCE connectivity
failures, after the PCC-PCE communication is recovered. failures, after the PCC-PCE communication is recovered.
The aliveness detection mechanism MUST ensure reciprocal knowledge of The aliveness detection mechanism MUST ensure reciprocal knowledge of
PCE and PCC liveness. PCE and PCC liveness.
6.3.2 Protocol Recovery 6.3.2 Protocol Recovery
In the event of the failure of a sender or of the communication In the event of the failure of a sender or of the communication
channel, the PCECP, upon recovery, MUST support resynchronization of channel, the PCECP, upon recovery, MUST support resynchronization of
information and requests between the sender and the receiver, and information (e.g. PCE congestion status) and requests between the
this SHOULD be arranged so as to minimize repeat data transfer. sender and the receiver, and this SHOULD be arranged so as to
minimize repeat data transfer.
6.3.3 LSP Rerouting & Reoptimization 6.3.3 LSP Rerouting & Reoptimization
If an LSP fails owing to the failure of a link or node that it If an LSP fails owing to the failure of a link or node that it
traverses, a new computation request may be made to a PCE in order to traverses, a new computation request may be made to a PCE in order to
repair the LSP. Since the PCC cannot know that the PCE's TED has been repair the LSP. Since the PCC cannot know that the PCE's TED has been
updated to reflect the failure network information, it is useful to updated to reflect the failure network information, it is useful to
include this information in the new path computation request. Also, include this information in the new path computation request. Also,
in order to re-use the resources used by the old LSP, it may be in order to re-use the resources used by the old LSP, it may be
advantageous to indicate the route of the old LSP as part of the new advantageous to indicate the route of the old LSP as part of the new
path computation request. path computation request.
Hence the path computation request message MUST allow an indication Hence the path computation request message MUST allow an indication
of whether the computation is for LSP restoration, and MUST support of whether the computation is for LSP restoration, and MUST support
the inclusion of the previously computed path as well as the identity the inclusion of the previously computed path as well as the identity
of the failed element. Note that the old path might only be useful of the failed element. Note that the old path might only be useful
if the old LSP has not yet been torn down. if the old LSP has not yet been torn down. The PCE MAY or MAY not
take into account failure indication carried in a given request when
handling subsequent requests. This should be driven by local policy
decision.
IP addresses are used to identify PCCs and PCEs. However, as noted
in Section 6.1.9, a private address space MAY be used if the PCE-PCC
communication takes place entirely within one limited domain.
Note that a network failure may impact a large number of LSPs. In Note that a network failure may impact a large number of LSPs. In
this case, a potentially large number of PCCs is going to this case, a potentially large number of PCCs will simultaneously
simultaneously send requests to the PCE. The PCECP MUST properly send requests to the PCE. The PCECP MUST properly handle such
handle such overload situations, such as for instance through overload situations, such as for instance through throttling of
throttling of requests as set forth in section 6.1.8. requests as set forth in section 6.1.8.
The path computation request message MUST support TE LSP path The path computation request message MUST support TE LSP path
reoptimization and the inclusion of a previously computed path. This reoptimization and the inclusion of a previously computed path. This
will help ensure optimal routing of a reoptimized path, since it will will help ensure optimal routing of a reoptimized path, since it will
allow the PCE to avoid double bandwidth accounting and help reduce allow the PCE to avoid double bandwidth accounting and help reduce
blocking issues. blocking issues.
6.4 Requirements Summary
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
Path computation request includes source &
destination MUST 6.1.4
Support path constraints (e.g., bandwidth, hops,
affinities) to include/exclude 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
Allow indicating the metric type (IGP or TE) to
be used for shortest path selection MUST 6.1.4
Allow indicating the set of path attributes
required in response message MUST 6.1.4
Allow indicating if load-balancing is allowed MUST 6.1.4
Support path computation responses MUST 6.1.5
Negative response support reasons for failure,
constraints to relax to achieve positive result SHOULD 6.1.5
Support inclusion of set of path attributes MUST 6.1.5
Support inclusion of set of computed paths of a
load-balancing path group, as well as their
respective bandwidth MUST 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 PCECP
itself or transport protocol) MUST 6.1.8
Allow detection & recovery of lost messages to
occur quickly & not impede operation of PCECP MUST 6.1.8
Handle overload situations without significant
decrease in performance, e.g., through
throttling of requests MUST 6.1.8
Detect/report lost/corrupted messages, retransmit
lost messages, handle out-of-order messages &
duplicate messages, provide flow control/
back-pressure to throttle messages, detect
PCECP communication failure detection MUST 6.1.8
Functionality added to PCECP if transport
protocol provides it SHOULD NOT 6.1.8
Secure message exchange (provided by PCECP 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
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., point-to-multipoint path
computations) SHOULD 6.1.14
Scale at least linearly with number of PCCs,
PCEs, PCCs communicating with single PCE, PCEs
communicated to by single PCC, domains, path
requests, handling bursts of requests MUST 6.1.15
Support path computation constraints MUST 6.1.16
Support "unsynchronized" & "synchronized"
objective functions MUST 6.1.17
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, PCECP failure
detection MUST 6.3.1
Protocol recovery support resynchronization of
information & requests between sender &
receiver MUST 6.3.2
Minimize repeat data transfer, allow PCE to
respond to computation requests issued before
failure without requests being re-issued SHOULD 6.3.2
Stateful PCE able to resynchronize/recover
states (e.g., LSP status, paths) after restart SHOULD 6.3.2
Allow indicating if computation is for LSP
restoration (support inclusion of previously
computed path & failed element) MUST 6.3.3
Support path reoptimization & inclusion of a
previously computed path MUST 6.3.3
7. Security Considerations 7. Security Considerations
Key management MUST be provided by the PCECP to provide for the
authenticity and integrity of PCECP messages. This will allow
protecting against PCE or PCC impersonation and also against message
content falsification.
The impact of the use of a PCECP MUST be considered in the light of The impact of the use of a PCECP MUST be considered in the light of
the impact that it has on the security of the existing routing and the impact that it has on the security of the existing routing and
signaling protocols and techniques in use within the network. signaling protocols and techniques in use within the network.
Intra-domain security is impacted since there is a new interface, Intra-domain security is impacted since there is a new interface,
protocol and element in the network. Any host in the network could protocol and element in the network. Any host in the network could
impersonate a PCC, and receive detailed information on network paths. impersonate a PCC, and receive detailed information on network paths.
Any host could also impersonate a PCE, both gathering information Any host could also impersonate a PCE, both gathering information
about the network before passing the request on to a real PCE, and about the network before passing the request on to a real PCE, and
spoofing responses. Some protection here depends on the security of spoofing responses. Some protection here depends on the security of
the PCE discovery process (see [PCE-DISC-REQ]). An increase in the PCE discovery process (see [PCE-DISC-REQ]). An increase in
skipping to change at page 17, line 44 skipping to change at page 16, line 38
It should be observed that the use of an external PCE introduces It should be observed that the use of an external PCE introduces
additional security issues. Most notable amongst these are: additional security issues. Most notable amongst these are:
- interception of PCE requests or responses - interception of PCE requests or responses
- impersonation of PCE or PCC - impersonation of PCE or PCC
- DoS attacks on PCEs or PCCs - DoS attacks on PCEs or PCCs
The PCECP MUST address these issues in detail using authentication, The PCECP MUST address these issues in detail using authentication,
encryption and DoS protection techniques. See also Section 6.1.9. encryption and DoS protection techniques. See also Section 6.1.9.
There are security implications of allowing arbitrary objective
functions, as discussed in Section 6.1.17, and the PCECP MUST allow
mitigating the risk of, for example, a PCC using complex objectives
to intentionally drive a PCE into resource exhaustion.
8. Manageability Considerations 8. Manageability Considerations
Manageability of the PCECP MUST address the following considerations: Manageability of the PCECP MUST address the following considerations:
- the need for a MIB module for control and monitoring of PCECP - the need for a MIB module for control and monitoring of PCECP
- the need for built-in diagnostic tools to test the operation of the - the need for built-in diagnostic tools to test the operation of the
protocol (e.g., partner failure detection, OAM, etc.) protocol (e.g., partner failure detection, OAM, etc.)
- configuration implications for the protocol - configuration implications for the protocol
PCECP operations MUST be modeled and controlled through appropriate PCECP operations MUST be modeled and controlled through appropriate
MIB modules. Statistics gathering will form an important part of the MIB modules. There are enough specific differences between PCCs and
operation of the PCECP. The operator MUST be able to determine PCECP PCEs to lead to the need of defining separate MIB modules.
historical interactions and the success rate of requests using data Statistics gathering will form an important part of the operation of
from MIB modules. Similarly, it is important for an operator to be the PCECP. The MIB modules MUST provide information that will allow
able to determine PCECP and PCE load and whether an individual PCC is an operator to determine PCECP historical interactions and the
responsible for a disproportionate amount of the load. It MUST be success rate of requests. Similarly, it is important for an operator
possible, through use of MIB modules, to record and inspect to be able to determine PCECP and PCE load and whether an individual
PCC is responsible for a disproportionate amount of the load. It
MUST be possible, through use of MIB modules, to record and inspect
statistics about the PCECP communications, including issues such as statistics about the PCECP communications, including issues such as
malformed messages, unauthorized messages and messages discarded malformed messages, unauthorized messages and messages discarded
owing to congestion. owing to congestion.
The new MIB modules should also be used to provide notifications The new MIB modules should also be used to provide notifications
(traps) when thresholds are crossed or when important events occur. (traps) when thresholds are crossed or when important events occur.
For example, the MIB module may support indication of exceeding the
congestion state threshold or rate limitation state.
PCECP techniques must enable a PCC to determine the liveness of a PCE PCECP techniques must enable a PCC to determine the liveness of a PCE
both before it sends a request and in the period between sending a both before it sends a request and in the period between sending a
request and receiving a response. request and receiving a response.
It is also important for a PCE to know about the liveness of PCCs to It is also important for a PCE to know about the liveness of PCCs to
gain a predictive view of the likely loading of a PCE in the future, gain a predictive view of the likely loading of a PCE in the future,
and to allow a PCE to abandon processing of a received request. and to allow a PCE to abandon processing of a received request.
The PCECP MUST support indication of congestion state and rate The PCECP MUST support indication of congestion state and rate
skipping to change at page 18, line 37 skipping to change at page 17, line 39
function. function.
9. IANA Considerations 9. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
10. Acknowledgements 10. Acknowledgements
The authors would like to extend their warmest thanks to (in The authors would like to extend their warmest thanks to (in
alphabetical order) Lou Berger, Ross Callon, Adrian Farrel, Thomas alphabetical order) Lou Berger, Ross Callon, Adrian Farrel, Thomas
Morin, Dimitri Papadimitriou, and JP Vasseur for their review and Morin, Dimitri Papadimitriou, Robert Sparks, and JP Vasseur for their
suggestions. review and suggestions.
11. Normative References 11. Normative References
[PCE-ARCH] Farrel, A., Vasseur, JP, Ash, J., "Path Computation [PCE-ARCH] Farrel, A., Vasseur, JP, Ash, J., "Path Computation
Element (PCE) Architecture", work in progress. Element (PCE) Architecture", work in progress.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
12. Informational References 12. Informational References
skipping to change at page 19, line 15 skipping to change at page 18, line 15
[PCE-DISC-REQ] Le Roux, JL, et. al., "Requirements for Path [PCE-DISC-REQ] Le Roux, JL, et. al., "Requirements for Path
Computation Element (PCE) Discovery," work in progress. Computation Element (PCE) Discovery," work in progress.
[PCECP-INTER-AREA] Le Roux, JL, et. al., "PCE Communication Protocol [PCECP-INTER-AREA] Le Roux, JL, et. al., "PCE Communication Protocol
(PCECP) specific requirements for Inter-Area (G)MPLS Traffic (PCECP) specific requirements for Inter-Area (G)MPLS Traffic
Engineering," work in progress. Engineering," work in progress.
[PCECP-INTER-LAYER] Oki, E., et. al., "PCC-PCE Communication [PCECP-INTER-LAYER] Oki, E., et. al., "PCC-PCE Communication
Requirements for Inter-Layer Traffic Engineering," work in progress. Requirements for Inter-Layer Traffic Engineering," work in progress.
13. Authors' & Contributors' Addresses [RFC3209] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels," RFC 3209, December 2001.
[RFC3127] Mitton, D., et. al., "Authentication, Authorization, and
Accounting: Protocol Evaluation," RFC 3127, June 2001.
13. Authors' Addresses
Jerry Ash (Editor) Jerry Ash (Editor)
AT&T AT&T
Room MT D5-2A01 Room MT D5-2A01
200 Laurel Avenue 200 Laurel Avenue
Middletown, NJ 07748, USA Middletown, NJ 07748, USA
Phone: (732)-420-4578 Phone: (732)-420-4578
Email: gash@att.com Email: gash@att.com
Jean-Louis Le Roux (Editor) Jean-Louis Le Roux (Editor)
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex, FRANCE 22307 Lannion Cedex, FRANCE
Email: jeanlouis.leroux@francetelecom.com Email: jeanlouis.leroux@francetelecom.com
Alia K. Atlas
Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
Email: akatlas@alum.mit.edu
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: 408 527 0677
Email: dcheng@cisco.com
Durga Gangisetti
MCI
Email: durga.gangisetti@mci.com
Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
Phone: 3-6678-3103
Email: ke-kumaki@kddi.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
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. 42 change blocks. 
296 lines changed or deleted 203 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/