Internet Draft Igor Bryskin
Category: Standards Track Lou Berger
Expiration Date: April 2007
October 2006
Path Computation Policy Information Model (PCPIM)
draft-bryskin-pce-pcpim-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
The 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. 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.
Bryskin & Berger [Page 1]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
Contents
1 Introduction ................................................ 3
1.1 Process of PC policy definition ............................. 4
1.2 Design goals and their ramifications ........................ 6
1.3 Modeling 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 ................................................. 24
3.1 Modeling PC constraints ..................................... 25
3.2 Modeling PC capabilities .................................... 42
3.3 Modeling PC policy relationships ............................ 54
3.4 Modeling PC actions ......................................... 60
3.5 Modeling PC variables ....................................... 65
3.6 Modeling PC values .......................................... 72
4 Formal PCPIM class definition ............................... 73
5 Security Considerations ..................................... 73
6 References .................................................. 73
6.1 Normative References ........................................ 73
6.2 Informative References ...................................... 73
7 Authors' Addresses .......................................... 74
8 Full Copyright Statement .................................... 74
9 Intellectual Property ....................................... 75
Bryskin & Berger [Page 2]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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].
Author's Note
Please note that this is an initial draft. Additional technical and
editorial revisions of the draft are expected.
1. Introduction
The Path Computation Policy Information Model (PCPIM) introduced in
this document establishes the specific framework and constructs for
specifying and representing policies that manage and control (G)MPLS
TE LSP, see [RFC3209] and [RFC3473], path computation process. Such
policies are referred to as "PC policies" in this document. The
framework consists of a set of classes and relationships that are
organized in an object-oriented information model. It is agnostic of
any specific Policy Decision Point (PDP) or Policy Enforcement Point
(PEP), see [RFC3198] for definitions, implementation.
PCPIM is designed to represent PC policy information for policy
domains, see [RFC3198] for definition of "policy domain". The goal
of this information model is to assist human administrators in their
definition of policies to control the path computation process. The
process of creating PCPIM class instances is fed by business rules,
network topology and PC methodology, e.g. centralized, distributed,
remote PCE, local PCE, etc., see [RFC4655] for definition of PCE.
This document is based on the IETF Policy Core Information Model and
its extensions as specified by [RFC3060] and [RFC3460]. PCPIM builds
upon these two documents to define an information model for the path
computation governed by policy. It is important to note that the
defined model 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 [Page 3]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
1.1. Process of PC policy definition
This section describes the process of using PCPIM for the definition
of PC policy for a policy domain. Figure 1 illustrates information
flow rather than the 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 PC policy definition 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, 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 distributed path computation
using remote PCE(s) [RFC4655] methodology may be considered in the PC
policy definition process.
Bryskin & Berger [Page 4]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
The network topology consists of an inventory of network resources
that make up the network. This inventory is usually auto discovered
and distributed via a Control Plane or the Management Plane, and made
available to the network's path computation engines that perform the
actual path computation.
Business rules are informal sets of requirements for specifying the
behavior of various services that may be provisioned on the network.
Business rules directly or indirectly prescribe specific attributes
for the services such as cost, availability, resilience to failures,
end-to-end delay expectations, etc. This information is required not
by PCPIM itself, but by the overall policy management system that
uses PCPIM. PCPIM is used to map business rules into semantics that
control service path computation, so that paths computed for a
specific service will can be successfully provisioned and will
conform to policy requirements and expectations.
Topology, PC methodology and business rules are necessary
prerequisites for defining service path computation. 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 level of visibility into inventory of
network resources. Even the same model 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 would 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", "Inter-AS Path
Computation Element", etc. For example, network administrator may
assign to 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, send the request to another
PCE, etc.) independent of the actual devices themselves.
Fortunately, [RFC3060] defines and [RFC3460] further enhances the
concept of role. As a [RFC3460] sub-class PCPIM uses roles to help
the administrator map a given set of network elements to a given set
Bryskin & Berger [Page 5]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
of PC policy constructs.
The 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. 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 their ramifications
This section explains PCPIM design goals and how these goals are
addressed. This section also describes 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
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/network configuration.
There are several 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 and match
Bryskin & Berger [Page 6]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
them to suit the needs of device-specific configurations.
1.2.1.1. Rule-based modeling
PCPIM describes PC policy using rule-based modeling as introduced in
[RFC3060] and [RFC3460]. A PC policy rule is structured as a
condition clause and an action clause. The semantics are simple: if
the condition clause evaluates to TRUE then a set of actions, as
specified in the action clause, can be executed. For example, the
rule:
"If bandwidth requirement is specified in the service provisioning
message, then restrict the path selection to TE links advertising
unreserved bandwidth to no less than the specified value"
could be formalized as:
"<If provBandwidth !=0 > then <require minimum BW = provBanwidth>"
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. On the other hand, PCPIM
relies predominantly on use of the SimplePolicyCondition,
CompoundPolicyCondition, SimplePolicyAction, and CompoundPolicyAction
classes defined in [RFC3460]. Such an approach enables PCPIM to be
easily extended. New path computation capabilities may be introduced
without modifications of PCC - PCE communication and PCE discovery
protocols and 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. To do this, 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/or policy groups. A
policy rule can also contain other policy rules and/or groups, thus
enabling a rule/sub-rule relationship.
The hierarchical design decision is based on the realization that it
is natural to organize policy rules in groups. Breaking down a
Bryskin & Berger [Page 7]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
complex policy into a set of simple rules is a process that follows
the way people tend to think and analyze systems. The complexity of
the abstract business-oriented policy is simplified and made 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 policy 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 (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 the PEPs would 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 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 provide a means for defining
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.
This design goal has several ramifications. First, roles are used to
define policies across multiple network elements. Second, the use of
Bryskin & Berger [Page 8]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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] are the means
for sharing policy building blocks, thus allowing central management
of global concepts. PCPIM provides the ability to reuse all policy
building blocks: variables and values, conditions and actions, policy
rules and policy groups. This provides the required flexibility to
manage large sets of policy rules over large policy domains.
For example, the following rule makes use of centrally defined
objects being reused (referenced):
If <SourceAddress == DomainA>
then <RecoveryPathDisjoitedness = SRLGDisjoint>
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
Bryskin & Berger [Page 9]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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, if/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. This is not only much less efficient, but
also is more prone to errors.
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/or PEP can use PCPIM's policy definition in order to
make the necessary decisions and enforce the required policy rules.
For example, a decision on which remote PCE a given path computation
request should be sent to should be made based entirely on the policy
definitions specified by PCPIM.
A PDP, associated with a given PCE (or PCC), should be capable to
extract all policies written for each of the PCEs (PCCs) roles and
deliver them to the PCEs (PCCs) PEP, which, it turn, should be able
to map the policies into sets of PCEs (PCCs) configuration commands,
so that desired behavior could be achieved.
PCPIM is designed to be agnostic 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.
3. Policy specified by PCPIM must be able to control the path
Bryskin & Berger [Page 10]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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, 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. However, 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 agnostic of the PC methodology used on the network. This
means that on any given network element the same PC Policy actions
could 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 PCEP 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 agnosticism is important, because it allows introduction
of new methodologies without (re-)writing policies governing the path
Bryskin & Berger [Page 11]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
computation.
1.3. Modeling abstract PC policies
This section provides a discussion of PC policy abstraction and the
way PCPIM addresses this issue.
As was mentioned earlier, the main goal of PCPIM is to create an
information model that can be used to help bridge (part of) 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/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 utter a policy statement that reads:
"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:
"Service A must have an end-to-end backup path disjoint from its
primary path enough to guarantee that a single network failure
will not make both paths simultaneously unusable for the service".
While this statement clearly defines PC policy at the business level,
it isn't specific enough to be enforceable by a network element (e.g.
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: "Require from a remote PCE a
computation of a path that end-to-end backs up the service A primary
path, require also the two paths to be link-disjoint from each
other".
Bryskin & Berger [Page 12]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
On a different network element on the same network the same
instruction may take different form (specific to the element),
despite that the element plays the same role in the path computation
process as the first one. This is because a different vendor has
built that element or it has a different set of functions (and hence
implementation), even though it is from the same vendor.
The first statement at the head of this section illustrates an
'abstract policy', while the second 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 be 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 is roughly 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.
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.
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 roles.
6. The PEPs apply/enforce the polices by translating them into
sets of network element-specific configuration instructions.
PCPIM, PCIM and PCIMe are used in step #3 above.
Bryskin & Berger [Page 13]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
1.4. Rule Hierarchy
Policy is described by a set of policy rules that may be grouped
together (see {PCIM] and [RFC3460]). 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 (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 require the 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 destination(s)"
Note 1. 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.
Note 2. The Optical Signal To Noise Ratio (OSNR) is a characteristic
that defines the optical signal "noisiness". 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
destination(s) 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)
THEN (SetOpticalConstraints)
Bryskin & Berger [Page 14]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
The policy becomes more readable. However, a more important
consequence of such policy nesting is that, if/when in future there
is a need for another optical constraint (e.g. Polarization Mode
Dispersion (PMD) at the service destination to be no greater than
certain value), all that will need to be done is modifying the
SetOpticalConstraints policy group, rather, than modifying all
policies that refer (use) the group.
1.5. Extensibility of the path computation process via PCPIM
Historically, a path computation entity was an intrinsic part of an
LSR's control plane and always co-located with the LSR's signaling
and routing subsystems. Such architectural approach allowed for
unlimited flexibility in providing various path computation
enhancements, such as: adding new types of constraints and their
relaxation strategies, adopting new objective functions and
optimization criteria, etc. All that had to be done to support an
enhancement was to upgrade the control plane software of a particular
LSR (and no other LSRs or any other network elements).
With the invent of the PCE architecture ([RFC4655]), the introduction
of new PCE capabilities became more complicated: it isn't enough
anymore for a PCE to upgrade its own software. In order to take
advantage of a PCE's new capabilities, new advertising and signaling
objects may need to be standardized, all PCCs may need to be upgraded
with new software, new interoperability problems may need to be
resolved, etc.
Within the context of the PCE architecture it is therefore highly
desirable to find a way to introduce new path computation
capabilities without requiring 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 are modeled
via policy rules with:
- condition clauses made up entirely of a combination of instances
of the SimplePolicyCondition class ([RFC3460]) and/or instances of
the CompoundPolicyCondition class ([RFC3460]) aggregating
instances of the SimplePolicyCondition class.
- action clauses made up entirely of a combination of instances
of the SimplePolicyAction class ([RFC3460]) and/or instances of
the CompoundPolicyAction class ([RFC3460]) aggregating instances
of the SimplePolicyAction class.
Bryskin & Berger [Page 15]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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.
Read more about the SimplePolicyCondition, SimplePolicyAction,
CompoundPolicyCondition and CompoundPolicyAction classes in [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, variables,
etc. 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
It is assumed, that when remote path computation service is used,
peer PCC and PCE 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 [Page 16]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
service IDs.
- Number of paths/trees connecting set of sources to set of
destinations to be computed.
- An opaque object carrying instances of PCPIM classes that model
path computation policies (e.g. policy variables, values,
constraints, objective functions, their relaxations, etc.)
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 (resulting) paths/trees.
- An opaque object carrying instances of PCPIM classes that model
path computation policies pertinent to the response
(e.g. constraints that needed to be relaxed, path/tree costs,
etc.)
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 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
decide 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 [Page 17]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
2. Class Hierarchies
2.1. Inheritance Hierarchy
PCPIM's class and association inheritance hierarchies are rooted in
[RFC3060] and [RFC3460]. Figures 2 and 3 depict 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 following figures
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.
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)
| | | | |
| | | | +--- PcPolicyPathElement (PCPIM, abstract)
| | | | | |
| | | | | +--- PcPolicyExcludeLinkConstraint (PCPIM)
Bryskin & Berger [Page 18]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
| | | | | |
| | | | | +--- 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)
| | | | +--- PcPolicyGMPLSMinimalDispersionObjectiveFunction
| | | | | (PCPIM)
| | | | |
| | | | +--- PcPolicyGMPLSMinimalAttenuationObjectiveFunction
| | | | | (PCPIM)
| | | | |
| | | | +--- PcPolicyGMPLSMinimalRegenerationObjectiveFunction
| | | | | (PCPIM)
| | | | |
| | | | +--- PcPolicyGMPLSOSNRLowerBoundConstraint (PCPIM)
| | | | |
| | | | +--- PcPolicyGMPLSDispersionUpperBoundConstraint
| | | | | (PCPIM)
| | | | |
| | | | +--- PcPolicyGMPLSAttenuationUpperBoundConstraint
Bryskin & Berger [Page 19]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
| | | | | (PCPIM)
| | | | |
| | | | +--- PcPolicyGMPLSRegenerationUpperBoundConstraint
| | | | | (PCPIM)
| | | | |
| | | | +--- PcPolicyGMPLSTransparentPathUpperBoundConstraint
| | | | | (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)
| | | | +--- PcPolicyExclusionConstraintSupport (PCPIM)
| | | | |
| | | | +--- PcPolicySharedLinkConstraintSupport (PCPIM)
| | | | |
| | | | +--- PcPolicyInclusionConstraintSupport (PCPIM)
| | | | |
| | | | +--- PcPolicyConcurrentPathComputationCapability
| | | | | (PCPIM)
| | | | |
| | | | +--- PcPolicyShortestPathObjectiveSupport (PCPIM)
| | | | |
| | | | +--- PcPolicyCostUpperBoundConstraintSupport (PCPIM)
Bryskin & Berger [Page 20]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
| | | | |
| | | | +--- PcPolicyE2EDelayObjectiveSupport (PCPIM)
| | | | |
| | | | +--- PcPolicyE2EDelayUpperBoundConstraintSupport
| | | | | (PCPIM)
| | | | |
| | | | +--PcPolicyGMPLSWavelengthContinuityConstraintSupport
| | | | | (PCPIM)
| | | | |
| | | | +--- PcPolicyGMPLSOSNRObjectiveSupport (PCPIM)
| | | | |
| | | | +--- PcPolicyGMPLSDispersionObjectiveSupport (PCPIM)
| | | | |
| | | | +--- PcPolicyGMPLSAttenuationObjectiveSupport
| | | | | (PCPIM)
| | | | +---PcPolicyGMPLSMinimalRegenerationsObjectiveFunction
| | | | | (PCPIM)
| | | | |
| | | | +--- PcPolicyGMPLSOSNRLowerBoundConstraintSupport
| | | | | (PCPIM)
| | | | |
| | | | +-- PcPolicyGMPLSDispersionUpperBoundConstraintSupport
| | | | | (PCPIM)
| | | | |
| | | | +--PcPolicyGMPLSAttenuationUpperBoundConstraintSupport
| | | | | (PCPIM)
| | | | |
| | | | +--PolicyGMPLSRegenerationsUpperBoundConstraintSupport
| | | | | (PCPIM)
| | | | |
| | | | +-- PcPolicyGMPLSTransparentPathUpper
| | | | | BoundConstraintSupport (PCPIM)
| | | | |
| | | | +---PcPolicyGMPLSMinimalRegenerationsObjectiveFunction
| | | | | (PCPIM)
| | | | |
| | | | +---PcPolicyGMPLSMinimalRegenerationsObjectiveFunction
| | | | | (PCPIM)
| | | | |
| | | | +--- .... (to be extended)
| | |
| | +---PolicyGroup (abstract, PCIM/PCIMe)
| | | |
| | | +--- PcPolicyPcReqRspSet (PCPIM)
| | | |
| | | +--- PcPolicyPcCapabilitySet (PCPIM)
| |
| +---PolicyVariable (abstract, PCIMe)
Bryskin & Berger [Page 21]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
| | |
| | +---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)
| | |
| | +--- PcPolicyServiceExcludeAnyVariable (PCPIM)
| | |
| | +--- PcPolicyServiceIncludeAllVariable (PCPIM)
| | |
| | +--- PcPolicyServiceEROVariable (PCPIM)
| | |
| | +--- PcPolicyServiceRROVariable (PCPIM)
| | |
| | +--- PcPolicyServiceReferencePointIDVariable (PCPIM)
| | |
| | +--- PcPolicyUserIDVariable (PCPIM)
| | |
| | +--- PcPolicyServiceQOSVariable (PCPIM)
| | |
| | +--- PcPolicyServiceCOSVariable (PCPIM)
Bryskin & Berger [Page 22]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
| | |
| | +--- 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)
| | |
| | +--- .... (to be extended)
| |
| +---PolicyValue (abstract, PCIMe)
| | |
| | +--- PCPolicyFPValue (PCPIM)
| | |
| | +--- PCPolicyUnnumLinkIDValue (PCPIM)
| | |
| | +--- PCPolicyROElementValue (PCPIM)
| | |
| | +--- PCPolicyROValue (PCPIM)
| | |
| | +--- .... (to be extended)
Figure 2. PCPIM Class Inheritance Hierarchy
Bryskin & Berger [Page 23]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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
3. PC Policies
This section describes PC policies that are modeled by PCPIM. PC
policies are policy enforced 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", "Process path computation response", etc. PC
policies are modeled using the class hierarchies introduced in
[RFC3060]/[RFC3460] and the PCPIM classes introduced in this document
(see Figures 2 and 3). PCPIM classes are sub-classes of
[RFC3060]/[RFC3460] classes.
Bryskin & Berger [Page 24]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
3.1. Modeling PC constraints
A PC constraint is modeled based on the PcPolicyPcReqRspComponent
abstract class introduced in this document.
+-----------------------+ +-------------------------+
| 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 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 (sub-)class:
- there should be one or more instances of PolicyCondition
(sub-)classes associated with the PolicyRule (sub-)class
instance in question via separate instances of the
PolicyConditionInPolicyRule (sub-)class;
and
- there should be one or more instances of PolicyAction
(sub-)classes associated with the PolicyRule (sub-)class
Bryskin & Berger [Page 25]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
instance in question via separate instance of the
PolicyActionInPolicyRule (sub-)class.
The approach taken in PCPIM with respect to the use of sub-classes of
the PcPolicyPcReqRspComponent class is to limit:
- the conditions that could 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 could 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 such 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 [Page 26]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
+-----------------------+ 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
Recall from [RFC3460] that SimplePolicyCondition class could be
expressed as:
if(<PolicyVariable> MATCH <PolicyValue>)
and SimplePolicyAction could be expressed as:
SET <PolicyVariable> TO <PolicyValue>
where <PolicyVariable> and <PolicyValue> are instances of
PolicyVariable and PolicyValue (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 (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 [Page 27]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
+-----------------------+ +-------------------------+
| SimplePolicyCondition | | SimplePolicyAction |
| class instances | | class instances |
| (PCIMe) | | (PCIMe) |
+-----------------------+ +-------------------------+
$ %
PolicyConditionInPolicyCondition $ % PolicyActionInPolicycyAction
class instances $ % class instances
(PCIMe) $ % (PCIMe)
$ %
+------------------------+ +-------------------------+
|CompoundPolicyCondition | | CompoundPolicyAction |
| class instance | | class instance |
| (PCIMe) | | (PCIMe) |
+------------------------+ +-------------------------+
Figure 7. Modeling Compound Policy Condition and Action
Notice that all components of the SimplyPolicyCondition and
SimplePolicyAction classes - variables, values, their associations,
what operators "MATCH" and "SET" mean, etc. - 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 can not be directly instantiated. All PC
policy classes describing path computation constraints, objective
functions, path disjointedness, etc. 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
defined value specifying the maximum number of attempts a PCE should
Bryskin & Berger [Page 28]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 [Page 29]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 [Page 30]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 [Page 31]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 [Page 32]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 [Page 33]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 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 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 [Page 34]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 [Page 35]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 [Page 36]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 [Page 37]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 [Page 38]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 [Page 39]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 [Page 40]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 [Page 41]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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.
- etc.
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,
SLAs, etc.) 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
Bryskin & Berger [Page 42]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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
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 [Page 43]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
+-----------------------+ +-------------------------+
| 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 [Page 44]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 can not 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 integers, 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 PCCs
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 [Page 45]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 [Page 46]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 PCEs 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 integers, each integer 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 [Page 47]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
requested path destination(s) might be located.
The class has a single property:
destDomains - a set of integers; each integer 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 properties.
Bryskin & Berger [Page 48]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 available bandwidth constraint (see
3.1.2).
The class does not have 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 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 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 properties.
Bryskin & Berger [Page 49]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 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 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 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 [Page 50]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 the path selection optimization according to
the shortest path criteria (see 3.1.14).
The class does not have 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 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 the path selection optimization according to the minimal
end- to-end delay criteria (see 3.1.15).
The class does not have 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 [Page 51]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
The class does not have 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 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 the path selection optimization according to the maximal
OSNR criteria (see 3.1.19).
The class does not have 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 the path selection optimization according to
the minimal OS dispersion criteria (see 3.1.20).
The class does not have 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 the path selection optimization according to
the minimal OS attenuation criteria (see 3.1.21).
The class does not have properties.
Bryskin & Berger [Page 52]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 the path selection optimization
according to the minimal number of OS regenerations criteria (see
3.1.22).
The class does not have 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 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 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 properties.
Bryskin & Berger [Page 53]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 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 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 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 [Page 54]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 [Page 55]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 [Page 56]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 [Page 57]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 [Page 58]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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
of the PcPolicyActionEvaluatePCE class could be associated
Bryskin & Berger [Page 59]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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, invoking other PCC/PCE software modules, etc. 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. Lets 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
number of well defined classes, while allowing and encouraging
Bryskin & Berger [Page 60]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 can not 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 [Page 61]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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
properties.
Bryskin & Berger [Page 62]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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 path computation response for the processed path computation
request, providing details on the resulting path(s) (actual path
costs, end-to- end delay characteristics, etc.) and conditions on
which their computation was possible to achieve (set of constraints
that were relaxed, additionally imposed or overruled by the PCE), PC
policy variables pertinent to the response, etc.)".
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, such as path
costs, end-to-end delay characteristics, relaxed constraints,
constraints additionally imposed or overruled by the PCE, list of
path computation domain IDs the paths will traverse, etc.
Bryskin & Berger [Page 63]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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)
then PcPolicyPeerPCEMetricVariable =
PcPolicyEvaluatedPCEMetricVariable;
PcPolicyPeerPCEIDVariable =
Bryskin & Berger [Page 64]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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.
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.
Bryskin & Berger [Page 65]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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].
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].
Bryskin & Berger [Page 66]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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.
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].
Bryskin & Berger [Page 67]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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].
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].
Bryskin & Berger [Page 68]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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.
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.
Bryskin & Berger [Page 69]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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).
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).
Bryskin & Berger [Page 70]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
3.5.30. 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.31. PcPolicyLocalPCDomainIDVariable
PcPolicyLocalPCDomainIDVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
integer value specifying a network unique ID of the local path
computation domain.
3.5.32. PcPolicySourcePCDomainIDVariable
PcPolicySourcePCDomainIDVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
unordered set of integer values, specifying network unique IDs of all
path computation domains, where the sources of the provisioned
service are located.
3.5.33. PcPolicyDestinationPCDomainIDVariable
PcPolicyDestinationPCDomainIDVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
unordered set of integer values, specifying network unique IDs of all
path computation domains, where the destinations of the provisioned
service are located.
3.5.34. PcPolicyTransitPCDomainIDVariable
PcPolicyTransitPCDomainIDVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
ordered set of integer values, specifying network unique IDs of all
path computation domains, the provisioned service paths are expected
to traverse.
Bryskin & Berger [Page 71]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
3.5.35. 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.
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).
Bryskin & Berger [Page 72]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
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. Formal PCPIM class definition
TBD in the next revision
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. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[PCE-POLICY] I. Bryskin, D. Papadimitriou, L. Berger,
"Policy-Enabled Path Computation Framework",
draft-ietf-pce-policy-enabled-path-comp-00.txt,
June 2006
[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.
6.2. Informative References
[RFC3198] Westerinen, A., et al., "Terminology for Policy-based
Management", RFC 3198, November 2001
Bryskin & Berger [Page 73]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
[RFC4655] A. Farrel, J.-P. Vasseur, J. Ash "A Path Computation
Element (PCE)-based Architecture", RFC 4655, August 2006
[PCEP] J.-P. Vasseur, Ed., "Path Computation Element (PCE)
communication Protocol PCEP) - Version 1",
draft-ietf-pce-pcep-02.txt, June 2006
[RFC4202] K. Kompella, Ed., Y. Rekhter, Ed. "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005
[RFC3471] L. Berger, Ed.," Generalized Multi-Protocol Label Switching
(GMPLS). Signaling Functional Description", RFC 3741,
January 2003
[RFC3209] Awduche, D., et al., "Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[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
7. Authors' Addresses
Igor Bryskin
Email: i_bryskin@yahoo.com
Lou Berger
LabN Consulting, L.L.C.
Email: lberger@labn.net
8. Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
Bryskin & Berger [Page 74]
Internet Draft draft-bryskin-pce-pcpim-00.txt October 2006
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
9. Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Bryskin & Berger [Page 75]
Generated on: Sun Oct 15 12:11:31 EDT 2006