importance in an inter-AS context, where PCE discovery may increase
the vulnerability to attacks and the consequences of these attacks.
Hence, mechanisms MUST be defined to ensure authenticity, integrity,
confidentiality, and containment of PCE discovery information:
- There MUST be a mechanism to authenticate discovery information.
- There MUST be a mechanism to verify discovery information
integrity.
- There MUST be a mechanism to encrypt discovery information.
- There MUST be a mechanism to restrict the scope of discovery to a
set of authorized PCCs and to filter PCE information disclosed at
domain boundaries (as per defined in Section 4.5).
A PCE and PCC MUST be identified by a globally unique ID, which may
be, for instance, a combination of AS number and IP address.
Mechanisms MUST be defined in order to limit the impact of a DoS
attack on the PCE discovery procedure (e.g., filter out excessive PCE
information change and flapping PCEs). Note also that DoS attacks
may be either accidental (caused by a misbehaving PCE system) or
intentional. As discussed in [RFC4657], such mechanisms may include
packet filtering, rate limiting, no promiscuous listening, and where
applicable use of private addresses spaces.
Also, key consideration MUST be given in terms of how to establish a
trust model for PCE discovery. The PCE discovery mechanism MUST
explicitly support a specific set of one or more trust models.
4.7. Extensibility
The PCE discovery mechanism MUST be flexible and extensible so as to
easily allow for the inclusion of additional PCE information that
could be defined in the future.
4.8. Scalability
The PCE discovery mechanism MUST be designed to scale well with an
increase of any of the following parameters:
- Number of PCCs discovering a given PCE.
- Number of PCEs to be discovered by a given PCC.
- Number of domains in the discovery scope.
The PCE discovery mechanism MUST NOT have an adverse effect in the
performance of other protocols (especially routing and signaling)
already operating in the network.
Note that there is no scalability requirement with regards to the
amount of information to be exchanged.
Information disclosed in the PCE discovery mechanism is relatively
static. Changes in PCE information may occur as a result of PCE
configuration updates, PCE deployment/activation, or PCE
deactivation/suppression, and should not occur as a result of the PCE
activity itself. Hence, this information is quite stable and will
not change frequently.
4.9. Operational Orders of Magnitudes
This section gives minimum order of magnitude estimates of what the
PCE discovery mechanism should support.
- Number of PCCs discovering a given PCE: 1000
- Number of PCEs to be discovered by a given PCC: 100
4.10. Manageability Considerations
Mechanisms are REQUIRED to manage PCE discovery operations. This
includes the configuration of PCE discovery functions and policies,
as well as the monitoring of the discovery protocol activity.
4.10.1. Configuration of PCE Discovery Parameters
It MUST be possible to enable and disable the PCE discovery function
at a PCC and at a PCE.
On the PCC, it MUST be possible for an operator to
activate/deactivate automatic PCE discovery. The activation of
automatic discovery MUST not prevent static configuration of PCE
information that may supplement discovered information.
On the PCE, it MUST be possible for an operator to control the
application of discovery policies by which the specific PCE is
discovered. As described in Section 4.5, this control MUST include
the ability to
- restrict the discovery scope to a set of authorized domains;
- define the type and nature of the information disclosed;
- specify the filtering and translation to be applied to the PCE
information disclosed at domain borders.
These configuration options MAY be supported through an
implementation-specific local configuration interface, or MAY be
supported via a standardised interface (such as a MIB module, as
below).
4.10.2. PCE Discovery MIB Modules
PCE discovery MIB modules MUST be specified for the control of the
function on PCCs and PCEs.
4.10.2.1. PCC MIB Module
The MIB module that will run on PCCs MUST include at least the
following:
- A control to disable automatic discovery by the PCC,
- The set of known PCEs,
- The number of known PCEs, and the number of discovered PCEs.
For each PCE reported in the MIB module, the following information
MUST be available:
- Information advertised by the PCE (i.e., discovered information),
- Information locally configured about the PCE,
- The time since the PCE was discovered,
- The time since any change to the discovered information for the
PCE.
Note that when a PCE is no longer alive (see Section 4.4), it SHOULD
no longer be reported in the PCC MIB module.
The MIB module SHOULD also provide the average and maximum rates of
arrival, departure, and modification of PCE discovery to enable
effective analysis of the operation of the protocols. Furthermore,
the MIB module SHOULD report on the operation of the discovery
protocol by counting the number of unacceptable and incomprehensible
information exchanges.
The PCC MIB module SHOULD also be used to provide notifications when
thresholds (e.g., on the maximum rate of change, on the number of
unacceptable messages) are crossed, or when important events occur
(e.g., the number of discovered PCEs decreases to zero).
4.10.2.2. PCE MIB module
The MIB module that will run on PCEs MUST include at least
- a control to disable automatic discovery announcements by the PCE;
- information to be advertised by the PCE, although this information
MAY be present as read-only;
- the discovery policies active on the PCE, although this information
MAY be present as read-only.
The MIB module SHOULD also include
- the time since the last change to the advertised PCE information;
- the time since the last change to the advertisement policies;
- control of on which interfaces the PCE issues advertisements where
this is applicable to the protocol solution selected.
Note that a PCE MAY also be configured to discover other PCEs. In
this case, it SHOULD operate the MIB module described in Section
4.10.2.1 as well as the module described here.
4.10.3. Monitoring Protocol Operations
It MUST be possible to monitor the operation of any PCE discovery
protocol. Where an existing protocol is used to support the PCE
discovery function, this monitoring SHOULD be achieved using the
techniques already defined for that protocol, enhanced by the MIB
modules described above. Where those techniques are inadequate, new
techniques MUST be developed.
Monitoring of the protocol operation demands support for at least the
following functions:
- Correlation of information advertised against information received.
- Counts of dropped, corrupt, and rejected information elements.
- Detection of ’segmented’ networks, that is, the ability to detect
and diagnose the failure of a PCE advertisement to reach a PCC.
4.10.4. Impact on Network Operations
Frequent changes in PCE information may have a significant impact on
PCCs that receive the advertisements, might destabilize the operation
of the network by causing the PCCs to swap between PCEs, and might
harm the network through excessive advertisement traffic. Hence, it
MUST be possible to apply at least the following controls:
- Configurable limit on the rate of announcement of changed
parameters at a PCE.
- Control of the impact on PCCs such as through discovery messages
rate-limiting.
- Configurable control of triggers that cause a PCC to swap to
another PCE.
5. Security Considerations
This document is a requirement document and hence does not raise by
itself any particular security issue.
A set of security requirements that MUST be addressed when
considering the design and deployment of a PCE discovery mechanism
has been identified in Section 4.6.
6. Acknowledgements
We would like to thank, in chronological order, Benoit Fondeviole,
Thomas Morin, Emile Stephan, Jean-Philippe Vasseur, Dean Cheng,
Adrian Farrel, Renhai Zhang, Mohamed Boucadair, Eric Gray, Igor
Bryskin, Dimitri Papadimitriou, Arthi Ayyangar, Andrew Dolganow, Lou
Berger, Nabil Bitar, and Kenji Kumaki.
Thanks also to Ross Callon, Ted Hardie, Dan Romascanu, Russ Housley
and Sam Hartman for their review and constructive discussions during
the final stages of publication.
7. Contributors
The following are the authors who contributed to the present
document:
Jean-Louis Le Roux (France Telecom)
Paul Mabey (Qwest Communications)
Eiji Oki (NTT)
Richard Rabbat (Fujitsu)
Ting Wo Chung (Bell Canada)
Raymond Zhang (BT Infonet)
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
8.2. Informative References
[RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, September 2006.
Contributors’ Addresses
Paul Mabey
Qwest Communications
950 17th Street
Denver, CO 80202
USA
EMail: pmabey@qwest.com
Eiji Oki
NTT
Midori-cho 3-9-11
Musashino-shi, Tokyo 180-8585
JAPAN
EMail: oki.eiji@lab.ntt.co.jp
Richard Rabbat
Fujitsu Laboratories of America
1240 East Arques Ave, MS 345
Sunnyvale, CA 94085
USA
EMail: richard@us.fujitsu.com
Ting Wo Chung
Bell Canada
181 Bay Street, Suite 350
Toronto, Ontario, M5J 2T3
CANADA
EMail: ting_wo.chung@bell.ca
Raymond Zhang
BT Infonet
2160 E. Grand Ave.
El Segundo, CA 90025
USA
EMail: raymond_zhang@infonet.com
Editor’s Address
Jean-Louis Le Roux (Editor)
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
EMail: jeanlouis.leroux@orange-ft.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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.
Intellectual Property
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
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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).