Internet Draft                               Lou Berger (Movaz Networks)
Category: Informational                    Igor Bryskin (Movaz Networks)
Expiration Date: April 2006              Dimitri Papadimitriou (Alcatel)

                                                            October 2005


                        PCE Policy Architecture


              draft-berger-pce-policy-architecture-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Abstract

   The PCE architecture [PCE-ARCH] introduces the concept of path
   computation related policy at a high level.  This document provides
   additional details on policy as applied to the PCE architecture.
















Berger, et. al. &                                               [Page 1]


Internet Draft draft-berger-pce-policy-architecture-00.txt  October 2005


Contents

 1      Introduction  ..............................................   3
 1.1    PCE Components  ............................................   3
 1.2    Areas for Standardization  .................................   9
 2      PCE Policy Architecture  ...................................  10
 2.1    Types of Policies  .........................................  10
 2.1.1  User and Request Specific Policies  ........................  10
 2.1.2  Client and Server Specific Policies  .......................  10
 2.1.3  Local and Domain Specific Policies  ........................  11
 2.2    Policy Application  ........................................  11
 2.3    Policy Communication Support  ..............................  13
 2.4    PCE Discovery Policy Considerations  .......................  13
 2.5    Policy Management  .........................................  14
 3      Representative Policy Scenario  ............................  14
 3.1    Scenario: Policy Configured Paths  .........................  15
 3.2    Scenario: Provider Selection Policy  .......................  16
 3.3    Scenario: Policy Based Constraints  ........................  17
 4      Security Considerations  ...................................  18
 5      IANA Considerations  .......................................  19
 6      References  ................................................  19
 6.1    Normative References  ......................................  19
 6.2    Informative References  ....................................  19
 7      Authors' Addresses  ........................................  20
 8      Full Copyright Statement  ..................................  20
 9      Intellectual Property  .....................................  20



Internet Draft draft-berger-pce-policy-architecture-00.txt  October 2005


1. Introduction

   The PCE architecture is introduced in [PCE-ARCH].  This document
   describes the impact policy on the PCE architecture.  Other
   documents, for example [PCE-POL-COMMS], will provide implications on
   more detailed aspects of PCE implementation.

   Policy impacts multiple aspects of the PCE architecture.  The first
   is internal impact; the second is impact on PCE related
   communication.

   It is envisioned that policy will be largely applied as a local mater
   within each PCE.  That said, it is necessary to define the policy
   models that the PCE architecture can support.  Some example policies
   include rejection of a request based on requesting PCC or identified
   constraints, selection of a path based on the computation target, or
   the selection of a path based on the time of day.  The definition of
   supported policy models will drive PCE solutions and will enable
   proper and complete evaluation of specific PCE solutions.  PCE
   supported policy models are discussed later in this document.

   While the implementation and enforcement of policy is largely a local
   matter, the policies that may be applied impact the communication
   protocols used to support PCE.  This includes PCC-PCE, PCE-PCE and
   PCE discovery communication.  The primary impact is to the
   information carried by the protocols.  To a lesser degree, policy
   support requirements may also drive the required protocol
   transactions.  As the more detailed requirements for each PCE
   communication protocol is defined, it is important for these
   documents to articulate supported (and unsupported) policy models and
   the related requirements.  Also, any defined solution must be
   evaluated on its ability to support these policy models and
   requirements.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


1.1. PCE Components

   From a component perspective, PCE policy is supported via a Policy
   Database.  The Policy database provides non-TE information and is
   used by a PCE when responding to a requested path computation.
   Additionally, policy may also be used to govern what requests are
   made to the PCE from a PCC.  [PCE-ARCH] shows the PCE architecture
   applied to four different node configurations.  Figures 1 through
   Figure 4 shows these configurations updated to reflect PCE Policy.



Berger, et. al. &                                               [Page 3]


