One document matched: draft-ash-pce-problem-statement-00.txt

Network Working Group                                        Jerry Ash
Internet Draft                                                    AT&T
Category: Informational                                              
Expires: December 2004                                   Adrian Farrel
                                                    Old Dog Consulting
                                                             June 2004

              Path Computation Element Problem Statement
               <draft-ash-pce-problem-statement-00.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.


Abstract

This document provides a problem statement for the proposed Path
Computation Element (PCE).  The PCE is an approach to MPLS traffic
engineering path computation that is particularly applicable in
inter-domain environments.

In this context, a domain may be an IGP area, an Autonomous System, or
some other division of computational responsibility.

An overview of solution alternatives and proposed PCE work group
charter is also provided.

Table of Contents

   1. Introduction                                             
   2. Problem Statement
   3. Overview of Solution Alternatives
   4. Proposed Charter of PCE Working Group
   5. Security Considerations                                 
   6. Acknowledgments                                         
   7. Normative References
   8. Informational References
   9. Authors' Addresses
   10. Intellectual Property Considerations
   11. Full Copyright Statement

1. Introduction

This document provides a problem statement for the proposed path
computation element (PCE) approach to computing MPLS traffic engineering
(TE) paths in multi-domain environments.  A domain may be an IGP area,
an Autonomous System (AS), or some other division of computational
responsibility.  This document covers the cases of multiple ASes
belonging to the same SP and also the inter-SP case.

Information on network status is flooded to the PCEs in the domain, and
the PCEs are queried to supply paths for LSPs.  The PCE responds to the
path computation requests by computing the best available LSP route(s)
satisfying the set of specified constraints based on various factors
such as the path metric, availability state/network status, and topology
information.  Note that the resultant explicit route(s) may be made up
of a set of strict or loose hops, or any combination of strict and loose
hops.

Inter-area/AS MPLS TE requirements appear in [inter-area-req,
inter-as-req] and a framework for inter-domain MPLS TE is found in
[ccamp_fw].  Several inter-area and inter-AS MPLS TE methods have been
proposed, among them [kompella, lee, vasseur1, vasseur2], and some of
these methods propose the use of a PCE capability [kompella, lee,
vasseur1, vasseur2], query capability [query, vasseur1], and crankback
capability [crankback].

A problem statement is provided in Section 2, overview of solution
alternatives in Section 3, and proposed charter of the PCE working group
in Section 4.

2.	Problem Statement

Criteria to be considered in applying an inter-domain computation method
are listed below. These criteria are applicable to inter-area, inter-AS
(including multiple ASes belonging to the same SP), and inter-SP.

a. Optimality - maximize network utilization and minimize cost,
considering QoS objectives.
b. Scalability - routing and signaling overhead (includes LSAs,
crankbacks, queries, etc.).
c. Load sharing - allow multiple paths which satisfy load sharing needs.
d. Restoration/protection -
   i)  Allow multiple paths which satisfy path diversity needs
   ii) Allow LSP restoration/protection to occur separately within each
      domain.
e. Path computation functionality -
   i)  Ability to reoptimize LSPs
   ii) incorporate routing constraints.
f. Path computation performance - Time to compute a path on demand may
affect LSP setup time.
g. Ability to provide a loose path (required in some cases to preserve
confidentiality across domains)

In the light of the above criteria, the problem statement is as follows.

A. Path computation may be a CPU-intensive operation.  In this
situation, it may not be appropriate for a router to perform path 
computation.  Although alternatives exist using loose routes, such 
techniques either force the path computation to be performed at other 
routers in the network (which may be similarly constrained), or reduce 
to hop-by-hop routing which may not be optimal from a TE perspective.  
In order to provide a full explicit path in such circumstances, the use 
of some remote PCE may be appropriate to compute the path (or the set of 
paths) satisfying a particular set of constraints and optimizing some 
specific objectives.

B. The traffic engineering database (TEDB) may be a large drain on the
resources of a router both from a memory perspective and because it may 
require significant CPU activity to maintain it.  The use of a PCE may
be appropriate in such circumstances to establish the TEDB and make it
available for path computation.

