GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5394

Network Working Group I. Bryskin Request for Comments: 5394 Adva Optical Category: Informational D. Papadimitriou

                                                               Alcatel
                                                             L. Berger
                                                       LabN Consulting
                                                                J. Ash
                                                                  AT&T
                                                         December 2008
             Policy-Enabled Path Computation Framework

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (c) 2008 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents (http://trustee.ietf.org/
 license-info) in effect on the date of publication of this document.
 Please review these documents carefully, as they describe your rights
 and restrictions with respect to this document.

Abstract

 The Path Computation Element (PCE) architecture introduces the
 concept of policy in the context of path computation.  This document
 provides additional details on policy within the PCE architecture and
 also provides context for the support of PCE Policy.  This document
 introduces the use of the Policy Core Information Model (PCIM) as a
 framework for supporting path computation policy.  This document also
 provides representative scenarios for the support of PCE Policy.

Bryskin, et al. Informational [Page 1] RFC 5394 Policy-Enabled Path Computation December 2008

Table of Contents

 1. Introduction ....................................................2
    1.1. Terminology ................................................3
 2. Background ......................................................4
    2.1. Motivation .................................................4
    2.2. Policy Attributes ..........................................6
    2.3. Representative Policy Scenarios ............................7
         2.3.1. Scenario: Policy Configured Paths ...................7
         2.3.2. Scenario: Provider Selection Policy ................10
         2.3.3. Scenario: Policy Based Constraints .................12
         2.3.4. Scenario: Advanced Load Balancing (ALB) Example ....14
 3. Requirements ...................................................16
 4. Path Computation Policy Information Model (PCPIM) ..............18
 5. Policy-Enabled Path Computation Framework Components ...........20
 6. Policy Component Configurations ................................21
    6.1. PCC-PCE Configurations ....................................21
    6.2. Policy Repositories .......................................24
    6.3. Cooperating PCE Configurations ............................25
    6.4. Policy Configuration Management ...........................27
 7. Inter-Component Communication ..................................27
    7.1. Policy Communication ......................................27
    7.2. PCE Discovery Policy Considerations .......................29
 8. Path Computation Sequence of Events ............................29
    8.1. Policy-Enabled PCC, Policy-Enabled PCE ....................29
    8.2. Policy-Ignorant PCC, Policy-Enabled PCE ...................31
 9. Introduction of New Constraints ................................32
 10. Security Considerations .......................................33
 11. Acknowledgments ...............................................33
 12. References ....................................................34
    12.1. Normative References .....................................34
    12.2. Informative References ...................................34

1. Introduction

 The Path Computation Element (PCE) Architecture is introduced in
 [RFC4655].  This document describes the impact of policy-based
 decision making when incorporated into the PCE architecture and
 provides additional details on, and context for, applying policy
 within the PCE architecture.
 Policy-based Management (PBM), see [RFC3198], is a network management
 approach that enables a network to automatically perform actions in
 response to network events or conditions based on pre-established
 rules, also denoted as policies, from a network administrator.  PBM
 enables network administrators to operate in a high-level manner
 through rule-based strategy (policies can be defined as a set of
 rules and actions); the latter are translated automatically (i.e.,

Bryskin, et al. Informational [Page 2] RFC 5394 Policy-Enabled Path Computation December 2008

 dynamically, without human interference) into individual device
 configuration directives, aimed at controlling a network as a whole.
 Two IETF Working Groups have considered policy networking in the
 past: The Resource Allocation Protocol (RAP) working group and the
 Policy Framework working group.
 A framework for policy-based admission control [RFC2753] was defined
 and a protocol for use between Policy Enforcement Points (PEP) and
 Policy Decision Points (PDP) was specified: Common Open Policy
 Service (COPS) [RFC2748].  This document uses the terms PEP and PDP
 to refer to the functions defined in the COPS context.  This document
 makes no assumptions nor does it require that the actual COPS
 protocol be used.  Any suitable policy exchange protocol (for
 example, Simple Object Access Protocol (SOAP) [W3CSOAP]) may be
 substituted.
 The IETF has also produced a general framework for representing,
 managing, sharing, and reusing policies in a vendor-independent,
 interoperable, and scalable manner.  It has also defined an
 extensible information model for representing policies, called the
 Policy Core Information Model (PCIM) [RFC3060], and an extension to
 this model to address the need for QoS management, called the Quality
 of Service (QoS) Policy Information Model (QPIM) [RFC3644].  However,
 additional mechanisms are needed in order to specify policies related
 to the path computation logic as well as its control.
 In Section 2, this document presents policy-related background and
 scenarios to provide a context for this work.  Section 3 provides
 requirements that must be addressed by mechanisms and protocols that
 enable policy-based control over path computation requests and
 decisions.  Section 4 introduces PCIM as a core component in a
 framework for providing policy-enabled path computation.  Section 5
 introduces a set of components that may be used to support policy-
 enabled path computation.  Sections 6, 7, and 8 provide details on
 possible component configurations, communication, and events.
 Section 10 discusses the ability to introduce new constraints with
 minimal impact.  It should be noted that this document, in Section 4,
 only introduces PCIM; specific PCIM definitions to support path
 computation will be discussed in a separate document.

1.1. Terminology

 The reader is assumed to be familiar with the following terms:
 BEEP:    Blocks Extensible Exchange Protocol, see [RFC3080].
 CIM:     Common Information Model, see [DMTF].
 COPS:    Common Open Policy Service, see [RFC2748].
 CSPF:    Constraint-based Shortest Path First, see [RFC3630].

Bryskin, et al. Informational [Page 3] RFC 5394 Policy-Enabled Path Computation December 2008

 LSP:     Label Switched Path, see [RFC3031].
 LSR:     Label Switching Router, see [RFC3031].
 PBM:     Policy-Based Management, see [RFC3198].
 PC:      Path Computation.
 PCC:     Path Computation Client, see [RFC4655].
 PCCIM:   Path Computation Core Information Model.
 PCE:     Path Computation Element, see [RFC4655].
 PCEP:    Path Computation Element Communication Protocol,
          see [PCEP].
 PCIM:    Policy Core Information Model, see [RFC3060].
 PDP:     Policy Decision Point, see [RFC2753].
 PEP:     Policy Enforcement Point, see [RFC2753].
 QPIM:    QoS Policy Information Model, see [RFC3644].
 SLA:     Service Level Agreement.
 SOAP:    Simple Object Access Protocol, see [W3CSOAP].
 TE:      Traffic Engineering, see [RFC3209] and [RFC3473].
 TED:     Traffic Engineering Database, see [RFC3209] and [RFC3473].
 TE LSP:  Traffic Engineering MPLS Label Switched Path, see
          [RFC3209] and [RFC3473].
 WDM:     Wavelength Division Multiplexing

2. Background

 This section provides some general background on the use of policies
 within the PCE architecture.  It presents the rationale behind the
 use of policies in the TE path computation process, as well as
 representative policies usage scenarios.  This information is
 intended to provide context for the presented PCE policy framework.
 This section does not attempt to present an exhaustive list of
 rationales or scenarios.