Internet Draft draft-berger-pce-policy-architecture-00.txt  October 2005


   In each configuration, policy is consulted before a response is
   provided by a PCE.  A PCE may have local policy information that
   impacts the one or more paths selected to satisfy a particular PCE
   request.  A local policy may be applied based on any information
   provided from a PCC.  The policy may have any number of results
   including, for example, rejecting the request, identifying one or
   more paths that provide different quality of service, or providing
   one or more paths that have different costs, different end-to-end
   delays or other different characteristics.  Additionally, changes in
   PCE policy may lead to a change to a previously provided path.

   Another, important policy decision is the one related to the TED
   selection. Indeed, the selection of the TED repository for the path
   computation itself can be subject to policing.  This means that this
   document extends the PCE architecture by allowing the access point to
   the PCE to be disjoint from the access point to the TED that will be
   used for path computation purposes.  This extension will likely
   impact inter-PCE communication, and selection of a "next PCE" when
   multiple PCEs are involved during the path computation.

   Path computation related policy must also be sensitive to where it is
   being applied.  For example, a different set of policies may be
   applied for an intra-area or single-layer PCE request, than would be
   provided for an inter-area or multi-layer PCE request.

   In each configuration, all policy decisions are made independently at
   each PCE based on information passed from the previous PCE.
   Alternatively, in the multiple PCE path computation with inter-PCE
   communication configuration, see Figure 4, there is likely to be
   explicit communication of policy information between PCEs.  The type
   of information conveyed to support policy will have significant
   implications on what policies may be applied at each PCE.

   Note that while the policy component is shown as co-resident, the
   policy database may be implemented using some form of distributed
   database.  Such distributed approaches have no impact on the PCE
   policy architecture and are therefore out of scope of this document.














Berger, et. al. &                                               [Page 4]


Internet Draft draft-berger-pce-policy-architecture-00.txt  October 2005


             ------------------------------
            |                  ---------   | Routing   ----------
            |                 |         |  | Protocol |          |
            |                 |   TED   |<-+----------+->        |
            |                 |         |  |          |          |
            |                  ---------   |          |          |
            |                     |        |          |          |
            |                     | Input  |          |          |
            |                     v        |          |          |
            |   ---------      ---------   |          |          |
            |  |  Policy |    |         |  |          | Adjacent |
            |  | Database|<-->|   PCE   |  |          |   Node   |
            |  |         |    |         |  |          |          |
            |   ---------      ---------   |          |          |
            |                     ^        |          |          |
            |                     |Request |          |          |
            |                     |Response|          |          |
            |                     v        |          |          |
            |                  ---------   |          |          |
    Service |                 |         |  | Signaling|          |
    Request |                 |Signaling|  | Protocol |          |
      ------+---------------->| Engine  |<-+----------+->        |
            |                 |         |  |          |          |
            |                  ---------   |           ----------
             ------------------------------

                       Figure 1. Composite PCE Node
























Berger, et. al. &                                               [Page 5]


Internet Draft draft-berger-pce-policy-architecture-00.txt  October 2005


     ----------------------
    |              -----   |
    |             | TED |<-+------------>
    |              -----   |  TED synchronization
    |                |     |  mechanism (e.g.,, routing protocol)
    |                |     |
    |                v     |
    |  ------      -----   |
    | |Policy|<-->| PCE |  |
    |  ------      -----   |
     ----------------------
                     ^
                     | Request/
                     | Response
                     v
         Service ----------  Signaling   ----------
         Request| Head-End | Protocol   | Adjacent |
           ---->|  Node    |<---------->|   Node   |
                 ----------              ----------

                        Figure 2. External PCE Node

        ------------------       -------------------
       |                  |     |                   |
       |        PCE       |     |        PCE        |
       |                  |     |                   |
       |  ------   -----  |     |   -----   ------  |
       | |Policy| | TED | |     |  | TED | |Policy| |
       |  ------   -----  |     |   -----   ------  |
        ------------------       -------------------
                ^                       ^
                | Request/              | Request/
                | Response              | Response
                v                       v
    Service --------  Signaling  ------------  Signaling  ------------
    Request|Head-End| Protocol  |Intermediate| Protocol  |Intermediate|
      ---->|  Node  |<--------->|    Node    |<--------->|    Node    |
            --------             ------------             ------------

                  Figure 3. Multiple PCE Path Computation











Berger, et. al. &                                               [Page 6]


