[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Internet Draft                                              Igor Bryskin
Category: Standards Track                                     Lou Berger
Expiration Date: September 5, 2007

                                                           March 5, 2007


           Path Computation Policy Information Model (PCPIM)


                     draft-bryskin-pce-pcpim-01.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

   This Internet-Draft will expire on September 5, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   The Policy-Enabled Path Computation Framework [PCE-POLICY] introduced
   the use of the Policy Core Information Model (PCIM), [RFC3060], as a
   framework for supporting path computation policy within the context
   of the Path Computation Element (PCE)-Based Architecture, [RFC4655].
   This document defines the Path Computation Policy Information Model
   (PCPIM), which provides the specifics of using PCIM as the method for
   supporting path computation policy.  PCPIM includes classes that
   model constraints, conditions, actions, variables and values
   associated with supporting path computation policy. While PCPIM was
   conceived to operate within the path computation element (PCE)-based



Bryskin & Berger        Expires September 5, 2007               [Page 1]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   architecture, it can be applied to any path computation methodology.



Contents

 1    Introduction  ................................................   3
 1.1  PC Policy Definition  ........................................   4
 1.2  Design Goals and Ramifications  ..............................   6
 1.3  Modeling of Abstract PC Policies  ............................  12
 1.4  Rule Hierarchy  ..............................................  14
 1.5  Extensibility of the path computation process via PCPIM  .....  15
 1.6  Requirements for PCC-PCE communication protocol  .............  16
 1.7  Intended Audiences  ..........................................  17
 2    Class Hierarchies  ...........................................  18
 2.1  Inheritance Hierarchy  .......................................  18
 2.2  Relationship Hierarchy  ......................................  24
 3    PC Policies  .................................................  25
 3.1  Modeling PC constraints  .....................................  25
 3.2  Modeling PC capabilities  ....................................  43
 3.3  Modeling PC policy relationships  ............................  55
 3.4  Modeling PC actions  .........................................  61
 3.5  Modeling PC variables  .......................................  66
 3.6  Modeling PC values  ..........................................  73
 4    PCPIM class definition  ......................................  74
 5    Security Considerations  .....................................  74
 6    IANA Considerations  .........................................  74
 7    References  ..................................................  74
 7.1  Normative References  ........................................  74
 7.2  Informative References  ......................................  75
 8    Authors' Addresses  ..........................................  76
 9    Full Copyright Statement  ....................................  76
10    Intellectual Property  .......................................  76



















Bryskin & Berger        Expires September 5, 2007               [Page 2]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


Conventions used in this document

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

   This document defines the Path Computation Policy Information Model,
   or PCPIM.  PCPIM identifies a framework and specific constructs for
   specifying and representing policies for the path computation process
   typically found with MPLS-TE and GMPLS LSPs, see [RFC3209] and
   [RFC3473].  PCPIM is intended to be consistent with the policy-
   enabled path computation framework defined in [PCE-POLICY].  PCPIM
   was conceived to operate within the path computation element
   (PCE)-based architecture, see [RFC4655], but can be applied to any
   path computation methodology.

   Consistent with [PCE-POLICY], PCPIM as defined in this document is
   based on the IETF Policy Core Information Model, see [RFC3060], and
   its extensions, see [RFC3460].  PCPIM builds upon these two documents
   to define an information model for the path computation governed by
   policy.  This document also adopts the terminology for policy-based
   management defined in [RFC3198].

   The policies that can be represented in PCPIM are referred to in this
   document as Path Computation (or PC) policies. The framework defined
   by PCPIM consists of a set of classes and relationships that are
   organized in an object-oriented information model. The definition is
   independent of any specific Policy Decision Point (PDP) or Policy
   Enforcement Point (PEP) implementation, see [RFC3198] for
   definitions.

   PCPIM is designed to represent PC policy information for policy
   domains, see [RFC3198].  The goal of this information model is to
   assist administrators in their definition of policies to control the
   path computation process typically associated with MPLS and GMPLS LSP
   establishment.  The process of creating PCPIM class instances is fed
   by business rules, network topology and PC methodology.  Examples of
   PC methodologies include centralized, distributed, remote PCE, and
   local PCE.

   It is important to note that PCPIM is independent of any particular
   data storage mechanism and access protocol.  This enables various
   data models (e.g., directory schemata, relational database schemata,
   and SNMP MIBs) to be designed and implemented according to a single
   uniform model.



Bryskin & Berger        Expires September 5, 2007               [Page 3]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


1.1. PC Policy Definition

   Figure 1 shows a notional process for the definition of PC policy for
   a policy domain. The figure illustrates information flow rather than
   an actual procedure.

       ----------        ----------       -----------
      | Business |      | Topology |     |   PC      |
      | Policy   |      |          |     |Methodology|
       ----------        ----------       -----------
           |                  |               |
           |                  |               |
           ------------------------------------
                              |
                              V
                       ---------------
                      |  PCPIM/PCIM(e)|
                      |   modeling    |
                       ---------------
                              |
          -------------       |            --------------
         | Service      |     |<----------| PCE info,    |
         | provisioning |---->|           | capabilities |
         | info         }     |            --------------
          -------------       V
                       (---------------)
                       ( PC action     )---)
                       ( (request/     )   )
                       (  response     )   )---)
                       (  processing   )   )   )
                       (---------------)   )   )
                            (--------------)   )
                                 (-------------)

             Figure 1: The PC definition information flow

   The process of defining PC policy is dependent on three types of
   information: the topology of network resources under management, the
   particular type of PC methodology used and the business rules and
   requirements for specifying service(s) delivered by the network. Both
   topology and business rules are outside of the scope of PCPIM.
   However, the important facets of both must be known and understood
   for the PC policy to be correctly specified.

   Typically the process of PC policy definition relies on one or more
   PC methodologies.  For example, the methodology of distributed path
   computation using remote PCE(s), per [RFC4655], may be considered in
   the PC policy definition process.



Bryskin & Berger        Expires September 5, 2007               [Page 4]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   Network topology consists of an inventory of network resources that
   make up a network. This inventory is usually automatically discovered
   and distributed via a Control Plane or a Management Plane, and made
   available to a network's path computation engines which perform the
   actual path computation.

   Business rules are informal sets of requirements for specifying the
   behavior of various services that may be provisioned on a network.
   Business rules directly or indirectly prescribe specific attributes
   for the services such as cost, availability, resilience to failures,
   end-to-end delay expectations and relative priority. This information
   is required by the overall policy management system that uses PCPIM
   rather than by PCPIM itself.  PCPIM is used to map business rules
   into semantics that control service related path computation, so that
   paths computed for a specific service can be successfully provisioned
   and will conform to a network's policy requirements and expectations.

   Information related to topology, PC methodology and business rules
   are necessary prerequisites for computing paths for services.  PCPIM
   enables a set of tools for specifying PC policy in a standard manner.
   Using a standard PC policy information model such as PCPIM is needed
   also because different network elements may have markedly different
   path computation capabilities and levels of visibility into the
   resources available within a network. Even the same type of equipment
   can have different functionality depending on operating system and
   software running in those devices. Therefore, a means is required to
   specify PC functionality in a standard way that is independent of the
   capabilities of different vendors' devices.  This is the role of
   PCPIM.

   In a typical scenario, the administrator will first determine the
   role(s) that each network element plays in the overall path
   computation process.  These roles define the path computation
   functions supplied by a given network element independent of vendor
   and element type. Examples of roles are: "Edge Path Computation
   Client", "Intra-Area Path Computation Element" and "Inter-AS Path
   Computation Element". For example, a network administrator may assign
   an edge IP router or GMPLS enabled OADM using remote path computation
   service a role of "Edge Path Computation Client". This enables the
   administrator to design policies that define how to constrain and/or
   optimize the path selection process for different types of services,
   how to select a PCE that can honor the specified constraints and
   objective functions, what to do if path computation fails (e.g. relax
   some of constraints, or send the request to another PCE) independent
   of the actual devices themselves.  PCPIM supports the concept of
   roles based on [RFC3060] and [RFC3460] definition of role.  PCPIM
   uses roles to help the administrator map a given set of network
   elements to a given set of PC policy constructs.



Bryskin & Berger        Expires September 5, 2007               [Page 5]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   Within PCPIM, PC policy constructs define the functionality required
   to perform desired path computation.  The functions themselves depend
   on the particular type of PC methodology chosen. For example, the
   outcome of applying policies on an edge IP router in case of the
   centralized path computation using a remote PCE is the contents of
   the path computation request sent to the PCE, while in case of the
   distributed path computation using local path computation engines the
   outcome is a particular call to the local engine.

   PCPIM class definitions are used to create instances of various
   policy constructs, such as PC constraints, in a form of policy rules
   that may be hierarchically organized in a higher level rules and
   groups.  Again, [RFC3060] and [RFC3460] serve as the foundation for
   these definitions, see [RFC3060] and [RFC3460] for definitions of
   PolicyGroup and PolicyRule classes.

   A hierarchical organization was chosen because it tends to reflect
   the way humans tend to think about complex policy. It is important to
   note that the described policy definition process is done
   independently of any specific device capabilities and configuration
   options. The policy definition is completely independent from details
   of implementation and configuration interface of individual network
   elements, as well as of the mechanisms that a network element may
   participate in the path selection process.


1.2. Design Goals and Ramifications

   This section explains PCPIM major design goals and how these goals
   are addressed.  This section also describes some of the ramifications
   of the design goals and the design decisions made in developing
   PCPIM.


1.2.1. Policy definition oriented

   The primary design goal of PCPIM is to model policies controlling the
   path selection process in a way that, as closely as possible,
   reflects the way humans tend to think about policy.  Therefore, PCPIM
   is designed to address the needs of policy definition and management,
   and not device or network configuration.

   There are several significant ramifications of this design goal.
   First, PCPIM uses rules to define policies based on [RFC3060] and
   [RFC3460]. Second, PCPIM uses hierarchical organizations of policies
   and policy information extensively.  Third, PCPIM does not force the
   policy writer to specify all implementation details; rather, it
   assumes that configuration agents, i.e. PEPs, interpret the policies



Bryskin & Berger        Expires September 5, 2007               [Page 6]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   and match them to suit the needs of device-specific configurations.


1.2.1.1. Rule-based modeling

   PCPIM describes PC policy using rule-based modeling as introduced in
   [RFC3060] and [RFC3460]. A PC policy rule is structured as a
   condition clause and an action clause. The semantics are simple: if
   the condition clause evaluates to TRUE then a set of actions, as
   specified in the action clause, can be executed.  For example, the
   rule:

      If bandwidth requirement is specified in the service provisioning
      message, then restrict the path selection to TE links advertising
      unreserved bandwidth to no less than the specified value.

   Could be formalized as:

      <If provBandwidth != 0 > then
          <require minimum BW = provBandwidth>"

   Where the first angle bracketed clause is a policy condition, and the
   second angle bracketed clause is a policy action.

   Note that the approach taken in PCPIM specifically does not define
   subclasses for the PolicyCondition class, and it uses subclasses of
   the PolicyAction class in a limited way.  Rather, PCPIM relies
   predominantly on use of the SimplePolicyCondition,
   CompoundPolicyCondition, SimplePolicyAction, and CompoundPolicyAction
   classes defined in [RFC3460]. This approach enables PCPIM to be
   easily extended. New path computation capabilities may be introduced
   without modifications of PCC - PCE communication, PCE discovery
   protocols or PDP/PEP/network element software (apart, of course, from
   the network elements (PCEs) actually implementing the new
   capabilities).


1.2.1.2. Hierarchical organization of information

   The organization of the information represented by PCPIM is designed
   to be hierarchical. PCPIM utilizes the PolicySetComponent aggregation
   class, see [RFC3460], to provide an arbitrarily nested organization
   of policy information.  A policy group provides a construct that
   represents policy rules and policy groups.  A policy rule can also
   contain other policy rules and groups, thus enabling a rule/sub-rule
   relationship.

   The hierarchical design approach is based on the observation that it



Bryskin & Berger        Expires September 5, 2007               [Page 7]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   is natural to organize policy rules in groups. Breaking down a
   complex policy into a set of simple rules is a process that follows
   the way many people tend to think and analyze systems.  The
   complexity of the abstract business-oriented policy is simplified and
   translated into a hierarchy of simple rules and grouping of simple
   rules.


1.2.1.3. Goal-oriented policy definition

   PCPIM facilitates goal-oriented PC policy definition.  This means
   that the process of defining PC policies is focused on the desired
   effect of policies, as opposed to the means of implementing the
   policy on network elements.

   PCPIM is intended to define a minimal specification of desired
   network behavior. It is the role of device-specific configuration
   agents, i.e., PEPs, to interpret policy expressed in a standard way
   and fill in the necessary configuration details. This helps ensure a
   common interpretation of the general policy as well as aid the
   administrator in specifying a common policy to be implemented by
   different devices.  This is analogous to the fundamental object-
   oriented paradigm of separating specification from implementation.

   With the help of PCPIM the path computation process can be specified
   in a general manner that can facilitate different implementations to
   satisfy a common goal. For example, a valid policy may include only a
   single rule that specifies that path selection must be limited to TE
   links with particular link protection capabilities. The rule does not
   need to include any of the various other details that may be needed
   for issuing a particular call to a local path computation engine or
   sending a request to a remote PCE.

   It is assumed that PEPs will fill in the device-specific details.
   The policy writer needs only to specify the main goal of the policy,
   making sure that the preferred path computation engine receives a
   properly constructed path computation request, so that the produced
   paths will be sufficiently detailed and include links best suiting
   the path(s) for the service in question.


1.2.2. Policy domain model

   An important design goal of PCPIM is to allow for policies that span
   numerous network elements.  This goal differentiates PCPIM from
   device-level information models which are designed for modeling
   policy that controls a single network element.




Bryskin & Berger        Expires September 5, 2007               [Page 8]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   This design goal has several ramifications. First, roles may be used
   to define policies across multiple network elements.  Second, the use
   of abstract policies frees the policy definition process from having
   to deal with individual network element peculiarities, and leaves
   interpretation and configuration to be modeled by PEPs. Third, the
   PCPIM allows extensive reuse of all policy building blocks in
   multiple rules and groups of rules used within different network
   elements.


1.2.2.1. Model PC policy in a device- and vendor-independent manner

   PCPIM models PC policy in a way designed to be independent of any
   particular device or vendor.  This enables to control the path
   computation process on networks made up of different network elements
   that (with respect to the path computation) have different
   capabilities using a single set of policies. This is important,
   because, otherwise, the policy will itself reflect and depend upon
   the differences between different implementations.


1.2.2.2. Use roles for mapping policy to network elements

   The use of roles enables a policy definition to be targeted to the
   network function of a network element, rather, than to the element's
   type and capabilities. The use of roles for mapping policy to network
   elements provides an efficient and simple method for compact and
   abstract policy definition.  A given abstract policy may be mapped to
   a group of network elements (for example, set of edge IP routers)
   without the need to specify configuration for each of these elements
   based on the capabilities of any one individual element.


1.2.2.3. Reuse

   Reusable objects as defined by [RFC3060] and [RFC3460] enable sharing
   policy building blocks, thus allowing central management of global
   concepts.  PCPIM provides the ability to reuse all policy building
   blocks: variables and values, conditions and actions, policy rules
   and policy groups.  This provides the required flexibility to manage
   large sets of policy rules over large policy domains.

   For example, the following rule makes use of centrally defined
   objects being reused (referenced):

      If <SourceAddress == DomainA>
          then <RecoveryPathDisjoitedness = SRLGDisjoint>




Bryskin & Berger        Expires September 5, 2007               [Page 9]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   In this rule the condition refers to an object named DomainA, which
   is a value (or possibly a set of values) defined and maintained in a
   reusable object container. The rule action makes use of a value named
   SRLGDisjoint, which is also a reusable object. The advantage of
   specifying a policy in this way is its inherent flexibility. For
   example, when business needs require a change in the domain
   definition for the organization, all that needed is to change the
   reusable value DomainA centrally. All referencing rules are
   immediately affected without the need to modify them individually.
   Without this capability the repository that is used to store the
   rules would have to be searched for all rules that refer to the
   domain DomainA, and then each matching rule's condition would have to
   be individually updated.  Such an approach would be much less
   efficient and would be more error prone.

   For a complete description of reusable objects, refer to [RFC3060]
   and [RFC3460].