2.1. Motivation

 The PCE architecture as introduced in [RFC4655] includes policy as an
 integral part of the PCE architecture.  This section presents some of
 the rationale for this inclusion.
 Network operators require a certain level of flexibility to shape the
 TE path computation process, so that the process can be aligned with
 their business and operational needs.  Many aspects of the path
 computation may be governed by policies.  For example, a PCC may use
 policies configured by the operator to decide which optimization
 criteria, constraints, diversities and their relaxation strategies to
 request while computing path(s) for a particular service.  Depending
 on SLAs, TE and cost/performance ratio goals, path computation
 requests may be issued differently for different services.  A given
 Service A, for instance, may require two Shared Risk Link Group
 (SRLG)-disjoint paths for building end-to-end recovery scheme, while

Bryskin, et al. Informational [Page 4] RFC 5394 Policy-Enabled Path Computation December 2008

 for a Service B link-disjoint paths may be sufficient.  Service A may
 need paths with minimal end-to-end delay, while Service B may be
 looking for shortest (minimal-cost) paths.  Different constraint
 relaxation strategies may be applied while computing paths for
 Service A and for Service B, and so forth.  So, based on distinct
 service requirements, distinct or similar policies may be adopted
 when issuing/handling path computation requests.
 Likewise, a PCE may apply policies to decide which algorithm(s) to
 use while performing path computations requested from a particular
 PCC or for a particular domain, see [RFC4927]; whether to seek the
 cooperation of other PCEs to satisfy a particular request or to
 handle a request on its own (possibly responding with non-explicit
 paths), or how the request should be modified before being sent to
 other member(s) of a group of cooperating PCEs, etc.
 Additional motivation for supporting policies within the PCE
 architecture can be described as follows.  Historically, a path
 computation entity was an intrinsic part of an LSR's control plane
 and always co-located with the LSR's signaling and routing
 subsystems.  This approach allowed for unlimited flexibility in
 providing various path computation enhancements, such as: adding new
 types of constraints, diversities and their relaxation strategies,
 adopting new objective functions and optimization criteria, etc.  All
 that had to be done to support an enhancement was to upgrade the
 control plane software of a particular LSR (and no other LSRs or any
 other network elements).
 With the introduction of the PCE architecture, the introduction of
 new PCE capabilities becomes more complicated: it isn't enough for a
 PCE to upgrade its own software.  In order to take advantage of a
 PCE's new capabilities, new advertising and signaling objects may
 need to be standardized, all PCCs may need to be upgraded with new
 software, and new interoperability problems may need to be resolved,
 etc.
 Within the context of the PCE architecture, it is therefore highly
 desirable to find a way to introduce new path computation
 capabilities without requiring modifying either the
 discovery/communication protocols or the PCC software.  One way to
 achieve this objective is to consider path selection constraints,
 their relaxations, and objective functions, as path computation
 request-specific policies.  Furthermore, such policies may be
 configured and managed by a network operator as any other policies
 and may be interpreted in real time by PCCs and PCEs.

Bryskin, et al. Informational [Page 5] RFC 5394 Policy-Enabled Path Computation December 2008

 There are a number of advantages and useful by-products of such an
 approach:
  1. New path computation capabilities may be introduced without

changing PCE-PCC communication and discovery protocols or PCC

   software.  Only the PCE module providing the path computation
   capabilities (referred to in this document as a path computation
   engine) needs to be updated.
  1. Existing constraints, objective functions and their relaxations may

be aggregated and otherwise associated, thus producing new, more

   complex objective functions that do not require a change of code
   even on the PCEs supporting the functions.
  1. Different elements such as conditions, actions, variables, etc.,

may be reused by multiple constraints, diversities, and

   optimizations.
  1. PCCs and PCEs need to handle other (that is, not request-specific)

policies. Path computation-related policies of all types can be

   placed within the same policy repositories, managed by the same
   policy management tools, and interpreted using the same mechanisms.
   Also, policies need to be supported by PCCs and PCEs independent of
   the peculiarities of a specific PCC-PCE communication protocol, see
   [PCEP].  Thus, introducing a new (request-specific) type of policy
   describing constraints and other elements of a path computation
   request will be a natural and relatively inexpensive addition to
   the policy-enabled path computation architecture.

2.2. Policy Attributes

 This section provides a summary listing of the policy attributes that
 may be included in the policy exchanges described in the scenarios
 that follow.  This list is provided for guidance and is not intended
 to be exclusive.  Implementation of this framework might include
 additional policy attributes not listed here.
    Identities
  1. LSP head-end
  2. LSP destination
  3. PCC
  4. PCE

Bryskin, et al. Informational [Page 6] RFC 5394 Policy-Enabled Path Computation December 2008

    LSP identifiers
  1. LSP head-end
  2. LSP destination
  3. Tunnel identifier
  4. Extended tunnel identifier
  5. LSP ID
  6. Tunnel name
    Requested LSP qualities
  1. bandwidth
  2. traffic parameters
  3. LSP attributes
  4. explicit path inclusions
  5. explicit path exclusions
  6. link protection level
  7. setup priority
  8. holding priority
  9. preexisting LSP route
    Requested path computation behavior
  1. objective function
  2. other LSPs to be considered
    Additional policy information
  1. Transparent policy information as received in Resource

Reservation Protocol (RSVP)-TE

2.3. Representative Policy Scenarios

 This section provides example scenarios of how policies may be
 applied using the PCE policy framework within the PCE architecture
 context.  Actual networks may deploy 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 policies within the PCE architecture.

2.3.1. Scenario: Policy Configured Paths

 A very simple usage scenario for PCE policy would be to use PCE to
 centrally administer configured paths.  Configured paths are composed
 of strict and loose hops in the form of Explicit Route Objects
 (EROs), see [RFC3209], and are used by one or more LSPs.  Typically,
 such paths are configured at the LSP ingress.  In the context of
 policy-enabled path computation, an alternate approach is possible.

Bryskin, et al. Informational [Page 7] RFC 5394 Policy-Enabled Path Computation December 2008

 In particular, service-specific policies can be installed that will
 provide configured path(s) for a specific service request.  The
 request may be identified based on service parameters such as
 endpoints, requested QoS, or even a token that identifies the
 initiator of a service request.  The configured path(s) would then be
 used as input to the path computation process, which would return
 explicit routes by expanding of all specified loose hops.
 Example of policy:
  if(service_destination matches 10.132.12.0/24)
     Use path: 10.125.13.1 => 10.125.15.1 => 10.132.12.1.
  else
     Compute path dynamically.
  1. ———————

| —– |

       |             | 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 1: Policy Enabled PCC and PCE
 Path computation policies may be applied at either a PCC or a PCE,
 see Figure 1.  In the PCC case, the configured path would be
 processed at the PCC and then passed to the PCE along with the PCE
 request, probably in the form of (inclusion) constraints.  When
 applied at the PCE, the configured path would be used locally.  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.

Bryskin, et al. Informational [Page 8] RFC 5394 Policy-Enabled Path Computation December 2008

  1. —————– ——————-

| | | |

    |        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 2: Multiple PCE Path Computation
  1. —————– ——————

| | 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 3: Multiple PCE Path Computation with Inter-PCE Communication
 Policy-configured paths may also be used in environments with
 multiple (more than one) cooperating PCEs (see Figures 2 and 3).  For
 example, consider the case when there is limited TE visibility and
 independent PCEs are used to determine path(s) within each area of
 the TE visibility.  In such a case, it may not be possible (or
 desirable) to configure entire explicit path(s) on a single PCE.
 However, it is possible to configure explicit path(s) for each area
 of the TE visibility and each responsible PCE.  One by one, the PCEs
 would then map an incoming signaling request to appropriate
 configured path(s).  Note that to make such a scenario work, it would