Internet Draft draft-berger-pce-policy-architecture-00.txt  October 2005


      ------------------                              ------------------
     |                  | Inter-PCE Request/Response |                  |
     |       PCE        |<-------------------------->|       PCE        |
     |                  |                            |                  |
     |  ------   -----  |                            |  ------   -----  |
     | |Policy| | TED | |                            | |Policy| | TED | |
     |  ------   -----  |                            |  ------   -----  |
      ------------------                              ------------------
                 ^
                 | Request/
                 | Response
                 v
    Service ----------  Signaling   ----------  Signaling   ----------
    Request| Head-End | Protocol   | Adjacent | Protocol   | Adjacent |
      ---->|  Node    |<---------->|   Node   |<---------->|   Node   |
            ----------              ----------              ----------

   Figure 4. Multiple PCE Path Computation with Inter-PCE Communication

   The PCE architecture allows for there to be multiple PCEs for a
   number of reasons, including for redundancy or for distributed path
   computation purposes.  Independent of purpose, in the configurations
   where multiple PCEs exist, the Policy Databases should be consistent
   across the PCEs in order for a PCE request to be satisfied as
   intended.  The means by which such consistency is established is
   viewed as a configuration issue.  The policy configuration interface
   is not specified or restricted by the PCE Policy Architecture.  The
   interface may be purely a local matter, or may be supported via a
   standardized interface or policy distribution mechanism (e.g., MIB or
   LDAP.)

   Policy may also play a part in the selection of a PCE by a PCC when
   multiple PCEs exists, see Figures 3 and 4.  Policy may also influence
   a request made by a PCC to a PCE.  Figure 5, shows the PCC components
   used to support the application of such policy.  Note Figure 5 also
   allows for multiple PCEs.















Berger, et. al. &                                               [Page 7]


Internet Draft draft-berger-pce-policy-architecture-00.txt  October 2005


          ----------------------
         |              -----   |
         |             | TED |<-+------------>
         |              -----   |  TED synchronization
         |                |     |  mechanism (e.g., routing protocol)
         |                |     |
         |                v     |
         |  ------      -----   |  Inter-PCE Request/Response
         | |Policy|<-->| PCE |<.+...........>  (when present)
         |  ------      -----   |
          ----------------------
                          ^
                          | Request/
                          | Response
                          v
            Service -------------  Signaling
            Request|[PCC][Policy]| Protocol
            ...--->|    Node     |<----....
       or Signaling -------------
          Protocol

                       Figure 5: Policy Enabled PCC

   As stated in [PCE-ARCH], the PCC is not necessarily an LSR.  Policy
   also is applied in such configurations.  The example shown in [PCE-
   ARCH] is of an NMS.  Figure 6 shows this example updated to support
   policy.
























Berger, et. al. &                                               [Page 8]


Internet Draft draft-berger-pce-policy-architecture-00.txt  October 2005


                              ----------------------
                             |   -----              |
         Service             |  | TED |<------------+------------>
         Request             |   -----              | TED synchronization
            |                |     |                | mechanism (e.g.,
            v                |     |                | routing protocol)
      ------------- Request/ |     v                |
     |             | Response|   -----      ------  |
     |     NMS     |<--------+->| PCE |<-->|Policy| |
     |             |         |   -----      ------  |
      -------------           ----------------------
    Service |
    Request |
            v
       ----------  Signaling   ----------
      | Head-End | Protocol   | Adjacent |
      |  Node    |<---------->|   Node   |
       ----------              ----------

                   Figure 6. Management-based PCE Usage


1.2. Areas for Standardization

   The following areas require standardization within the PCE policy
   architecture:

   - Communication between PCCs and PCEs, and between cooperating
     PCEs, including the definition of policy related information
     communication.

   - Communication of policy related information dissemination e.g. as
     part of the PCE discovery or some other communication process.

   - Definition of metrics to evaluate policy support of path
     computation models.  The focal point of this effort is to evaluate
     potential solutions to the Policy aspects of the PCE architecture.

   - MIB modules related to policy support.

   - Configuration related support for policy databases.