1.2.3. Enforceable Policy

   Policy defined by PCPIM is assumed to be enforceable.  This means
   that a PDP and a PEP can use PCPIM's policy definition in order to
   make the necessary decisions and enforce the required policy rules.
   For example, a policy related to the selection of the remote PCE for
   a given path computation request could be made based entirely on the
   policy definitions specified by PCPIM.

   A PDP, associated with a given PCE or PCC, should be capable of
   extracting all policies written for each of the PCE's or PCC's roles
   and delivering them to the PCE's or PCC's PEP, which, it turn, should
   be able to map the policies into sets of PCE's or PCC's configuration
   commands, so that the desired behavior will be achieved.

   As previously mentioned, PCPIM is designed to be independent of any
   particular vendor-dependent technology. However, PCPIM's constructs
   should always be interpreted so that policy-compliant behavior can be
   enforced on the network under management.  Therefore, there are three
   fundamental requirements that PCPIM must satisfy:

   1. Policy specified by PCPIM must be able to be mapped to
      sets of configuration instructions specific to network
      elements where the policy is intended to be applied.

   2. Policy specified by PCPIM must be able to be enforced
      on the network elements, meaning that expected behavior of
      network elements must be achievable solely by applying the
      policy.



Bryskin & Berger        Expires September 5, 2007              [Page 10]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   3. Policy specified by PCPIM must be able to control path
      computation functions without making reference to a
      specific type of network element or vendor.

   PCPIM satisfies requirements (1) and (2) above by using the concept
   of roles. Specifically, through the PolicyRoles property defined in
   [RFC3060] and further refined in [RFC3460].  By matching roles
   assigned to policy groups and to network elements, a PDP can
   determine what policy should be applied to a given network element or
   group of network elements.

   The use of roles in mapping policy to network elements supports model
   scalability.  PCPIM policy can be mapped to large-scale policy
   domains by assigning a single role to a group of network elements.
   This can be done even when the policy domain contains heterogeneous
   devices.  So, a small set of policies can be deployed to large
   networks without having to re-specify the policy for each device
   separately.  This PCPIM property is important for PC policy
   management applications that strive to ease the task of policy
   definition for large policy domains.

   Requirement (2) is also satisfied by making PCPIM domain-oriented,
   see [RFC3198] for the definition of "domain".  In other words, the
   target of the policy is a domain as opposed to a specific network
   element.

   Requirement (3) is satisfied by modeling PC actions that are commonly
   configured on various PCCs and PCEs.  Additionally, PCPIM is
   extensible to allow for modeling of actions that are not included yet
   into the PCPIM.

   It is important to note that different PEPs will have different
   capabilities and functions. This necessitates different individual
   configurations, even if the different PEPs are controlled by the same
   policy.


1.2.4. PCPIM and path computation methodologies

   PCPIM is independent of the PC methodology used on the network. This
   means that on any given network element the same PC Policy actions
   can be translated into different sets of operations, depending on the
   PC methodology used in the network. For example, the PC Policy action
   "Request Path Computation", when applied on PCC using remote path
   computation service, will cause the PCC to send a request to a remote
   PCE (e.g. via the protocol defined in [PCEP]). On the other hand, the
   same PC Policy action applied on a IP router using a local path
   computation engine will cause the router to call the engine. Such



Bryskin & Berger        Expires September 5, 2007              [Page 11]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   independence is important, because it allows introduction of new
   methodologies without (re-)writing the policies governing a path
   computation.


1.3. Modeling of Abstract PC Policies

   As previously mentioned, the main goal of PCPIM is to create an
   information model that can be used to help bridge the conceptual gap
   between a human policy maker and a network element that is capable to
   enforce the policy. Clearly this wide gap implies several translation
   levels from the abstract to the concrete. At the abstract end are the
   business path computation considerations and rules. Once the business
   rules are known, a network administrator must interpret them as
   network PC policy and represent this PC policy using PCPIM
   constructs.  PCPIM facilitates a formal representation of PC rules,
   thus, providing the first concentration level.

   When a human business executive defines network policy, it is usually
   done using informal business terms and language.  For example, a
   human may define a policy of:

      Service A must be available 99.999% through its lifetime.

   In the context of path computation the statement above could be
   translated into the following policy:

      Service A must have an end-to-end backup path which is
      sufficiently disjoint from its primary path to guarantee that a
      single network failure will not make both paths simultaneously
      unusable for the service.

   While this statement clearly defines a PC policy at the business
   level, it isn't specific enough to be enforceable by a network
   element (i.e. for the service ingress GMPLS LSR responsible for the
   path computation for the service).

   On the other end of the scale, a network element functioning as a PEP
   (e.g. GMPLS LSR) can be configured with specific commands which
   determine a particular set of parameters (e.g. path computation
   constraints) that could control the path selection for the service in
   such a way that the goal expressed in the informal statement could be
   achieved. The element-specific configuration command on a PEP
   controlling a PCC could read:

      For service A, require that a remote PCE provide an end-to-end
      backup path and that the primary and backup path be link-disjoint.




Bryskin & Berger        Expires September 5, 2007              [Page 12]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   On a different network element on the same network the same policy
   may take different element specific form, in spite of the element
   playing the same role in the path computation process. This is may be
   due to the second network element being from a different vendor than
   the first, or that the second has a different set of functions (and
   hence implementation) even though it is from the same vendor.

   The "human" policy mentioned above is an example of an "abstract
   policy", while the "path computation" policy illustrates a "concrete
   configuration".  Furthermore, the first statement illustrates an end-
   to-end policy that covers all necessary path computations for the
   service which could include several requested by several PCCs and
   performed by several PCEs.  The second statement illustrates
   configuration for a particular PEP or a set thereof.

   The translation process from abstract business policy to concrete PEP
   configuration can be expressed as follows:

   1. Informal business PC policy is expressed by a human policy
      maker.

   2. A network administrator analyzes the policy domain's topology
      and determines the roles of particular network elements.  A
      role may be assigned to a large group of elements, which will
      result in mapping a particular policy to a large group of
      elements.

   3. The network administrator models the informal policy using the
      PCPIM constructs, thus creating a formal representation of the
      abstract policy. The administrator places these models in a
      Policy Repository that is accessible to PDPs in the network.

   4. The network administrator assigns roles to the policy groups
      created in the previous step, matching the network elements'
      roles assigned in step (2) above, and then places the roles
      in the Policy Repository.

   5. A PDP extracts the abstract policies from the Policy Repository
      and delivers them to PEPs associated with the elements that are
      assigned roles matching the policies and roles.

   6. The PEPs apply and enforce the polices by translating them into
      sets of network element-specific configuration instructions.

   PCPIM (with PCIM and PCIMe) are used in steps (3) and (4) above.






Bryskin & Berger        Expires September 5, 2007              [Page 13]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


1.4. Rule Hierarchy

   As with [RFC3060] and [RFC3460], PCPIM policy is described by a set
   of policy rules that may be grouped together. Policy rules and policy
   groups can be nested within other policy rules, providing a
   hierarchical policy definition. Nested rules are also called sub-
   rules, and we use both terms in this document interchangeably.  The
   aggregation PolicySetComponent class, as defined in [RFC3460], is
   used to represent the nesting of a policy rule or group in another
   policy rule or group.

   The hierarchical policy rule definition enhances policy readability
   and reuse. Within the PC policy information model, hierarchy is used
   to model context or scope for the sub-rule actions.

   Consider the following example, where the informal policy reads:

      In a WDM service, path computation requires a wavelength
      continuity constraint within each transparent segment of the
      service; for such path computation also constrain the OSNR to be
      no less than K at each point of optical signal regeneration and at
      the service end-points

   In this context, the wavelength continuity constraint means the
   requirement to select WDM links that have at least one lambda channel
   with the same wavelength available on all links selected for the path
   segment. The wavelength continuity constraint is necessary due to
   inability of transparent optical switches to perform the wavelength
   conversion.

   OSNR, or Optical Signal To Noise Ratio, is a characteristic that
   defines the optical signal quality. It has a lower bound, meaning
   that the characteristic needs to be no lower than a certain value at
   the points of the signal regeneration and at the service end-points
   for the signal to be usable.

   This policy could be modeled by PCPIM using the following rules:

   IF (Service Switching Type == LAMBDA && Service Data Type == LAMBDA)
      THEN (Set WavelengthContinuityConstraint = TRUE)
   IF (Service Switching Type == LAMBDA && Service Data Type == LAMBDA)
      THEN (Set MinimalOSNR = MINIMAL_OSNR)

   Assume that these two rules are grouped within a reusable group named
   SetOpticalConstraints. Than the policy above could be expressed as
   follows:

   IF (Service Switching Type == LAMBDA && Service Data Type == LAMBDA)



Bryskin & Berger        Expires September 5, 2007              [Page 14]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


       THEN (SetOpticalConstraints)

   This results in a more readable policy.  Additionally, and more
   importantly, policy nesting facilitates future modification of
   optical constraints (e.g.adding maximum allowable Polarization Mode
   Dispersion, PMD). In the case where a modification is needed, all
   that would need to be done is to modify the SetOpticalConstraints
   policy group, rather, than modifying all policies that use the group.


1.5. Extensibility of the path computation process via PCPIM

   Traditionally, a path computation entity was integrated with an LSR's
   control plane and always co-located with the LSR's signaling and
   routing subsystems. This architectural approach allowed for unlimited
   flexibility in providing various path computation enhancements.  For
   example, adding new types of constraints and their relaxation
   strategies, adopting new objective functions and optimization
   criteria.  With this approach, all that had to be done to support a
   PC related enhancement was to upgrade the control plane software of a
   particular LSR (and no other LSRs or any other network elements).

   This model doesn't hold for the PCE architecture, [RFC4655].  When
   the PCE architecture is used, the introduction of new PCE
   capabilities is more complicated and more than a single element's
   software must be modified to introduce new PC capabilites. In order
   to take advantage of a new PCE capability, new PCEP, advertising and
   signaling objects may be needed, all PCCs may need to be upgraded,
   and new interoperability problems may need to be resolved.

   Within the context of the PCE architecture it is therefore highly
   desirable to find a way to introduce new path computation
   capabilities without requiring modifications of either the
   discovery/communication protocols or PCC software. One way to achieve
   this objective is to model path selection constraints, their
   relaxations and objective functions as path computation request
   specific policies using PCPIM. Within PCPIM such policies may be
   modeled via policy rules with:

   - condition clauses made up entirely of a combination of instances
     of the SimplePolicyCondition class and/or instances of the
     CompoundPolicyCondition class, see [RFC3460], aggregating
     instances of the SimplePolicyCondition class.

   - action clauses made up entirely of a combination of instances
     of the SimplePolicyAction class and/or instances of the
     CompoundPolicyAction class, see [RFC3460], aggregating instances
     of the SimplePolicyAction class.



Bryskin & Berger        Expires September 5, 2007              [Page 15]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   Such an approach makes policy rule engines running on the PEPs
   insensitive to the semantics of the policies describing PC
   constraints and capabilities. Hence the only PC component that needs
   to understand such semantics is the PCE advertising the capabilities
   and actually using the constraints in the path selection. Under these
   circumstances PCCs can select a PCE that suits the best a given path
   computation request, as well as require necessary constraints without
   actually understanding what these capabilities or constraints mean.

   The SimplePolicyCondition, SimplePolicyAction,
   CompoundPolicyCondition and CompoundPolicyAction classes are defined
   [RFC3460]

   There are a number of advantages and useful by-products of such an
   approach:

   - New path computation capabilities may be introduced without
     changing PCC-PCE communication and discovery protocols or PCC
     software.

   - Existing constraints, objective functions and their relaxations
     may be aggregated and, otherwise, associated together, thus
     producing new more complex ones that do not require change of
     code even on PCEs supporting them.

   - Different elements such as conditions, actions and variables
     may be re-used by multiple constraints, diversities and
     optimizations.

   - PCCs and PCEs need to handle other (that is, not request
     specific) policies.  (For example, a policy instructing the PCE
     whether to accept or reject a path computation request issued by
     a PCC.) Path computation related policies of all types can be
     modeled by PCPIM, placed within the same policy
     repositories, can be managed by the same policy management tools
     and can be interpreted using the same mechanisms.


1.6. Requirements for PCC-PCE communication protocol

   When remote path computation service is used, peer PCC and PCE will
   communicate via some request-response communication protocol. The
   protocol is expected to provide the following minimal capabilities:

   For the PCC to signal in a path computation request:

   - One or more service source addresses.
   - One or more service destination addresses or point-to-multipoint



Bryskin & Berger        Expires September 5, 2007              [Page 16]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


     service IDs.
   - The number of paths/trees connecting set of sources to set of
     destinations to be computed.
   - Zero or more opaque objects carrying instances of PCPIM classes
     that model path computation policies (e.g. policy variables,
     values, constraints, objective functions, and their relaxations)
     pertinent to the request.

   For the PCE to signal in a path computation response:

   - Status/completion code of the path computation request.
   - One or more computed paths/trees.
   - Zero or more opaque objects carrying instances of PCPIM classes
     that model path computation policies pertinent to the response
     (e.g. constraints that needed to be relaxed and path/tree costs.)


   The communication protocol introduced in [PCEP] provides such
   capabilities.


1.7. Intended Audiences

   PCPIM is intended for several audiences.  The following lists some of
   the possible audiences and their respective uses:

   1. Developers of PC policy management applications can use this
      model as an extensible framework for defining policies to
      control PEPs and PDPs in an interoperable manner.

   2. Developers of PDPs and PEPs designed to control the path
      computation process.

   3. Builders of large organization data and knowledge bases who
      define ways to combine PC policy information with other
      networking policy information (for example, service recovery
      policy), assuming all modeling is based on sub-classes of
      [RFC3060] and [RFC3460].

   4. Authors of various standards may use constructs introduced in
      this document to enhance their work.  Authors of data models
      wishing to map a storage specific technology to PCPIM must
      use this document as well.








Bryskin & Berger        Expires September 5, 2007              [Page 17]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


2. Class Hierarchies

   PCPIM's class and association inheritance hierarchies are rooted in
   [RFC3060] and [RFC3460].  This section provides figures that
   represent these PCPIM inheritance hierarchies, while noting their
   relationships to [RFC3060] and[RFC3460] classes.  Note that many
   other classes used to form PCPIM policies (for example, the
   SimplePolicyCondition class) are defined in [RFC3060] and [RFC3460].
   Thus the figures in this section do not represent all necessary
   classes and relationships for defining PCPIM policies.  Rather, the
   designer using PCPIM should use appropriate classes and relationships
   from [RFC3060] and [RFC3460] in conjunction with those defined below.