Bryskin, et al. Informational [Page 9] RFC 5394 Policy-Enabled Path Computation December 2008

 likely be necessary to start and finish the configured paths on TE
 domain boundary nodes.  Clearly, consistent PCE Policy Repositories
 are also critical in this example.

2.3.2. Scenario: Provider Selection Policy

 A potentially more interesting scenario is applying PC policies in
 multi-provider topologies.  There are numerous interesting policy
 applications in such topologies.  A rudimentary example is simple
 access control, that is, deciding which PCCs are permitted to request
 inter-domain path computation.
 A more complicated example is applying policy to determine which
 domain or network provider will be used to support a particular PCE
 request.  Consider the topology presented in Figure 4.  In this
 example, there are multiple transit domains available to provide a
 path from a source domain to a destination domain.  Furthermore, each
 transit domain may have one or more options for reaching a particular
 domain.  Each domain will need to select which of the multiple
 available paths will be used to satisfy a particular PCE request.
 In today's typical path computation process, TE reachability,
 availability, and metric are the basic criteria for path selection.
 However, policies can provide an important added consideration in the
 decision process.  For example, transit domain A may be more
 expensive and provide lower delay or loss than transit domain B.
 Likewise, a transit domain may wish to treat PCE requests from its
 own customers differently than requests from other providers.  In
 both cases, computation based on traffic engineering databases will
 result in multiple transit domains that provide reachability, and
 policies can be used to govern which PCE requests get better service.

Bryskin, et al. Informational [Page 10] RFC 5394 Policy-Enabled Path Computation December 2008

                            +-------+
                 +----------+Transit+----------+
             +---+---+      | Domain|      +---+---+
             |Transit|      |   C   |      |Transit|
    +--------+ Domain|      +---+---+      | Domain+--------+
    |        |   A   +--+       |       +--+   F   |        |
 +--+---+    +---+---+  |       |       |  +---+---+     +--+---+
 |Source|        |      |   +---+---+   |      |         |Target|
 |Domain|        |      +---+Transit+---+      |         |Domain|
 +--+---+        |      +---+ Domain|---+      |         +--+---+
    |        +---+---+  |   |   D   |   |  +---+---+        |
    |        |Transit|  |   +---+---+   |  |Transit|        |
    +--------+ Domain+--+       |       +--+ Domain+--------+
             |   B   |          |          |   G   |
             +---+---+      +---+---+      +---+---+
                 |          |Transit|          |
                 +----------+ Domain+----------+
                            |   E   |
                            +-------+
     Figure 4: Multi-Domain Network with Multiple Transit Options
 There are multiple options for differentiating which PCE requests use
 a particular transit domain and get a particular (better or worse)
 level of service.  For example, a PCE in the source domain may use
 user- and request-specific policies to determine the level of service
 to provide.  A PCE in the source domain may also use domain-specific
 policies to choose which transit domains are acceptable.  A PCE in a
 transit domain may use request-specific policies to determine if a
 request is from a direct customer or another provider, and then use
 domain-specific policies to identify how the request should be
 processed.
 Example of policy:
  if(path computation request issued by a PCC within Source Domain)
     Route the path through Transit Domain A.
  else
     Route the path through Transit Domain B.

Bryskin, et al. Informational [Page 11] RFC 5394 Policy-Enabled Path Computation December 2008

2.3.3. Scenario: Policy Based Constraints

 Another usage scenario is the use of policy to provide constraints in
 a PCE request.  Consider an LSR with a policy enabled PCC, as shown
 in Figure 1, which receives a service request via signaling,
 including over a Network-Network Interface (NNI) or User Network
 Interface (UNI) reference point, or receives a configuration request
 over a management interface to establish a service.  In either case,
 the path(s) needed to support the service are not explicitly
 specified in the message/request, and 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, optimization criterion, and
 constraint relaxation strategies 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, such as 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 are determined, the PCC generates a path computation
 request that includes the request-specific policies that describe the
 determined set of constraints, optimizations, and other parameters
 that indicate how the request is to be considered in the path
 computation process.
 Example of policy:
  if(LSP belongs to a WDM layer network)
     Compute the path with wavelength continuity constraint with the
     maximum Optical Signal Noise Ratio (OSNR) at the path end
     optimization.
  else if(LSP belongs to a connection oriented Ethernet layer network)
     Compute the path with minimum end-to-end delay.
  else
     Compute the shortest path.
 The PCC may also apply server-specific policies in order to select
 which PCE to use from the set of known (i.e., discovered or
 configured) PCEs.  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 has a higher likelihood of being satisfied
 in an efficient way.  An example of a request modification as the
 result of a server-specific policy is removing a constraint not
 supported by the PCE.  Once the policy processing is completed at the

Bryskin, et al. Informational [Page 12] RFC 5394 Policy-Enabled Path Computation December 2008

 PCC, and the path computation request resulting from the original
 service request is updated by the policy processing, the request is
 sent to the PCE.
 Example of policy:
  if(LSP belongs to a WDM layer network)
     Identify a PCE supporting wavelength continuity and optical
     impairment constraints;
     Send a request to such PCE, requesting path computation with the
     following constraints:
        a) wavelength continuity;
        b) maximum Polarization Mode Dispersion (PMD) at the path end.
     if(the path computation fails) remove the maximum PMD constraint
        and try the computation again.
 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 available at the PCE, e.g., client- and domain-
 specific policies.  As a result of the policy processing, the PCE may
 decide to reject the request.
 Example of policy:
  Authenticate the PCC requesting the path computation using the
  PCC ID found in the path computation request;
  Reject the request if the authentication fails.
 The PCE also may decide to respond with one or several pre-computed
 paths if user- or client-specific policies 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 requests 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 the result back to the requesting PCC.  The
 response may indicate 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
 constraints were honored, which were dismissed, and which were
 relaxed and in what way.

Bryskin, et al. Informational [Page 13] RFC 5394 Policy-Enabled Path Computation December 2008

 Example of policy:
  if(the path destination belongs to domain A)
     Instruct local path computation engine to perform the path
     computation;
  else
     Identify the PCE supporting the destination domain;
     Send path computation request to such PCE;
     Wait for and process the response.
  Send the path computation response to the requesting PCC.
 The PCC processes the response and instructs the LSR to encode the
 received path(s) into the outgoing signaling message(s).

2.3.4. Scenario: Advanced Load Balancing (ALB) Example

 Figure 5 illustrates a problem that stems from the coupling between
 BGP and IGP in the BGP decision process.  If a significant portion of
 the traffic destined for the data center (or customer network) enters
 a PCE-enabled network from AS 1 and all IGP links' weights are the
 same, then both PE3 and PE4 will prefer to reach the data center
 using the routes advertised by PE2.  PE5 will use the router-IDs of
 PE1 and PE2 to break the tie and might therefore also select to use
 the path through PE2 (if the router ID of PE2 is smaller than that of
 PE1).  Either way, the net result is that the link between PE2 and CE
 will carry most of the traffic while the link between PE1 and the
 Customer Edge (CE) will be mostly idle.