Berger, et. al. &                                               [Page 9]


Internet Draft draft-berger-pce-policy-architecture-00.txt  October 2005


2. PCE Policy Architecture

   This section provides definitions and other aspects related to the
   support of policy by the PCE architecture.


2.1. Types of Policies

   For the purposes of PCE, we breakdown policy into multiple
   categories: user specific, request specific, client specific, server
   specific and domain specific.


2.1.1. User and Request Specific Policies

   User specific policies are policies that use as conditions user or
   service specified information.  Examples of such information includes
   the contents of objects of a signaling or provisioning message, port
   ID over which the message was received, VPN ID, reference point type,
   or even the identity of the user initiating the request.  User
   specific policies could be applied while building a path computation
   request.  For example, Service A may require two SRLG disjoint paths
   for building end-to-end recovery scheme, while for service B link-
   disjoint paths may be sufficient.  Alternatively, service A may need
   paths with minimal end-to-end delay, while service B may be looking
   for shortest (minimal-cost) paths.  A final example is that different
   constraint relaxation strategies could be applied while computing
   paths for service A and for service B.

   Request specific policies are policies that use as conditions
   information found in a path computation request. Examples of request
   specific policies include constraints, diversities, constraint and
   diversity relaxation strategies, and optimization functions.
   Request-specific policies directly affect the path selection process
   because they specify which links, nodes, path segments and/or paths
   that are not acceptable or, on the contrary, may be desirable to
   appear in the resulting paths.


2.1.2. Client and Server Specific Policies

   Client specific policies are policies that use as a condition the
   requesting Path Computation Client (PCC) or, in the inter-PCE
   requesting case, a requesting Path Computation Engine (PCE).  A PCE
   may take specific action depending on the identity of the requester.
   Some examples are the PCE may choose to drop or relax certain
   specified constraints or impose additional ones, select an algorithm
   or heuristic for the path computation, decide whether cooperation of



Berger, et. al. &                                              [Page 10]


Internet Draft draft-berger-pce-policy-architecture-00.txt  October 2005


   other PCEs are needed and whether explicit resulting paths should be
   generated or loose ones are sufficient.

   Server specific policies are policies that are associated with a
   particular Path Computation Engine and applied at a PCC or at a PCE
   initiating a inter-PCE request.  A PCC or PCE may take specific
   action depending on the identity of the identity of the PCE to which
   it may make a request. One examples of this is that a requester may
   select a PCE based on its capabilities.  Another example is that a
   requester may include different information in a path computation
   request based on the capabilities of a specific PCE.  Capabilities in
   this context mean the ability of a PCE to provide specific functions,
   such as support for certain path computation constraints or
   optimization functions, method of PCE related communication
   authentication, or billing.


2.1.3. Local and Domain Specific Policies

   Local specific policies are policies that use as a condition the ID
   the PCC acting on behalf one (or more) LSRs. These policies uses
   conditions that are specific to the PCC to which they apply. In a
   network including multiple PCCs these conditions can be applied
   independently of the policies applying to the other PCC policies.

   Domain specific policies are policies that use as a condition the ID
   of a path computation domain the requesting PCC belongs to and/or IDs
   of domains the resulting paths go through. These policies have the
   same affect on the path computation process as client specific
   policies with the difference that they could be associated
   with/applied for a group of clients rather than individual clients.
   One example of domain-specific policy is a policy restricting which
   information a PCE should publish within a given domain.  In such a
   case, PCEs in some domains may advertise just its presence while
   others may advertise details regarding its capabilities, client
   authentication process, billing, and computation resource
   availability.


2.2. Policy Application

   The PCE policy architecture supports policy being applied at a PCC
   and at a PCE.  While the architecture supports policy being applied
   at both, there is no requirement for policy to always being applied
   at both or even at either.  The use of policy in a network, on PCCs
   and on PCEs, is specific network design choice.  Some networks may
   choose to apply policy only at PCCs, some may choose to only apply
   policies at PCEs, and others will may choose to apply policies at



Berger, et. al. &                                              [Page 11]