2.1. Inheritance Hierarchy

   Figure 2 shows the PCPIM inheritance hierarchy.

   ManagedElement (abstract, PCIM)
      |
      +--Policy (abstract, PCIM)
      |  |
      |  +---PolicyAction (abstract, PCIM)
      |  |     |
      |  |     +---PcPolicyAction (abstract, PCPIM)
      |  |     |   |
      |  |     |   +--- PcPolicyActionRequestPathComputation (PCPIM)
      |  |     |   |
      |  |     |   +--- PcPolicyActionSendPathComputationResponse
      |  |     |   |                                             (PCPIM)
      |  |     |   |
      |  |     |   +--- PcPolicyActionProcessPathComputationResponse
      |  |     |                                                 (PCPIM)
      |  |     +--- PcPolicyActionEvaluatePCE (PCPIM)
      |  |
      |  +---PolicySet (abstract, PCIMe)
      |  |     |
      |  |     +---PolicyRule (abstract, PCIM/PCIMe)
      |  |     |   |
      |  |     |   +---PcPolicyPcReqRspComponent(PCPIM, abstract)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyBandwidthConstraint(PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyAffinityConstraint (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyLinkProtectionConstraint PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyLinkSwitchCapConstraint(PCPIM)



Bryskin & Berger        Expires September 5, 2007              [Page 18]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


      |  |     |   |   |
      |  |     |   |   +--- PcPolicyPathElement (PCPIM, abstract)
      |  |     |   |   |      |
      |  |     |   |   |      +--- PcPolicyExcludeLinkConstraint (PCPIM)
      |  |     |   |   |      |
      |  |     |   |   |      +--- PcPolicyExcludeNodeConstraint (PCPIM)
      |  |     |   |   |      |
      |  |     |   |   |      +--- PcPolicySharedLinkConstraint (PCPIM)
      |  |     |   |   |      |
      |  |     |   |   |      +--- PcPolicyIncludePathElement (PCPIM,
      |  |     |   |   |              |                        abstract)
      |  |     |   |   |              |
      |  |     |   |   |              +--- PcPolicyIncludeLinkConstraint
      |  |     |   |   |              |                        (PCPIM)
      |  |     |   |   |              |
      |  |     |   |   |              +--- PcPolicyIncludeNodeConstraint
      |  |     |   |   |                                       (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyStrictPathsConstraint (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicySecondaryPathRequest (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicySecondaryPathDisjoitedness (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyShortestPathObjectiveFunction
      |  |     |   |   |                                         (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyMinimalE2EDelayObjectiveFunction
      |  |     |   |   |                                         (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyShortestPathUpperBoundConstraint
      |  |     |   |   |                                         (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyE2EDelayUpperBoundConstraint (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyGMPLSWavelengthContinuityConstraint
      |  |     |   |   |                                         (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyGMPLSMaximalOSNRObjectiveFunction
      |  |     |   |   |                                         (PCPIM)
      |  |     |   |   +--- PcPolicyGMPLSMinimalDispersion
      |  |     |   |   |                 ObjectiveFunction       (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyGMPLSMinimalAttenuation
      |  |     |   |   |                 ObjectiveFunction       (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyGMPLSMinimalRegeneration
      |  |     |   |   |                 ObjectiveFunction       (PCPIM)



Bryskin & Berger        Expires September 5, 2007              [Page 19]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


      |  |     |   |   |
      |  |     |   |   +--- PcPolicyGMPLSOSNRLowerBoundConstraint
      |  |     |   |   |                                         (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyGMPLSDispersionUpperBoundConstraint
      |  |     |   |   |                                         (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyGMPLSAttenuationUpperBoundConstraint
      |  |     |   |   |                                         (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyGMPLSRegenerationUpperBound
      |  |     |   |   |                 Constraint              (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyGMPLSTransparentPathUpperBound
      |  |     |   |   |                 Constraint              (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyReturnPathCost (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyReturnPathE2EDelay (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- .... (to be extended)
      |  |     |   |
      |  |     |   +--- PcPolicyPcCapabilityComponent (PCPIM, abstract)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyPCELocation (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyPCEAdminPriority (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyTEVisibilityDomains (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyDestinationDomains (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyInterDomainCapability (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyRequestPrioritizationSupport (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyLinkBanwidthConstraintSupport
      |  |     |   |   |                                         (PCPIM)
      |  |     |   |   |
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyLinkAffinitiesConstraintSupport
      |  |     |   |   |                                         (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyLinkProtectionConstraintSupport
      |  |     |   |   |                                         (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyLinkSwitchCapConstraintSupport
      |  |     |   |   |                                         (PCPIM)



Bryskin & Berger        Expires September 5, 2007              [Page 20]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


      |  |     |   |   |
      |  |     |   |   +--- PcPolicyExclusionConstraintSupport   (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicySharedLinkConstraintSupport  (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyInclusionConstraintSupport   (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyConcurrentPathComputationCapability
      |  |     |   |   |                                         (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyShortestPathObjectiveSupport (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyCostUpperBoundConstraint
      |  |     |   |   |                Support                  (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyE2EDelayObjectiveSupport     (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyE2EDelayUpperBoundConstraintSupport
      |  |     |   |   |                                        (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--PcPolicyGMPLSWavelengthContinuity
      |  |     |   |   |                ConstraintSupport       (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyGMPLSOSNRObjectiveSupport    (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyGMPLSDispersionObjectiveSupport
      |  |     |   |   |                                        (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyGMPLSAttenuationObjectiveSupport
      |  |     |   |   |                                        (PCPIM)
      |  |     |   |   |
      |  |     |   |   +---PcPolicyGMPLSMinimalRegenerations
      |  |     |   |   |                ObjectiveFunction       (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- PcPolicyGMPLSOSNRLowerBound
      |  |     |   |   |                ConstraintSupport       (PCPIM)
      |  |     |   |   |
      |  |     |   |   +-- PcPolicyGMPLSDispersionUpperBound
      |  |     |   |   |                ConstraintSupport       (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--PcPolicyGMPLSAttenuationUpperBound
      |  |     |   |   |                ConstraintSupport       (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--PolicyGMPLSRegenerationsUpperBound
      |  |     |   |   |                ConstraintSupport       (PCPIM)
      |  |     |   |   |
      |  |     |   |   +-- PcPolicyGMPLSTransparentPathUpper
      |  |     |   |   |                BoundConstraintSupport  (PCPIM)



Bryskin & Berger        Expires September 5, 2007              [Page 21]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


      |  |     |   |   |
      |  |     |   |   +---PcPolicyGMPLSMinimalRegenerations
      |  |     |   |   |                ObjectiveFunction       (PCPIM)
      |  |     |   |   |
      |  |     |   |   +---PcPolicyGMPLSMinimalRegenerations
      |  |     |   |   |                ObjectiveFunction       (PCPIM)
      |  |     |   |   |
      |  |     |   |   +--- .... (to be extended)
      |  |     |
      |  |     +---PolicyGroup (abstract, PCIM/PCIMe)
      |  |     |   |
      |  |     |   +--- PcPolicyPcReqRspSet (PCPIM)
      |  |     |   |
      |  |     |   +--- PcPolicyPcCapabilitySet (PCPIM)
      |  |
      |  +---PolicyVariable (abstract, PCIMe)
      |  |   |
      |  |   +---PolicyImplicitVariable (abstract, PCIMe)
      |  |       |
      |  |       +--- PcPolicyServiceSourceIPv4Variable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyServiceSourceIPv6Variable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyServiceDestinationIPv4Variable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyServiceDestinationIPv6Variable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyServiceMcstGroupIDVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyServiceEncodingTypeVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyServiceSwitchingTypeVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyServiceGPIDVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyServiceBandwidthVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyServiceBandwidthDirectionalityVariable
      |  |       |                                               (PCPIM)
      |  |       +--- PcPolicyServiceBandwidthPriorityVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyServicePathRecoveryFlagsVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyServiceLinkProtectionFlagsVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyServiceSessionNameVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyServiceIncludeAnyVariable (PCPIM)



Bryskin & Berger        Expires September 5, 2007              [Page 22]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


      |  |       |
      |  |       +--- PcPolicyServiceExcludeAnyVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyServiceIncludeAllVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyServiceEROVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyServiceRROVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyServiceReferencePointIDVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyUserIDVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyServiceQOSVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyServiceCOSVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyServiceAvailabilityVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyLocalPCCIDVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyLocalPCEIDVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyPeerPCEIDVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyPeerPCEMetricVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyEvaluatedPCEIDVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyEvaluatedPCEMetricVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyPeerPCCIDVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyLocalPCDomainIDVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicySourcePCDomainIDVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyDestinationPCDomainIDVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyTransitPCDomainIDVariable (PCPIM)
      |  |       |
      |  |       +--- PcPolicyPcRequestResponseCodeVariable (PCPIM)
      |  |       |
      |  |       +---  .... (may be extended)
      |  |
      |  +---PolicyValue (abstract, PCIMe)
      |  |   |
      |  |   +--- PCPolicyFPValue (PCPIM)



Bryskin & Berger        Expires September 5, 2007              [Page 23]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


      |  |   |
      |  |   +--- PCPolicyUnnumLinkIDValue (PCPIM)
      |  |   |
      |  |   +--- PCPolicyROElementValue (PCPIM)
      |  |   |
      |  |   +--- PCPolicyROValue (PCPIM)
      |  |   |
      |  |   +---  .... (may be extended)

            Figure 2. PCPIM Class Inheritance Hierarchy


2.2. Relationship Hierarchy

   Figure 3 shows the PCPIM relationship hierarchy.

   [unrooted] (abstract, PCIM)
     |
     +---Dependency (abstract)
     |   |
     |   +--- PcPolicyPcReqRspComponentInPcReqRspSet (PCPIM)
     |   |
     |   +--- PcPolicyPcReqRspSetInPcReqRspSet (PCPIM)
     |   |
     |   +--- PcPolicyPcCapabilityComponentInPcCapabilitySet (PCPIM)
     |   |
     |   +--- PcPolicyPcCapabilitySetInPcCapabilitySet (PCPIM)
     |   |
     |   +--- PcPolicyPcReqRspComponentInPcSecondaryPathRequest
     |   |                                                    (PCPIM)
     |   |
     |   +--- PcPolicyPcReqRspSetInPcPolicyAction (PCPIM)
     |   |
     |   +--- PolicyImplicitVariableInPcPolicyAction (PCPIM)
     |   |
     |   +--- PcPolicyPcCapabilitySetInPcPolicyActionEvaluatePCE
     |   |                                                    (PCPIM)

         Figure 3. PCPIM Association Class Inheritance Hierarchy












Bryskin & Berger        Expires September 5, 2007              [Page 24]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


3. PC Policies

   This section describes PC policies that are modeled by PCPIM.  PC
   policies are policy related network behaviors that are specific to
   the path computation. Examples of PC policies are "Set path
   computation constraint" , "Evaluate a PCE for a path computation
   request", "Request path computation", "Send response to path
   computation request" and "Process path computation response". PC
   policies are modeled using the class hierarchies introduced in
   [RFC3060] and [RFC3460] as well as the PCPIM classes introduced in
   this document. PCPIM classes are sub-classes of [RFC3060]/[RFC3460]
   classes.



3.1. Modeling PC constraints

   A PC constraint is modeled based on the PcPolicyPcReqRspComponent
   abstract class introduced in this document.
































Bryskin & Berger        Expires September 5, 2007              [Page 25]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


         +-----------------------+    +-------------------------+
         | SimplePolicyCondition |    | CompoundPolicyCondition |
         |    class instances    |    |     class instances     |
         |       (PCIMe)         |    |         (PCIMe)         |
         +-----------------------+    +-------------------------+
                    * PolicyConditionInPolicyRule *
                    *       class instances       *
                    *           (PCIM)            *
                    *******************************
                                   *
                                   *
                    +--------------------------------+
                    |    PcPolicyPcReqRspComponent   |
                    |      sub-class instance        |
                    |           (PCPIM)              |
                    +--------------------------------+
                                   #
                                   #
                    ###############################
                    #  PolicyActionInPolicyRule   #
                    #       class instances       #
                    #           (PCIM)            #
         +-----------------------+    +-------------------------+
         |   SimplePolicyAction  |    |    CompoundPolicyAction |
         |    class instances    |    |      class instances    |
         |       (PCIMe)         |    |         (PCIMe)         |
         +-----------------------+    +-------------------------+

               Figure 4. Modeling PC Constraint

   The abstract class is derived from the PolicyRule class introduced in
   [RFC3060]. The rules of using the PolicyRule class, and its sub-
   classes, require that for each instance of PolicyRule class and sub-
   class:

   - There should be one or more instances of PolicyCondition
     classes or sub-classes associated with the PolicyRule class
     or sub-class instance in question via separate instances of
     the PolicyConditionInPolicyRule class or sub-class;

   and

   - there should be one or more instances of PolicyAction
     classes or sub-classes associated with the PolicyRule class
     or sub-class instance in question via separate instance of
     the PolicyActionInPolicyRule class or sub-class.

   The approach taken in PCPIM with respect to the use of sub-classes of



Bryskin & Berger        Expires September 5, 2007              [Page 26]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   the PcPolicyPcReqRspComponent class is to limit:

   - the conditions that can be associated with an instance of
     PcPolicyPcReqRspComponent sub-class to be instances of the
     SimplePolicyCondition class ([RFC3460]) and/or sets of instances
     of the SimplePolicyCondition class aggregated into instances of
     the CompoundPolicyCondition class ([RFC3460]) via instances of the
     PolicyConditionInPolicyCondition class ([RFC3460]) (see Figure 7.);

   and

   - the actions that can be associated with an instance of
     PcPolicyPcReqRspComponent sub-class to be instances of the
     SimplePolicyAction class ([RFC3460]) and/or sets of instances of
     the SimplePolicyAction class aggregated into instances of the
     CompoundPolicyAction class ([RFC3460]) via instances of the
     PolicyActionInPolicyAction class ([RFC3460]) (see Figure 7).

   The rationale for this decision is that the SimplePolicyCondition and
   SimplePolicyAction classes are fully defined within the policy realm.
   The classes are modeled as shown on Figure 5 and Figure 6
   respectively.

   +-----------------------+ PolicyValueInSimplePo- +----------------+
   |  SimplePolicyCondition| licyCondition class    | PolicyValue    |
   |      class instance   | instance(PCIMe)        | class instance |
   |         (PCIMe)       |xxxxxxxxxxxxxxxxxxxxxxxx|     (PCIMe)    |
   +-----------------------+                        +----------------+
                 v
                 v PolicyVariableInSimplePolicyCondition
                 v class instance (PCIMe)
                 v
   +-----------------------+ ExpectedPolicyValues-  +----------------+
   |    PolicyVariable     | ForPolicyVariable      | PolicyValue    |
   |    class instance     | class instances (PCIMe)| class instances|
   |       (PCIMe)         |========================|     (PCIMe)    |
   +-----------------------+                        +----------------+

                    Figure 5. Modeling Simple Policy Condition












Bryskin & Berger        Expires September 5, 2007              [Page 27]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   +-----------------------+ PolicyValueInSimplePo-+----------------+
   |    SimplePolicyAction | licyAction class      | PolicyValue    |
   |        class instance | instance(PCIMe)       | class instance |
   |           (PCIMe)     |xxxxxxxxxxxxxxxxxxxxxxx|     (PCIMe)    |
   +-----------------------+                       +----------------+
                 v
                 v PolicyVariableInSimplePolicyAction
                 v class instance (PCIMe)
                 v
   +-----------------------+ ExpectedPolicyValues-  +----------------+
   |    PolicyVariable     | ForPolicyVariable      | PolicyValue    |
   |    class instance     | class instances (PCIMe)| class instances|
   |       (PCIMe)         |========================|     (PCIMe)    |
   +-----------------------+                        +----------------+

                    Figure 6. Modeling Simple Policy Action

   As defined in [RFC3460], SimplePolicyCondition class can be expressed
   as:

      if(<PolicyVariable> MATCH <PolicyValue>)

   and SimplePolicyAction could be expressed as:

      SET <PolicyVariable> TO <PolicyValue>

   where <PolicyVariable> and <PolicyValue> are instances of
   PolicyVariable and PolicyValue classes and sub-classes associated
   with the instances of the SimplePolicyCondition and
   SimplePolicyAction classes. In the PCPIM context, the variables that
   could be associated with instances of the SimplePolicyCondition and
   SimplePolicyAction classes could be either instances of
   ImplicitPolicyVariable ([RFC3460]) sub-classes, as these are PC
   policy variable classes introduced and discussed later in this
   document (e.g. PcPolicyServiceBandwidthVariable), or instances of the
   ExplicitPolicyVariable ([RFC3460]) class bound to properties of PC
   Policy classes (e.g. mandatory property of the
   PcPolicyPcReqRspComponent class).













Bryskin & Berger        Expires September 5, 2007              [Page 28]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


                 +-----------------------+ +-------------------------+
                 | SimplePolicyCondition | |   SimplePolicyAction    |
                 |    class instances    | |     class instances     |
                 |        (PCIMe)        | |         (PCIMe)         |
                 +-----------------------+ +-------------------------+
                                    $          %
   PolicyConditionInPolicyCondition $          % PolicyActionInPolicy
                                    $          %               Action
        class instances             $          %      class instances
            (PCIMe)                 $          %          (PCIMe)
                                    $          %
                 +------------------------+ +-------------------------+
                 |CompoundPolicyCondition | |  CompoundPolicyAction   |
                 |    class instance      | |     class instance      |
                 |        (PCIMe)         | |         (PCIMe)         |
                 +------------------------+ +-------------------------+


              Figure 7.  Modeling Compound Policy Condition and Action

   It should be noted that all components of the SimplyPolicyCondition
   and SimplePolicyAction classes (e.g., variables, values, their
   associations and the definition of operators "MATCH" and "SET") are
   fully defined within the policy realm. This means that the rule
   engines running on PEPs do not need to understand semantics of the
   rules based on the SimplePolicyCondition and SimplePolicyAction
   classes. Indeed, applying such policies cause only comparing
   variables against values and setting variables to new values, rather,
   than performing actual (re-)configuration of network elements.
   Therefore, adding new constraint types is a fairly simple and
   "painless" operation. All what required is an introduction of new
   sub-classes of the PcPolicyPcReqRspComponent class, while the
   modification of the software running on the PEPs is not needed.


3.1.1. PcPolicyPcReqRspComponent class

   PcPolicyPcReqRspComponent is a class derived from the PolicyRule
   class introduced in [RFC3060]. PcPolicyPcReqRspComponent class is an
   abstract class, that is, it cannot be directly instantiated. All PC
   policy classes describing path computation constraints, objective
   functions, path disjointedness, SHOULD be derived from the
   PcPolicyPcReqRspComponent class. The class has two properties:
   mandatory and relaxation_round. The former is a Boolean identifying
   whether the constraint modeled by an instance of the
   PcPolicyPcReqRspComponent sub-class is mandatory (could not be
   relaxed) or optional (could be relaxed). The relaxation_round
   property is an integer from the range {1 ...M-1}, where M is a policy



Bryskin & Berger        Expires September 5, 2007              [Page 29]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   defined value specifying the maximum number of attempts a PCE should
   take on a given path computation request (with each attempt relaxing
   one or more constraints) before giving up and sending a negative
   response to the requesting PCC. This property specifies the priority
   of the constraint relaxation. For example, if the property equals to
   1, the constraint will be relaxed after initial path computation
   (with full set of constraints) fails, that is, before the second
   computation attempt; if the property equals to 2, the constraint will
   be relaxed after a failure of the path computation with all optional
   constraints that have the relaxation_round property 1 relaxed, and so
   forth.

   Provided that conditions of the policy modeled by a
   PcPolicyPcReqRspComponent sub-class evaluate to TRUE, there MUST be
   one or more actions associated with the policy that set either the
   mandatory or relaxation_priority properties to TRUE/non-zero value.
   Otherwise, (mandatory is FALSE and relaxation_priority is 0) the
   constraint is considered as NOT specified and will not be accounted
   in the path computation.

   Multiple instances of PcPolicyPcReqRspComponent sub-classes could be
   aggregated into a constraint set - an instance of the container class
   PcPolicyPcReqRspSet - using the
   PcPolicyPcReqRspComponentInPcReqRspSet aggregation class. Instances
   of PcPolicyPcReqRspSet classes could be nested within each other.
   Zero, one or more instances of the PcPolicyPcReqRspSet class could be
   associated with a single path computation request or response modeled
   by the PcPolicyActionRequestPathComputation and
   PcPolicyActionSendPathComputationResponse respectively.

   Note that a path computation constraint set (an instance of the
   PcPolicyPcReqRspSet class) may contain several instances of the same
   PcPolicyPcReqRspComponent sub-class. For example, the set may contain
   two instances of the PcPolicyBandwidthConstraint class (described in
   the following section): the first, mandatory, specifying 10Mb of
   bandwidth, and the second, optional, specifying 12Mb of bandwidth. It
   is assumed that when several constraints of the same type are
   specified in the request, the PCE will use the most stringent one
   (12Mb, in our example). If the path computation fails, optional
   constraints will be relaxed, and the computation will be attempted
   again. Thus, the policy that could be expressed as "Try, first, to
   compute a 12Mb path, if the computation fails, then compute a 10Mb
   path" could be easily achieved.








Bryskin & Berger        Expires September 5, 2007              [Page 30]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


3.1.2. PcPolicyBandwidthConstraint class

   PcPolicyBandwidthConstraint is a class derived from the
   PcPolicyPcReqRspComponent. It specifies the link bandwidth
   availability constraint. The class has the following properties:

     bandwidth - an integer specifying minimum bandwidth in Kb to be
                 available on a TE link in order for the link to be
                 considered as a valid candidate for a resulting path

     priority -  an integer from the range {0...7} specifying the
                 lowest priority at which the bandwidth must be
                 available

     directionality - an integer specifying the direction in which
                      the bandwidth must be available; the valid
                      values are:
                  1 - the bandwidth must be available only in forward
                      (from the source to the destination) direction
                  2 - the bandwidth must be available only in reverse
                      (from the destination to the source) direction
                  3 - the bandwidth must be available in both directions

   A policy of setting the bandwidth constraint may (but does not have
   to) be associated with instances of PcPolicyServiceBandwidthVariable,
   PcPolicyServiceBandwidthDirectionalityVariable and
   PcPolicyServiceBandwidthPriorityVariable classes (bandwidth
   parameters provisioned for the service for which the path computation
   is requested). For example, the policy could be expressed as follows:

     if(PcPolicyServiceBandwidthVariable !=0)
       then banwidthConstraint. bandwidth =
                 PcPolicyServiceBandwidthVariable;
            bandwidthConstraint.directionality =
                 PcPolicyServiceBandwidthDirectionalityVariable;
            bandwidthConstraint.priority =
                 PcPolicyServiceBandwidthPriorityVariable;


3.1.3. PcPolicyAffinityConstraint class

   PcPolicyAffinityConstraint is a class derived from the
   PcPolicyPcReqRspComponent. It specifies types (advertised as colors)
   of TE links the path selection must be constrained to.

   The class has the following properties:

    includeAny - a bit field specifying a subset of colors. A given



Bryskin & Berger        Expires September 5, 2007              [Page 31]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


                 TE link may be considered in the path selection only
                 if it advertises at least one of these colors

    excludeAny - a bit field specifying a subset of colors. A given
                 TE link must be excluded from the path selection if
                 it advertises at least one of these colors

    includeAll - a bit field specifying a subset of colors. A given
                 TE link may be considered in the path selection only
                 if it advertises all of these colors

   A policy of setting the affinity constraint may (but does not have
   to) be associated with instances of
   PcPolicyServiceIncludeAnyVariable, PcPolicyServiceExcludeAnyVariable
   and PcPolicyServiceIncludeAllVariable classes (affinities provisioned
   for the service for which the path computation is requested) in a
   similar way as described in 3.1.1


3.1.4. PcPolicyLinkProtectionConstraint class

   PcPolicyLinkProtectionConstraint is a class derived from the
   PcPolicyPcReqRspComponent. It specifies minimal link protection
   capabilities for a TE link to be considered in the path selection.

   The class has a single property:

     linkProtection - an integer specifying the link capability code
                      according to [RFC4202].

   A given TE link may be considered in the path selection only if it
   advertises the link protection capability numerically greater or
   equal to the value of this property

   A policy of setting the link protection capability constraint may
   (but does not have to) be associated with an instance of the
   PcPolicyServiceLinkProtectionFlagsVariable class (link protection
   capability provisioned for the service for which the path computation
   is requested) in a similar way as described in 3.1.1


3.1.5. PcPolicyLinkSwitchCapConstraint class

   PcPolicyLinkSwitchCapConstraint is a class derived from the
   PcPolicyPcReqRspComponent. It specifies the network layer of the
   requested path(s). Specifically, it constraints the path selection to
   TE links with particular switching capabilities, that is, TE links,
   advertising data switching and encoding capabilities matching the



Bryskin & Berger        Expires September 5, 2007              [Page 32]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   values specified in the properties (see below) of the
   PcPolicyLinkSwitchCapConstraint class instance.

   The class has the following properties:

     switchType - an integer specifying the link switching type
                  according to [RFC3471]

     encodeType - an integer specifying the link data encoding type
                  according to [RFC3471]

   A policy of setting the link switching capability constraint may (but
   does not have to) be associated with instance of the
   PcPolicyServiceSwitchingTypeVariable and
   PcPolicyServiceEncodingTypeVariable classes (link switching
   capabilities provisioned for the service for which the path
   computation is requested) in a similar way as described in 3.1.1


3.1.6. PcPolicyPathElement class

   PcPolicyPathElement is class derived from the
   PolicyPcReqRspComponent.  PcPolicyPathElement is an abstract class to
   be used as a base class for the classes, describing explicit path
   constraints such as exclusions and inclusions (see the following
   sections).

   The PcPolicyPathElement class has a single property:

     teNodeID - network unique number identifying the node associated
                with the path element (for example, a TE link to be
                included or excluded)


3.1.7. PcPolicyExcludeLinkConstraint and PcPolicyExcludeNodeConstraint
   classes

   PcPolicyExcludeLinkConstraint and PcPolicyExcludeNodeConstraint are
   classes derived from the PcPolicyPathElement class. Instances of
   these classes specify TE links and nodes respectively that must be
   explicitly excluded from the path computation.

   The PcPolicyExcludeLinkConstraint class has a single property:

     teLinkID - network unique number identifying a numbered link or
                node unique number identifying (along with the
                teNodeID property of the PcPolicyPathElement class)
                an unnumbered link



Bryskin & Berger        Expires September 5, 2007              [Page 33]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   The PcPolicyExcludeNodeConstraint class has no properties

   Several instances of PcPolicyExcludeLinkConstraint and/or
   PcPolicyExcludeNodeConstraint classes associated with a path
   computation request specify an unordered set of TE links/nodes that
   are explicitly prohibited to appear in the resulting path(s).


3.1.8. PcPolicySharedLinkConstraint class

   PcPolicySharedLinkConstraint is a class derived from the
   PcPolicyPathElement class. Instances of this class specify TE links
   which resources could be shared between two or more service paths
   and, therefore, may be considered in the path computation even if
   they do not have sufficient resources (bandwidth) available

   The PcPolicySharedLinkConstraint class has a single property:

     teLinkID - network unique number identifying a numbered link or
                node unique number identifying (along with the
                teNodeID property of the PcPolicyPathElement) an
                unnumbered link


3.1.9. PcPolicyIncludePathElement class

   PcPolicyIncludePathElement is class derived from the
   PcPolicyPathElement class. PcPolicyIncludePathElement is an abstract
   class to be used as a base class for the classes describing inclusion
   constraints

   The PcPolicyIncludePathElement class has the following properties:

     order  -  an integer number specifying the order of appearing of
               this path element in the path (the smaller number, the
               closer the path element to the path head)

     loose  -  a Boolean specifying whether this path element is loose
               (TRUE) or strict (FALSE). Path element is considered to
               be loose with respect to the path element that appears
               immediately before in the path, if it is permissible to
               insert one or more other path elements between the two
               path elements








Bryskin & Berger        Expires September 5, 2007              [Page 34]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


3.1.10. PcPolicyIncludeLinkConstraint and PcPolicyIncludeNodeConstraint
   classes

   PcPolicyIncludeLinkConstraint and PcPolicyIncludeNodeConstraint are
   classes derived from the PcPolicyIncludePathElement class. Instances
   of these classes specify TE links and nodes respectively that must
   appear in the resulting path(s) in the specified order.

   The PcPolicyExcludeLinkConstraint class has a single property:

     teLinkID  - network unique number identifying a numbered link
                 or node unique number identifying (along with the
                 teNodeID property of the PcPolicyPathElement class)
                 an unnumbered link

   The PcPolicyExcludeNodeConstraint class does not have any properties.

   Several instances of PcPolicyIncludeLinkConstraint and/or
   PcPolicyIncludeNodeConstraint classes associated with a path
   computation request specify an ordered set of TE links/nodes that
   must appear in the resulting path(s).


3.1.11. PcPolicyStrictPathsConstraint class

   PcPolicyStrictPathsConstraint is a class derived from the
   PolicyPcReqRspComponent class. An instance of the
   PcPolicyStrictPathsConstraint class requires the resulting path(s) to
   be explicit, that is, to contain only strict path elements.

   The PcPolicyStrictPathsConstraint class does not have any properties


3.1.12. PcPolicySecondaryPathRequest class

   PcPolicySecondaryPathRequest is a class derived from the
   PolicyPcReqRspComponent class. An instance of the
   PcPolicySecondaryPathRequest class requests computation of a
   secondary path (backup path or path to a point-to-multipoint service
   leaf) to be performed concurrently with the primary and other
   secondary paths.

   The PcPolicySecondaryPathRequest class has the following properties:

     pathSource - an IPv4 or IPv6 value specifying the source of the
                  secondary path; if specified as 0, it MUST be
                  assumed that the source of the secondary path is
                  the same as of the primary path



Bryskin & Berger        Expires September 5, 2007              [Page 35]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


     pathDestination - an IPv4 or IPv6 value specifying the
                  destination of the secondary path; if specified as
                  0, it MUST be assumed that the destination of the
                  secondary path is the same as of the primary path

   PCPIM allows direct associations of an instance of the
   PcPolicySecondaryPathRequest class with one or more instances of any
   of PolicyPcReqRspComponent sub-classes via instances of the
   PcPolicyPcReqRspComponentInPcSecondaryPathRequest association class.
   This is useful for requesting an individual set of constraints for
   the secondary path distinct from one for the primary path and other
   secondary paths. If such associations are not provided between some
   of the constraints, specified for the primary path, and a given
   instance of the PcPolicySecondaryPathRequest class, it MUST be
   interpreted as a requirement for the secondary path computation to
   use the same such constraints as for the primary path computation.
   For example, suppose that an instance of the
   PcPolicySecondaryPathRequest class is associated only with several
   instances of the PcPolicyIncludeLinkConstraint classes (in order to
   specify, say, a preferred path between a branch and a leaf of a
   point- to-multipoint tunnel). Although, the bandwidth constraint in
   this case is not explicitly specified for this secondary path, the
   path will be computed with the bandwidth constraint specified for the
   primary path/tree.


3.1.13. PcPolicySecondaryPathDisjoitedness class

   PcPolicySecondaryPathDisjoitedness is a class derived from the
   PolicyPcReqRspComponent class. An instance of the
   PcPolicySecondaryPathDisjoitedness class describes how a secondary
   path should be disjoint from (or converged with) the primary and
   other secondary paths.

   In section 3.1.12 it was mentioned that an instance of any
   PolicyPcReqRspComponent sub-class can be associated with an instance
   of the PcPolicySecondaryPathRequest class.  If such association is
   specified for an instance of the PcPolicySecondaryPathDisjoitedness
   class, the disjointedness parameters provided by the instance apply
   only for the secondary path in question (but not for any other
   secondary paths).  Otherwise, (that is, the association is not
   specified), the disjointedness parameters apply for all secondary
   paths in the request (specified via instances of the
   PcPolicySecondaryPathRequest class aggregated into the same instance
   of the PcPolicyPcReqRspSet class).

   The PcPolicySecondaryPathDisjoitedness class has the following
   properties:



Bryskin & Berger        Expires September 5, 2007              [Page 36]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


    disjointedness - an integer specifying the path disjointedness
                 code that could take one of the following values:
            1    - link-disjoint (no links in common);
            2    - node-disjoint (no nodes in common);
            3    - SRLG-disjoint (no Shared Risk Link
                                  Groups in common);
            4    - best- disjoint (best available
                   disjointedness with applying penalties
                   for sharing links, nodes and SRLGs)
            5    - converged (as many links in common as
                   possible, useful for point-to-
                   multipoint path/tree computations)

    linkSharingCostPenalty - an integer specifying by how much the
                 cost of the secondary path must be increased for
                 every link shared with the primary or other secondary
                 paths; this property is only meaningful
                 when the disjointedness property set to 4

    nodeSharingCostPenalty - an integer specifying by how much the
                 cost of the secondary path must be increased for
                 every node shared with the primary or other secondary
                 paths; this property is only meaningful
                 when the disjointedness property set to 4

    SRLGSharingCostPenalty - an integer specifying by how much
                 cost of the secondary path must be increased for
                 every SRLG shared with the primary or other secondary
                 paths; this property is only meaningful
                 when the disjointedness property set to 4


3.1.14. PcPolicyShortestPathObjectiveFunction class

   PcPolicyShortestPathObjectiveFunction is a class derived from the
   PolicyPcReqRspComponent class. An instance of the
   PcPolicyShortestPathObjectiveFunction class instructs the path
   computation engine to optimize the path selection according to the
   shortest path criteria.

   The PcPolicyShortestPathObjectiveFunction class has a single
   property:

    optimization - a Boolean specifying whether the path selection
                   should be optimized according to minimal summary
                   TE metric (TRUE) or minimal number of hops (FALSE)
                   criteria




Bryskin & Berger        Expires September 5, 2007              [Page 37]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


3.1.15. PcPolicyMinimalE2EDelayObjectiveFunction class

   PcPolicyMinimalE2EDelayObjectiveFunction is a class derived from the
   PolicyPcReqRspComponent class. An instance of the
   PcPolicyMinimalE2EDelayObjectiveFunction class instructs the path
   computation engine to optimize the path selection according to the
   minimal end-to-end delay criteria.

   The PcPolicyMinimalE2EDelayObjectiveFunction class does not have
   properties.


3.1.16. PcPolicyShortestPathUpperBoundConstraint class

   PcPolicyShortestPathUpperBoundConstraint is a class derived from the
   PolicyPcReqRspComponent class. An instance of the
   PcPolicyShortestPathUpperBoundConstraint class sets upper bound on
   the cost of the resulting paths in terms of either summary TE metric
   or number of hops or both.

   The PcPolicyShortestPathUpperBoundConstraint class has the following
   properties:

     maxMetric    - an integer specifying maximally acceptable summary
                    path TE metric
     maxHopNumber - an integer specifying maximally acceptable number
                    of hops in the path(s)


3.1.17. PcPolicyE2EDelayUpperBoundConstraint class

   PcPolicyE2EDelayUpperBoundConstraint is a class derived from the
   PolicyPcReqRspComponent class. An instance of the
   PcPolicyE2EDelayUpperBoundConstraint class sets upper bound on the
   end- to-end delay characteristic of each of the resulting paths.

   The PcPolicyE2EDelayUpperBoundConstraint class has a single property:

     maxE2Edelay - an integer specifying maximally acceptable value
                   of the path end-to-end delay characteristic


3.1.18. PcPolicyGMPLSWavelengthContinuityConstraint class

   PcPolicyGMPLSWavelengthContinuityConstraint is a class derived from
   the PolicyPcReqRspComponent class. This class is meaningful in the
   context of transparent optical network path computation. An instance
   of the PcPolicyGMPLSWavelengthContinuityConstraint class constrains



Bryskin & Berger        Expires September 5, 2007              [Page 38]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   the path computation engine to consider only WDM links for the
   resulting path(s) that have at least one lambda channel with the same
   wavelength available on all links selected for any given transparent
   path segment (that is, path segment between optical signal (OS)
   regeneration points). The wavelength continuity constraint is
   necessary due to inability of transparent optical switches to perform
   the wavelength conversion.

   The PcPolicyGMPLSWavelengthContinuityConstraint class does not have
   properties.


3.1.19. PcPolicyGMPLSMaximalOSNRObjectiveFunction class

   PcPolicyGMPLSMaximalOSNRObjectiveFunction is a class derived from the
   PolicyPcReqRspComponent class. This class is meaningful in the
   context of transparent optical network path computation. An instance
   of the PcPolicyGMPLSMaximalOSNRObjectiveFunction class instructs the
   path computation engine to optimize the path selection according to
   the maximal Optical Signal to Noise Ratio (OSNR) criteria at points
   of OS regeneration and path destination(s).

   The PcPolicyGMPLSMaximalOSNRObjectiveFunction class does not have
   properties.


3.1.20. PcPolicyGMPLSMinimalDispersionObjectiveFunction class

   PcPolicyGMPLSMinimalDispersionObjectiveFunction is a class derived
   from the PolicyPcReqRspComponent class. This class is meaningful in
   the context of transparent optical network path computation. An
   instance of the PcPolicyGMPLSMinimalDispersionObjectiveFunction class
   instructs the path computation engine to optimize the path selection
   according to the minimal OS dispersion criteria at points of OS
   regeneration and path destination(s).

   The PcPolicyGMPLSMinimalDispersionObjectiveFunction class does not
   have properties.


3.1.21. PcPolicyGMPLSMinimalAttenuationObjectiveFunction class

   PcPolicyGMPLSMinimalAttenuationObjectiveFunction is a class derived
   from the PolicyPcReqRspComponent class. This class is meaningful in
   the context of transparent optical network path computation. An
   instance of the PcPolicyGMPLSMinimalAttenuationObjectiveFunction
   class instructs the path computation engine to optimize the path
   selection according to the minimal OS attenuation criteria at points



Bryskin & Berger        Expires September 5, 2007              [Page 39]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   of OS regeneration and path destination(s).

   The PcPolicyGMPLSMinimalAttenuationObjectiveFunction class does not
   have properties.


3.1.22. PcPolicyGMPLSMinimalRegenerationObjectiveFunction class

   PcPolicyGMPLSMinimalRegenerationObjectiveFunction is a class derived
   from the PolicyPcReqRspComponent class. This class is meaningful in
   the context of transparent optical network path computation. An
   instance of the PcPolicyGMPLSMinimalRegenerationObjectiveFunction
   class instructs the path computation engine to optimize the path
   selection according to the minimal number of OS regenerations
   criteria.

   The PcPolicyGMPLSMinimalRegenerationObjectiveFunction class does not
   have properties.


3.1.23. PcPolicyGMPLSOSNRLowerBoundConstraint class

   PcPolicyGMPLSOSNRLowerBoundConstraint is a class derived from the
   PolicyPcReqRspComponent class. This class is meaningful in the
   context of transparent optical network path computation. An instance
   of the PcPolicyGMPLSOSNRLowerBoundConstraint class sets a lower bound
   on the OSNR characteristic at the resulting path(s) destination(s)
   and points of OS regeneration.

   The PcPolicyGMPLSOSNRLowerBoundConstraint class has a single
   property:

     minOSNR - an integer specifying minimally acceptable value of
               OSNR characteristic


3.1.24. PcPolicyGMPLSDispersionUpperBoundConstraint class

   PcPolicyGMPLSDispersionUpperBoundConstraint is a class derived from
   the PolicyPcReqRspComponent class. This class is meaningful in the
   context of transparent optical network path computation. An instance
   of the PcPolicyGMPLSDispersionUpperBoundConstraint class sets upper
   bound on the OS dispersion characteristic at the resulting path(s)
   destination(s) and points of OS regeneration.

   The PcPolicyGMPLSDispersionUpperBoundConstraint class has a single
   property:




Bryskin & Berger        Expires September 5, 2007              [Page 40]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


     maxDispersion - an integer specifying maximally acceptable value
                     of OS dispersion characteristic


3.1.25. PcPolicyGMPLSAttenuationUpperBoundConstraint class

   PcPolicyGMPLSAttenuationUpperBoundConstraint is a class derived from
   the PolicyPcReqRspComponent class. This class is meaningful in the
   context of transparent optical network path computation. An instance
   of the PcPolicyGMPLSAttenuationUpperBoundConstraint class sets upper
   bound on the  OS attenuation characteristic at the resulting path(s)
   destination(s) and points of OS regeneration.

   The PcPolicyGMPLSAttenuationUpperBoundConstraint class has a single
   property:

     maxAttenuation - an integer specifying maximally acceptable value
                      of OS attenuation characteristic


3.1.26. PcPolicyGMPLSRegenerationUpperBoundConstraint class

   PcPolicyGMPLSRegenerationUpperBoundConstraint is a class derived from
   the PolicyPcReqRspComponent class. This class is meaningful in the
   context of transparent optical network path computation. An instance
   of the PcPolicyGMPLSRegenerationUpperBoundConstraint class sets upper
   bound on the number of OS regenerations along each of the resulting
   path(s).

   The PcPolicyGMPLSRegenerationUpperBoundConstraint class has a single
   property:

     maxRenerations - an integer specifying maximally acceptable number
                      of OS regenerations


3.1.27. PcPolicyGMPLSTransparentPathUpperBoundConstraint class

   PcPolicyGMPLSTransparentPathUpperBoundConstraint is a class derived
   from the PolicyPcReqRspComponent class. This class is meaningful in
   the context of transparent optical network path computation. An
   instance of the PcPolicyGMPLSTransparentPathUpperBoundConstraint
   class sets an upper bound on the length of a transparent path segment
   (path segment between two points of OS regeneration) of each of the
   resulting path(s).

   The PcPolicyGMPLSTransparentPathUpperBoundConstraint class has a
   single property:



Bryskin & Berger        Expires September 5, 2007              [Page 41]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


     maxLenTranspSegment - an integer specifying maximally acceptable
                           length of a transparent path segment


3.1.28. PcPolicyReturnPathCost class

   PcPolicyReturnPathCost is a class derived from the
   PolicyPcReqRspComponent class. An instance of the
   PcPolicyReturnPathCost class requests information on a computed path
   actual cost in terms of summary TE link metric and hop number. An
   instance of the PcPolicyReturnPathCost class could be associated with
   an instance of the PcPolicySecondaryPathRequest class via an instance
   of the PcPolicyPcReqRspComponentInPcSecondaryPathRequest class. Such
   association instructs the peer PCE which (of possibly several) paths
   the actual cost must be returned for. If the association is not
   specified the cost characteristics will be returned for the computed
   primary path.

   The PcPolicyReturnPathCost class has the following properties:

     pathMetric - an integer specifying computed path summary TE metric
     hopNumber  - an integer specifying computed path hop number


3.1.29. PcPolicyReturnPathE2EDelay class

   PcPolicyReturnPathE2EDelay is a class derived from the
   PolicyPcReqRspComponent class. An instance of the
   PcPolicyReturnPathE2EDelay class requests information on a computed
   path actual end-to-end delay characteristic. An instance of the
   PcPolicyReturnPathE2EDelay class could be associated with an instance
   of the PcPolicySecondaryPathRequest class via an instance of the
   PcPolicyPcReqRspComponentInPcSecondaryPathRequest class. Such
   association instructs the peer PCE which (of possibly several) paths
   the actual end-to-end delay characteristic must be returned for. If
   the association is not specified, the characteristic will be returned
   for the computed primary path.

   The PcPolicyReturnPathE2EDelay class has a single property:

     pathE2Edelay - an integer specifying computed path end-to-end
                    delay characteristic









Bryskin & Berger        Expires September 5, 2007              [Page 42]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


3.2. Modeling PC capabilities

   There could be several PCEs serving on the network at the same time
   because:

   - the PCEs may have different PC capabilities and, therefore, be
     suited for different types of the path computation.

   - the PCEs may have different visibility into the network
     resources and hence compute paths within and across different
     path computation domains.

   - the PCEs may have different security restraints on accessing
     their services.

   - two or more PCEs with identical capabilities and TE visibility
     may be deployed for the purpose of path computation load
     balancing.

   Furthermore, one should keep in mind that PCCs may have access to
   local path computation engine(s) capable of certain types of the path
   computation, but not of others, for which they may request a remote
   PCE service. Therefore, a PCC must be capable to decide for a given
   path computation on whether local or remote PCE should be used, and,
   in the latter case, select the PCE that suits best the path
   computation in question.

   In 3.1 we discussed a PC constraint as a policy that influences the
   outcome of the path selection process. It was noted that PCPIM makes
   it possible for a PCC, while not understanding what a given PC
   constraint means, to request it anyway simply because the policy
   tells the PCC to do so. This is achieved via modeling PC constraints
   as policy rules (based on the [RFC3060] PolicyRule sub-classes) and
   associating them with conditions and actions based on the
   SimplePolicyCondition and SimplePolicyAction sub-classes
   respectively. Such an approach allows for requesting the constraints
   via applying some logic defined/governed by policy on a limited set
   of variables which values are defined outside of the policy realm
   (e.g. information provided by signaling or provisioning messages or
   SLAs) without actually understanding the semantics of the
   constraints. However, in a multi-PCE environment requesting PC
   constraints would be of a little use, if the PC request with the
   constraints is sent to a PCE that does not recognize or support the
   constraints.

   In this section we will discuss a PC capability as a policy that
   could be used by a PCC while selecting a PCE for a given path
   computation request. As in case of the PC constraints, it is



Bryskin & Berger        Expires September 5, 2007              [Page 43]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   important for PCPIM (in order to be open for future path computation
   process enhancements) to make it possible for a PCC to use/apply PC
   capabilities without understanding their semantics.

   Suppose an IP router is about to setup a tunnel going through an
   optical domain. In order for such tunnel to be successfully set up
   and operational, it is important to request the wavelength continuity
   constraint (discussed in 3.1). However, neither of software
   components on the router needs to understand what does the constraint
   mean. Nor it needs to understand what does the capability to support
   the constraint mean. The goal is to have the PCC, associated with the
   router, request the constraint and send the request to a PCE capable
   to support the constraint, solely because the PC policy instructs the
   PCC to do so (one reason for such instruction could be the fact that
   the tunnel is provisioned with the transparent optical switching
   capability requirements).

   In PCPIM a PC capability is modeled based on the
   PcPolicyPcCapabilityComponent class (see the next sub-section).
































Bryskin & Berger        Expires September 5, 2007              [Page 44]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


       +-----------------------+    +-------------------------+
       | SimplePolicyCondition |    | CompoundPolicyCondition |
       |    class instances    |    |     class instances     |
       |       (PCIMe)         |    |         (PCIMe)         |
       +-----------------------+    +-------------------------+
                  * PolicyConditionInPolicyRule *
                  *       class instances       *
                  *           (PCIM)            *
                  *******************************
                                 *
                                 *
                  +--------------------------------+
                  |  PcPolicyPcCapabilityComponent |
                  |      sub-class instance        |
                  |           (PCPIM)              |
                  +--------------------------------+
                                 #
                                 #
                  ###############################
                  #  PolicyActionInPolicyRule   #
                  #       class instances       #
                  #           (PCIM)            #
       +-----------------------+    +-------------------------+
       |   SimplePolicyAction  |    |    CompoundPolicyAction |
       |    class instances    |    |      class instances    |
       |       (PCIMe)         |    |         (PCIMe)         |
       +-----------------------+    +-------------------------+

                  Figure 8.  Modeling PC Capability

   The approach taken in PCPIM with respect to the use of sub-classes of
   the PcPolicyPcCapabilityComponent class is similar to one taken for
   the use of PcPolicyPcReqRspComponent sub-classes (described at the
   top of 3.1).

   Specifically, it was decided to limit:

   - the conditions that could be associated with an instance of a
     PcPolicyPcCapabilityComponent sub-class to be instances of the
     SimplePolicyCondition class([RFC3460]) and/or sets of instances of
     the SimplePolicyCondition class aggregated into instances of the
     CompoundPolicyCondition class ([RFC3460]) via instances of the
     PolicyConditionInPolicyCondition class ([RFC3460]) (see Figure 7);

   - the actions that could be associated with an instance of a
     PcPolicyPcCapabilityComponent sub-class to be instances of the
     SimplePolicyAction class ([RFC3460]) and/or sets of instances of
     the SimplePolicyAction class aggregated into instances of the



Bryskin & Berger        Expires September 5, 2007              [Page 45]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


     CompoundPolicyAction class ([RFC3460]) via instances of the
     PolicyActionInPolicyAction class ([RFC3460]) (see Figure 7).

   It should be noted that in the majority of cases PC capabilities
   introduced in 3.2 match PC constraints introduced in 3.1. Therefore,
   instances of matching PC constraint and capability classes may use
   (that is, may be associated with) the same conditions (the same
   instances of the SimplePolicyCondition sub-classes). For example, the
   same conditions that cause a PCC PEP to ask for the end-to-end delay
   optimization in a particular path computation request may "encourage"
   the PCC PEP to select for the path computation a PCE that actually
   supports this path computation objective.


3.2.1. PcPolicyPcCapabilityComponent class

   PcPolicyPcCapabilityComponent is a class derived from the PolicyRule
   class introduced in [RFC3060]. PcPolicyPcCapabilityComponent class is
   an abstract class, that is, it cannot be directly instantiated. All
   PC policy classes describing path computation capabilities SHOULD be
   derived from the PcPolicyPcCapabilityComponent class. The class has
   two properties:  domains and pceMetric.

   The domains property is a set of IPv4 or IPv6 values, each of which
   uniquely identifying one path computation domain in the network. A
   given PCE may perform differently when processing requests from
   and/or computing paths across different path computation domains
   Therefore, the domains property of the  PcPolicyPcCapabilityComponent
   class is necessary to specify for which of the domains the
   information provided by the properties of a given instance of the
   PcPolicyPcCapabilityComponent sub- class is valid.

   The pceMetric property is a small integer expressing a PCC's
   preference to use the PCE that claims this PC capability (modeled by
   this instance of a PcPolicyPcCapabilityComponent sub-class) for a
   particular path computation request. The pceMetric property has a
   special role in the PCE evaluation process. This is the only writable
   property of the PcPolicyPcCapabilityComponent class and any of its
   sub-classes. In other words, this is the only property whose value
   could be overwritten as a result of associated policy action(s). It
   is important to note that in contrast with PcPolicyPcReqRspComponent
   sub-classes (describing PC constraints, see 3.1), which properties
   are set via associated policy actions, all properties of
   PcPolicyPcCapabilityComponent sub-classes are pre-set (normally, by
   Policy Management Tool), and, as far as a PCC PEP is concerned, are
   read-only: they could be used as condition variables, but not as
   action variables. The only exception is the pceMetric property, which
   value is re-set during the PCE evaluation process. The process could



Bryskin & Berger        Expires September 5, 2007              [Page 46]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   be described as follows. It starts after a PC request is built.
   During the process policies, modeling PC capabilities (instances of
   PcPolicyPcCapabilityComponent sub-classes) associated with a given
   PCE are applied. If conditions of a such policy are evaluated to
   TRUE, its actions are expected to set the pceMetric policy property
   to some positive integer, thus, making the PCE "more attractive" for
   the path computation request.

   For example, an instance of the PcPolicyE2EDelayObjectiveSupport
   class, modeling the PC capability to support minimal end-to-end delay
   objective function, may be associated with one condition and one
   action in a way that could be expressed as follows:

     if(E2EDelayOptimizationIsRequested)
        then e2eDelayOptimizationSupport.pceMetric =
                                                 E2E_DELAY_OPT_METRIC;

   where

   E2EDelayOptimizationIsRequested is a policy (Boolean) variable which
   is set to TRUE if the minimal end-to-end delay optimization is
   specified in the path computation request, for which a PCE is being
   evaluated.  E2E_DELAY_OPT_METRIC is a policy value expressing the
   attractiveness of a PCE claiming to support such optimization.

   After all PC capability policies associated with a given PCE are
   applied, a PC policy action "Evaluate PCE For PC Request" (an
   instance of the PcPolicyActionEvaluatePCE class) is expected to be
   executed. The action enables the selection of PCE that suits the best
   for a given path computation request (see more details in 3.4.5).

   Multiple instances of PcPolicyPcCapabilityComponent sub-classes could
   be aggregated into a capability set - an instance of the container
   class PcPolicyPcCapabilitySet - using the aggregation class
   PcPolicyPcCapabilityComponentInPcCapabilitySet. Instances of the
   PcPolicyPcCapabilitySet class could be nested within each other. One
   or more instances of the PcPolicyPcCapabilitySet class could be
   associated with a given instance of the PcPolicyActionEvaluatePCE
   class.


3.2.2. PcPolicyPCELocation class

   PcPolicyPCELocation is a class derived from the
   PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyPCELocation class specifies the IP address which the PCE
   could be reached at.




Bryskin & Berger        Expires September 5, 2007              [Page 47]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   The class has a single property:

     pceAddress  - IPv4 or IPv6 value specifying an IP address
                   associated with the PCE.


3.2.3. PcPolicyPCEAdminPriority class

   PcPolicyPCEAdminPriority is a class derived from the
   PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyPCEAdminPriority class specifies the network operator
   preference for the associated PCE to be used for path computations.
   The ability to express the PCE administrative priority is necessary
   to balance path computation load.

   The class has a single property:

     pcePriority  - an integer expressing the PCE's administratively
                    assigned priority


3.2.4. PcPolicyTEVisibilityDomains class

   PcPolicyTEVisibilityDomains is a class derived from the
   PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyTEVisibilityDomains class specifies a set of path computation
   domains for which the associated PCE has an access to the information
   about inventory and availability of network resources, and hence
   across which it can compute explicit TE paths. This information is
   useful in the PCE selection process, when it is known a prior which
   domains the resulting path(s) will cross.

   The class has a single property:

     teDomains  - a set of IPv4 or IPv6 addresses, each address from
                  the set identifies one path computation domain that
                  is TE visible to the PCE


3.2.5. PcPolicyDestinationDomains class

   PcPolicyDestinationDomains is a class derived from the
   PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyDestinationDomains class specifies a set of path computation
   domains towards which the associated PCE can compute (perhaps, non-
   explicit) TE paths, even when the PCE does not have full TE
   visibility into these domains. This information is useful in the PCE
   selection process, when it is known a prior which domains the



Bryskin & Berger        Expires September 5, 2007              [Page 48]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   requested path destination(s) might be located.

   The class has a single property:

     destDomains  - a set of IPv4 or IPv6 addresses, each address from
                    the set identifies one path computation domain in
                    direction towards which the PCE can compute paths


3.2.6. PcPolicyInterDomainCapability class

   PcPolicyInterdomainCapability is a class derived from the
   PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyPCELocation class specifies the scope(s) of the paths that
   could be computed by the associated PCE.

   The class has the following properties:

     fIntraArea - a Boolean indicating whether the PCE is capable
                  (TRUE) to compute paths that do not cross IGP area
                  boundaries

     fInterArea - a Boolean indicating whether the PCE is capable
                  (TRUE) to compute paths that may cross IGP area
                  boundaries, but not AS boundaries

     fInterAS   - a Boolean indicating whether the PCE is capable
                  (TRUE) to compute paths that may cross inter-AS
                  boundaries

     fInterLayer - a Boolean indicating whether the PCE is capable
                  (TRUE) to compute paths that span multiple (more
                  than two) network layers


3.2.7. PcPolicyRequestPrioritizationSupport class

   PcPolicyRequestPrioritizationSupport is a class derived from the
   PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyRequestPrioritizationSupport class indicates that the
   associated PCE honors the path computation request prioritization.

   The class does not have any properties.








Bryskin & Berger        Expires September 5, 2007              [Page 49]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


3.2.8. PcPolicyLinkBanwidthConstraintSupport class

   PcPolicyLinkBanwidthConstraintSupport is a class derived from the
   PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyLinkBanwidthConstraintSupport class indicates that the
   associated PCE supports the link available bandwidth constraint (see
   3.1.2).

   The class does not have any properties.


3.2.9. PcPolicyLinkAffinitiesConstraintSupport class

   PcPolicyLinkAffinitiesConstraintSupport is a class derived from the
   PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyLinkAffinitiesConstraintSupport class indicates that the
   associated PCE supports the link affinity constraint (see 3.1.3).

   The class does not have any properties.


3.2.10. PcPolicyLinkProtectionConstraintSupport class

   PcPolicyLinkProtectionConstraintSupport is a class derived from the
   PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyLinkProtectionConstraintSupport class indicates that the
   associated PCE supports the link protection capability constraint
   (see 3.1.4).

   The class does not have any properties.


3.2.11. PcPolicyLinkSwitchCapConstraintSupport class

   PcPolicyLinkSwitchCapConstraintSupport is a class derived from the
   PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyLinkSwitchCapConstraintSupport class indicates that the
   associated PCE supports the link switching capability constraint (see
   3.1.5).

   The class does not have any properties.










Bryskin & Berger        Expires September 5, 2007              [Page 50]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


3.2.12. PcPolicyExclusionConstraintSupport class

   PcPolicyExclusionConstraintSupport is a class derived from the
   PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyExclusionConstraintSupport class indicates that the
   associated PCE supports the exclusion constraints (see 3.1.7).

   The class does not have any properties.


3.2.13. PcPolicySharedLinkConstraintSupport class

   PcPolicySharedLinkConstraintSupport is a class derived from the
   PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicySharedLinkConstraintSupport class indicates that the
   associated PCE supports the shared link constraint (see 3.1.8).

   The class does not have any properties.


3.2.14. PcPolicyInclusionConstraintSupport class

   PcPolicyInclusionConstraintSupport is a class derived from the
   PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyInclusionConstraintSupport class indicates that the
   associated PCE supports the inclusion constraints (see 3.1.10).

   The class does not have any properties.


3.2.15. PcPolicyConcurrentPathComputationCapability class

   PcPolicyConcurrentPathComputationCapability is a class derived from
   the PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyConcurrentPathComputationCapability class indicates that the
   associated PCE is capable of concurrent computation of several (more
   than one) paths between the specified sets of sources and
   destinations.

   The class has the following properties:

     maxPathNumber - an integer specifying the maximal number of paths
                     that could be computed concurrently
     fLinkDisjoint - a Boolean indicating whether the PCE is capable
                     (TRUE) to compute link-disjoint paths (see
                     discussions on path disjointedness in 3.1.13)
     fNodeDisjoint - a Boolean indicating whether the PCE is capable
                     (TRUE) to compute node-disjoint paths



Bryskin & Berger        Expires September 5, 2007              [Page 51]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


     fSRLGDisjoint - a Boolean indicating whether the PCE is capable
                     (TRUE) to compute SRLG-disjoint paths
     fBestDisjoint - a Boolean indicating whether the PCE is capable
                     (TRUE) to compute best-disjoint paths
     fConverged    - a Boolean indicating whether the PCE is capable
                     (TRUE) to compute paths that share maximum TE links


3.2.16. PcPolicyShortestPathObjectiveSupport class

   PcPolicyShortestPathObjectiveSupport is a class derived from the
   PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyShortestPathObjectiveSupport class indicates that the
   associated PCE supports path selection optimization according to the
   shortest path criteria (see 3.1.14).

   The class does not have any properties.


3.2.17. PcPolicyCostUpperBoundConstraintSupport class

   PcPolicyCostUpperBoundConstraintSupport is a class derived from the
   PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyCostUpperBoundConstraintSupport class indicates that the
   associated PCE supports the upper bound path cost constraint (see
   3.1.16).

   The class does not have any properties.


3.2.18. PcPolicyE2EDelayObjectiveSupport class

   PcPolicyE2EDelayObjectiveSupport is a class derived from the
   PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyE2EDelayObjectiveSupport class indicates that the associated
   PCE supports path selection optimization according to the minimal
   end- to-end delay criteria (see 3.1.15).

   The class does not have any properties.


3.2.19. PcPolicyE2EDelayUpperBoundConstraintSupport class

   PcPolicyE2EDelayUpperBoundConstraintSupport is a class derived from
   the PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyE2EDelayUpperBoundConstraintSupport class indicates that the
   associated PCE supports the upper bound end-to-end delay constraint
   (see 3.1.17).



Bryskin & Berger        Expires September 5, 2007              [Page 52]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   The class does not have any properties.


3.2.20. PcPolicyGMPLSWavelengthContinuityConstraintSupport class

   PcPolicyGMPLSWavelengthContinuityConstraintSupport is a class derived
   from the PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyGMPLSWavelengthContinuityConstraintSupport class indicates
   that the associated PCE supports the OS wavelength continuity
   constraint (see 3.1.18).

   The class does not have any properties.


3.2.21. PcPolicyGMPLSOSNRObjectiveSupport class

   PcPolicyGMPLSOSNRObjectiveSupport is a class derived from the
   PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyGMPLSOSNRObjectiveSupport class indicates that the associated
   PCE supports path selection optimization according to the maximal
   OSNR criteria (see 3.1.19).

   The class does not have any properties.


3.2.22. PcPolicyGMPLSDispersionObjectiveSupport class

   PcPolicyGMPLSDispersionObjectiveSupport is a class derived from the
   PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyGMPLSDispersionObjectiveSupport class indicates that the
   associated PCE supports path selection optimization according to the
   minimal OS dispersion criteria (see 3.1.20).

   The class does not have any properties.


3.2.23. PcPolicyGMPLSAttenuationObjectiveSupport class

   PcPolicyGMPLSAttenuationObjectiveSupport is a class derived from the
   PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyGMPLSAttenuationObjectiveSupport class indicates that the
   associated PCE supports path selection optimization according to the
   minimal OS attenuation criteria (see 3.1.21).

   The class does not have any properties.






Bryskin & Berger        Expires September 5, 2007              [Page 53]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


3.2.24. PcPolicyGMPLSMinimalRegenerationsObjectiveFunction class

   PcPolicyGMPLSMinimalRegenerationsObjectiveFunction is a class derived
   from the PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyGMPLSMinimalRegenerationsObjectiveFunction class indicates
   that the associated PCE supports path selection optimization
   according to the minimal number of OS regenerations criteria (see
   3.1.22).

   The class does not have any properties.


3.2.25. PcPolicyGMPLSOSNRLowerBoundConstraintSupport class

   PcPolicyGMPLSOSNRLowerBoundConstraintSupport is a class derived from
   the PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyGMPLSOSNRLowerBoundConstraintSupport class indicates that the
   associated PCE supports the OSNR lower bound constraint (see 3.1.23).

   The class does not have any properties.


3.2.26. PcPolicyGMPLSDispersionUpperBoundConstraintSupport class

   PcPolicyGMPLSDispersionUpperBoundConstraintSupport is a class derived
   from the PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyGMPLSDispersionUpperBoundConstraintSupport class indicates
   that the associated PCE supports the OS dispersion upper bound
   constraint (see 3.1.24).

   The class does not have any properties.


3.2.27. PcPolicyGMPLSAttenuationUpperBoundConstraintSupport class

   PcPolicyGMPLSAttenuationUpperBoundConstraintSupport is a class
   derived from the PcPolicyPcCapabilityComponent class. An instance of
   the PcPolicyGMPLSAttenuationUpperBoundConstraintSupport class
   indicates that the associated PCE supports the OS attenuation upper
   bound constraint (see 3.1.25).

   The class does not have any properties.









Bryskin & Berger        Expires September 5, 2007              [Page 54]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


3.2.28. PcPolicyGMPLSRegenerationsUpperBoundConstraintSupport class

   PcPolicyGMPLSRegenerationsUpperBoundConstraintSupport is a class
   derived from the PcPolicyPcCapabilityComponent class. An instance of
   the PcPolicyGMPLSRegenerationsUpperBoundConstraintSupport class
   indicates that the associated PCE supports the number of OS
   regenerations upper bound constraint (see 3.1.26).

   The class does not have any properties.


3.2.29. PcPolicyGMPLSTransparentPathUpperBoundConstraintSupport class

   PcPolicyGMPLSTransparentPathUpperBoundConstraintSupport is a class
   derived from the PcPolicyPcCapabilityComponent class. An instance of
   the PcPolicyGMPLSTransparentPathUpperBoundConstraintSupport class
   indicates that the associated PCE supports the maximal length
   transparent segment constraint (see 3.1.27).

   The class does not have any properties.


3.2.30. PcPolicyP2MPComutationSupport class

   PcPolicyP2MPComutationSupport is a class derived from the
   PcPolicyPcCapabilityComponent class. An instance of the
   PcPolicyP2MPComutationSupport class indicates that the associated PCE
   can perform point-to-multipoint tree computations.

   The class does not have any properties.



3.3. Modeling PC policy relationships

   PC policies of the same type need to be aggregated together, and,
   then, associated with PC actions (for discussions on PC actions see
   3.4).  For example, in order for PC constraints to be considered in a
   given path computation, they should be aggregated into one or more
   constraint sets which, in turn, should be associated with the PC
   action "Request Path Computation".  In the PCPIM PC policy
   aggregations and associations are modeled via container and
   association classes described in this section.








Bryskin & Berger        Expires September 5, 2007              [Page 55]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


3.3.1. PcPolicyPcReqRspSet class

   PcPolicyPcReqRspSet is a class derived from the PolicyGroup class
   (introduced in [RFC3060]). This is a container class. It allows for
   aggregating of one or more instances of PcPolicyPcReqRspComponent
   sub- classes (modeling PC constraints) into a single set, using
   instances of the PcPolicyPcReqRspComponentInPcReqRspSet class.

   The sets may be unlimitedly nested within each other via instances of
   the PcPolicyPcReqRspSetInPcReqRspSet classes. The
   PcPolicyPcReqRspComponentInPcReqRspSet and
   PcPolicyPcReqRspSetInPcReqRspSet association classes are discussed
   later in this section.

   The PcPolicyPcReqRspSet does not have properties.


3.3.2. PcPolicyPcCapabilitySet class

   PcPolicyPcCapabilitySet is a class derived from the PolicyGroup class
   (introduced in [RFC3060]). This is a container class. It allows for
   aggregating of one or more instances of PcPolicyPcCapabilityComponent
   sub-classes (modeling PC capabilities) into a single set via
   instances of the PcPolicyPcCapabilityComponentInPcCapabilitySet
   class.  The sets may be unlimitedly nested within each other via
   instances of the  PcPolicyPcCapabilitySetInPcCapabilitySet classes.
   The PcPolicyPcCapabilityComponentInPcCapabilitySet and
   PcPolicyPcCapabilitySetInPcCapabilitySet are discussed later in this
   section.

   The PcPolicyPcCapabilitySet does not have properties.


3.3.3. PcPolicyPcReqRspComponentInPcReqRspSet class

   PcPolicyPcReqRspComponentInPcReqRspSet is a class derived from the
   PolicyComponentSet class (introduced in [RFC3460]). This is an
   association class. It is used for aggregating an instance of a
   PcPolicyPcReqRspComponent sub-class into an instance of the
   PcPolicyPcReqRspSet class.

   The PcPolicyPcReqRspComponentInPcReqRspSet has the following
   properties:

     GroupComponent [ref PcPolicyPcReqRspSet[0..n]]- a pointer to the
                  instance of the containing (PcPolicyPcReqRspSet)
                  class; the cardinality [0..n] means that zero, one or
                  more instances of the PcPolicyPcReqRspSet class could



Bryskin & Berger        Expires September 5, 2007              [Page 56]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


                  be associated with (that is, contain within itself)
                  the same instance of the PcPolicyPcReqRspComponent
                  sub-class by this association

     PartComponent [ref PcPolicyPcReqRspComponent[1..n]]- a pointer to
                  the instance of the contained
                  (PcPolicyPcReqRspComponent sub-) class; the
                  cardinality [1..n] means that one or more instances
                  of PcPolicyPcReqRspComponent sub-classes could be
                  associated with (that is, contained in) the same
                  instance of the PcPolicyPcReqRspSet class by this
                  association


3.3.4. PcPolicyPcReqRspSetInPcReqRspSet class

   PcPolicyPcReqRspSetInPcReqRspSet is a class derived from the
   PolicyComponentSet class (introduced in [RFC3460]). This is an
   association class. It is used for nesting an instance of the
   PcPolicyPcReqRspSet class into another instance of the
   PcPolicyPcReqRspSet class.

   The PcPolicyPcReqRspSetInPcReqRspSet has the following properties:

     GroupComponent [ref PcPolicyPcReqRspSet[0..n]]- a pointer to the
                 nesting instance of the PcPolicyPcReqRspSet class; the
                 cardinality [0..n] means that zero, one or more
                 instances of the PcPolicyPcReqRspSet class could nest
                 the same instance of this class by this association

     PartComponent [ref PcPolicyPcReqRspSet [0..n]]- a pointer to the
                 nested instance of the PcPolicyPcReqRspSet class; the
                 cardinality [0..n] means that zero, one or more
                 instances of the PcPolicyPcReqRspSet class could be
                 nested within the same instance of this class by this
                 association


3.3.5. PcPolicyPcCapabilityComponentInPcCapabilitySet class

   PcPolicyPcCapabilityComponentInPcCapabilitySet is a class derived
   from the PolicyComponentSet class (introduced in [RFC3460]). This is
   an association class. It is used for aggregating an instance of a
   PcPolicyPcCapabilityComponent sub-class into an instance of the
   PcPolicyPcCapabilitySet class.

   The PcPolicyPcCapabilityComponentInPcCapabilitySet has the following
   properties:



Bryskin & Berger        Expires September 5, 2007              [Page 57]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   GroupComponent [ref PcPolicyPcCapabilitySet[1..n]]- a pointer to
         the instance of the containing (PcPolicyPcCapabilitySet)
         class; the cardinality [1..n] means that one or more
         instances of the PcPolicyPcCapabilitySet class could be
         associated with (that is, contain within itself) the same
         instance of the PcPolicyPcCapabilityComponent sub-class by
         this association

   PartComponent [ref PcPolicyPcCapabilityComponent[1..n]]- a pointer
         to the instance of the contained (PcPolicyPcCapabilityComponent
         sub-) class; the cardinality [1..n] means that one or more
         instances of PcPolicyPcCapabilityComponent sub-class could
         be associated with (that is, contained in) the same instance
         of the PcPolicyPcCapabilitySet class by this association


3.3.6. PcPolicyPcCapabilitySetInPcCapabilitySet class

   PcPolicyPcCapabilitySetInPcCapabilitySet is a class derived from the
   PolicyComponentSet class (introduced in [RFC3460]). This is an
   association class. It is used for nesting an instance of the
   PcPolicyPcCapabilitySet class into another instance of the same
   class.

   The PcPolicyPcCapabilitySetInPcCapabilitySet has the following
   properties:

   GroupComponent [ref PcPolicyPcCapabilitySet[0..n]]- a pointer to the
             nesting instance of the PcPolicyPcCapabilitySet class;
             the cardinality [0..n] means that zero, one or more
             instances of the PcPolicyPcCapabilitySet class could nest
             the same instance of this class by this association

   PartComponent [ref PcPolicyPcCapabilitySet [0..n]]- a pointer to the
             nested instance of the PcPolicyPcCapabilitySet class;
             the cardinality [0..n] means that zero, one or more
             instances of the PcPolicyPcCapabilitySet class could be
             nested within the same instance of this class by this
             association


3.3.7. PcPolicyPcReqRspComponentInPcSecondaryPathRequest class

   It was mentioned in 3.1.12 that PCPIM allows for requesting a
   distinct set of PC constraints for each of secondary paths that is
   computed concurrently with the primary and zero or more other
   secondary paths.  Such a complex structure of the path computation
   request is modeled by associating an instance of the



Bryskin & Berger        Expires September 5, 2007              [Page 58]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   PcPolicyPcSecondaryPathRequest class with zero or more instances of
   any of PcPolicyPcReqRspComponent sub-class via separate instances of
   the PcPolicyPcReqRspComponentInPcSecondaryPathRequest class. The
   class is derived from the Dependency class (introduced in [RFC3060]).

   The PcPolicyPcReqRspComponentInPcSecondaryPathRequest has the
   following properties:

   Antecendent [ref PcPolicySecondaryPathRequest [0..n]]- a pointer to
           an instance of the PcPolicySecondaryPathRequest class; the
           cardinality [0..n] means that zero, one or more instances
           of the PcPolicySecondaryPathRequest class could be associated
           with (share) a given instance of a PcPolicyPcReqRspComponent
           sub-class by this association

   Dependent [ref PcPolicyPcReqRspComponent [0..n]]- a pointer to an
           instance of a PcPolicyPcReqRspComponent sub-class; the
           cardinality [0..n] means that zero, one or more instances of
           PcPolicyPcReqRspComponent sub-classes could be associated
           with the same instance of the PcPolicySecondaryPathRequest
           class by this association


3.3.8. PcPolicyPcReqRspSetInPcPolicyAction and
   PolicyImplicitVariableInPcPolicyAction classes

   PC policy actions (such as "Request Path Computation" modeled by the
   PcPolicyActionRequestPathComputation class (see 3.4) need to have an
   access to the properties of the PC constraints and/or PC policy
   variables related to the request.

   The access to the PC constraints is modeled by associating an
   instance of a PcPolicyAction sub-class with one or more instances of
   the PcPolicyPcReqRspSet class via separate instances of the
   PcPolicyPcReqRspSetInPcPolicyAction class.

   The access to the PC policy variables is modeled by associating an
   instance of a PcPolicyAction sub-class with one or more instances of
   PolicyImplicitVariable ([RFC3460]) sub-class(es) via separate
   instances of the PolicyImplicitVariableInPcPolicyAction class.

   The PcPolicyPcReqRspSetInPcPolicyAction class is derived from the
   Dependency class (introduced in [RFC3060]).

   The class has the following properties:

   Antecendent [ref PcPolicyAction [0..n]]- a pointer to an instance of
           a PcPolicyAction sub-class; the cardinality [0..n] means that



Bryskin & Berger        Expires September 5, 2007              [Page 59]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


           zero, one or more instances of one or more PcPolicyAction
           sub-class(es) could be associated with (share) a given
           instance of the PcPolicyPcReqRspSet class by this association

   Dependent [ref PcPolicyPcReqRspSet [0..n]]- a pointer to an instance
           of the PcPolicyPcReqRspSet class; the cardinality [0..n]
           means that zero, one or more instances of the
           PcPolicyPcReqRspSet class could be associated with the
           same instance of a PcPolicyAction sub-class by this
           association

   The PolicyImplicitVariableInPcPolicyAction class is also derived from
   the Dependency class.

   The class has the following properties:

   Antecendent [ref PcPolicyAction [0..n]]- a pointer to an instance of
           a PcPolicyAction sub-class; the cardinality [0..n] means that
           zero, one or more instances of one or more PcPolicyAction
           sub-class(es) could be associated with (share) a given
           instance of a PolicyImplicitVariable sub-class by this
           association

   Dependent [ref PolicyImplicitVariable [0..n]]- a pointer to an
           instance of a PolicyImplicitVariable sub-class; the
           cardinality [0..n] means that zero, one or more instances
           of one or more PolicyImplicitVariable sub-class(es) could
           be associated with the same instance of a PcPolicyAction
           sub-class by this association


3.3.9. PcPolicyPcCapabilitySetInPcPolicyActionEvaluatePCE class

   The "Evaluate PCE" PC action (modeled by the
   PcPolicyActionEvaluatePCE class (see 3.4)) needs to have an access to
   the properties of the PC capabilities published for any given PCE.
   This access is modeled by associating an instance of the
   PcPolicyActionEvaluatePCE class with one or more instances of the
   PcPolicyPcCapabilitySet class via separate instances of the
   PcPolicyPcCapabilitySetInPcPolicyActionEvaluatePCE class. The class
   is derived from the Dependency class (introduced in [RFC3060]).

   The PcPolicyPcCapabilitySetInPcPolicyActionEvaluatePCE has the
   following properties:

     Antecendent [ref PcPolicyActionEvaluatePCE [0..n]]- a pointer to an
           instance of the PcPolicyActionEvaluatePCE class; the
           cardinality [0..n] means that zero, one or more instances



Bryskin & Berger        Expires September 5, 2007              [Page 60]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


           of the PcPolicyActionEvaluatePCE class could be associated
           with (share) a given instance of the PcPolicyPcCapabilitySet
           class by this association

     Dependent [ref PcPolicyPcCapabilitySet [1..n]]- a pointer to an
           instance of the PcPolicyPcCapabilitySet class; the
           cardinality [1..n] means that one or more instances of the
           PcPolicyPcCapabilitySet class could be associated with the
           same instance of the PcPolicyActionEvaluatePCE class by this
           association


3.4. Modeling PC actions

   PC policies introduced in 3.1 and 3.2 - PC constraints and PC
   capabilities - are modeled based on the SimplePolicyCondition and
   SimplePolicyAction classes. Applying such policies on a PCC or PCE
   PEP results in setting new values for properties of the policy class
   instances and/or PC policy variables (see 3.5), but does not require
   any processing outside of the rule engine, such as PCC/PCE
   reconfiguration or invoking other PCC/PCE software modules.  As was
   mentioned on several occasions in this document, such approach is
   beneficial, because it allows great deal of flexibility in
   introducing new policies (that is, new PC constraints and
   capabilities) without requiring modification of the PCC/PCE software.

   Clearly, not all of the PC policies could be modeled this way. A PCC
   PEP, for example, after applying all policies for building a path
   computation request (setting necessary PC constraints) and selecting
   suitable PCE for the request, needs to actually send the request to
   the PCE, that is, invoke a PCC-PCE communication protocol to encode
   and deliver the request. Let's call such PC action "Request Path
   Computation" action (see more 3.4.2). Note that the PCC PEP rule
   engine, while applying PC actions such as the "Request Path
   Computation" action, (in sharp contrast with all previously discussed
   PC policies) DOES need to understand the semantics of the action,
   because it needs to translate the action into actual API call(s).
   Also note that the same PC action may be interpreted differently on
   different PEPs. For example, the result of the interpretation of the
   "Request Path Computation" action on a PCE PEP is one or more calls
   to local path computation engine(s), while on a PCC PEP is a local
   call to a PCC- PCE communication protocol, such as one introduced in
   [PCEP].

   Furthermore, two PCC or PCE PEPs may translate the same PC action
   into a different set of vendor- and device-specific operations.

   An important design goal of PCPIM is to model PC actions via a small



Bryskin & Berger        Expires September 5, 2007              [Page 61]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   number of well defined classes, while allowing and encouraging
   unlimited introduction (by PC policy writers) of new PC constraints
   and capabilities via sub-classing the PCPIM classes, introduced in
   sections 3.1 and 3.2, as well as adding new similar classes. PCPIM
   classes, modeling the PC actions, are discussed in the remainder of
   this section.


3.4.1. PcPolicyAction class

   PcPolicyAction is a class derived from the PolicyAction class
   introduced in [RFC3060]. PcPolicyAction class is an abstract class,
   and hence cannot be directly instantiated. The
   PcPolicyActionRequestPathComputation,
   PcPolicyActionSendPathComputationResponse and
   PcPolicyActionProcessPathComputationResponse are derived from the
   PcPolicyAction class. The class has the following properties:

     PCEID - IPv4 or IPv6 value specifying the peer PCE ID
     PCCID - IPv4 or IPv6 value specifying the peer PCC ID


3.4.2. PcPolicyActionRequestPathComputation class

   PcPolicyActionRequestPathComputation is a class derived from the
   PcPolicyAction class.  The PcPolicyActionRequestPathComputation class
   models the "Request Path Computation" PC policy action, mentioned at
   the top of 3.4. An instance of the
   PcPolicyActionRequestPathComputation class can be associated with
   zero or more instances of the PcPolicyPcReqRspSet class(see 3.3.1)
   via separate instances of the PcPolicyPcReqRspSetInPcPolicyAction
   class (see 3.3.8) and zero or more instances of
   PolicyImplicitVariable sub-class(es) (see 3.5) via separate instances
   of the PolicyImplicitVariableInPcPolicyAction class (see 3.3.8).

   This PC policy action could be informally stated as: "Request path
   computation, using the specified set of path computation constraints
   and/or path computation policy variables".

   The interpretation of the "Request Path Computation" PC policy action
   on a PCC PEP informally sounds as: "Encode the associated PC
   constraints and PC policy variables into a path computation request;
   send the request to the specified peer PCE and wait for the
   response". It is assumed that:

   a) the PCC-PCE protocol has a transport tool (an opaque object) which
      could be used for delivery of the associated PC constraint
      policies and PC policy variables;



Bryskin & Berger        Expires September 5, 2007              [Page 62]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   b) the transferred by the PCC-PCE protocol PC constraint policies and
      PC policy variables could be presented to the PCE PEP in the same
      format as local policies (the ones that are delivered to the PCE
      PEP from the PCE PDP)

   The interpretation of the "Request Path Computation" PC policy action
   on a PCE PEP informally could be expressed as follows:

   a) Use associated with the path computation request constraints
      (properties of PC constraint policy instances) to configure a call
      to a local path computation engine;

   b) Call the path computation engine;

   c) If the path computation fails, relax optional constraints of the
      first round of the constraint relaxation (see 3.1.1.) and call the
      path computation engine again;

   d) If the path computation fails, relax optional constraints of the
      next round of the constraint relaxation, and call the path
      computation engine again;

   e) Repeat the previous step until either the path computation
      succeeds or there are no more optional constraints left to relax.

   Note that in addition to constraints arriving in the path computation
   request a PCE may need to apply a set of local PC constraint policies
   (those that are delivered by the PCE PDP). The latter policies could
   be specific to a particular request and/or requesting PCC and/or
   source/destination/transit PC domains. For example, for certain PCCs
   there could be a policy to further constrain the path computation or,
   on the contrary, relax some constraints, specified by the PCC. The PC
   policy variables sent by the PCC in the request are likely to be an
   input for the PCE PEP local policies.

   Obviously, the final configuration of the call to the path
   computation engine should reflect both local and remote (coming in
   the request) policies. It is quite possible that some policies from
   one set will contradict the similar policies from another set. For
   example, a PCC may require the end-to-end delay optimization for the
   path selection, and a local PCE policy may explicitly require not to
   ask for such optimization. The PolicyRule priority mechanism,
   introduced in [RFC3060] and further enhanced in [RFC3460], could be
   used to make sure that local PCE policies always "win".

   The PcPolicyActionRequestPathComputation class does not have any
   properties.




Bryskin & Berger        Expires September 5, 2007              [Page 63]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


3.4.3. PcPolicyActionSendPathComputationResponse class

   PcPolicyActionSendPathComputationResponse is a class derived from the
   PcPolicyAction class.  The PcPolicyActionRequestPathComputation class
   models the "Send Response For the Path Computation Request" PC policy
   action. An instance of the PcPolicyActionSendPathComputationResponse
   class can be associated with zero or more instances of the
   PcPolicyPcReqRspSet class(see 3.3.1) via separate instances of the
   PcPolicyPcReqRspSetInPcPolicyAction class (see 3.3.8) and zero or
   more instances of PolicyImplicitVariable sub-class(es) (see 3.5) via
   separate instances of the PolicyImplicitVariableInPcPolicyAction
   class (see 3.3.8).

   This PC policy action could be informally expressed as follows:

      Send a path computation response for the processed path
      computation request, providing details on the resulting path(s)
      (e.g., actual path costs or end-to-end delay characteristics) and
      conditions on which their computation was possible to achieve
      (e.g., set of constraints that were relaxed, additionally imposed
      or overruled by the PCE), and PC policy variables pertinent to the
      response.

   This PC policy action is meaningful/applicable only on PCE PEPs.

   The PcPolicyActionSendPathComputationResponse class does not have
   properties.


3.4.4. PcPolicyActionProcessPathComputationResponse class

   PcPolicyActionProcessPathComputationResponse is a class derived from
   the PcPolicyAction class.  The
   PcPolicyActionProcessPathComputationResponse class models the
   "Process the Response For the Path Computation Request" PC policy
   action. An instance of the
   PcPolicyActionProcessPathComputationResponse class can be associated
   with zero or more instances of the PcPolicyPcReqRspSet class(see
   3.3.1) via separate instances of the
   PcPolicyPcReqRspSetInPcPolicyAction class (see 3.3.8) and zero or
   more instances of PolicyImplicitVariable sub- class(es) (see 3.5) via
   separate instances of the PolicyImplicitVariableInPcPolicyAction
   class (see 3.3.8).

   The instances of the PcPolicyPcReqRspSet class and
   PolicyImplicitVariable sub-class(es) model policy information sent by
   the PCE to the requesting PCC about computed paths.  Examples include
   path costs, end-to-end delay characteristics, relaxed constraints,



Bryskin & Berger        Expires September 5, 2007              [Page 64]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   constraints additionally imposed or overruled by the PCE, and the
   list of path computation domain IDs the paths will traverse.

   This PC policy action could be informally expressed as follows:

      "Process a path computation response for the requested path
      computation request, possibly generating a new set of constraints
      and requesting an additional path computation possibly from a
      different PCE".

   For example, the result of the processing could be setting new values
   for one or more PC policy variables, which PC policies for setting
   constraints and selecting PCE depend on.

   This PC policy action is meaningful/applicable only on PCC PEPs.

   The PcPolicyActionProcessPathComputationResponse class does not have
   properties.


3.4.5. PcPolicyActionEvaluatePCE class

   PcPolicyActionEvaluatePCE is a class derived directly from the
   PolicyAction [RFC3060] class, rather, than from the PcPolicyAction
   class as each of the previously described PC policy action classes.
   The PcPolicyActionEvaluatePCE class models the "Evaluate PCE For PC
   Request" PC policy action. In order to be meaningful an instance of
   the PcPolicyActionEvaluatePCE class needs to be associated with one
   or more instances of the PcPolicyPcCapabilitySet class (see 3.3.2)
   via separate instances of the
   PcPolicyPcCapabilitySetInPcPolicyActionEvaluatePCE class (see 3.3.9).

   The process of PCE evaluation is described in 3.2.1

   This PC policy action could be informally expressed as follows:

      "Summarize the pceMetric property of all associated instances of
      PcPolicyPcCapabilityComponent sub-classes; store the computed sum
      in the PcPolicyEvaluatedPCEMetricVariable and the PCEID of the
      evaluated PCE in the PcPolicyEvaluatedPCEIDVariable".

   The "Evaluate PCE For PC Request" PC policy action enables the
   selection of a PCE for a given path computation request via an
   instance of the PolicyRule class ([RFC3060], [RFC3460]) modeling the
   following logic:

        if(PcPolicyEvaluatedPCEMetricVariable >
                                      PcPolicyPeerPCEMetricVariable)



Bryskin & Berger        Expires September 5, 2007              [Page 65]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


             then PcPolicyPeerPCEMetricVariable =
                          PcPolicyEvaluatedPCEMetricVariable;
                  PcPolicyPeerPCEIDVariable =
                          PcPolicyEvaluatedPCEIDVariable;

   This PC policy action is meaningful/applicable only on PCC PEPs.  The
   PcPolicyActionEvaluatePCE does not have properties.


3.5. Modeling PC variables

   PC policy provides the necessary flexibility for the network operator
   to influence on a provisioned service path selection. To accomplish
   this objective PC policy needs some input, generated outside of the
   policy realm, to be used as conditions for the policy actions.
   Specifically, PCPIM needs to connect the PC policies modeled by PCPIM
   with the information that is important for the path selection such as
   service provisioning/signaling message or SLA contents. For example,
   in order to constrain the path computation for a given service, PC
   policy needs information about the service setup parameters. In a
   model, based on the [RFC3060]/[RFC3460] policy class hierarchies,
   such input is modeled via policy implicit variables (the
   PolicyImplicitVariable sub-classes). The policy framework defines the
   value type and acceptable values for such variables, however, their
   actual values are expected to be set before the policy is applied.
   Under these circumstances the variables could be associated with
   policy conditions and hence produce necessary connection between the
   policy and the network state. For instance, the
   PcPolicyServiceLinkProtectionFlagsVariable is expected to contain the
   link protection flags provisioned for a GMPLS tunnel. The variable
   could be associated with one or more instances of the
   SimplePolicyCondition class ([RFC3460]),  which, in turn, could be
   associated with the PC policies, constraining the path computation
   request (instances of PcPolicyPcReqRspComponent sub-classes) and/or
   selecting a PCE for the computation (instances of
   PcPolicyPcCapabilityComponent sub-classes).

   The purpose of this section is to define frequently used variables in
   PC policy domains that could be used to form PC policy conditions and
   actions. The described set could be easily extended. Notice that this
   section only adds to the variable classes as defined in [RFC3460] and
   reuses the mechanism defined there.









Bryskin & Berger        Expires September 5, 2007              [Page 66]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


3.5.1. PcPolicyServiceSourceIPv4Variable

   PcPolicyServiceSourceIPv4Variable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   unordered set of IPv4 values specifying all source address(es) of the
   provisioned service.


3.5.2. PcPolicyServiceSourceIPv6Variable

   PcPolicyServiceSourceIPv6Variable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   unordered set of IPv6 values specifying all source address(es) of the
   provisioned service.


3.5.3. PcPolicyServiceDestinationIPv4Variable

   PcPolicyServiceDestinationIPv4Variable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   unordered set of IPv4 values specifying all destination address(es)
   of the provisioned service.


3.5.4. PcPolicyServiceDestinationIPv6Variable

   PcPolicyServiceDestinationIPv6Variable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   unordered set of IPv6 values specifying all destination address(es)
   of the provisioned service.


3.5.5. PcPolicyServiceMcstGroupIDVariable

   PcPolicyServiceMcstGroupIDVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   integer value specifying network scope unique multicast group ID of
   the provisioned point-to-multipoint service.


3.5.6. PcPolicyServiceEncodingTypeVariable

   PcPolicyServiceEncodingTypeVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   integer value specifying the provisioned service data encoding type
   according to [RFC3471].





Bryskin & Berger        Expires September 5, 2007              [Page 67]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


3.5.7. PcPolicyServiceSwitchingTypeVariable

   PcPolicyServiceSwitchingTypeVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   integer value specifying the provisioned service data switching type
   according to [RFC3471].


3.5.8. PcPolicyServiceGPIDVariable

   PcPolicyServiceGPIDVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   integer value specifying the provisioned service GPID type according
   to [RFC3471].


3.5.9. PcPolicyServiceBandwidthVariable

   PcPolicyServiceBandwidthVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   IEEE floating point format value (PCPolicyFPValue class see 3.6.1)
   specifying the provisioned service bandwidth requirements in bytes
   per second units.


3.5.10. PcPolicyServiceBandwidthDirectionalityVariable

   PcPolicyServiceBandwidthDirectionalityVariable is a class derived
   from the PolicyImplicitVariable ([RFC3460]) class. The variable
   contains an integer specifying the provisioned service bandwidth
   directionality requirements. The acceptable values are:

      1 - requested bandwidth must be available only in forward (from
          service source to service destination) direction
      2 - requested bandwidth must be available only in reverse (from
          service destination to service source) direction
      3 - requested bandwidth must be available in both directions


3.5.11. PcPolicyServiceBandwidthPriorityVariable

   PcPolicyServiceBandwidthPriorityVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   integer from the range {0...7}, specifying the priority level at
   which the bandwidth must be available for the service.






Bryskin & Berger        Expires September 5, 2007              [Page 68]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


3.5.12. PcPolicyServicePathRecoveryFlagsVariable

   PcPolicyServicePathRecoveryFlagsVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains a bit
   field specifying the provisioned service path recovery flags as
   encoded in the PROTECTION object according to [RFC3471] and
   [E2ERECOVERY].


3.5.13. PcPolicyServiceLinkProtectionFlagsVariable

   PcPolicyServiceLinkProtectionFlagsVariable is a class derived from
   the PolicyImplicitVariable ([RFC3460]) class. The variable contains a
   bit field specifying the provisioned service link protection flags as
   encoded in the PROTECTION object according to [RFC3471].


3.5.14. PcPolicyServiceNameVariable

   PcPolicyServiceNameVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains a
   character string specifying the provisioned service readable name.


3.5.15. PcPolicyServiceIncludeAnyVariable

   PcPolicyServiceIncludeAnyVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains a bit
   field specifying the "IncludeAny" link affinities provisioned for the
   service according to [RFC3209].


3.5.16. PcPolicyServiceExcludeAnyVariable

   PcPolicyServiceExcludeAnyVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains a bit
   field specifying the "ExcludeAny" link affinities provisioned for the
   service according to [RFC3209].


3.5.17. PcPolicyServiceIncludeAllVariable

   PcPolicyServiceIncludeAllVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains a bit
   field specifying the "IncludeAll" link affinities provisioned for the
   service according to [RFC3209].





Bryskin & Berger        Expires September 5, 2007              [Page 69]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


3.5.18. PcPolicyServiceEROVariable

   PcPolicyServiceEROVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   unordered set of the PCPolicyROValue (see 3.6.4 ) values specifying
   all Explicit Route Objects (EROs), provisioned for the service
   according to [RFC3209].


3.5.19. PcPolicyServiceRROVariable

   PcPolicyServiceRROVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   unordered set of the PCPolicyROValue (see 3.6.4 ) values specifying
   all Record Route Objects (EROs), generated for the service according
   to [RFC3209].

   One use of this PC policy variable is to associate it with a path
   computation request for a service requiring the "make-before-break"
   re- routing.


3.5.20. PcPolicyServiceReferencePointIDVariable

   PcPolicyServiceReferencePointIDVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   integer specifying network unique ID of a reference point/SAP/port
   the service provisioning/signaling SETUP message was received from.


3.5.21. PcPolicyUserIDVariable

   PcPolicyUserIDVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   integer specifying network unique ID of the provisioned service
   user/customer as stated in the SLA.


3.5.22. PcPolicyServiceQOSVariable

   PcPolicyServiceQOSVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   integer specifying the provisioned service QOS as stated in the SLA.








Bryskin & Berger        Expires September 5, 2007              [Page 70]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


3.5.23. PcPolicyServiceCOSVariable

   PcPolicyServiceCOSVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   integer specifying the provisioned service COS as stated in the SLA.


3.5.24. PcPolicyServiceAvailabilityVariable

   PcPolicyServiceAvailabilityVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   integer specifying the provisioned service availability
   characteristic as stated in the SLA.


3.5.25. PcPolicyLocalPCCIDVariable

   PcPolicyLocalPCCIDVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   IPv4 or IPv6 value specifying the local PCC ID (the ID of a PCC
   controlled by the PCC-PEP applying the PC policy).


3.5.26. PcPolicyLocalPCEIDVariable

   PcPolicyLocalPCEIDVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   IPv4 or IPv6 value specifying the local PCE ID ( the ID of a PCE
   controlled by the PCE-PEP applying the PC policy).


3.5.27. PcPolicyPeerPCEIDVariable

   PcPolicyPeerPCEIDVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   IPv4 or IPv6 value specifying the peer PCE ID ( the ID of a PCE
   currently used or selected for a given path computation).


3.5.28. PcPolicyPeerPCEMetricVariable

   PcPolicyPeerPCEMetricVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   integer value specifying the PCE metric of a PCE currently used or
   selected for a given path computation (PCE metric is described in
   3.2.1 and 3.4.5).





Bryskin & Berger        Expires September 5, 2007              [Page 71]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


3.5.29. PcPolicyEvaluatedPCEIDVariable

   PcPolicyEvaluatedPCEIDVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   IPv4 or IPv6 value specifying the ID of a PCE candidate (the ID of a
   PCE currently evaluated for a given path computation).


3.5.30. PcPolicyEvaluatedPCEMetricVariable

   PcPolicyEvaluatedPCEMetricVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   integer value specifying the PCE metric of a PCE candidate (a PCE
   currently evaluated for a given path computation).


3.5.31. PcPolicyPeerPCCIDVariable

   PcPolicyPeerPCCIDVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   IPv4 or IPv6 value specifying the peer PCC ID ( the ID of a PCC
   requested currently undergoing path computation).


3.5.32. PcPolicyLocalPCDomainIDVariable

   PcPolicyLocalPCDomainIDVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   IPv4 or IPv6 value specifying a network unique ID of the local path
   computation domain.


3.5.33. PcPolicySourcePCDomainIDVariable

   PcPolicySourcePCDomainIDVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   unordered set of IPv4 or IPv6  values, specifying network unique IDs
   of all path computation domains, where the sources of the provisioned
   service are located.


3.5.34. PcPolicyDestinationPCDomainIDVariable

   PcPolicyDestinationPCDomainIDVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   unordered set of IPv4 or IPv6 values, specifying network unique IDs
   of all path computation domains, where the destinations of the
   provisioned service are located.



Bryskin & Berger        Expires September 5, 2007              [Page 72]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


3.5.35. PcPolicyTransitPCDomainIDVariable

   PcPolicyTransitPCDomainIDVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   ordered set of IPv4 or IPv6 values, specifying network unique IDs of
   all path computation domains which the provisioned service paths are
   expected to traverse.


3.5.36. PcPolicyPcRequestResponseCodeVariable

   PcPolicyPcRequestResponseCodeVariable is a class derived from the
   PolicyImplicitVariable ([RFC3460]) class. The variable contains an
   integer value, specifying the response code for the completed path
   computation request.


3.6. Modeling PC values

   Values are used in the policy information model as building blocks
   for the policy conditions and policy actions, as described in
   [RFC3060] and [RFC3460].  This section defines a set of value types
   that are used for PC policies. All value classes extend the
   PolicyValue class [RFC3460].  The sub-classes specify specific
   data/value types that are not defined in [RFC3460].


3.6.1. PCPolicyFPValue

   PCPolicyFPValue is a class derived from the PolicyValue ([RFC3460])
   class.  The values of PC variables and properties of PCPIM classes of
   this type must be interpreted as IEEE floating point format values.
   For example, this is the only acceptable value type for the
   PcPolicyServiceBandwidthVariable class (introduced in 3.5.8).


3.6.2. PCPolicyUnnumLinkIDValue

   PCPolicyUnnumLinkIDValue is a class derived from the PolicyValue
   ([RFC3460]) class. This value type is a combination of IPv4 and
   integer values. The values of PC variables and properties of PCPIM
   classes, containing unnumbered TE link IDs, are of the
   PCPolicyUnnumLinkIDValue type.








Bryskin & Berger        Expires September 5, 2007              [Page 73]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


3.6.3. PCPolicyROElementValue

   PCPolicyROElementValue is a class derived from the PolicyValue
   ([RFC3460]) class. This value type is a union of IPv4, IPv6,
   PCPolicyUnnumLinkIDValue and integer value types used to specify
   values for IPv4 numbered TE link IDs, IPv6 numbered TE link IDs,
   unnumbered TE link IDs and resource labels respectively in the RSVP-
   TE style Route Objects (EROs and RROs).


3.6.4. PCPolicyROValue

   PCPolicyROValue is a class derived from the PolicyValue ([RFC3460])
   class. This value type describes an ordered set of
   PCPolicyROElementValue values, specifying one RSVP-TE style route
   object (ERO or RRO).


4. PCPIM class definition

   [This section to be completed based on Section 3.]


5. Security Considerations

   The Policy Core Information Model [RFC3060] describes the general
   security considerations related to the general core policy model. The
   extensions defined in this document do not introduce any additional
   considerations related to security.


6. IANA Considerations

    None.


7. References

7.1. Normative References

   [PCE-POLICY] I. Bryskin, D. Papadimitriou, L. Berger, J. Ash,
                "Policy-Enabled Path Computation Framework",
                draft-ietf-pce-policy-enabled-path-comp-01.txt,
                March 2007

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




Bryskin & Berger        Expires September 5, 2007              [Page 74]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   [RFC3060] Moore, B., Ellesson, E., Strassner, J. and
             A. Westerinen,  "Policy Core Information Model --
             Version 1  Specification", RFC 3060, February 2001.

   [RFC3460] Moore, B., Ed., "Policy Core Information Model
             Extensions", RFC 3460, January 2003.


7.2. Informative References

   [E2ERECOVERY] J.P. Lang, Ed., Y. Rekhter, Ed., D. Papadimitriou, Ed.,
                 "RSVP-TE Extensions in support of End-to-End
                 Generalized Multi-Protocol Label Switching (GMPLS)-
                 based Recovery",
                 draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt,
                 April 2005

   [PCEP]    J. P. Vasseur, Ed., "Path Computation Element (PCE)
             communication Protocol PCEP) - Version 1",
             draft-ietf-pce-pcep-02.txt, June 2006

   [RFC3198] Westerinen, A., et al., "Terminology for Policy-based
             Management", RFC 3198, November 2001

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

   [RFC3471] L. Berger, Ed.," Generalized Multi-Protocol Label Switching
             (GMPLS). Signaling Functional Description", RFC 3741,
             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.

   [RFC4202] K. Kompella, Ed., Y. Rekhter, Ed. "Routing Extensions in
             Support of Generalized Multi-Protocol Label Switching
             (GMPLS)", RFC 4202, October 2005

   [RFC4655] A. Farrel, J. P. Vasseur,  J. Ash "A Path Computation
             Element (PCE)-based Architecture", RFC 4655, August 2006









Bryskin & Berger        Expires September 5, 2007              [Page 75]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


8. Authors' Addresses

   Igor Bryskin
   Email: i_bryskin@yahoo.com

   Lou Berger
   LabN Consulting, L.L.C.
   Email: lberger@labn.net


9. Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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, THE IETF TRUST 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.



10. Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary



Bryskin & Berger        Expires September 5, 2007              [Page 76]


Internet-Draft       draft-bryskin-pce-pcpim-01.txt        March 5, 2007


   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).











































Bryskin & Berger        Expires September 5, 2007              [Page 77]

Generated on: Sun Mar 4 09:16:35 EST 2007


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/