Bryskin, et al. Informational [Page 14] RFC 5394 Policy-Enabled Path Computation December 2008

                         ..............................
                         .          AS 1              .
                         .                            .
                         .   +---+   +---+   +----+   .
                         ....|PE8|...|PE9|...|PE10|....
                             +---+   +---+   +----+
                               |       |       |
                             +---+   +---+   +---+
                       ......|PE3|...|PE4|...|PE5|......
                       .     +---+   +---+   +---+     .
  ..............     +---+     \      /    ___/      +---+
  .            .    _|PE2|_____+--+__/    /         _|PE6|
  .           +--+ / +---+     |P1|_____+--+_______/ +---+
  . Customer  |CE|=    .       +--+     |P2|           .
  . Network   +--+ \_+---+        \     +--+           .
  .            .     |PE1|________+--+___/|     x===x  .  PCE used
  ..............     +---+        |P3|    |     |PCE|  .  by all
                       .          +--+    |     x===x  .  AS0 nodes
                       .    AS 0         +---+         .
                       ..................|PE7|..........
                                         +---+
                   Figure 5: Advanced Load Balancing
 This is a common problem for providers and customers alike.  Analysis
 of Netflow records, see [IRSCP], for a large ISP network on a typical
 day has shown that for 71.8% of multi-homed customers, there is a
 complete imbalance, where the most loaded link carries all the
 traffic and the least loaded link carries none.
 PCE policies can address this problem by basing the routing decision
 at the ingress routers on the offered load towards the multi-homed
 customer.  For example, in Figure 5, PCE policies could be configured
 such that traffic load is monitored (e.g., based on Netflow data) at
 ingress routers PE3 to PE7 towards the data center prefixes served by
 egress routers PE1 and PE2.  Using this offered load information, the
 path computations returned by PCE, based on the enabled PCE policies,
 can direct traffic to the appropriate egress router, on a per-ingress
 router basis.  For example, the PCE path computation might direct
 traffic from both PE4 and PE5 to egress PE1, thus overriding the
 default IGP based selection.  Alternatively, traffic from each
 ingress router to each egress link could be split 50-50.
 This scenario is a good example of how a policy-governed PCE can
 account for some information that was not or cannot be advertised as
 TE link/node attributes, and, therefore, cannot be subject for
 explicit path computation constraints.  More generally, such
 information can be pretty much anything.  For example, traffic demand

Bryskin, et al. Informational [Page 15] RFC 5394 Policy-Enabled Path Computation December 2008

 forecasts, flow monitoring feedback, any administrative policies,
 etc.  Further examples are described in [IRSCP] of how PCE policies
 might address certain network routing problems, such as selective
 distributed denial-of-service (DDoS) blackholing, planned
 maintenance, and VPN gateway selection.
 Example of policy:
  for(all traffic flows destined to Customer Network)
     if(flow ingresses on PE3, PE4, or PE5)
        Route the flow over PE1.
     else
        Route the flow over PE2.

3. Requirements

 The following requirements must be addressed by mechanisms and
 protocols that enable policy-based control over path computation
 requests and decisions:
  1. (G)MPLS path computation-specific

The mechanisms must meet the policy-based control requirements

   specific to the problem of path computation using RSVP-TE as the
   signaling protocol on MPLS and GMPLS LSRs.
  1. Support for non-(G)MPLS PCCs

The mechanisms must be sufficiently generic to support non-(G)MPLS

   (LSR) clients such as a Network Management System (NMS), or network
   planner, etc.
  1. Support for many policies

The mechanisms must include support for many policies and policy

   configurations.  In general, the determination and configuration of
   viable policies are the responsibility of the service provider.
  1. Provision for monitoring and accounting information

The mechanisms must include support for monitoring policy state and

   provide access information.  In particular, mechanisms must provide
   usage and access information that may be used for accounting
   purposes.
  1. Fault tolerance and recovery

The mechanisms must include provisions for fault tolerance and

   recovery from failure cases such as failure of PCC/PCE PDPs,
   disruption in communication that separate a PCC/PCE PDP from its
   associated PCC/PCE PEPs.

Bryskin, et al. Informational [Page 16] RFC 5394 Policy-Enabled Path Computation December 2008

  1. Support for policy-ignorant nodes

The mechanisms should not be mandatory for every node in a network.

   Policy-based path computation control may be enforced at a subset
   of nodes, for example, on boundary nodes within an administrative
   domain.  These policy-capable nodes will function as trusted nodes
   from the point of view of the policy-ignorant nodes in that
   administrative domain.  Alternatively, policy may be applied solely
   on PCEs with all PCCs being policy-ignorant nodes.
  1. Scalability

One of the important requirements for the mechanisms is

   scalability.  The mechanisms must scale at least to the same extent
   that RSVP-TE signaling scales in terms of accommodating multiple
   LSPs and network nodes in the path of an LSP.  There are several
   sensitive areas in terms of scalability of policy-based path
   computation control.  First, not every policy-aware node in an
   infrastructure should be expected to contact a remote PDP.  This
   would cause potentially long delays in verifying requests.
   Additionally, the policy control architecture must scale at least
   as well as RSVP-TE protocol based on factors such as the size of
   RSVP-TE messages, the time required for the network to service an
   RSVP-TE request, local processing time required per node, and local
   memory consumed per node.  These scaling considerations are of
   particular importance during re-routing of a set of LSPs.
  1. Security and denial-of-service considerations

The policy control architecture, protocols, and mechanisms must be

   secure as far as the following aspects are concerned:
    o First, the mechanisms proposed must minimize theft and denial-
      of-service threats.
    o Second, it must be ensured that the entities (such as PEPs and
      PDPs) involved in policy control can verify each other's
      identity and establish necessary trust before communicating.
  1. Inter-AS and inter-area requirements

There are several inter-AS policy-related requirements discussed in

   [RFC4216] and [RFC5376], and inter-area policy-related requirements
   discussed in [RFC4927].  These requirements must be addressed by
   policy-enabled PCE mechanisms and protocols.
 It should be noted that this document only outlines the communication
 elements and mechanisms needed to allow a wide variety of possible
 policies to be applied for path computation control.  It does not
 include any discussion of any specific policy behavior, nor does it
 define or require use of specific policies.

Bryskin, et al. Informational [Page 17] RFC 5394 Policy-Enabled Path Computation December 2008

4. Path Computation Policy Information Model (PCPIM)

 The Policy Core Information Model (PCIM) introduced in [RFC3060] and
 expanded in [RFC3460] presents the object-oriented information model
 for representing general policy information.
 This model defines two hierarchies of object classes:
  1. Structural classes representing policy information and control of

policies.

  1. Association classes that indicate how instances of the structural

classes are related to each other.

 These classes can be mapped to various concrete implementations, for
 example, to a directory that uses Lightweight Directory Access
 Protocol version 3 (LDAPv3) as its access protocol.
 Figure 6 shows an abstract from the class inheritance hierarchy for
 PCIM.