Internet Draft draft-berger-pce-policy-architecture-00.txt  October 2005


   both.  Regardless of how policy is applied, as previously mentioned,
   it must be applied in a consistent fashion in order to achieve the
   results intended.

   Section 1.1 shows some possible example configurations of where
   policy can be applied within the PCE architecture.  Figures 1 through
   6 show policy being applied at a PCE.  Figure 5 shows policy being
   applied at both a PCC and a PCE.

   Along with supporting a flexibility in where policy may be applied,
   the PCE policy architecture is also flexible in terms of where
   specific types of policies may be applied.  Also the PCE policy
   architecture allows for the application of only a subset of policy
   types.  Section 2.1 defines multiple types of policies.  Each of
   these may be applied at either a PCC or a PCE.  Clearly when policy
   is only applied at PCCs or at PCEs, all policy types used in a
   network must be applied at those locations.

   In the case when policy is only applied at a PCE, it is expected that
   the PCC will pass to the PCE all information about the service that
   it could gather in the path computation request, most likely in the
   form of policy information.  The PCE is expected to understand this
   policy information and apply appropriate policies while defining the
   actual parameters of the path computation to be performed.  Note that
   in this case, the PCC cannot use local or server policy information
   to select a PCE.

   When applying policy at both PCCs and PCEs, it is necessary to select
   which types of policies are applied at each.  In such configurations,
   it is likely that the application of policy types will be distributed
   across PCCs and PCEs rather than applying all types at both.
   Particularly for those policy types that apply to the role being
   performed by the component.  For example, user specific, server
   specific and request specific policies may be applied at PCCs, domain
   specific policies may be applied at PCEs and client specific policies
   may be applied at both.  Client specific policies may also be
   relative to the location where the policy is applied, i.e., at the
   PCC the client is the service requester, while at the PCE the client
   is the requesting PCC or PCE.

   In the case when policy is only applied at a PCC, the PCC must apply
   all the types of required policies, for example user, service, and
   domain-specific policies.  The PCC uses the policies to construct a
   path computation request that appropriately represents the applied
   policies.  The request will necessarily be limited to the set of
   "basic", non-policy capable, constraints explicitly defined by the
   PCC-PCE communication protocol.




Berger, et. al. &                                              [Page 12]


Internet Draft draft-berger-pce-policy-architecture-00.txt  October 2005


2.3. Policy Communication Support

   The described PCE policy architecture allows for a fair bit of
   flexibility in where and in what types of policy is applied.  This is
   critical from the architecture perspective, but it does imply added
   complexity on the part of the PCE related communication protocols.

   The first added complexity is that the PCE communication protocols
   must carry sufficient information to support the types of policies
   that may be applied.  For example, in the case where policy is only
   applied at a PCE, a PCC-PCE request must carry sufficient information
   for the PCE to apply request or even user specific policies.  This
   does imply that a PCC must have sufficient understanding of what
   policy types may be applied at a PCE.  Such information may be
   obtained via such approaches as configuration, static coding, or even
   via a PCE discovery mechanism.  The PCC must also have sufficient
   understanding to properly encode the required information for each
   type of policy.

   The second added complexity is that the PCE communication protocols
   must also be able to carry information that may result from a policy
   decision.  For example, user specific policy applied at a PCC may
   result in policy related information that must be carried along with
   the request for use by a PCE policy component.  This complexity is
   particularly important as it may be used to introduce new path
   computation related constraints without modification of the core PCC
   and PCE.  This communication will likely simply require the PCE
   communication protocol(s) to support opaque policy related
   information elements.

   The final added complexity is that the PCE communication protocols
   must also be able to support updated or unsolicited responses from a
   PCE.  For example, changes in PCE policy may force a change to a
   previously provided path.  Such updated or unsolicited responses may
   contain information that the PCC must act on, and may contain policy
   (opaque) information that must be provided to a PCC's policy
   component.


2.4. PCE Discovery Policy Considerations

   Dynamic PCE discovery allows PCCs/PCEs to automatically discover a
   set of PCEs, including information required for PCE selection, and to
   dynamically detect new PCEs or any modification of PCE's information.
   Policy can be applied in two ways in this context:

   1.  Restricting the scope of information distribution for the
   mandatory set of information (in particular the PCE location).



