返回首页

RFC 4657 - Path Computation Element (PCE) Communication Prot(2)

时间:2006-11-02 来源: 作者: 点击:
whenmultiplerecomputationsarerequested.ThePCECPMUSThandle thecongestioninagracefulwaysothatitdoesnotundulyimpact therestofthenetwork,andsothatitdoesnotgatetheabilityof thePCEtoperformcomputation. 5.1
  
   when multiple recomputations are requested.  The PCECP MUST 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.

5.1.16.  Constraints

   This section provides a list of generic constraints that MUST be
   supported by the PCECP.  Other constraints may be added to service
   specific applications as identified by separate application-specific
   requirements documents.  Note that the provisions of Section 5.1.14
   mean that new constraints can be added to this list without impacting
   the protocol to a level that requires major protocol changes.

   The set of supported generic constraints MUST include at least the
   following:

   o MPLS-TE and GMPLS generic constraints:
     - Bandwidth
     - Affinities inclusion/exclusion
     - Link, Node, Shared Risk Link Group (SRLG) inclusion/exclusion
     - Maximum end-to-end IGP metric
     - Maximum hop count
     - Maximum end-to-end TE metric
     - Degree of paths disjointness (Link, Node, SRLG)

   o MPLS-TE specific constraints
     - Class-type
     - Local protection
     - Node protection
     - Bandwidth protection

   o GMPLS specific constraints
     - Switching type, encoding type
     - Link protection type

5.1.17.  Objective Functions Supported

   This section provides a list of generic objective functions that MUST
   be supported by the PCECP.  Other objective functions MAY be added to
   service specific applications as identified by separate application-
   specific requirements documents.  Note that the provisions of Section
   5.1.14 mean that new objective functions MAY be added to this list
   without impacting the protocol.

   The PCECP MUST support at least the following "unsynchronized"
   functions:

   - Minimum cost path with respect to a specified metric
     (shortest path)
   - Least loaded path
   - Maximum available bandwidth path

   Also, the PCECP MUST support at least the following "synchronized"
   objective functions:

   - Minimize aggregate bandwidth consumption on all links
   - Maximize the residual bandwidth on the most loaded link
   - Minimize the cumulative cost of a set of diverse paths

5.2.  Deployment Support Requirements