Bryskin, et al. Informational [Page 18] RFC 5394 Policy-Enabled Path Computation December 2008

 ManagedElement (abstract)
    |
    +--Policy (abstract)
    |  |
    |  +---PolicySet (abstract)
    |  |   |
    |  |   +---PolicyGroup
    |  |   |
    |  |   +---PolicyRule
    |  |
    |  +---PolicyCondition (abstract)
    |  |   |
    |  |   +---PolicyTimePeriodCondition
    |  |   |
    |  |   +---VendorPolicyCondition
    |  |   |
    |  |   +---SimplePolicyCondition
    |  |   |
    |  |   +---CompoundPolicyCondition
    |  |       |
    |  |       +---CompoundFilterCondition
    |  |
    |  +---PolicyAction (abstract)
    |  |   |
    |  |   +---VendorPolicyAction
    |  |   |
    |  |   +---SimplePolicyAction
    |  |   |
    |  |   +---CompoundPolicyAction
    |  |
    |  +---PolicyVariable (abstract)
    |  |   |
    |  |   +---PolicyExplicitVariable
    |  |   |
    |  |   +---PolicyImplicitVariable
    |  |       |
    |  |       +---(subtree of more specific classes)
    |  |
    |  +---PolicyValue (abstract)
    |      |
    |      +---(subtree of more specific classes)
                   Figure 6: PCIM Class Inheritance
 The policy classes and associations defined in PCIM are sufficiently
 generic to allow them to represent policies related to anything.

Bryskin, et al. Informational [Page 19] RFC 5394 Policy-Enabled Path Computation December 2008

 Policy models for application-specific areas such as the Path
 Computation Service may extend the PCIM in several ways.  The
 preferred way is to use the PolicyGroup, PolicyRule, and
 PolicyTimePeriodCondition classes directly as a foundation for
 representing and communicating policy information.  Then, specific
 subclasses derived from PolicyCondition and PolicyAction can capture
 application-specific definitions of conditions and actions of
 policies.
 The Policy Quality of Service Information Model [RFC3644] further
 extends the PCIM to represent QoS policy information for large-scale
 policy domains.  New classes introduced in this document describing
 QoS- and RSVP-related variables, conditions, and actions can be used
 as a foundation for the PCPIM.
 Detailed description of the PCPIM will be provided in a separate
 document.

5. Policy-Enabled Path Computation Framework Components

 The following components are defined as part of the framework to
 support policy-enabled path computation:
  1. PCE Policy Repository

A database from which PCE policies are available in the form of

   instances of PCPIM classes.  PCE Policies are configured and
   managed by PCE Policy Management Tools;
  1. PCE Policy Decision Point (PCE-PDP)

A logical entity capable of retrieving relevant path computation

   policies from one or more Policy Repositories and delivering the
   information to associated PCE-PEP(s);
  1. PCE Policy Enforcement Point (PCE-PEP)

A logical entity capable of issuing device-specific Path

   Computation Engine configuration requests for the purpose of
   enforcing the policies;
  1. PCC Policy Decision Point (PCC-PDP)

A logical entity capable of retrieving relevant path computation

   policies from one or more Policy Repositories and delivering the
   information to associated PCC-PEP(s);
  1. PCC Policy Enforcement Point (PCC-PEP)

A logical entity capable of issuing device-specific Path

   Computation Service User configuration requests for the purpose of
   enforcing the policies.

Bryskin, et al. Informational [Page 20] RFC 5394 Policy-Enabled Path Computation December 2008

 From the policy perspective a PCC is logically decomposed into two
 parts: PCC-PDP and PCC-PEP.  When present, a PCC-PEP is co-located
 with a Path Computation Service User entity that requires remote path
 computation (for example, the GMPLS control plane of an LSR).  The
 PCC-PEP and PCC-PDP may be physically co-located (as per [RFC2748])
 or separated.  In the latter case, they talk to each other via such
 protocols as SOAP [W3CSOAP] or BEEP [RFC3080].
 Likewise, a PCE is logically decomposed into two parts: PCE-PEP and
 PCE-PDP.  When present, PCE-PEP is co-located with a Path Computation
 Engine entity that actually provides the Path Computation Service
 (that is, runs path computation algorithms).  PCE-PEP and PCE-PDP may
 be physically co-located or separated.  In the later case, they
 communicate using such protocols as SOAP and/or BEEP.
 PCC-PDP/PCE-PDP may be co-located with, or separated from, an
 associated PCE Policy Repository.  In the latter case, the PDPs use
 some access protocol (for example, LDAPv3 or SNMP).  The task of PDPs
 is to retrieve policies from the repository (or repositories) and
 convey them to respective PEPs either in an unsolicited way or upon
 the PEP's requests.
 A PCC-PEP may receive policy information not only from PCC-PDP(s) but
 also from PCE-PEP(s) via PCC-PCE communication and/or PCE discovery
 protocols.  Likewise, a PCE-PEP may receive policy information not
 only from PCE-PDP(s) but also from PCC-PEP(s), via the PCC-PCE
 communication protocol [PCEP].
 Any given policy can be interpreted (that is, translated into a
 sequence of concrete device specific configuration requests) either
 on a PDP or on the associated PEP or partly on the PDP and partly on
 the PEP.
 Generally speaking, the task of the PCC-PEP is to select the PCE and
 build path computation requests applying service-specific policies
 provided by the PCC-PDP.  The task of the PCE-PEP is to control path
 computations by applying request-specific policies found in the
 requests as well as client-specific and domain-specific policies
 supplied by the PCE-PDP.

6. Policy Component Configurations

6.1. PCC-PCE Configurations

 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 be applied at
 both, or even at either.  The use of policy in a network, on PCCs,

Bryskin, et al. Informational [Page 21] RFC 5394 Policy-Enabled Path Computation December 2008

 and on PCEs, is a specific network design choice.  Some networks may
 choose to apply policy only at PCCs (Figure 7), some at PCEs (Figure
 8), and others at both PCCs and PCEs (Figure 9).  Regardless of where
 policy is applied, it must be applied in a consistent fashion in
 order to achieve the intended results.
                       .........................
                       .                       .
                       . PCE Policy Management .
                       .                       .
                       .........................
                                   .
                                   .
  ---------  Policy     -----------------------
 | PCC-PDP |<--------- | PCE Policy Repository |
  ---------             -----------------------
      ^
      | e.g., SOAP
      v
  ---------                     PCEP                      ---------
 | PCC-PEP |<------------------------------------------->|   PCE   |
  ---------         PCC-PCE Communication Protocol        ---------
                Figure 7: Policies Applied on PCC Only
 Along with supporting flexibility in where policy may be applied, the
 PCE architecture is also flexible in terms of where specific types of
 policies may be applied.  Also, the PCE architecture allows for the
 application of only a subset of policy types.  [RFC4655] defines
 several PC policy types.  Each of these may be applied at either a
 PCC or a PCE or both.  Clearly, when policy is only applied at PCCs
 or at PCEs, all PCE policy types used in the network must be applied
 at those locations.

Bryskin, et al. Informational [Page 22] RFC 5394 Policy-Enabled Path Computation December 2008

                       .........................
                       .                       .
                       . PCE Policy Management .
                       .                       .
                       .........................
                                   .
                                   .
                        -----------------------  Policy    ---------
                       | PCE Policy Repository | -------->| PCE-PDP |
                        -----------------------            ---------
                                                              ^
                                                   e.g., SOAP |
                                                              v
  ---------                     PCEP                      ---------
 |   PCC   |<------------------------------------------->| PCE-PEP |
  ---------         PCC-PCE Communication Protocol        ---------
                  Figure 8: Policies Applied on Only
 In the case where 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 can gather in the path computation request (most likely in
 the form of PCPIM policy variables).  The PCE is expected to
 understand this information and apply appropriate policies while
 defining the actual parameters of the path computation to be
 performed.  Note that in this scenario, the PCC cannot apply server-
 specific or any other policies, and PCE selection is static.
 When applying policy at both the PCC and PCE, 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 the PCC and PCE rather than applying all
 of them at both.  For example, user-specific and server-specific
 policies may be applied at a PCC, request- and client-specific
 policies may be applied at a PCE, while domain-specific policies may
 be applied at both the PCC and 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-,
 server-, 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" (that is, non-policy capable) constraints explicitly
 defined by the PCC-PCE communication protocol.