Berger, et. al. &                                              [Page 13]


Internet Draft draft-berger-pce-policy-architecture-00.txt  October 2005


   2.  Restricting the type and nature of the optional information
   distributed by the discovery protocol.  The latter is also subject to
   policy since the PCE architecture allows for distributing this
   information using either the discovery protocol or the specific PCC-
   PCE communication protocol.  Here the most important policy decision
   is determined by the nature of the information to be discovered in
   particular when this information is not strictly speaking a
   "discovery" information, but a PCE state information exchange the
   policy should allow for making use of the appropriate protocol to
   exchange that information with the client PCC/PCE

   Another level where policing applies is at the administrative
   boundaries.  This class of polices applies in particular when
   multiple PCEs would have to communicate one each other and cross an
   administrative boundary.  In this context, several specific polices
   would be applied to 1) filter the information exchanged with peering
   PCEs during the discovery process (to the bare minimum in most cases
   if at all allowed by the security policy) and 2) strictly limit the
   exchange of information during path computation request/responses.


2.5. Policy Management

   The management of policy information used at PCCs and PCEs is largely
   out of scope of the PCE architecture.  The architecture assumes that
   such information is installed using typical policy management
   techniques and are available for use by policy components co-resident
   with PCCs and PCEs.  The policy management techniques may be
   statically configured, managed via an information or policy
   management protocol, e.g., LDAPv3 [RFC3377], or even dynamically
   established.


3. Representative Policy Scenario

   This section provides some example of policy may be applied using the
   PCE policy architecture.  The intent of this section is to provide
   several diverse examples of how policy may be applied within the PCE
   architecture.  Actual networks may use one of the scenarios
   discussed, some combination of the presented scenarios, or other
   scenarios not discussed.  This section should not be viewed as
   limiting other applications of policy within the PCE architecture.

   [Authors' note: it is expected that this section will generate a
   number of divergent views of how PCE policy may be applied within the
   architecture.  We view this as beneficial and that it is imperative
   for the PCE policy architecture to be sufficiently flexible to
   accommodate all views, and that each perspective be suitably



Berger, et. al. &                                              [Page 14]


Internet Draft draft-berger-pce-policy-architecture-00.txt  October 2005


   represented in this section.]


3.1. Scenario: Policy Configured Paths

   A very simple usage scenario for PCE policy would be to use PCE to
   centrally administer configured path.  Configured paths are composed
   of strict and loose explicit hops, EROs see [RFC3209], and are used
   by one or more LSPs.  Typically such paths are configured at the LSP
   ingress.  With PCE policy, an alternate approach is possible.

   Using PCE policy, user specific policies can be created that will
   provide a configured path for a specific user request.  The user
   request could be identified based on service parameters such as end-
   points, requested service/QoS, or even a token that identifies the
   end-user.  The configured path would then be used as input to PCE
   computation process.  The PCE process would return any explicit
   routes and expand all possible loose hops.

   This described policy could be applied at either PCC or PCE, see
   Figure 5.  In the PCC case, the configured path would be expanded at
   the PCC and then passed to the PCE along with the PCE request,
   probably in the form of constraints.  When applied at the PCE, the
   configured path would be internally expanded and used.  Both cases
   require some method to configure and manage policies.  In the PCC
   case, the real benefit would come when there is an automated policy
   distribution mechanism.

   Policy configured paths can also be used in multiple PCE
   environments, see Figures 3 and 4.  For example, consider the case
   where there is limited visibility and multiple PCEs are used to
   resolve each region of visibility.  In this example, it may not be
   possible, or desirable to configure the whole explicit path on the
   first PCE.  What could be done, is to configure the explicit path for
   each area of visibility with each responsible PCE.  Each PCE would
   then map an incoming request to the matching configured path.  For
   this example to work, it would likely be necessary to include the
   exit point from, or the entry point into, each area of visibility.
   Clearly, policy database consistent is also critical in this example.












Berger, et. al. &                                              [Page 15]


Internet Draft draft-berger-pce-policy-architecture-00.txt  October 2005