C. Some networks do not run adequate IGPs to build a full TEDB. For
example, a network may run OSPF without the OSPF-TE extensions, or some
routers in the network may not support the TE extensions.  In these 
cases, in order to successfully operate MPLS TE signaling in the network, 
the TEDB must be constructed or supplemented through configuration 
action, and updated as LSPs are added or removed.  Such a TEDB could be 
distributed to each router so that each router can perform path 
computation, or held centrally for centralized path computation.

D. It is possible that the ingress router for an LSP has limited
visibility to the destination.  This limitation may occur because the
destination lies in a separate domain (for example, a different IGP area 
or AS) and so the ingress router does not receive TE information about 
all of the links between the source and destination.  In such cases, it 
is possible to use loose routes to establish the LSP, relying on routers 
at the domain borders to establish the next piece of the path.  However, 
because no node has an overall view of the network, it is not possible 
to guarantee that the optimal path will be used, nor even that a viable 
path will be discovered except, possibly, through repeated trial and 
error using crankback (and still such a solution does not guarantee an 
optimal path).  A PCE solution to this problem allows cooperation 
between the domains so that an optimal path can be computed and used.

E. The issues expressed in point D can be further highlighted in the
context of LSP re-optimization, or the establishment of multiple diverse 
LSPs for protection or load sharing.

F. An LER may not be part of the routing domain for administrative
reasons (for example, a CE device connected to the PE router in the 
context of an MPLS VPN and for which it is desired to provide a CE to CE 
TE LSP path).  Note that this provides a good example of a PCE returning 
a loose path.

The above issues point to a solution that may not involve doing
computation on the ingress router or relying wholly on loose hops.

3. Overview of Solution Alternatives

Solution alternatives discussed here identify approaches on how to
provide support for PCE.  There are two ways of providing a computed
path:

a. The path computation may be provided by the LSR that needs it;
b. The path computation may be done by some other network node on behalf
of the LSR.

In the former case, no extra work is required to achieve the computed
path. In the latter case, the LSR that requires the computation must
find and communicate with the other node that will provide the
computation.

In all cases, the computation may be achieved:

c. By a single node;
d. Through cooperation between nodes.

In the case of d, the cooperation may be reflected as:

d1. Loose hops or non-explicit abstract nodes in the path used by the
first LSR.  This forces other LSRs to make further path computations 
using a. or b.
d2. Cooperation between the requesting LSR and multiple other network
nodes to derive the full path.
d3. Cooperation between other network nodes unbeknownst to the
requesting LSR.

Mechanisms for option a. are well-known, and these extend to ac. and
ad1.  The PCE is the network element that supports option b.  Various
mechanisms are required in order to define different ways to support bc,
bd1, bd2, and bd3.

The following structure can be considered for solution alternatives:

3.1 PCE for Inter-Domain TE LSP Path Computation

3.1.1 Distributed PCEs for Inter-Domain TE

i) Single SP case

- PCEs are provided at each of n domain boundary nodes (such as
ABRs/ASBRs) in each domain
- Assumes dynamic PCE discovery (with load balancing, primary/secondary
node)
- Shortest end-to-end path built by backward recursive computation

Impacts:

- Requires more complex protocol extensions (LSR/PCE signaling, PCE
discovery)
- Optimal end-to-end path is computed (where optimal means shortest
path)
- Diverse path computation is possible

ii) Inter-SP case

- Same path computation technique as above
- Confidentiality/security aspects need to be considered

3.1.2 Centralized PCEs for Inter-Domain TE

This technique applies only to inter-domain TE within a single SP.

- Similar to scenario 5 described in [kompella].

3.2 PCE for Intra-area TE LSP Path Computation

There is no assumption that PCE services should be limited to
inter-domain LSPs. PCE might be required for the more CPU intensive TE
LSP path computation, typically multiple-constraints optimization
techniques.  Examples might be:

- Non-PSC TE LSP path computation where significant optical constraints
might be applied
- Point-to-multipoint path computation

4. Proposed Charter of PCE Working Group