5.2.1.  Support for Different Service Provider Environments

   The PCECP must at least support the following environments:

   - MPLS-TE and GMPLS networks
   - Packet and non-packet networks
   - Centralized and distributed PCE path computation
   - Single and multiple PCE path computation

   For example, PCECP is possibly applicable to packet networks (e.g.,
   IP networks), non-packet networks (e.g., time-division multiplexed
   (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 [RFC4655].

5.2.2.  Policy Support

   The PCECP MUST allow for the use of policies to accept/reject
   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
   to determine the reason for rejection or failure.  For example,
   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
   rejected.  However, specific policy details are left to application-
   specific PCECP requirements.  Actual policies, configuration of
   policies, and applicability of policies are out of scope.

   Note that work on supported policy models and the corresponding
   requirements/implications is being undertaken as a separate work item
   in the PCE working group.

   PCECP messages MUST be able to carry transparent policy information.

5.3.  Aliveness Detection & Recovery Requirements

5.3.1.  Aliveness Detection

   The PCECP MUST allow a PCC/PCE to

   - check the liveliness of the PCC-PCE communication,
   - rapidly detect PCC-PCE communication failure (indifferently to
     partner failure or connectivity failure), and
   - distinguish PCC/PCE node failures from PCC-PCE connectivity
     failures, after the PCC-PCE communication is recovered.

   The aliveness detection mechanism MUST ensure reciprocal knowledge of
   PCE and PCC liveness.

5.3.2.  Protocol Recovery

   In the event of the failure of a sender or of the communication
   channel, the PCECP, upon recovery, MUST support resynchronization of
   information (e.g., PCE congestion status) and requests between the
   sender and the receiver; this SHOULD be arranged so as to minimize
   repeat data transfer.

5.3.3.  LSP Rerouting & Reoptimization

   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
   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 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
   advantageous to indicate the route of the old LSP as part of the new
   path computation request.

   Hence the path computation request message MUST allow an indication
   of whether the computation is for LSP restoration, and it MUST
   support 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 if the old LSP has not yet been torn down.  The PCE MAY choose
   to take failure indication information carried in a given request
   into account when handling subsequent requests.  This should be
   driven by local policy decision.

   Note that a network failure may impact a large number of LSPs.  In
   this case, a potentially large number of PCCs will simultaneously
   send requests to the PCE.  The PCECP MUST properly handle such
   overload situations, such as, for instance, through throttling of
   requests as set forth in Section 5.1.8.

   The path computation request message MUST support TE LSP path
   reoptimization and the inclusion of a previously computed path.  This
   will help ensure optimal routing of a reoptimized path, since it will
   allow the PCE to avoid double bandwidth accounting and help reduce
   blocking issues.

6.  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 light of the
   impact that it has on the security of the existing routing and
   signaling protocols and techniques in use within the network.
   Intra-domain security is impacted since there is a new interface,
   protocol, and element in the network.  Any host in the network could
   impersonate a PCC and receive detailed information on network paths.
   Any host could also impersonate a PCE, both gathering information
   about the network before passing the request on to a real PCE and
   spoofing responses.  Some protection here depends on the security of
   the PCE discovery process (see [PCE-DISC-REQ]).  An increase in
   inter-domain information flows may increase the vulnerability to
   security attacks, and the facilitation of inter-domain paths may
   increase the impact of these security attacks.

   Of particular relevance are the implications for confidentiality
   inherent in a PCECP 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 an external PCE introduces
   additional security issues.  Most notable among these are the
   following:

   - Interception of PCE requests or responses
   - Impersonation of PCE or PCC
   - DoS attacks on PCEs or PCCs

   The PCECP MUST address these issues in detail using authentication,
   encryption, and DoS protection techniques.  See also Section 5.1.9.

   There are security implications of allowing arbitrary objective
   functions, as discussed in Section 5.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.

7.  Manageability 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 built-in diagnostic tools to test the operation of the
     protocol (e.g., partner failure detection, Operations
     Administration and Maintenance (OAM), etc.)
   - Configuration implications for the protocol

   PCECP operations MUST be modeled and controlled through appropriate
   MIB modules.  There are enough specific differences between PCCs and
   PCEs to lead to the need of defining separate MIB modules.
   Statistics gathering will form an important part of the operation of
   the PCECP.  The MIB modules MUST provide information that will allow
   an operator to determine PCECP historical interactions and the
   success rate of requests.  Similarly, it is important for an operator
   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
   malformed messages, unauthorized messages, and messages discarded
   owing to congestion.

   The new MIB modules should also be used to provide notifications
   (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
   both before it sends a request and in the period between sending a
   request and receiving a response.

   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
   and to allow a PCE to abandon processing of a received request.

   The PCECP MUST support indication of congestion state and rate
   limitation state, and MAY allow the operator to control such a
   function.

8.  Contributors

   This document is the result of the PCE Working Group PCECP
   requirements design team joint effort.  In addition to the
   authors/editors listed in the "Authors’ Addresses" section, the
   following are the design team members who contributed to the
   document:

   Alia K.  Atlas
   Google Inc.
   1600 Amphitheatre Parkway
   Mountain View, CA  94043 USA
   EMail: akatlas@alum.mit.edu

   Arthi Ayyangar
   Nuova Systems,
   2600 San Tomas Expressway
   Santa Clara, CA 95051
   EMail: arthi@nuovasystems.com

   Nabil Bitar
   Verizon
   40 Sylvan Road
   Waltham, MA 02145 USA
   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

9.  Acknowledgements

   The authors would like to extend their warmest thanks to (in
   alphabetical order) Lou Berger, Ross Callon, Adrian Farrel, Thomas
   Morin, Dimitri Papadimitriou, Robert Sparks, and J.P. Vasseur for
   their review and suggestions.

10.  References

10.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.

10.2.  Informative References

   [METRIC]            Le Faucheur, F., Uppili, R., Vedrenne, A.,
                       Merckx, P., and T. Telkamp, "Use of Interior
                       Gateway Protocol (IGP) Metric as a second MPLS
                       Traffic Engineering (TE) Metric", BCP 87, RFC
                       3785, May 2004.

   [PCE-DISC-REQ]      Le Roux, J.L., et al., "Requirements for Path
                       Computation Element (PCE) Discovery", Work in
                       Progress.

   [PCECP-INTER-AREA]  Le Roux, J.L., et al., "PCE Communication
                       Protocol (PCECP) specific requirements for
                       Inter-Area (G)MPLS Traffic Engineering", Work in
                       Progress.

   [PCECP-INTER-LAYER] Oki, E., et al., "PCC-PCE Communication
                       Requirements for Inter-Layer Traffic
                       Engineering", Work in Progress.

   [PCECP-INTER-AS]    Bitar, N., Zhang, R., Kumaki, K., "Inter-AS
                       Requirements for the Path Computation Element
                       Communication Protocol (PCECP)", Work in
                       Progress.

   [RFC3209]           Awduche, D., Berger, L., Gan, D., Li, T.,
                       Srinivasan, V., and G. Swallow, "RSVP-TE:
                       Extensions to RSVP for LSP Tunnels", RFC 3209,
                       December 2001.

   [RFC3127]           Mitton, D., St.Johns, M., Barkley, S., Nelson,
                       D., Patil, B., Stevens, M., and B. Wolff,
                       "Authentication, Authorization, and Accounting:
                       Protocol Evaluation", RFC 3127, June 2001.

Authors’ Addresses

   Jerry Ash (Editor)
   AT&T
   Room MT D5-2A01
   200 Laurel Avenue
   Middletown, NJ 07748, USA

   Phone: (732)-420-4578
   EMail: gash@att.com

   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).
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容