3.2. Scenario: Provider Selection Policy

   A more interesting usage scenario is applying policy to multi-domain,
   multi-provider, networks.  There a number of interesting applications
   of policy in such networks.  A rudimentary example is simple access
   control, i.e., which users, clients or PCEs are permitted to request
   inter-domain path computation.

   A more interesting example is applying policy to select which domain,
   or provider, is used to support a particular PCE request.  Consider a
   topology that has multiple transit networks, see Figure 7.  In this
   case, there are multiple transit networks available to provide a path
   from a source domain to a destination (or target) domain.
   Furthermore, each transit network may have one or more options for
   reaching the target domain.  Each domain may need to select which of
   the multiple available paths can be used to satisfy a particular PCE
   request.

   Clear reachability is a base criteria for path selection, but policy
   may be a more interesting and important criteria.  For example
   transit network A may be more expensive and provide lower delay or
   loss than transit network C.  Likewise, a transit network may wish to
   treat PCE requests from its own customers differently than requests
   from another provider.  In both cases, computation based on traffic
   engineering databases will result in multiple transit networks that
   provide reachability, but policy can be used to dictate which PCE
   requests get the better service.

              +----------------+
              |Transit Domain A| +----------------+
              +----------------+ |Transit Domain D|
   +------+   +----------------+ +----------------+    +------+
   |Source|   |Transit Domain B| +----------------+    |Target|
   |Domain|   +----------------+ |Transit Domain E|    |Domain|
   +------+   +----------------+ +----------------+    +------+
              |Transit Domain C| +----------------+
              +----------------+ |Transit Domain F|
                                 +----------------+

       Figure 7: Multi-domain network with multiple transit options

   There are multiple options for differentiating which PCE requests use
   a particular transit domain and get better service.  For example, the
   source domain may use user and client specific policies, to determine
   the level of service to provide and use domain specific policies to
   choose which transit domains are acceptable.  A transit domain may
   use a combination of client specific policies to determine if a
   request is from a direct customer or another provider, and then use



Berger, et. al. &                                              [Page 16]


Internet Draft draft-berger-pce-policy-architecture-00.txt  October 2005


   domain specific policies to identify how the request should be
   processed.

   While this description presumes multiple PCEs, while envisioned to be
   less common, it is also possible to apply provider selection policy
   in single PCE environments.  In this case, the single PCE will apply
   all policies, (e.g., user, client and domain specific policies) to
   determine the appropriate constraints for a particular PCE request.

   While less likely, the described policy could be also applied at a
   PCC.  In the PCC case, the provider related policy would be expanded
   at the PCC and then passed to the PCE along with the PCE request,
   probably in the form of constraints.

   Independent of the number of PCEs, or the application of policy at
   PCCs, there must be some method to configure and manage policies
   consistently.

   It is also worth noting that this basic approach can also be used
   within a domain to provide different paths and services based on
   users, PCC, VPN ID, or even application.


3.3. Scenario: Policy Based Constraints

   Another usage scenario is to use policy to provide additional
   constraints for PCE request.  Consider an LSR with a policy capable
   PCC, as shown in Figure 5, which receives a signaling message via
   signaling, including over a NNI or UNI reference point, or receives
   configuration request over a management interface to establish a
   service.  The path(s) for LSP(s) that are needed to support the
   service are not explicitly specified in the message/request; hence
   path computation is needed.

   In this case, the PCC may apply user or service specific policies to
   decide how the path selection process should be constrained, that is,
   which constraints, diversities, optimizations and relaxations should
   be applied in order for the service LSP(s) to have a likelihood to be
   successfully established and provide necessary QoS and resilience
   against network failures.  When deciding on the set of constraints
   the PCC uses as an input all information it knows about the user and
   service, including the contents of the received message, port ID over
   which message was received, associated VPN ID, signaling/reference
   point type, request time, etc.  Once the constraints and other
   parameters of the required path computation is determined, the PCC
   generates a path computation request which includes the request-
   specific policies that describe the determined set of constraints,
   optimizations, and other parameters that describe how the request



Berger, et. al. &                                              [Page 17]