Bryskin, et al. Informational [Page 23] RFC 5394 Policy-Enabled Path Computation December 2008

6.2. Policy Repositories

 Within the policy-enabled path computation framework policy
 repositories may be used in a single or multiple PCE policy
 repository configuration:
 o) Single PCE Policy Repository
 In this configuration, there is a single PCE Policy Repository shared
 between PCCs and PCEs.
                       .........................
                       .                       .
                       . PCE Policy Management .
                       .                       .
                       .........................
                                   .
                                   .
  ---------  Policy a   -----------------------  Policy b  ---------
 | PCC-PDP |<--------- | PCE Policy Repository | -------->| PCE-PDP |
  ---------             -----------------------            ---------
      ^                                                       ^
      | e.g., SOAP                                 e.g., SOAP |
      v                                                       v
  ---------                     PCEP                      ---------
 | PCC-PEP |<------------------------------------------->| PCE-PEP |
  ---------         PCC-PCE Communication Protocol        ---------
              Figure 9: Single PCC/PCE Policy Repository
 o) Multiple PCE Policy Repositories
 The repositories in this case may be fully or partially synchronized
 by some discovery/synchronization management protocol or may be
 completely independent.  Note that the situation when PCE Policy
 Repository A exactly matches PC Policy Repository B, results in the
 single PCE Policy Repository configuration case.

Bryskin, et al. Informational [Page 24] RFC 5394 Policy-Enabled Path Computation December 2008

  1. ————- ————–

| PCE Policy | | PCE Policy |

  1. –| Repository A | | Repository B |—

| ————– ————– |

      |                                                       |
      | Policy a                                     Policy b |
      |                                                       |
      v                                                       v
  ---------                                               ---------
 | PCC-PDP |                                             | PCE-PDP |
  ---------                                               ---------
      ^                                                       ^
      | e.g., SOAP                                 e.g., SOAP |
      v                                                       v
  ---------                     PCEP                      ---------
 | PCC-PEP |<------------------------------------------->| PCE-PEP |
  ---------         PCC-PCE Communication Protocol        ---------
            Figure 10: Multiple PCE/PCC Policy Repositories

6.3. Cooperating PCE Configurations

 The previous section shows the relationship between PCCs and PCEs.  A
 parallel relationship exists between cooperating PCEs, and, in fact,
 this relationship can be viewed as the same as the relationship
 between PCCs and PCEs.  The one notable difference is that there will
 be cases where having a shared PCE Policy Repository will not be
 desirable, for example, when the PCEs are managed by different
 entities.  Note that in this case, it still remains necessary for the
 policies to be consistent across the domains in order to identify
 usable paths.  The other notable difference is that a PCE, while
 processing a path computation request, may need to apply requester-
 specific (that is, client-specific) policies in order to modify the
 request before sending it to other cooperating PCE(s).  This
 relationship is particularly important as the PCE architecture allows
 for configuration where all PCCs are not policy-enabled.
 The following are example configurations.  These examples do not
 represent an exhaustive list and other configurations are expected.
 o) Single Policy Repository
 In this configuration, there is a single PCE Policy Repository shared
 between PCEs.  This configuration is likely to be useful within a
 single administrative domain where multiple PCEs are provided for
 redundancy or load distribution purposes.

Bryskin, et al. Informational [Page 25] RFC 5394 Policy-Enabled Path Computation December 2008

                       .........................
                       .                       .
                       . PCE Policy Management .
                       .                       .
                       .........................
                                   .
                                   .
  ---------  Policy a   -----------------------  Policy b  ---------
 | PCE-PDP |<--------- | PCE Policy Repository | -------->| PCE-PDP |
  ---------             -----------------------            ---------
      ^                                                       ^
      | e.g., SOAP                                 e.g., SOAP |
      v                                                       v
  ---------                                               ---------
 | PCE-PEP |<------------------------------------------->| PCE-PEP |
  ---------         PCE-PCE Communication Protocol        ---------
                Figure 11: Single PCC Policy Repository
 o) Multiple Policy Repositories
 The repositories in this case may be fully or partially synchronized
 by some discovery/synchronization management protocol(s) or may be
 completely independent.  In the multi-domain case, it is expected
 that the repositories will be distinct, providing, however,
 consistent policies.
  1. ————- ————–

| PCE Policy | | PCE Policy |

  1. –| Repository A | | Repository B |—

| ————– ————– |

      |                                                       |
      | Policy a                                     Policy b |
      |                                                       |
      v                                                       v
  ---------                                               ---------
 | PCE-PDP |                                             | PCE-PDP |
  ---------                                               ---------
      ^                                                       ^
      | e.g., SOAP                                 e.g., SOAP |
      v                                                       v
  ---------                     PCEP                      ---------
 | PCE-PEP |<------------------------------------------->| PCE-PEP |
  ---------         PCC-PCE Communication Protocol        ---------
              Figure 12: Multiple PCC Policy Repositories

Bryskin, et al. Informational [Page 26] RFC 5394 Policy-Enabled Path Computation December 2008

6.4. Policy Configuration Management

 The management of path computation policy information used by PCCs
 and PCEs is largely out of scope of the described framework.  The
 framework assumes that such information is installed, removed, and
 otherwise managed using typical policy management techniques.  Policy
 Repositories may be populated and managed via static configuration,
 standard and proprietary policy management tools, or even dynamically
 via policy management/discovery protocols and applications.

7. Inter-Component Communication

7.1. Policy Communication

 Flexibility in the application of policy types is imperative from the
 architecture perspective.  However, this commodity implies added
 complexity on the part of the PCE-related communication protocols.
 One added complexity is that PCE communication protocols must carry
 certain information to support various policy types 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 service- or user-specific policies.  This does imply that a
 PCC must have sufficient understanding of what policies can be
 applied at the PCE.  Such information may be obtained via local
 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 policy type.
 Another added complexity is that PCE communication protocols must
 also be able to carry information that may result from a policy
 decision.  For example, user- or service-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.  This complexity is
 particularly important as it may be used to introduce new path
 computation parameters (e.g., constraints, objection functions, etc.)
 without modification of the core PCC and PCE.  This communication
 will likely simply require the PCE communication protocols to support
 opaque policy-related information elements.
 A final added complexity is that 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
 information that must be provided to a PCC.

