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: then " 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 then 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( MATCH ) and SimplePolicyAction could be expressed as: SET TO where and 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