Internet Draft draft-berger-pce-policy-architecture-00.txt  October 2005


   must considered in the path computation process.

   The PCC may also apply server specific policies for each of known,
   i.e., discovered or configured, PCE in order to select which PCE to
   use.  The PCC may also use server specific policies to form the
   request to match the PCE's capabilities so that the request will not
   be rejected and so that it has a higher likelihood of being satisfied
   in an efficient way.  An example of modification as a result of a
   server specific policy is to remove a constraint not supported by the
   PCE. Once the policy processing is complete one the PCC, and the PCE
   request resulting from the original service request is updated by the
   policy processing, the request is sent to the PCE.

   The PCE that receives the request validates and otherwise processes
   the request applying the policies found in the request as well as any
   policies that are applied at the PCE, e.g., client and domain
   specific polices.  As a result of the policy processing the PCE may
   decide to reject the request.  It also may decide to respond with one
   or several pre-computed paths if user or client-specific polices
   instruct the PCE to do so.  If the PCE decides to satisfy the request
   by performing a path computation, it determines if it needs the
   cooperation of other PCEs and defines parameters for path
   computations to be performed locally and remotely.  After that the
   PCE instructs a co-located path computation engine to perform the
   local path computation(s) and, if necessary, sends path computation
   request(s) to one or more other PCEs.  It then waits for the
   responses from the local path computation engine and, when used, the
   remote PCE.  It then combines the resulting paths and sends them back
   to the requesting PCC.  The response may represent policies
   describing the resulting paths, their characteristics (summary cost,
   expected end-to-end delay, etc.) as well as additional information
   related to the request, e.g., which of constraints were honored,
   which were dismissed and which were relaxed and in what way.

   PCC processes the response and instructs the LSR to encode the
   received path(s) into the outgoing signaling message(s).


4. Security Considerations

   This document adds a policy dimension to the considerations mentioned
   in [PCE-ARCH].  In particular it is now necessary to consider the
   security of policy information and policy related transactions.  The
   most notable of these are:

   - Interception of policy related information in PCE requests
     and responses.




Berger, et. al. &                                              [Page 18]


Internet Draft draft-berger-pce-policy-architecture-00.txt  October 2005


   - Impersonation of user and client identities.

   - Falsification of policy information or PCE capabilities.

   - Denial of service attacks on policy related communication
     mechanisms.

   As with [PCE-ARCH], it is expected that PCE solutions will address
   these issues in detail.


5. IANA Considerations

   This document makes no requests to IANA.


6. References

6.1. Normative References

   [PCE-ARCH] Farrel, A., Vasseur, JP., Ash, J., "Path Computation
              Element (PCE) Architecture", July 2005.


6.2. Informative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels," RFC 2119.

   [RFC3209] Awduche, et al, "RSVP-TE: Extensions to RSVP for
             LSP Tunnels", RFC 3209, December 2001.

   [RFC3377] Hodges, J., Morgan, R., "Lightweight Directory Access
             Protocol (v3): Technical Specification", September 2002.

   [PCE-POL-COMMS] Bryskin, I., Papadimitriou, D., Berger, L.,
                   "Policy-Enabled Path Computation Communication
                   Requirements", October 2005.













Berger, et. al. &                                              [Page 19]


Internet Draft draft-berger-pce-policy-architecture-00.txt  October 2005


7. Authors' Addresses

   Lou Berger
   Movaz Networks, Inc
   Phone: +1 703-847-1801
   Email: lberger@movaz.com

   Igor Bryskin
   Movaz Networks, Inc
   Phone: +1 703-847-4208
   Email: ibryskin@movaz.com

   Dimitri Papadimitriou
   Alcatel
   Francis Wellensplein 1,
   B-2018 Antwerpen, Belgium
   Phone : +32 3 240 8491
   Email: dimitri.papadimitriou@alcatel.be



8. Full Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   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.


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



Berger, et. al. &                                              [Page 20]


Internet Draft draft-berger-pce-policy-architecture-00.txt  October 2005


   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.








































Berger, et. al. &                                              [Page 21]

Generated on: Mon Oct 17 00:29:11 EDT 2005