Bryskin, et al. Informational [Page 27] RFC 5394 Policy-Enabled Path Computation December 2008

 PCC-PEP and PCE-PEP or a pair of PCE-PEPs communicate via a request-
 response type PCC-PCE Communication Protocol, i.e., [PCEP].  This
 document makes no assumptions as to what exact protocol is used to
 support this communication.  This document does assume that the
 semantics of a path computation request are sufficiently abstract and
 general, and support both PCE-PCC and PCE-PCE communication.
 From a policy perspective, a path computation request should include
 at a minimum:
 o One or more source addresses;
 o One or more destination addresses;
 o Computation type (P2P (point to point), P2MP (point to multipoint),
   MP2P (multipoint to point), etc.);
 o Number of required paths;
 o Zero or more policy descriptors in the following format:
   <policy name>,
   <policy variable1 name>, <param11>, <param12>,...,<param1N>
   <policy variable2 name>, <param21>, <param12>,...,<param2N>
   ...
   <policy variableM name>, <paramM1>, <paramM2>,...,<paramMN>
 A successful path computation response, at minimum, should include
 the list of computed paths and may include policies (in the form of
 policy descriptors as in path computation request, see above) for use
 in evaluating and otherwise applying the computed paths.
 PCC-PCE Communication Protocol provides transport for policy
 information and should not understand nor make any assumptions about
 the semantics of policies specified in path computation requests and
 responses.
 Note: This document explicitly allows for (but does not require) the
 PCC to decide that all necessary constraints, objective functions,
 etc.  pertinent to the computation of paths for the service in
 question are to be determined by the PCE performing the computation.
 In this case, the PCC will use a set of policies (more precisely,
 PCPIM policy variables) describing the service-specific information.
 These policies may be placed within the path computation request and
 delivered to the PCE via a PCC-PCE communication protocol such as
 [PCEP].  The PCE (more precisely, PCE-PEP) is expected to understand
 this information and use it to determine the constraints and
 optimization functions applying local policies (that is, policies
 locally configured or provided by the associated PCE-PDP(s)).

Bryskin, et al. Informational [Page 28] RFC 5394 Policy-Enabled Path Computation December 2008

7.2. PCE Discovery Policy Considerations

 Dynamic PCE discovery allows for PCCs and PCEs to automatically
 discover a set of PCEs (including information required for the PCE
 selection).  It also allows for PCCs and PCEs to dynamically detect
 new PCEs or any modification of PCEs status.  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 presence and
    location).
 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 PCE discovery protocol(s) or PCC-PCE
    communication protocol(s).  One important policy decision in this
    context is the nature of the information to be distributed,
    especially, when this information is not strictly speaking
    "discovery" information, rather, the PCE state changes.  Client-
    specific and domain-specific policies may be applied when deciding
    whether this information should be distributed and to which
    clients of the path computation service (that is, which PCCs
    and/or PCEs).
 Another place where policy applies is at the administrative
 boundaries.  In multi-domain networks, multiple PCEs will communicate
 with each other and across administrative boundaries.  In such cases,
 domain-specific policies would be applied to 1) filter the
 information exchanged between peering PCEs during the discovery
 process (to the bare minimum in most cases if at all allowed by the
 security policy) and 2) limit the content of information being passed
 in path computation request and responses.

8. Path Computation Sequence of Events

 This section presents a non-exhaustive list of representative
 scenarios.

8.1. Policy-Enabled PCC, Policy-Enabled PCE

 When a GMPLS LSR receives a Setup (RSVP Path) message from an
 upstream LSR, the LSR may decide to use a remote Path Computation
 Entity.  The following sequence of events occurs in this case:
  1. A PCC-PEP co-located with the LSR applies the service-specific

policies to select a PCE for the service path computation as well

   as to build the path computation request (that is, to select a list

Bryskin, et al. Informational [Page 29] RFC 5394 Policy-Enabled Path Computation December 2008

   of policies, their variables, conditions and actions expressing
   constraints, diversities, objective functions and relaxation
   strategies appropriate for the service path computation).  The
   policies may be:
   a) Statically configured on the PCC-PEP;
   b) Communicated to the PCC-PEP by a remote or local PCC-PDP via
      protocol such as SOAP either proactively (most of the cases) or
      upon an explicit request by the PCC-PEP in cases when some
      specifics of the new service have not been covered yet by the
      policies so far known to the PCC-PEP).
   The input for the decision process on the PCC-PEP is the
   information found in the signaling message as well as any other
   service-specific information such as port ID over which the message
   was received, associated VPN ID, the reference point type (UNI,
   E-NNI, etc.) and so forth.  After the path computation request is
   built, it is sent directly to the PCE-PEP using the PCC-PCE
   Communication Protocol, e.g., [PCEP].
  1. PCE-PEP validates and otherwise processes the request applying the

policies found in the request- as well as client- and domain-

   specific policies.  The latter, again, may be either statically
   configured on the PCE-PEP or provided by the associated local or
   remote PCE-PDP via a protocol such as SOAP.  The outcome of the
   decision process is the following information:
   a) Whether the request should be satisfied, rejected, or dismissed.
   b) The sets of sources and destinations for which paths should be
      locally computed.
   c) The set of constraints, diversities, optimization functions, and
      relaxations to be considered in each of locally performed path
      computation.
   d) The address of the next-in-chain PCE.
   e) The path computation request to be sent to the next-in-chain
      PCE.
   The PCE-PEP instructs a co-located path computation engine to
   perform the local path computation(s) and, if necessary, sends the
   path computation request to the next-in-chain PCE using a PCC-PCE
   Communication Protocol.  Then, it waits for the responses from the
   local path computation engine and the remote PCE, combines the
   resulting paths, and sends them back to the PCC-PEP using the PCC-

Bryskin, et al. Informational [Page 30] RFC 5394 Policy-Enabled Path Computation December 2008

   PCE Communication Protocol.  The response contains the resulting
   paths as well as policies describing some additional information
   (for example, which of constraints were honored, which were
   dismissed, and which were relaxed and in what way).
  1. PCC-PEP instructs the signaling subsystem of the GMPLS LSR to

encode the received path(s) into the outgoing Setup message(s).

8.2. Policy-Ignorant PCC, Policy-Enabled PCE

 This case parallels the previous example, but the user- and service-
 specific policies should be applied at the PCE as the PCC is policy
 ignorant.  Again, when a GMPLS LSR has received a Setup (RSVP Path)
 message from an upstream LSR, the LSR may decide to use a non-co-
 located Path Computation Entity.  The following sequence of events
 occurs in this case:
  1. The PCC constructs a PCE request using information found in the

signaling/provisioning message as well as any other service-

   specific information such as port ID over which the message was
   received, associated VPN ID, the reference point type (UNI, E-NNI,
   etc.) and so forth.  This information is encoded in the request in
   the form of policy variables.  After the request is built, it is
   sent directly to the PCE-PEP using a PCC-PCE Communication
   Protocol.
  1. PCE-PEP validates and otherwise processes the request interpreting

the policy variables found in the request and applying user-,

   service-, client-, and domain-specific policies to build the actual
   path computation request.  The policies, again, may be either
   statically configured on the PCE-PEP or provided by the associated
   local or remote PCE-PDP via a protocol such as SOAP.  The outcome
   of the decision process is the following information:
   a) Whether the request should be satisfied, rejected, or dismissed.
   b) The sets of sources and destinations for which paths should be
      locally computed.
   c) The set of constraints, diversities, optimization functions, and
      relaxations to be considered in each of locally performed path
      computation.
   d) The address of the next-in-chain PCE.
   e) The path computation request to be sent to the next-in-chain
      PCE.