The PCE working group coordinates the work within the IETF of defining
the operation of path computation elements within the Internet. Path
computation elements are responsible for computing paths through IP
networks for uses such as traffic engineering so that a prime consumer
of such paths might be an MPLS-TE LSR. Areas of responsibility will 
include the collection of attributes relevant to the computation of 
paths, the discovery by LSRs of available path computation elements, 
the communication with LSRs for the request of path computation, the 
collaboration between path computation elements within the network, 
and analysis of path computation algorithms with a view to ensuring 
consistency between computed paths. The working group will work 
closely with many working groups in the Routing Area including the 
OSPF, IS-IS, IDR, MPLS and CCAMP working groups.

The PCE working group scope includes:

a. Definition of Generalized Traffic Engineered LSP paths computation
techniques involving Path Computation Element(s). This includes the
intra IGP area, inter IGP area, inter-AS and inter-provider TE LSPs 
path computation for Point-to-Point, Point-to-Multipoint and
Multipoint-to-Multipoint TE LSPs.
b. Definition of protocol-independent metrics and constraints defining
path quality measurement criteria, algorithm complexity and 
scalability criteria related to path computation techniques.
c. Definition of requirements for communication between LSRs and PCEs
including routing extensions in support of PCE discovery techniques
within an IGP area and across multiple IGP areas, ASes and Provider 
networks, and including the development of new protocols or protocol 
extensions for requesting path computation and supplying responses. 
Any protocol extensions will developed in conjunction with the 
working groups in charge of the specific protocols.
d. Specification of routing (OSPF, ISIS, BGP) and signaling extensions
(RSVP-TE) required by PCE-based path computation techniques. The
extensions will developed in conjunction with the working groups in 
charge of the specific protocols.
e. Specification of requirements and protocol extensions related to the
policy, security and confidentiality aspects of PCE-based path
computation techniques involving PCEs of multiple Providers.
f. Definition of MIBs, management procedures related to the protocol
extensions defined by the WG

In doing this work, the WG will closely work with at least the following
other WGs: CCAMP, MPLS, ISIS, OSPF, IDR. The WG will also cooperate with
the ITU-T and OIF.

5. Security Considerations

This is an informational problem statement and introduces no security
considerations in its own right.

However, it should be observed that the use of a PCE does introduce
additional security issues above those already present in MPLS signaling
and routing. Most notable amongst these are:

- Interception of PCE requests or responses
- Impersonation of PCE
- Denial of service attacks on PCE or PCE communication mechanisms.

It is expected that PCE solutions will address these issues in detail

Additionally, certain confidentiality issues may arise where domains
desire to keep private their topology or optimal paths. For example,
when LSPs traverse networks maintained by different SPs. PCE solutions
in these cases are expected to provide suitable confidentiality.

6. Acknowledgments

The authors would like to thank JP Vasseur for many helpful comments and
suggestions.

7. Normative References

[ccamp_fw] Farrel, A., et. al., "A Framework for Inter-Domain MPLS
Traffic Engineering," work in progress.

[inter-as-req] Zhang, R, Vasseur, JP, et. al., "MPLS Inter-AS Traffic
Engineering requirements", work in progress.

[inter-area-req] Le Roux, JL, et. al., "Requirements for Inter-area MPLS
Traffic Engineering," work in progress.

8. Informational References

[kompella] Kompella, K., et. al., Rekhter, Y., Vasseur, JP, "Multi-area
MPLS Traffic Engineering," work in progress.

[lee] Lee, C-Y, et. al., "Distributed Route Exchangers," work in
progress.

[query] Lee, C-Y, Ganti, S., "Path Request and Path Reply Message,"
work in progress.

[vasseur1] Vasseur, JP, "RSVP Path Computation Request and Reply
Messages," work in progress.

[vasseur2] Vasseur, JP, et. al., "Inter-area and Inter-AS MPLS Traffic
Engineering," work in progress.

9. Authors' Addresses

Jerry Ash  (editor)
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1-(732)-420-4578
Fax:   +1-(732)-368-8659
Email: gash@att.com

Adrian Farrel
Old Dog Consulting
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk

10. Intellectual Property Considerations

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.

10.1. IPR Disclosure Acknowledgement

By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, and any of
which I become aware will be disclosed, in accordance with RFC 3668.

11. Full Copyright Statement

Copyright (C) The Internet Society (2004). 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.