Bryskin, et al. Informational [Page 31] RFC 5394 Policy-Enabled Path Computation December 2008

   The PCE-PEP instructs a co-located path computation engine to
   perform the local path computation(s) and, if necessary, sends the
   path computation request to the next-in-chain PCE using the PCC-PCE
   Communication Protocol.  Then, it waits for the responses from the
   local path computation engine and the remote PCE, combines the
   resulting paths, and sends them back to the PCC-PEP using the PCC-
   PCE Communication Protocol.  The response contains the resulting
   paths as well as policies describing some additional information
   (for example, which of constraints were honored, which were
   dismissed, and which were relaxed and in what way)
  1. PCC-PEP instructs the signaling sub-system of the GMPLS LSR to

encode the received path(s) into the outgoing Setup message(s).

9. Introduction of New Constraints

 An important aspect of the policy-enabled path computation framework
 discussed above is the ability to introduce new constraints with
 minimal impact.  In particular, only those components and mechanisms
 that will use a new constraint need to be updated in order to support
 the new constraint.  Importantly, those components and mechanisms
 that will not use the new constraint must not require any change in
 order for the new constraint to be utilized.  For example, the PCE
 communication protocols must not require any changes to support new
 constraints.  Likewise, PCC and PCEs that will not process new
 constraints must not require any modification.
 Consider the case where a PCE has been upgraded with software
 supporting optical physical impairment constraint, such as
 Polarization Mode Dispersion (PMD), that previously was not supported
 in the domain.  In this case, one or more new policies will be
 installed in the PCE Policy Repository (associated with the PCE)
 defining the constraint (rules that determine application criteria,
 set of policy variables, conditions, actions, etc.) and its
 relaxation strategy (or strategies).  The new policies will be also
 propagated into other PCE Policy Repositories within the domain via
 discovery and synchronization protocols or via local configuration.
 PCE-PDPs and PCC-PDPs will then retrieve the corresponding policies
 from the repository (or repositories).  From then on, PCC-PDPs will
 instruct associated PCC-PEPs to add the new policy information into
 path computation requests for services with certain parameters (for
 example, for services provisioned in the optical channel (OCh)
 layer).
 It is important to note that policy-enabled path computation model
 naturally solves the PCE capability discovery issues.  Suppose a PCE
 working in a single PCE Policy Repository configuration starts to
 support a new constraint.  Once a corresponding policy installed in

Bryskin, et al. Informational [Page 32] RFC 5394 Policy-Enabled Path Computation December 2008

 the repository, it automatically becomes available for all repository
 users, that is, PCCs.  In the multi-repository case some policy
 synchronization must be provided; however, this problem is one of the
 management plane which is solved already.

10. Security Considerations

 This document adds to the policy security considerations mentioned in
 [RFC4655].  In particular, it is now necessary to consider the
 security issues related to policy information maintained in PCE
 Policy Repositories and policy-related transactions.  The most
 notable issues, some of which are also listed in [RFC4655], are:
  1. Unauthorized access to the PCE Policy Repositories;
  1. Interception of policy information when it is retrieved from the

repositories and/or transported from PDPs to PEPs;

  1. Interception of policy-related information in path computation

requests and responses;

   o  Impersonation of user and client identities;
   o  Falsification of policy information and/or PCE capabilities;
   o  Denial-of-service attacks on policy-related communication
      mechanisms.
 As with [RFC4655], it is expected that PCE solutions will address the
 PCE aspects of these issues in detail.

11. Acknowledgments

 Adrian Farrel contributed significantly to this document.  We would
 like to thank Bela Berde for fruitful discussions on PBM and policy-
 driven path computation.  We would also like to thank Kobus Van der
 Merwe for providing insights and examples regarding PCE policy
 applications.

Bryskin, et al. Informational [Page 33] RFC 5394 Policy-Enabled Path Computation December 2008

12. References

12.1. Normative References

 [RFC2753]  Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
            for Policy-based Admission Control", RFC 2753, January
            2000.
 [RFC3060]  Moore, B., Ellesson, E., Strassner, J., and A. Westerinen,
            "Policy Core Information Model -- Version 1
            Specification", RFC 3060, February 2001.
 [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.
 [RFC3460]  Moore, B., Ed., "Policy Core Information Model (PCIM)
            Extensions", RFC 3460, January 2003.
 [RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
            Switching (GMPLS) Signaling Resource ReserVation
            Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
            3473, January 2003.
 [RFC3644]  Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B.
            Moore, "Policy Quality of Service (QoS) Information
            Model", RFC 3644, November 2003.
 [RFC4216]  Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-
            Autonomous System (AS) Traffic Engineering (TE)
            Requirements", RFC 4216, November 2005.
 [RFC4655]  Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
            Computation Element (PCE)-Based Architecture", RFC 4655,
            August 2006.
 [RFC4927]  Le Roux, J.-L., Ed., "Path Computation Element
            Communication Protocol (PCECP) Specific Requirements for
            Inter-Area MPLS and GMPLS Traffic Engineering", RFC 4927,
            June 2007.

12.2. Informative References

 [DMTF]     Common Information Model (CIM) Schema, version 2.x.
            Distributed Management Task Force, Inc. The components of
            the CIM v2.x schema are available via links on the
            following DMTF web page:
            http://www.dmtf.org/standards/standard_cim.php.

Bryskin, et al. Informational [Page 34] RFC 5394 Policy-Enabled Path Computation December 2008

 [IRSCP]    Van der Merwe, J., et al., "Dynamic Connectivity
            Management with an Intelligent Route Service Control
            Point," ACM SIGCOMM Workshop on Internet Network
            Management (INM), Pisa, Italy, September 11, 2006.
 [PCEP]     Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
            Element (PCE) Communication Protocol (PCEP)", Work in
            Progress, November 2008.
 [RFC2748]  Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan,
            R., and A. Sastry, "The COPS (Common Open Policy Service)
            Protocol", RFC 2748, January 2000.
 [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
            Label Switching Architecture", RFC 3031, January 2001.
 [RFC3080]  Rose, M., "The Blocks Extensible Exchange Protocol Core",
            RFC 3080, March 2001.
 [RFC3198]  Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
            M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
            J., and S. Waldbusser, "Terminology for Policy-Based
            Management", RFC 3198, November 2001.
 [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
            (TE) Extensions to OSPF Version 2", RFC 3630, September
            2003.
 [RFC5376]  Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS
            Requirements for the Path Computation Element
            Communication Protocol (PCECP)", RFC 5376, November 2008.
 [W3CSOAP]  Hadley, M., Mendelsohn, N., Moreau, J., Nielsen, H., and
            Gudgin, M., "SOAP Version 1.2 Part 1: Messaging
            Framework", W3C REC REC-soap12-part1-20030624, June 2003.

Bryskin, et al. Informational [Page 35] RFC 5394 Policy-Enabled Path Computation December 2008

Authors' Addresses

 Igor Bryskin
 ADVA Optical
 7926 Jones Branch Drive
 Suite 615
 McLean, VA 22102
 EMail: ibryskin@advaoptical.com
 Dimitri Papadimitriou
 Alcatel
 Fr. Wellesplein 1,
 B-2018 Antwerpen, Belgium
 Phone: +32 3 240-8491
 EMail: dimitri.papadimitriou@alcatel.be
 Lou Berger
 LabN Consulting, LLC
 Phone: +1 301 468 9228
 EMail: lberger@labn.net
 Jerry Ash
 AT&T
 EMail: gash5107@yahoo.com

Bryskin, et al. Informational [Page 36]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5394.txt · Last modified: 2008/12/10 18:45 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki