Internet Draft Igor Bryskin
Category: Standards Track Lou Berger
Expiration Date: September 5, 2007
March 5, 2007
Path Computation Policy Information Model (PCPIM)
draft-bryskin-pce-pcpim-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 5, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The Policy-Enabled Path Computation Framework [PCE-POLICY] introduced
the use of the Policy Core Information Model (PCIM), [RFC3060], as a
framework for supporting path computation policy within the context
of the Path Computation Element (PCE)-Based Architecture, [RFC4655].
This document defines the Path Computation Policy Information Model
(PCPIM), which provides the specifics of using PCIM as the method for
supporting path computation policy. PCPIM includes classes that
model constraints, conditions, actions, variables and values
associated with supporting path computation policy. While PCPIM was
conceived to operate within the path computation element (PCE)-based
Bryskin & Berger Expires September 5, 2007 [Page 1]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
architecture, it can be applied to any path computation methodology.
Contents
1 Introduction ................................................ 3
1.1 PC Policy Definition ........................................ 4
1.2 Design Goals and Ramifications .............................. 6
1.3 Modeling of Abstract PC Policies ............................ 12
1.4 Rule Hierarchy .............................................. 14
1.5 Extensibility of the path computation process via PCPIM ..... 15
1.6 Requirements for PCC-PCE communication protocol ............. 16
1.7 Intended Audiences .......................................... 17
2 Class Hierarchies ........................................... 18
2.1 Inheritance Hierarchy ....................................... 18
2.2 Relationship Hierarchy ...................................... 24
3 PC Policies ................................................. 25
3.1 Modeling PC constraints ..................................... 25
3.2 Modeling PC capabilities .................................... 43
3.3 Modeling PC policy relationships ............................ 55
3.4 Modeling PC actions ......................................... 61
3.5 Modeling PC variables ....................................... 66
3.6 Modeling PC values .......................................... 73
4 PCPIM class definition ...................................... 74
5 Security Considerations ..................................... 74
6 IANA Considerations ......................................... 74
7 References .................................................. 74
7.1 Normative References ........................................ 74
7.2 Informative References ...................................... 75
8 Authors' Addresses .......................................... 76
9 Full Copyright Statement .................................... 76
10 Intellectual Property ....................................... 76
Bryskin & Berger Expires September 5, 2007 [Page 2]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1. Introduction
This document defines the Path Computation Policy Information Model,
or PCPIM. PCPIM identifies a framework and specific constructs for
specifying and representing policies for the path computation process
typically found with MPLS-TE and GMPLS LSPs, see [RFC3209] and
[RFC3473]. PCPIM is intended to be consistent with the policy-
enabled path computation framework defined in [PCE-POLICY]. PCPIM
was conceived to operate within the path computation element
(PCE)-based architecture, see [RFC4655], but can be applied to any
path computation methodology.
Consistent with [PCE-POLICY], PCPIM as defined in this document is
based on the IETF Policy Core Information Model, see [RFC3060], and
its extensions, see [RFC3460]. PCPIM builds upon these two documents
to define an information model for the path computation governed by
policy. This document also adopts the terminology for policy-based
management defined in [RFC3198].
The policies that can be represented in PCPIM are referred to in this
document as Path Computation (or PC) policies. The framework defined
by PCPIM consists of a set of classes and relationships that are
organized in an object-oriented information model. The definition is
independent of any specific Policy Decision Point (PDP) or Policy
Enforcement Point (PEP) implementation, see [RFC3198] for
definitions.
PCPIM is designed to represent PC policy information for policy
domains, see [RFC3198]. The goal of this information model is to
assist administrators in their definition of policies to control the
path computation process typically associated with MPLS and GMPLS LSP
establishment. The process of creating PCPIM class instances is fed
by business rules, network topology and PC methodology. Examples of
PC methodologies include centralized, distributed, remote PCE, and
local PCE.
It is important to note that PCPIM is independent of any particular
data storage mechanism and access protocol. This enables various
data models (e.g., directory schemata, relational database schemata,
and SNMP MIBs) to be designed and implemented according to a single
uniform model.
Bryskin & Berger Expires September 5, 2007 [Page 3]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
1.1. PC Policy Definition
Figure 1 shows a notional process for the definition of PC policy for
a policy domain. The figure illustrates information flow rather than
an actual procedure.
---------- ---------- -----------
| Business | | Topology | | PC |
| Policy | | | |Methodology|
---------- ---------- -----------
| | |
| | |
------------------------------------
|
V
---------------
| PCPIM/PCIM(e)|
| modeling |
---------------
|
------------- | --------------
| Service | |<----------| PCE info, |
| provisioning |---->| | capabilities |
| info } | --------------
------------- V
(---------------)
( PC action )---)
( (request/ ) )
( response ) )---)
( processing ) ) )
(---------------) ) )
(--------------) )
(-------------)
Figure 1: The PC definition information flow
The process of defining PC policy is dependent on three types of
information: the topology of network resources under management, the
particular type of PC methodology used and the business rules and
requirements for specifying service(s) delivered by the network. Both
topology and business rules are outside of the scope of PCPIM.
However, the important facets of both must be known and understood
for the PC policy to be correctly specified.
Typically the process of PC policy definition relies on one or more
PC methodologies. For example, the methodology of distributed path
computation using remote PCE(s), per [RFC4655], may be considered in
the PC policy definition process.
Bryskin & Berger Expires September 5, 2007 [Page 4]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
Network topology consists of an inventory of network resources that
make up a network. This inventory is usually automatically discovered
and distributed via a Control Plane or a Management Plane, and made
available to a network's path computation engines which perform the
actual path computation.
Business rules are informal sets of requirements for specifying the
behavior of various services that may be provisioned on a network.
Business rules directly or indirectly prescribe specific attributes
for the services such as cost, availability, resilience to failures,
end-to-end delay expectations and relative priority. This information
is required by the overall policy management system that uses PCPIM
rather than by PCPIM itself. PCPIM is used to map business rules
into semantics that control service related path computation, so that
paths computed for a specific service can be successfully provisioned
and will conform to a network's policy requirements and expectations.
Information related to topology, PC methodology and business rules
are necessary prerequisites for computing paths for services. PCPIM
enables a set of tools for specifying PC policy in a standard manner.
Using a standard PC policy information model such as PCPIM is needed
also because different network elements may have markedly different
path computation capabilities and levels of visibility into the
resources available within a network. Even the same type of equipment
can have different functionality depending on operating system and
software running in those devices. Therefore, a means is required to
specify PC functionality in a standard way that is independent of the
capabilities of different vendors' devices. This is the role of
PCPIM.
In a typical scenario, the administrator will first determine the
role(s) that each network element plays in the overall path
computation process. These roles define the path computation
functions supplied by a given network element independent of vendor
and element type. Examples of roles are: "Edge Path Computation
Client", "Intra-Area Path Computation Element" and "Inter-AS Path
Computation Element". For example, a network administrator may assign
an edge IP router or GMPLS enabled OADM using remote path computation
service a role of "Edge Path Computation Client". This enables the
administrator to design policies that define how to constrain and/or
optimize the path selection process for different types of services,
how to select a PCE that can honor the specified constraints and
objective functions, what to do if path computation fails (e.g. relax
some of constraints, or send the request to another PCE) independent
of the actual devices themselves. PCPIM supports the concept of
roles based on [RFC3060] and [RFC3460] definition of role. PCPIM
uses roles to help the administrator map a given set of network
elements to a given set of PC policy constructs.
Bryskin & Berger Expires September 5, 2007 [Page 5]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
Within PCPIM, PC policy constructs define the functionality required
to perform desired path computation. The functions themselves depend
on the particular type of PC methodology chosen. For example, the
outcome of applying policies on an edge IP router in case of the
centralized path computation using a remote PCE is the contents of
the path computation request sent to the PCE, while in case of the
distributed path computation using local path computation engines the
outcome is a particular call to the local engine.
PCPIM class definitions are used to create instances of various
policy constructs, such as PC constraints, in a form of policy rules
that may be hierarchically organized in a higher level rules and
groups. Again, [RFC3060] and [RFC3460] serve as the foundation for
these definitions, see [RFC3060] and [RFC3460] for definitions of
PolicyGroup and PolicyRule classes.
A hierarchical organization was chosen because it tends to reflect
the way humans tend to think about complex policy. It is important to
note that the described policy definition process is done
independently of any specific device capabilities and configuration
options. The policy definition is completely independent from details
of implementation and configuration interface of individual network
elements, as well as of the mechanisms that a network element may
participate in the path selection process.
1.2. Design Goals and Ramifications
This section explains PCPIM major design goals and how these goals
are addressed. This section also describes some of the ramifications
of the design goals and the design decisions made in developing
PCPIM.
1.2.1. Policy definition oriented
The primary design goal of PCPIM is to model policies controlling the
path selection process in a way that, as closely as possible,
reflects the way humans tend to think about policy. Therefore, PCPIM
is designed to address the needs of policy definition and management,
and not device or network configuration.
There are several significant ramifications of this design goal.
First, PCPIM uses rules to define policies based on [RFC3060] and
[RFC3460]. Second, PCPIM uses hierarchical organizations of policies
and policy information extensively. Third, PCPIM does not force the
policy writer to specify all implementation details; rather, it
assumes that configuration agents, i.e. PEPs, interpret the policies
Bryskin & Berger Expires September 5, 2007 [Page 6]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
and match them to suit the needs of device-specific configurations.
1.2.1.1. Rule-based modeling
PCPIM describes PC policy using rule-based modeling as introduced in
[RFC3060] and [RFC3460]. A PC policy rule is structured as a
condition clause and an action clause. The semantics are simple: if
the condition clause evaluates to TRUE then a set of actions, as
specified in the action clause, can be executed. For example, the
rule:
If bandwidth requirement is specified in the service provisioning
message, then restrict the path selection to TE links advertising
unreserved bandwidth to no less than the specified value.
Could be formalized as:
<If provBandwidth != 0 > then
<require minimum BW = provBandwidth>"
Where the first angle bracketed clause is a policy condition, and the
second angle bracketed clause is a policy action.
Note that the approach taken in PCPIM specifically does not define
subclasses for the PolicyCondition class, and it uses subclasses of
the PolicyAction class in a limited way. Rather, PCPIM relies
predominantly on use of the SimplePolicyCondition,
CompoundPolicyCondition, SimplePolicyAction, and CompoundPolicyAction
classes defined in [RFC3460]. This approach enables PCPIM to be
easily extended. New path computation capabilities may be introduced
without modifications of PCC - PCE communication, PCE discovery
protocols or PDP/PEP/network element software (apart, of course, from
the network elements (PCEs) actually implementing the new
capabilities).
1.2.1.2. Hierarchical organization of information
The organization of the information represented by PCPIM is designed
to be hierarchical. PCPIM utilizes the PolicySetComponent aggregation
class, see [RFC3460], to provide an arbitrarily nested organization
of policy information. A policy group provides a construct that
represents policy rules and policy groups. A policy rule can also
contain other policy rules and groups, thus enabling a rule/sub-rule
relationship.
The hierarchical design approach is based on the observation that it
Bryskin & Berger Expires September 5, 2007 [Page 7]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
is natural to organize policy rules in groups. Breaking down a
complex policy into a set of simple rules is a process that follows
the way many people tend to think and analyze systems. The
complexity of the abstract business-oriented policy is simplified and
translated into a hierarchy of simple rules and grouping of simple
rules.
1.2.1.3. Goal-oriented policy definition
PCPIM facilitates goal-oriented PC policy definition. This means
that the process of defining PC policies is focused on the desired
effect of policies, as opposed to the means of implementing the
policy on network elements.
PCPIM is intended to define a minimal specification of desired
network behavior. It is the role of device-specific configuration
agents, i.e., PEPs, to interpret policy expressed in a standard way
and fill in the necessary configuration details. This helps ensure a
common interpretation of the general policy as well as aid the
administrator in specifying a common policy to be implemented by
different devices. This is analogous to the fundamental object-
oriented paradigm of separating specification from implementation.
With the help of PCPIM the path computation process can be specified
in a general manner that can facilitate different implementations to
satisfy a common goal. For example, a valid policy may include only a
single rule that specifies that path selection must be limited to TE
links with particular link protection capabilities. The rule does not
need to include any of the various other details that may be needed
for issuing a particular call to a local path computation engine or
sending a request to a remote PCE.
It is assumed that PEPs will fill in the device-specific details.
The policy writer needs only to specify the main goal of the policy,
making sure that the preferred path computation engine receives a
properly constructed path computation request, so that the produced
paths will be sufficiently detailed and include links best suiting
the path(s) for the service in question.
1.2.2. Policy domain model
An important design goal of PCPIM is to allow for policies that span
numerous network elements. This goal differentiates PCPIM from
device-level information models which are designed for modeling
policy that controls a single network element.
Bryskin & Berger Expires September 5, 2007 [Page 8]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
This design goal has several ramifications. First, roles may be used
to define policies across multiple network elements. Second, the use
of abstract policies frees the policy definition process from having
to deal with individual network element peculiarities, and leaves
interpretation and configuration to be modeled by PEPs. Third, the
PCPIM allows extensive reuse of all policy building blocks in
multiple rules and groups of rules used within different network
elements.
1.2.2.1. Model PC policy in a device- and vendor-independent manner
PCPIM models PC policy in a way designed to be independent of any
particular device or vendor. This enables to control the path
computation process on networks made up of different network elements
that (with respect to the path computation) have different
capabilities using a single set of policies. This is important,
because, otherwise, the policy will itself reflect and depend upon
the differences between different implementations.
1.2.2.2. Use roles for mapping policy to network elements
The use of roles enables a policy definition to be targeted to the
network function of a network element, rather, than to the element's
type and capabilities. The use of roles for mapping policy to network
elements provides an efficient and simple method for compact and
abstract policy definition. A given abstract policy may be mapped to
a group of network elements (for example, set of edge IP routers)
without the need to specify configuration for each of these elements
based on the capabilities of any one individual element.
1.2.2.3. Reuse
Reusable objects as defined by [RFC3060] and [RFC3460] enable sharing
policy building blocks, thus allowing central management of global
concepts. PCPIM provides the ability to reuse all policy building
blocks: variables and values, conditions and actions, policy rules
and policy groups. This provides the required flexibility to manage
large sets of policy rules over large policy domains.
For example, the following rule makes use of centrally defined
objects being reused (referenced):
If <SourceAddress == DomainA>
then <RecoveryPathDisjoitedness = SRLGDisjoint>
Bryskin & Berger Expires September 5, 2007 [Page 9]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
In this rule the condition refers to an object named DomainA, which
is a value (or possibly a set of values) defined and maintained in a
reusable object container. The rule action makes use of a value named
SRLGDisjoint, which is also a reusable object. The advantage of
specifying a policy in this way is its inherent flexibility. For
example, when business needs require a change in the domain
definition for the organization, all that needed is to change the
reusable value DomainA centrally. All referencing rules are
immediately affected without the need to modify them individually.
Without this capability the repository that is used to store the
rules would have to be searched for all rules that refer to the
domain DomainA, and then each matching rule's condition would have to
be individually updated. Such an approach would be much less
efficient and would be more error prone.
For a complete description of reusable objects, refer to [RFC3060]
and [RFC3460].
1.2.3. Enforceable Policy
Policy defined by PCPIM is assumed to be enforceable. This means
that a PDP and a PEP can use PCPIM's policy definition in order to
make the necessary decisions and enforce the required policy rules.
For example, a policy related to the selection of the remote PCE for
a given path computation request could be made based entirely on the
policy definitions specified by PCPIM.
A PDP, associated with a given PCE or PCC, should be capable of
extracting all policies written for each of the PCE's or PCC's roles
and delivering them to the PCE's or PCC's PEP, which, it turn, should
be able to map the policies into sets of PCE's or PCC's configuration
commands, so that the desired behavior will be achieved.
As previously mentioned, PCPIM is designed to be independent of any
particular vendor-dependent technology. However, PCPIM's constructs
should always be interpreted so that policy-compliant behavior can be
enforced on the network under management. Therefore, there are three
fundamental requirements that PCPIM must satisfy:
1. Policy specified by PCPIM must be able to be mapped to
sets of configuration instructions specific to network
elements where the policy is intended to be applied.
2. Policy specified by PCPIM must be able to be enforced
on the network elements, meaning that expected behavior of
network elements must be achievable solely by applying the
policy.
Bryskin & Berger Expires September 5, 2007 [Page 10]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
3. Policy specified by PCPIM must be able to control path
computation functions without making reference to a
specific type of network element or vendor.
PCPIM satisfies requirements (1) and (2) above by using the concept
of roles. Specifically, through the PolicyRoles property defined in
[RFC3060] and further refined in [RFC3460]. By matching roles
assigned to policy groups and to network elements, a PDP can
determine what policy should be applied to a given network element or
group of network elements.
The use of roles in mapping policy to network elements supports model
scalability. PCPIM policy can be mapped to large-scale policy
domains by assigning a single role to a group of network elements.
This can be done even when the policy domain contains heterogeneous
devices. So, a small set of policies can be deployed to large
networks without having to re-specify the policy for each device
separately. This PCPIM property is important for PC policy
management applications that strive to ease the task of policy
definition for large policy domains.
Requirement (2) is also satisfied by making PCPIM domain-oriented,
see [RFC3198] for the definition of "domain". In other words, the
target of the policy is a domain as opposed to a specific network
element.
Requirement (3) is satisfied by modeling PC actions that are commonly
configured on various PCCs and PCEs. Additionally, PCPIM is
extensible to allow for modeling of actions that are not included yet
into the PCPIM.
It is important to note that different PEPs will have different
capabilities and functions. This necessitates different individual
configurations, even if the different PEPs are controlled by the same
policy.
1.2.4. PCPIM and path computation methodologies
PCPIM is independent of the PC methodology used on the network. This
means that on any given network element the same PC Policy actions
can be translated into different sets of operations, depending on the
PC methodology used in the network. For example, the PC Policy action
"Request Path Computation", when applied on PCC using remote path
computation service, will cause the PCC to send a request to a remote
PCE (e.g. via the protocol defined in [PCEP]). On the other hand, the
same PC Policy action applied on a IP router using a local path
computation engine will cause the router to call the engine. Such
Bryskin & Berger Expires September 5, 2007 [Page 11]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
independence is important, because it allows introduction of new
methodologies without (re-)writing the policies governing a path
computation.
1.3. Modeling of Abstract PC Policies
As previously mentioned, the main goal of PCPIM is to create an
information model that can be used to help bridge the conceptual gap
between a human policy maker and a network element that is capable to
enforce the policy. Clearly this wide gap implies several translation
levels from the abstract to the concrete. At the abstract end are the
business path computation considerations and rules. Once the business
rules are known, a network administrator must interpret them as
network PC policy and represent this PC policy using PCPIM
constructs. PCPIM facilitates a formal representation of PC rules,
thus, providing the first concentration level.
When a human business executive defines network policy, it is usually
done using informal business terms and language. For example, a
human may define a policy of:
Service A must be available 99.999% through its lifetime.
In the context of path computation the statement above could be
translated into the following policy:
Service A must have an end-to-end backup path which is
sufficiently disjoint from its primary path to guarantee that a
single network failure will not make both paths simultaneously
unusable for the service.
While this statement clearly defines a PC policy at the business
level, it isn't specific enough to be enforceable by a network
element (i.e. for the service ingress GMPLS LSR responsible for the
path computation for the service).
On the other end of the scale, a network element functioning as a PEP
(e.g. GMPLS LSR) can be configured with specific commands which
determine a particular set of parameters (e.g. path computation
constraints) that could control the path selection for the service in
such a way that the goal expressed in the informal statement could be
achieved. The element-specific configuration command on a PEP
controlling a PCC could read:
For service A, require that a remote PCE provide an end-to-end
backup path and that the primary and backup path be link-disjoint.
Bryskin & Berger Expires September 5, 2007 [Page 12]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
On a different network element on the same network the same policy
may take different element specific form, in spite of the element
playing the same role in the path computation process. This is may be
due to the second network element being from a different vendor than
the first, or that the second has a different set of functions (and
hence implementation) even though it is from the same vendor.
The "human" policy mentioned above is an example of an "abstract
policy", while the "path computation" policy illustrates a "concrete
configuration". Furthermore, the first statement illustrates an end-
to-end policy that covers all necessary path computations for the
service which could include several requested by several PCCs and
performed by several PCEs. The second statement illustrates
configuration for a particular PEP or a set thereof.
The translation process from abstract business policy to concrete PEP
configuration can be expressed as follows:
1. Informal business PC policy is expressed by a human policy
maker.
2. A network administrator analyzes the policy domain's topology
and determines the roles of particular network elements. A
role may be assigned to a large group of elements, which will
result in mapping a particular policy to a large group of
elements.
3. The network administrator models the informal policy using the
PCPIM constructs, thus creating a formal representation of the
abstract policy. The administrator places these models in a
Policy Repository that is accessible to PDPs in the network.
4. The network administrator assigns roles to the policy groups
created in the previous step, matching the network elements'
roles assigned in step (2) above, and then places the roles
in the Policy Repository.
5. A PDP extracts the abstract policies from the Policy Repository
and delivers them to PEPs associated with the elements that are
assigned roles matching the policies and roles.
6. The PEPs apply and enforce the polices by translating them into
sets of network element-specific configuration instructions.
PCPIM (with PCIM and PCIMe) are used in steps (3) and (4) above.
Bryskin & Berger Expires September 5, 2007 [Page 13]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
1.4. Rule Hierarchy
As with [RFC3060] and [RFC3460], PCPIM policy is described by a set
of policy rules that may be grouped together. Policy rules and policy
groups can be nested within other policy rules, providing a
hierarchical policy definition. Nested rules are also called sub-
rules, and we use both terms in this document interchangeably. The
aggregation PolicySetComponent class, as defined in [RFC3460], is
used to represent the nesting of a policy rule or group in another
policy rule or group.
The hierarchical policy rule definition enhances policy readability
and reuse. Within the PC policy information model, hierarchy is used
to model context or scope for the sub-rule actions.
Consider the following example, where the informal policy reads:
In a WDM service, path computation requires a wavelength
continuity constraint within each transparent segment of the
service; for such path computation also constrain the OSNR to be
no less than K at each point of optical signal regeneration and at
the service end-points
In this context, the wavelength continuity constraint means the
requirement to select WDM links that have at least one lambda channel
with the same wavelength available on all links selected for the path
segment. The wavelength continuity constraint is necessary due to
inability of transparent optical switches to perform the wavelength
conversion.
OSNR, or Optical Signal To Noise Ratio, is a characteristic that
defines the optical signal quality. It has a lower bound, meaning
that the characteristic needs to be no lower than a certain value at
the points of the signal regeneration and at the service end-points
for the signal to be usable.
This policy could be modeled by PCPIM using the following rules:
IF (Service Switching Type == LAMBDA && Service Data Type == LAMBDA)
THEN (Set WavelengthContinuityConstraint = TRUE)
IF (Service Switching Type == LAMBDA && Service Data Type == LAMBDA)
THEN (Set MinimalOSNR = MINIMAL_OSNR)
Assume that these two rules are grouped within a reusable group named
SetOpticalConstraints. Than the policy above could be expressed as
follows:
IF (Service Switching Type == LAMBDA && Service Data Type == LAMBDA)
Bryskin & Berger Expires September 5, 2007 [Page 14]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
THEN (SetOpticalConstraints)
This results in a more readable policy. Additionally, and more
importantly, policy nesting facilitates future modification of
optical constraints (e.g.adding maximum allowable Polarization Mode
Dispersion, PMD). In the case where a modification is needed, all
that would need to be done is to modify the SetOpticalConstraints
policy group, rather, than modifying all policies that use the group.
1.5. Extensibility of the path computation process via PCPIM
Traditionally, a path computation entity was integrated with an LSR's
control plane and always co-located with the LSR's signaling and
routing subsystems. This architectural approach allowed for unlimited
flexibility in providing various path computation enhancements. For
example, adding new types of constraints and their relaxation
strategies, adopting new objective functions and optimization
criteria. With this approach, all that had to be done to support a
PC related enhancement was to upgrade the control plane software of a
particular LSR (and no other LSRs or any other network elements).
This model doesn't hold for the PCE architecture, [RFC4655]. When
the PCE architecture is used, the introduction of new PCE
capabilities is more complicated and more than a single element's
software must be modified to introduce new PC capabilites. In order
to take advantage of a new PCE capability, new PCEP, advertising and
signaling objects may be needed, all PCCs may need to be upgraded,
and new interoperability problems may need to be resolved.
Within the context of the PCE architecture it is therefore highly
desirable to find a way to introduce new path computation
capabilities without requiring modifications of either the
discovery/communication protocols or PCC software. One way to achieve
this objective is to model path selection constraints, their
relaxations and objective functions as path computation request
specific policies using PCPIM. Within PCPIM such policies may be
modeled via policy rules with:
- condition clauses made up entirely of a combination of instances
of the SimplePolicyCondition class and/or instances of the
CompoundPolicyCondition class, see [RFC3460], aggregating
instances of the SimplePolicyCondition class.
- action clauses made up entirely of a combination of instances
of the SimplePolicyAction class and/or instances of the
CompoundPolicyAction class, see [RFC3460], aggregating instances
of the SimplePolicyAction class.
Bryskin & Berger Expires September 5, 2007 [Page 15]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
Such an approach makes policy rule engines running on the PEPs
insensitive to the semantics of the policies describing PC
constraints and capabilities. Hence the only PC component that needs
to understand such semantics is the PCE advertising the capabilities
and actually using the constraints in the path selection. Under these
circumstances PCCs can select a PCE that suits the best a given path
computation request, as well as require necessary constraints without
actually understanding what these capabilities or constraints mean.
The SimplePolicyCondition, SimplePolicyAction,
CompoundPolicyCondition and CompoundPolicyAction classes are defined
[RFC3460]
There are a number of advantages and useful by-products of such an
approach:
- New path computation capabilities may be introduced without
changing PCC-PCE communication and discovery protocols or PCC
software.
- Existing constraints, objective functions and their relaxations
may be aggregated and, otherwise, associated together, thus
producing new more complex ones that do not require change of
code even on PCEs supporting them.
- Different elements such as conditions, actions and variables
may be re-used by multiple constraints, diversities and
optimizations.
- PCCs and PCEs need to handle other (that is, not request
specific) policies. (For example, a policy instructing the PCE
whether to accept or reject a path computation request issued by
a PCC.) Path computation related policies of all types can be
modeled by PCPIM, placed within the same policy
repositories, can be managed by the same policy management tools
and can be interpreted using the same mechanisms.
1.6. Requirements for PCC-PCE communication protocol
When remote path computation service is used, peer PCC and PCE will
communicate via some request-response communication protocol. The
protocol is expected to provide the following minimal capabilities:
For the PCC to signal in a path computation request:
- One or more service source addresses.
- One or more service destination addresses or point-to-multipoint
Bryskin & Berger Expires September 5, 2007 [Page 16]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
service IDs.
- The number of paths/trees connecting set of sources to set of
destinations to be computed.
- Zero or more opaque objects carrying instances of PCPIM classes
that model path computation policies (e.g. policy variables,
values, constraints, objective functions, and their relaxations)
pertinent to the request.
For the PCE to signal in a path computation response:
- Status/completion code of the path computation request.
- One or more computed paths/trees.
- Zero or more opaque objects carrying instances of PCPIM classes
that model path computation policies pertinent to the response
(e.g. constraints that needed to be relaxed and path/tree costs.)
The communication protocol introduced in [PCEP] provides such
capabilities.
1.7. Intended Audiences
PCPIM is intended for several audiences. The following lists some of
the possible audiences and their respective uses:
1. Developers of PC policy management applications can use this
model as an extensible framework for defining policies to
control PEPs and PDPs in an interoperable manner.
2. Developers of PDPs and PEPs designed to control the path
computation process.
3. Builders of large organization data and knowledge bases who
define ways to combine PC policy information with other
networking policy information (for example, service recovery
policy), assuming all modeling is based on sub-classes of
[RFC3060] and [RFC3460].
4. Authors of various standards may use constructs introduced in
this document to enhance their work. Authors of data models
wishing to map a storage specific technology to PCPIM must
use this document as well.
Bryskin & Berger Expires September 5, 2007 [Page 17]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
2. Class Hierarchies
PCPIM's class and association inheritance hierarchies are rooted in
[RFC3060] and [RFC3460]. This section provides figures that
represent these PCPIM inheritance hierarchies, while noting their
relationships to [RFC3060] and[RFC3460] classes. Note that many
other classes used to form PCPIM policies (for example, the
SimplePolicyCondition class) are defined in [RFC3060] and [RFC3460].
Thus the figures in this section do not represent all necessary
classes and relationships for defining PCPIM policies. Rather, the
designer using PCPIM should use appropriate classes and relationships
from [RFC3060] and [RFC3460] in conjunction with those defined below.
2.1. Inheritance Hierarchy
Figure 2 shows the PCPIM inheritance hierarchy.
ManagedElement (abstract, PCIM)
|
+--Policy (abstract, PCIM)
| |
| +---PolicyAction (abstract, PCIM)
| | |
| | +---PcPolicyAction (abstract, PCPIM)
| | | |
| | | +--- PcPolicyActionRequestPathComputation (PCPIM)
| | | |
| | | +--- PcPolicyActionSendPathComputationResponse
| | | | (PCPIM)
| | | |
| | | +--- PcPolicyActionProcessPathComputationResponse
| | | (PCPIM)
| | +--- PcPolicyActionEvaluatePCE (PCPIM)
| |
| +---PolicySet (abstract, PCIMe)
| | |
| | +---PolicyRule (abstract, PCIM/PCIMe)
| | | |
| | | +---PcPolicyPcReqRspComponent(PCPIM, abstract)
| | | | |
| | | | +--- PcPolicyBandwidthConstraint(PCPIM)
| | | | |
| | | | +--- PcPolicyAffinityConstraint (PCPIM)
| | | | |
| | | | +--- PcPolicyLinkProtectionConstraint PCPIM)
| | | | |
| | | | +--- PcPolicyLinkSwitchCapConstraint(PCPIM)
Bryskin & Berger Expires September 5, 2007 [Page 18]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
| | | | |
| | | | +--- PcPolicyPathElement (PCPIM, abstract)
| | | | | |
| | | | | +--- PcPolicyExcludeLinkConstraint (PCPIM)
| | | | | |
| | | | | +--- PcPolicyExcludeNodeConstraint (PCPIM)
| | | | | |
| | | | | +--- PcPolicySharedLinkConstraint (PCPIM)
| | | | | |
| | | | | +--- PcPolicyIncludePathElement (PCPIM,
| | | | | | abstract)
| | | | | |
| | | | | +--- PcPolicyIncludeLinkConstraint
| | | | | | (PCPIM)
| | | | | |
| | | | | +--- PcPolicyIncludeNodeConstraint
| | | | | (PCPIM)
| | | | |
| | | | +--- PcPolicyStrictPathsConstraint (PCPIM)
| | | | |
| | | | +--- PcPolicySecondaryPathRequest (PCPIM)
| | | | |
| | | | +--- PcPolicySecondaryPathDisjoitedness (PCPIM)
| | | | |
| | | | +--- PcPolicyShortestPathObjectiveFunction
| | | | | (PCPIM)
| | | | |
| | | | +--- PcPolicyMinimalE2EDelayObjectiveFunction
| | | | | (PCPIM)
| | | | |
| | | | +--- PcPolicyShortestPathUpperBoundConstraint
| | | | | (PCPIM)
| | | | |
| | | | +--- PcPolicyE2EDelayUpperBoundConstraint (PCPIM)
| | | | |
| | | | +--- PcPolicyGMPLSWavelengthContinuityConstraint
| | | | | (PCPIM)
| | | | |
| | | | +--- PcPolicyGMPLSMaximalOSNRObjectiveFunction
| | | | | (PCPIM)
| | | | +--- PcPolicyGMPLSMinimalDispersion
| | | | | ObjectiveFunction (PCPIM)
| | | | |
| | | | +--- PcPolicyGMPLSMinimalAttenuation
| | | | | ObjectiveFunction (PCPIM)
| | | | |
| | | | +--- PcPolicyGMPLSMinimalRegeneration
| | | | | ObjectiveFunction (PCPIM)
Bryskin & Berger Expires September 5, 2007 [Page 19]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
| | | | |
| | | | +--- PcPolicyGMPLSOSNRLowerBoundConstraint
| | | | | (PCPIM)
| | | | |
| | | | +--- PcPolicyGMPLSDispersionUpperBoundConstraint
| | | | | (PCPIM)
| | | | |
| | | | +--- PcPolicyGMPLSAttenuationUpperBoundConstraint
| | | | | (PCPIM)
| | | | |
| | | | +--- PcPolicyGMPLSRegenerationUpperBound
| | | | | Constraint (PCPIM)
| | | | |
| | | | +--- PcPolicyGMPLSTransparentPathUpperBound
| | | | | Constraint (PCPIM)
| | | | |
| | | | +--- PcPolicyReturnPathCost (PCPIM)
| | | | |
| | | | +--- PcPolicyReturnPathE2EDelay (PCPIM)
| | | | |
| | | | +--- .... (to be extended)
| | | |
| | | +--- PcPolicyPcCapabilityComponent (PCPIM, abstract)
| | | | |
| | | | +--- PcPolicyPCELocation (PCPIM)
| | | | |
| | | | +--- PcPolicyPCEAdminPriority (PCPIM)
| | | | |
| | | | +--- PcPolicyTEVisibilityDomains (PCPIM)
| | | | |
| | | | +--- PcPolicyDestinationDomains (PCPIM)
| | | | |
| | | | +--- PcPolicyInterDomainCapability (PCPIM)
| | | | |
| | | | +--- PcPolicyRequestPrioritizationSupport (PCPIM)
| | | | |
| | | | +--- PcPolicyLinkBanwidthConstraintSupport
| | | | | (PCPIM)
| | | | |
| | | | |
| | | | +--- PcPolicyLinkAffinitiesConstraintSupport
| | | | | (PCPIM)
| | | | |
| | | | +--- PcPolicyLinkProtectionConstraintSupport
| | | | | (PCPIM)
| | | | |
| | | | +--- PcPolicyLinkSwitchCapConstraintSupport
| | | | | (PCPIM)
Bryskin & Berger Expires September 5, 2007 [Page 20]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
| | | | |
| | | | +--- PcPolicyExclusionConstraintSupport (PCPIM)
| | | | |
| | | | +--- PcPolicySharedLinkConstraintSupport (PCPIM)
| | | | |
| | | | +--- PcPolicyInclusionConstraintSupport (PCPIM)
| | | | |
| | | | +--- PcPolicyConcurrentPathComputationCapability
| | | | | (PCPIM)
| | | | |
| | | | +--- PcPolicyShortestPathObjectiveSupport (PCPIM)
| | | | |
| | | | +--- PcPolicyCostUpperBoundConstraint
| | | | | Support (PCPIM)
| | | | |
| | | | +--- PcPolicyE2EDelayObjectiveSupport (PCPIM)
| | | | |
| | | | +--- PcPolicyE2EDelayUpperBoundConstraintSupport
| | | | | (PCPIM)
| | | | |
| | | | +--PcPolicyGMPLSWavelengthContinuity
| | | | | ConstraintSupport (PCPIM)
| | | | |
| | | | +--- PcPolicyGMPLSOSNRObjectiveSupport (PCPIM)
| | | | |
| | | | +--- PcPolicyGMPLSDispersionObjectiveSupport
| | | | | (PCPIM)
| | | | |
| | | | +--- PcPolicyGMPLSAttenuationObjectiveSupport
| | | | | (PCPIM)
| | | | |
| | | | +---PcPolicyGMPLSMinimalRegenerations
| | | | | ObjectiveFunction (PCPIM)
| | | | |
| | | | +--- PcPolicyGMPLSOSNRLowerBound
| | | | | ConstraintSupport (PCPIM)
| | | | |
| | | | +-- PcPolicyGMPLSDispersionUpperBound
| | | | | ConstraintSupport (PCPIM)
| | | | |
| | | | +--PcPolicyGMPLSAttenuationUpperBound
| | | | | ConstraintSupport (PCPIM)
| | | | |
| | | | +--PolicyGMPLSRegenerationsUpperBound
| | | | | ConstraintSupport (PCPIM)
| | | | |
| | | | +-- PcPolicyGMPLSTransparentPathUpper
| | | | | BoundConstraintSupport (PCPIM)
Bryskin & Berger Expires September 5, 2007 [Page 21]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
| | | | |
| | | | +---PcPolicyGMPLSMinimalRegenerations
| | | | | ObjectiveFunction (PCPIM)
| | | | |
| | | | +---PcPolicyGMPLSMinimalRegenerations
| | | | | ObjectiveFunction (PCPIM)
| | | | |
| | | | +--- .... (to be extended)
| | |
| | +---PolicyGroup (abstract, PCIM/PCIMe)
| | | |
| | | +--- PcPolicyPcReqRspSet (PCPIM)
| | | |
| | | +--- PcPolicyPcCapabilitySet (PCPIM)
| |
| +---PolicyVariable (abstract, PCIMe)
| | |
| | +---PolicyImplicitVariable (abstract, PCIMe)
| | |
| | +--- PcPolicyServiceSourceIPv4Variable (PCPIM)
| | |
| | +--- PcPolicyServiceSourceIPv6Variable (PCPIM)
| | |
| | +--- PcPolicyServiceDestinationIPv4Variable (PCPIM)
| | |
| | +--- PcPolicyServiceDestinationIPv6Variable (PCPIM)
| | |
| | +--- PcPolicyServiceMcstGroupIDVariable (PCPIM)
| | |
| | +--- PcPolicyServiceEncodingTypeVariable (PCPIM)
| | |
| | +--- PcPolicyServiceSwitchingTypeVariable (PCPIM)
| | |
| | +--- PcPolicyServiceGPIDVariable (PCPIM)
| | |
| | +--- PcPolicyServiceBandwidthVariable (PCPIM)
| | |
| | +--- PcPolicyServiceBandwidthDirectionalityVariable
| | | (PCPIM)
| | +--- PcPolicyServiceBandwidthPriorityVariable (PCPIM)
| | |
| | +--- PcPolicyServicePathRecoveryFlagsVariable (PCPIM)
| | |
| | +--- PcPolicyServiceLinkProtectionFlagsVariable (PCPIM)
| | |
| | +--- PcPolicyServiceSessionNameVariable (PCPIM)
| | |
| | +--- PcPolicyServiceIncludeAnyVariable (PCPIM)
Bryskin & Berger Expires September 5, 2007 [Page 22]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
| | |
| | +--- PcPolicyServiceExcludeAnyVariable (PCPIM)
| | |
| | +--- PcPolicyServiceIncludeAllVariable (PCPIM)
| | |
| | +--- PcPolicyServiceEROVariable (PCPIM)
| | |
| | +--- PcPolicyServiceRROVariable (PCPIM)
| | |
| | +--- PcPolicyServiceReferencePointIDVariable (PCPIM)
| | |
| | +--- PcPolicyUserIDVariable (PCPIM)
| | |
| | +--- PcPolicyServiceQOSVariable (PCPIM)
| | |
| | +--- PcPolicyServiceCOSVariable (PCPIM)
| | |
| | +--- PcPolicyServiceAvailabilityVariable (PCPIM)
| | |
| | +--- PcPolicyLocalPCCIDVariable (PCPIM)
| | |
| | +--- PcPolicyLocalPCEIDVariable (PCPIM)
| | |
| | +--- PcPolicyPeerPCEIDVariable (PCPIM)
| | |
| | +--- PcPolicyPeerPCEMetricVariable (PCPIM)
| | |
| | +--- PcPolicyEvaluatedPCEIDVariable (PCPIM)
| | |
| | +--- PcPolicyEvaluatedPCEMetricVariable (PCPIM)
| | |
| | +--- PcPolicyPeerPCCIDVariable (PCPIM)
| | |
| | +--- PcPolicyLocalPCDomainIDVariable (PCPIM)
| | |
| | +--- PcPolicySourcePCDomainIDVariable (PCPIM)
| | |
| | +--- PcPolicyDestinationPCDomainIDVariable (PCPIM)
| | |
| | +--- PcPolicyTransitPCDomainIDVariable (PCPIM)
| | |
| | +--- PcPolicyPcRequestResponseCodeVariable (PCPIM)
| | |
| | +--- .... (may be extended)
| |
| +---PolicyValue (abstract, PCIMe)
| | |
| | +--- PCPolicyFPValue (PCPIM)
Bryskin & Berger Expires September 5, 2007 [Page 23]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
| | |
| | +--- PCPolicyUnnumLinkIDValue (PCPIM)
| | |
| | +--- PCPolicyROElementValue (PCPIM)
| | |
| | +--- PCPolicyROValue (PCPIM)
| | |
| | +--- .... (may be extended)
Figure 2. PCPIM Class Inheritance Hierarchy
2.2. Relationship Hierarchy
Figure 3 shows the PCPIM relationship hierarchy.
[unrooted] (abstract, PCIM)
|
+---Dependency (abstract)
| |
| +--- PcPolicyPcReqRspComponentInPcReqRspSet (PCPIM)
| |
| +--- PcPolicyPcReqRspSetInPcReqRspSet (PCPIM)
| |
| +--- PcPolicyPcCapabilityComponentInPcCapabilitySet (PCPIM)
| |
| +--- PcPolicyPcCapabilitySetInPcCapabilitySet (PCPIM)
| |
| +--- PcPolicyPcReqRspComponentInPcSecondaryPathRequest
| | (PCPIM)
| |
| +--- PcPolicyPcReqRspSetInPcPolicyAction (PCPIM)
| |
| +--- PolicyImplicitVariableInPcPolicyAction (PCPIM)
| |
| +--- PcPolicyPcCapabilitySetInPcPolicyActionEvaluatePCE
| | (PCPIM)
Figure 3. PCPIM Association Class Inheritance Hierarchy
Bryskin & Berger Expires September 5, 2007 [Page 24]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
3. PC Policies
This section describes PC policies that are modeled by PCPIM. PC
policies are policy related network behaviors that are specific to
the path computation. Examples of PC policies are "Set path
computation constraint" , "Evaluate a PCE for a path computation
request", "Request path computation", "Send response to path
computation request" and "Process path computation response". PC
policies are modeled using the class hierarchies introduced in
[RFC3060] and [RFC3460] as well as the PCPIM classes introduced in
this document. PCPIM classes are sub-classes of [RFC3060]/[RFC3460]
classes.
3.1. Modeling PC constraints
A PC constraint is modeled based on the PcPolicyPcReqRspComponent
abstract class introduced in this document.
Bryskin & Berger Expires September 5, 2007 [Page 25]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
+-----------------------+ +-------------------------+
| SimplePolicyCondition | | CompoundPolicyCondition |
| class instances | | class instances |
| (PCIMe) | | (PCIMe) |
+-----------------------+ +-------------------------+
* PolicyConditionInPolicyRule *
* class instances *
* (PCIM) *
*******************************
*
*
+--------------------------------+
| PcPolicyPcReqRspComponent |
| sub-class instance |
| (PCPIM) |
+--------------------------------+
#
#
###############################
# PolicyActionInPolicyRule #
# class instances #
# (PCIM) #
+-----------------------+ +-------------------------+
| SimplePolicyAction | | CompoundPolicyAction |
| class instances | | class instances |
| (PCIMe) | | (PCIMe) |
+-----------------------+ +-------------------------+
Figure 4. Modeling PC Constraint
The abstract class is derived from the PolicyRule class introduced in
[RFC3060]. The rules of using the PolicyRule class, and its sub-
classes, require that for each instance of PolicyRule class and sub-
class:
- There should be one or more instances of PolicyCondition
classes or sub-classes associated with the PolicyRule class
or sub-class instance in question via separate instances of
the PolicyConditionInPolicyRule class or sub-class;
and
- there should be one or more instances of PolicyAction
classes or sub-classes associated with the PolicyRule class
or sub-class instance in question via separate instance of
the PolicyActionInPolicyRule class or sub-class.
The approach taken in PCPIM with respect to the use of sub-classes of
Bryskin & Berger Expires September 5, 2007 [Page 26]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
the PcPolicyPcReqRspComponent class is to limit:
- the conditions that can be associated with an instance of
PcPolicyPcReqRspComponent sub-class to be instances of the
SimplePolicyCondition class ([RFC3460]) and/or sets of instances
of the SimplePolicyCondition class aggregated into instances of
the CompoundPolicyCondition class ([RFC3460]) via instances of the
PolicyConditionInPolicyCondition class ([RFC3460]) (see Figure 7.);
and
- the actions that can be associated with an instance of
PcPolicyPcReqRspComponent sub-class to be instances of the
SimplePolicyAction class ([RFC3460]) and/or sets of instances of
the SimplePolicyAction class aggregated into instances of the
CompoundPolicyAction class ([RFC3460]) via instances of the
PolicyActionInPolicyAction class ([RFC3460]) (see Figure 7).
The rationale for this decision is that the SimplePolicyCondition and
SimplePolicyAction classes are fully defined within the policy realm.
The classes are modeled as shown on Figure 5 and Figure 6
respectively.
+-----------------------+ PolicyValueInSimplePo- +----------------+
| SimplePolicyCondition| licyCondition class | PolicyValue |
| class instance | instance(PCIMe) | class instance |
| (PCIMe) |xxxxxxxxxxxxxxxxxxxxxxxx| (PCIMe) |
+-----------------------+ +----------------+
v
v PolicyVariableInSimplePolicyCondition
v class instance (PCIMe)
v
+-----------------------+ ExpectedPolicyValues- +----------------+
| PolicyVariable | ForPolicyVariable | PolicyValue |
| class instance | class instances (PCIMe)| class instances|
| (PCIMe) |========================| (PCIMe) |
+-----------------------+ +----------------+
Figure 5. Modeling Simple Policy Condition
Bryskin & Berger Expires September 5, 2007 [Page 27]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
+-----------------------+ PolicyValueInSimplePo-+----------------+
| SimplePolicyAction | licyAction class | PolicyValue |
| class instance | instance(PCIMe) | class instance |
| (PCIMe) |xxxxxxxxxxxxxxxxxxxxxxx| (PCIMe) |
+-----------------------+ +----------------+
v
v PolicyVariableInSimplePolicyAction
v class instance (PCIMe)
v
+-----------------------+ ExpectedPolicyValues- +----------------+
| PolicyVariable | ForPolicyVariable | PolicyValue |
| class instance | class instances (PCIMe)| class instances|
| (PCIMe) |========================| (PCIMe) |
+-----------------------+ +----------------+
Figure 6. Modeling Simple Policy Action
As defined in [RFC3460], SimplePolicyCondition class can be expressed
as:
if(<PolicyVariable> MATCH <PolicyValue>)
and SimplePolicyAction could be expressed as:
SET <PolicyVariable> TO <PolicyValue>
where <PolicyVariable> and <PolicyValue> are instances of
PolicyVariable and PolicyValue classes and sub-classes associated
with the instances of the SimplePolicyCondition and
SimplePolicyAction classes. In the PCPIM context, the variables that
could be associated with instances of the SimplePolicyCondition and
SimplePolicyAction classes could be either instances of
ImplicitPolicyVariable ([RFC3460]) sub-classes, as these are PC
policy variable classes introduced and discussed later in this
document (e.g. PcPolicyServiceBandwidthVariable), or instances of the
ExplicitPolicyVariable ([RFC3460]) class bound to properties of PC
Policy classes (e.g. mandatory property of the
PcPolicyPcReqRspComponent class).
Bryskin & Berger Expires September 5, 2007 [Page 28]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
+-----------------------+ +-------------------------+
| SimplePolicyCondition | | SimplePolicyAction |
| class instances | | class instances |
| (PCIMe) | | (PCIMe) |
+-----------------------+ +-------------------------+
$ %
PolicyConditionInPolicyCondition $ % PolicyActionInPolicy
$ % Action
class instances $ % class instances
(PCIMe) $ % (PCIMe)
$ %
+------------------------+ +-------------------------+
|CompoundPolicyCondition | | CompoundPolicyAction |
| class instance | | class instance |
| (PCIMe) | | (PCIMe) |
+------------------------+ +-------------------------+
Figure 7. Modeling Compound Policy Condition and Action
It should be noted that all components of the SimplyPolicyCondition
and SimplePolicyAction classes (e.g., variables, values, their
associations and the definition of operators "MATCH" and "SET") are
fully defined within the policy realm. This means that the rule
engines running on PEPs do not need to understand semantics of the
rules based on the SimplePolicyCondition and SimplePolicyAction
classes. Indeed, applying such policies cause only comparing
variables against values and setting variables to new values, rather,
than performing actual (re-)configuration of network elements.
Therefore, adding new constraint types is a fairly simple and
"painless" operation. All what required is an introduction of new
sub-classes of the PcPolicyPcReqRspComponent class, while the
modification of the software running on the PEPs is not needed.
3.1.1. PcPolicyPcReqRspComponent class
PcPolicyPcReqRspComponent is a class derived from the PolicyRule
class introduced in [RFC3060]. PcPolicyPcReqRspComponent class is an
abstract class, that is, it cannot be directly instantiated. All PC
policy classes describing path computation constraints, objective
functions, path disjointedness, SHOULD be derived from the
PcPolicyPcReqRspComponent class. The class has two properties:
mandatory and relaxation_round. The former is a Boolean identifying
whether the constraint modeled by an instance of the
PcPolicyPcReqRspComponent sub-class is mandatory (could not be
relaxed) or optional (could be relaxed). The relaxation_round
property is an integer from the range {1 ...M-1}, where M is a policy
Bryskin & Berger Expires September 5, 2007 [Page 29]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
defined value specifying the maximum number of attempts a PCE should
take on a given path computation request (with each attempt relaxing
one or more constraints) before giving up and sending a negative
response to the requesting PCC. This property specifies the priority
of the constraint relaxation. For example, if the property equals to
1, the constraint will be relaxed after initial path computation
(with full set of constraints) fails, that is, before the second
computation attempt; if the property equals to 2, the constraint will
be relaxed after a failure of the path computation with all optional
constraints that have the relaxation_round property 1 relaxed, and so
forth.
Provided that conditions of the policy modeled by a
PcPolicyPcReqRspComponent sub-class evaluate to TRUE, there MUST be
one or more actions associated with the policy that set either the
mandatory or relaxation_priority properties to TRUE/non-zero value.
Otherwise, (mandatory is FALSE and relaxation_priority is 0) the
constraint is considered as NOT specified and will not be accounted
in the path computation.
Multiple instances of PcPolicyPcReqRspComponent sub-classes could be
aggregated into a constraint set - an instance of the container class
PcPolicyPcReqRspSet - using the
PcPolicyPcReqRspComponentInPcReqRspSet aggregation class. Instances
of PcPolicyPcReqRspSet classes could be nested within each other.
Zero, one or more instances of the PcPolicyPcReqRspSet class could be
associated with a single path computation request or response modeled
by the PcPolicyActionRequestPathComputation and
PcPolicyActionSendPathComputationResponse respectively.
Note that a path computation constraint set (an instance of the
PcPolicyPcReqRspSet class) may contain several instances of the same
PcPolicyPcReqRspComponent sub-class. For example, the set may contain
two instances of the PcPolicyBandwidthConstraint class (described in
the following section): the first, mandatory, specifying 10Mb of
bandwidth, and the second, optional, specifying 12Mb of bandwidth. It
is assumed that when several constraints of the same type are
specified in the request, the PCE will use the most stringent one
(12Mb, in our example). If the path computation fails, optional
constraints will be relaxed, and the computation will be attempted
again. Thus, the policy that could be expressed as "Try, first, to
compute a 12Mb path, if the computation fails, then compute a 10Mb
path" could be easily achieved.
Bryskin & Berger Expires September 5, 2007 [Page 30]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
3.1.2. PcPolicyBandwidthConstraint class
PcPolicyBandwidthConstraint is a class derived from the
PcPolicyPcReqRspComponent. It specifies the link bandwidth
availability constraint. The class has the following properties:
bandwidth - an integer specifying minimum bandwidth in Kb to be
available on a TE link in order for the link to be
considered as a valid candidate for a resulting path
priority - an integer from the range {0...7} specifying the
lowest priority at which the bandwidth must be
available
directionality - an integer specifying the direction in which
the bandwidth must be available; the valid
values are:
1 - the bandwidth must be available only in forward
(from the source to the destination) direction
2 - the bandwidth must be available only in reverse
(from the destination to the source) direction
3 - the bandwidth must be available in both directions
A policy of setting the bandwidth constraint may (but does not have
to) be associated with instances of PcPolicyServiceBandwidthVariable,
PcPolicyServiceBandwidthDirectionalityVariable and
PcPolicyServiceBandwidthPriorityVariable classes (bandwidth
parameters provisioned for the service for which the path computation
is requested). For example, the policy could be expressed as follows:
if(PcPolicyServiceBandwidthVariable !=0)
then banwidthConstraint. bandwidth =
PcPolicyServiceBandwidthVariable;
bandwidthConstraint.directionality =
PcPolicyServiceBandwidthDirectionalityVariable;
bandwidthConstraint.priority =
PcPolicyServiceBandwidthPriorityVariable;
3.1.3. PcPolicyAffinityConstraint class
PcPolicyAffinityConstraint is a class derived from the
PcPolicyPcReqRspComponent. It specifies types (advertised as colors)
of TE links the path selection must be constrained to.
The class has the following properties:
includeAny - a bit field specifying a subset of colors. A given
Bryskin & Berger Expires September 5, 2007 [Page 31]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
TE link may be considered in the path selection only
if it advertises at least one of these colors
excludeAny - a bit field specifying a subset of colors. A given
TE link must be excluded from the path selection if
it advertises at least one of these colors
includeAll - a bit field specifying a subset of colors. A given
TE link may be considered in the path selection only
if it advertises all of these colors
A policy of setting the affinity constraint may (but does not have
to) be associated with instances of
PcPolicyServiceIncludeAnyVariable, PcPolicyServiceExcludeAnyVariable
and PcPolicyServiceIncludeAllVariable classes (affinities provisioned
for the service for which the path computation is requested) in a
similar way as described in 3.1.1
3.1.4. PcPolicyLinkProtectionConstraint class
PcPolicyLinkProtectionConstraint is a class derived from the
PcPolicyPcReqRspComponent. It specifies minimal link protection
capabilities for a TE link to be considered in the path selection.
The class has a single property:
linkProtection - an integer specifying the link capability code
according to [RFC4202].
A given TE link may be considered in the path selection only if it
advertises the link protection capability numerically greater or
equal to the value of this property
A policy of setting the link protection capability constraint may
(but does not have to) be associated with an instance of the
PcPolicyServiceLinkProtectionFlagsVariable class (link protection
capability provisioned for the service for which the path computation
is requested) in a similar way as described in 3.1.1
3.1.5. PcPolicyLinkSwitchCapConstraint class
PcPolicyLinkSwitchCapConstraint is a class derived from the
PcPolicyPcReqRspComponent. It specifies the network layer of the
requested path(s). Specifically, it constraints the path selection to
TE links with particular switching capabilities, that is, TE links,
advertising data switching and encoding capabilities matching the
Bryskin & Berger Expires September 5, 2007 [Page 32]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
values specified in the properties (see below) of the
PcPolicyLinkSwitchCapConstraint class instance.
The class has the following properties:
switchType - an integer specifying the link switching type
according to [RFC3471]
encodeType - an integer specifying the link data encoding type
according to [RFC3471]
A policy of setting the link switching capability constraint may (but
does not have to) be associated with instance of the
PcPolicyServiceSwitchingTypeVariable and
PcPolicyServiceEncodingTypeVariable classes (link switching
capabilities provisioned for the service for which the path
computation is requested) in a similar way as described in 3.1.1
3.1.6. PcPolicyPathElement class
PcPolicyPathElement is class derived from the
PolicyPcReqRspComponent. PcPolicyPathElement is an abstract class to
be used as a base class for the classes, describing explicit path
constraints such as exclusions and inclusions (see the following
sections).
The PcPolicyPathElement class has a single property:
teNodeID - network unique number identifying the node associated
with the path element (for example, a TE link to be
included or excluded)
3.1.7. PcPolicyExcludeLinkConstraint and PcPolicyExcludeNodeConstraint
classes
PcPolicyExcludeLinkConstraint and PcPolicyExcludeNodeConstraint are
classes derived from the PcPolicyPathElement class. Instances of
these classes specify TE links and nodes respectively that must be
explicitly excluded from the path computation.
The PcPolicyExcludeLinkConstraint class has a single property:
teLinkID - network unique number identifying a numbered link or
node unique number identifying (along with the
teNodeID property of the PcPolicyPathElement class)
an unnumbered link
Bryskin & Berger Expires September 5, 2007 [Page 33]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
The PcPolicyExcludeNodeConstraint class has no properties
Several instances of PcPolicyExcludeLinkConstraint and/or
PcPolicyExcludeNodeConstraint classes associated with a path
computation request specify an unordered set of TE links/nodes that
are explicitly prohibited to appear in the resulting path(s).
3.1.8. PcPolicySharedLinkConstraint class
PcPolicySharedLinkConstraint is a class derived from the
PcPolicyPathElement class. Instances of this class specify TE links
which resources could be shared between two or more service paths
and, therefore, may be considered in the path computation even if
they do not have sufficient resources (bandwidth) available
The PcPolicySharedLinkConstraint class has a single property:
teLinkID - network unique number identifying a numbered link or
node unique number identifying (along with the
teNodeID property of the PcPolicyPathElement) an
unnumbered link
3.1.9. PcPolicyIncludePathElement class
PcPolicyIncludePathElement is class derived from the
PcPolicyPathElement class. PcPolicyIncludePathElement is an abstract
class to be used as a base class for the classes describing inclusion
constraints
The PcPolicyIncludePathElement class has the following properties:
order - an integer number specifying the order of appearing of
this path element in the path (the smaller number, the
closer the path element to the path head)
loose - a Boolean specifying whether this path element is loose
(TRUE) or strict (FALSE). Path element is considered to
be loose with respect to the path element that appears
immediately before in the path, if it is permissible to
insert one or more other path elements between the two
path elements
Bryskin & Berger Expires September 5, 2007 [Page 34]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
3.1.10. PcPolicyIncludeLinkConstraint and PcPolicyIncludeNodeConstraint
classes
PcPolicyIncludeLinkConstraint and PcPolicyIncludeNodeConstraint are
classes derived from the PcPolicyIncludePathElement class. Instances
of these classes specify TE links and nodes respectively that must
appear in the resulting path(s) in the specified order.
The PcPolicyExcludeLinkConstraint class has a single property:
teLinkID - network unique number identifying a numbered link
or node unique number identifying (along with the
teNodeID property of the PcPolicyPathElement class)
an unnumbered link
The PcPolicyExcludeNodeConstraint class does not have any properties.
Several instances of PcPolicyIncludeLinkConstraint and/or
PcPolicyIncludeNodeConstraint classes associated with a path
computation request specify an ordered set of TE links/nodes that
must appear in the resulting path(s).
3.1.11. PcPolicyStrictPathsConstraint class
PcPolicyStrictPathsConstraint is a class derived from the
PolicyPcReqRspComponent class. An instance of the
PcPolicyStrictPathsConstraint class requires the resulting path(s) to
be explicit, that is, to contain only strict path elements.
The PcPolicyStrictPathsConstraint class does not have any properties
3.1.12. PcPolicySecondaryPathRequest class
PcPolicySecondaryPathRequest is a class derived from the
PolicyPcReqRspComponent class. An instance of the
PcPolicySecondaryPathRequest class requests computation of a
secondary path (backup path or path to a point-to-multipoint service
leaf) to be performed concurrently with the primary and other
secondary paths.
The PcPolicySecondaryPathRequest class has the following properties:
pathSource - an IPv4 or IPv6 value specifying the source of the
secondary path; if specified as 0, it MUST be
assumed that the source of the secondary path is
the same as of the primary path
Bryskin & Berger Expires September 5, 2007 [Page 35]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
pathDestination - an IPv4 or IPv6 value specifying the
destination of the secondary path; if specified as
0, it MUST be assumed that the destination of the
secondary path is the same as of the primary path
PCPIM allows direct associations of an instance of the
PcPolicySecondaryPathRequest class with one or more instances of any
of PolicyPcReqRspComponent sub-classes via instances of the
PcPolicyPcReqRspComponentInPcSecondaryPathRequest association class.
This is useful for requesting an individual set of constraints for
the secondary path distinct from one for the primary path and other
secondary paths. If such associations are not provided between some
of the constraints, specified for the primary path, and a given
instance of the PcPolicySecondaryPathRequest class, it MUST be
interpreted as a requirement for the secondary path computation to
use the same such constraints as for the primary path computation.
For example, suppose that an instance of the
PcPolicySecondaryPathRequest class is associated only with several
instances of the PcPolicyIncludeLinkConstraint classes (in order to
specify, say, a preferred path between a branch and a leaf of a
point- to-multipoint tunnel). Although, the bandwidth constraint in
this case is not explicitly specified for this secondary path, the
path will be computed with the bandwidth constraint specified for the
primary path/tree.
3.1.13. PcPolicySecondaryPathDisjoitedness class
PcPolicySecondaryPathDisjoitedness is a class derived from the
PolicyPcReqRspComponent class. An instance of the
PcPolicySecondaryPathDisjoitedness class describes how a secondary
path should be disjoint from (or converged with) the primary and
other secondary paths.
In section 3.1.12 it was mentioned that an instance of any
PolicyPcReqRspComponent sub-class can be associated with an instance
of the PcPolicySecondaryPathRequest class. If such association is
specified for an instance of the PcPolicySecondaryPathDisjoitedness
class, the disjointedness parameters provided by the instance apply
only for the secondary path in question (but not for any other
secondary paths). Otherwise, (that is, the association is not
specified), the disjointedness parameters apply for all secondary
paths in the request (specified via instances of the
PcPolicySecondaryPathRequest class aggregated into the same instance
of the PcPolicyPcReqRspSet class).
The PcPolicySecondaryPathDisjoitedness class has the following
properties:
Bryskin & Berger Expires September 5, 2007 [Page 36]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
disjointedness - an integer specifying the path disjointedness
code that could take one of the following values:
1 - link-disjoint (no links in common);
2 - node-disjoint (no nodes in common);
3 - SRLG-disjoint (no Shared Risk Link
Groups in common);
4 - best- disjoint (best available
disjointedness with applying penalties
for sharing links, nodes and SRLGs)
5 - converged (as many links in common as
possible, useful for point-to-
multipoint path/tree computations)
linkSharingCostPenalty - an integer specifying by how much the
cost of the secondary path must be increased for
every link shared with the primary or other secondary
paths; this property is only meaningful
when the disjointedness property set to 4
nodeSharingCostPenalty - an integer specifying by how much the
cost of the secondary path must be increased for
every node shared with the primary or other secondary
paths; this property is only meaningful
when the disjointedness property set to 4
SRLGSharingCostPenalty - an integer specifying by how much
cost of the secondary path must be increased for
every SRLG shared with the primary or other secondary
paths; this property is only meaningful
when the disjointedness property set to 4
3.1.14. PcPolicyShortestPathObjectiveFunction class
PcPolicyShortestPathObjectiveFunction is a class derived from the
PolicyPcReqRspComponent class. An instance of the
PcPolicyShortestPathObjectiveFunction class instructs the path
computation engine to optimize the path selection according to the
shortest path criteria.
The PcPolicyShortestPathObjectiveFunction class has a single
property:
optimization - a Boolean specifying whether the path selection
should be optimized according to minimal summary
TE metric (TRUE) or minimal number of hops (FALSE)
criteria
Bryskin & Berger Expires September 5, 2007 [Page 37]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
3.1.15. PcPolicyMinimalE2EDelayObjectiveFunction class
PcPolicyMinimalE2EDelayObjectiveFunction is a class derived from the
PolicyPcReqRspComponent class. An instance of the
PcPolicyMinimalE2EDelayObjectiveFunction class instructs the path
computation engine to optimize the path selection according to the
minimal end-to-end delay criteria.
The PcPolicyMinimalE2EDelayObjectiveFunction class does not have
properties.
3.1.16. PcPolicyShortestPathUpperBoundConstraint class
PcPolicyShortestPathUpperBoundConstraint is a class derived from the
PolicyPcReqRspComponent class. An instance of the
PcPolicyShortestPathUpperBoundConstraint class sets upper bound on
the cost of the resulting paths in terms of either summary TE metric
or number of hops or both.
The PcPolicyShortestPathUpperBoundConstraint class has the following
properties:
maxMetric - an integer specifying maximally acceptable summary
path TE metric
maxHopNumber - an integer specifying maximally acceptable number
of hops in the path(s)
3.1.17. PcPolicyE2EDelayUpperBoundConstraint class
PcPolicyE2EDelayUpperBoundConstraint is a class derived from the
PolicyPcReqRspComponent class. An instance of the
PcPolicyE2EDelayUpperBoundConstraint class sets upper bound on the
end- to-end delay characteristic of each of the resulting paths.
The PcPolicyE2EDelayUpperBoundConstraint class has a single property:
maxE2Edelay - an integer specifying maximally acceptable value
of the path end-to-end delay characteristic
3.1.18. PcPolicyGMPLSWavelengthContinuityConstraint class
PcPolicyGMPLSWavelengthContinuityConstraint is a class derived from
the PolicyPcReqRspComponent class. This class is meaningful in the
context of transparent optical network path computation. An instance
of the PcPolicyGMPLSWavelengthContinuityConstraint class constrains
Bryskin & Berger Expires September 5, 2007 [Page 38]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
the path computation engine to consider only WDM links for the
resulting path(s) that have at least one lambda channel with the same
wavelength available on all links selected for any given transparent
path segment (that is, path segment between optical signal (OS)
regeneration points). The wavelength continuity constraint is
necessary due to inability of transparent optical switches to perform
the wavelength conversion.
The PcPolicyGMPLSWavelengthContinuityConstraint class does not have
properties.
3.1.19. PcPolicyGMPLSMaximalOSNRObjectiveFunction class
PcPolicyGMPLSMaximalOSNRObjectiveFunction is a class derived from the
PolicyPcReqRspComponent class. This class is meaningful in the
context of transparent optical network path computation. An instance
of the PcPolicyGMPLSMaximalOSNRObjectiveFunction class instructs the
path computation engine to optimize the path selection according to
the maximal Optical Signal to Noise Ratio (OSNR) criteria at points
of OS regeneration and path destination(s).
The PcPolicyGMPLSMaximalOSNRObjectiveFunction class does not have
properties.
3.1.20. PcPolicyGMPLSMinimalDispersionObjectiveFunction class
PcPolicyGMPLSMinimalDispersionObjectiveFunction is a class derived
from the PolicyPcReqRspComponent class. This class is meaningful in
the context of transparent optical network path computation. An
instance of the PcPolicyGMPLSMinimalDispersionObjectiveFunction class
instructs the path computation engine to optimize the path selection
according to the minimal OS dispersion criteria at points of OS
regeneration and path destination(s).
The PcPolicyGMPLSMinimalDispersionObjectiveFunction class does not
have properties.
3.1.21. PcPolicyGMPLSMinimalAttenuationObjectiveFunction class
PcPolicyGMPLSMinimalAttenuationObjectiveFunction is a class derived
from the PolicyPcReqRspComponent class. This class is meaningful in
the context of transparent optical network path computation. An
instance of the PcPolicyGMPLSMinimalAttenuationObjectiveFunction
class instructs the path computation engine to optimize the path
selection according to the minimal OS attenuation criteria at points
Bryskin & Berger Expires September 5, 2007 [Page 39]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
of OS regeneration and path destination(s).
The PcPolicyGMPLSMinimalAttenuationObjectiveFunction class does not
have properties.
3.1.22. PcPolicyGMPLSMinimalRegenerationObjectiveFunction class
PcPolicyGMPLSMinimalRegenerationObjectiveFunction is a class derived
from the PolicyPcReqRspComponent class. This class is meaningful in
the context of transparent optical network path computation. An
instance of the PcPolicyGMPLSMinimalRegenerationObjectiveFunction
class instructs the path computation engine to optimize the path
selection according to the minimal number of OS regenerations
criteria.
The PcPolicyGMPLSMinimalRegenerationObjectiveFunction class does not
have properties.
3.1.23. PcPolicyGMPLSOSNRLowerBoundConstraint class
PcPolicyGMPLSOSNRLowerBoundConstraint is a class derived from the
PolicyPcReqRspComponent class. This class is meaningful in the
context of transparent optical network path computation. An instance
of the PcPolicyGMPLSOSNRLowerBoundConstraint class sets a lower bound
on the OSNR characteristic at the resulting path(s) destination(s)
and points of OS regeneration.
The PcPolicyGMPLSOSNRLowerBoundConstraint class has a single
property:
minOSNR - an integer specifying minimally acceptable value of
OSNR characteristic
3.1.24. PcPolicyGMPLSDispersionUpperBoundConstraint class
PcPolicyGMPLSDispersionUpperBoundConstraint is a class derived from
the PolicyPcReqRspComponent class. This class is meaningful in the
context of transparent optical network path computation. An instance
of the PcPolicyGMPLSDispersionUpperBoundConstraint class sets upper
bound on the OS dispersion characteristic at the resulting path(s)
destination(s) and points of OS regeneration.
The PcPolicyGMPLSDispersionUpperBoundConstraint class has a single
property:
Bryskin & Berger Expires September 5, 2007 [Page 40]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
maxDispersion - an integer specifying maximally acceptable value
of OS dispersion characteristic
3.1.25. PcPolicyGMPLSAttenuationUpperBoundConstraint class
PcPolicyGMPLSAttenuationUpperBoundConstraint is a class derived from
the PolicyPcReqRspComponent class. This class is meaningful in the
context of transparent optical network path computation. An instance
of the PcPolicyGMPLSAttenuationUpperBoundConstraint class sets upper
bound on the OS attenuation characteristic at the resulting path(s)
destination(s) and points of OS regeneration.
The PcPolicyGMPLSAttenuationUpperBoundConstraint class has a single
property:
maxAttenuation - an integer specifying maximally acceptable value
of OS attenuation characteristic
3.1.26. PcPolicyGMPLSRegenerationUpperBoundConstraint class
PcPolicyGMPLSRegenerationUpperBoundConstraint is a class derived from
the PolicyPcReqRspComponent class. This class is meaningful in the
context of transparent optical network path computation. An instance
of the PcPolicyGMPLSRegenerationUpperBoundConstraint class sets upper
bound on the number of OS regenerations along each of the resulting
path(s).
The PcPolicyGMPLSRegenerationUpperBoundConstraint class has a single
property:
maxRenerations - an integer specifying maximally acceptable number
of OS regenerations
3.1.27. PcPolicyGMPLSTransparentPathUpperBoundConstraint class
PcPolicyGMPLSTransparentPathUpperBoundConstraint is a class derived
from the PolicyPcReqRspComponent class. This class is meaningful in
the context of transparent optical network path computation. An
instance of the PcPolicyGMPLSTransparentPathUpperBoundConstraint
class sets an upper bound on the length of a transparent path segment
(path segment between two points of OS regeneration) of each of the
resulting path(s).
The PcPolicyGMPLSTransparentPathUpperBoundConstraint class has a
single property:
Bryskin & Berger Expires September 5, 2007 [Page 41]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
maxLenTranspSegment - an integer specifying maximally acceptable
length of a transparent path segment
3.1.28. PcPolicyReturnPathCost class
PcPolicyReturnPathCost is a class derived from the
PolicyPcReqRspComponent class. An instance of the
PcPolicyReturnPathCost class requests information on a computed path
actual cost in terms of summary TE link metric and hop number. An
instance of the PcPolicyReturnPathCost class could be associated with
an instance of the PcPolicySecondaryPathRequest class via an instance
of the PcPolicyPcReqRspComponentInPcSecondaryPathRequest class. Such
association instructs the peer PCE which (of possibly several) paths
the actual cost must be returned for. If the association is not
specified the cost characteristics will be returned for the computed
primary path.
The PcPolicyReturnPathCost class has the following properties:
pathMetric - an integer specifying computed path summary TE metric
hopNumber - an integer specifying computed path hop number
3.1.29. PcPolicyReturnPathE2EDelay class
PcPolicyReturnPathE2EDelay is a class derived from the
PolicyPcReqRspComponent class. An instance of the
PcPolicyReturnPathE2EDelay class requests information on a computed
path actual end-to-end delay characteristic. An instance of the
PcPolicyReturnPathE2EDelay class could be associated with an instance
of the PcPolicySecondaryPathRequest class via an instance of the
PcPolicyPcReqRspComponentInPcSecondaryPathRequest class. Such
association instructs the peer PCE which (of possibly several) paths
the actual end-to-end delay characteristic must be returned for. If
the association is not specified, the characteristic will be returned
for the computed primary path.
The PcPolicyReturnPathE2EDelay class has a single property:
pathE2Edelay - an integer specifying computed path end-to-end
delay characteristic
Bryskin & Berger Expires September 5, 2007 [Page 42]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
3.2. Modeling PC capabilities
There could be several PCEs serving on the network at the same time
because:
- the PCEs may have different PC capabilities and, therefore, be
suited for different types of the path computation.
- the PCEs may have different visibility into the network
resources and hence compute paths within and across different
path computation domains.
- the PCEs may have different security restraints on accessing
their services.
- two or more PCEs with identical capabilities and TE visibility
may be deployed for the purpose of path computation load
balancing.
Furthermore, one should keep in mind that PCCs may have access to
local path computation engine(s) capable of certain types of the path
computation, but not of others, for which they may request a remote
PCE service. Therefore, a PCC must be capable to decide for a given
path computation on whether local or remote PCE should be used, and,
in the latter case, select the PCE that suits best the path
computation in question.
In 3.1 we discussed a PC constraint as a policy that influences the
outcome of the path selection process. It was noted that PCPIM makes
it possible for a PCC, while not understanding what a given PC
constraint means, to request it anyway simply because the policy
tells the PCC to do so. This is achieved via modeling PC constraints
as policy rules (based on the [RFC3060] PolicyRule sub-classes) and
associating them with conditions and actions based on the
SimplePolicyCondition and SimplePolicyAction sub-classes
respectively. Such an approach allows for requesting the constraints
via applying some logic defined/governed by policy on a limited set
of variables which values are defined outside of the policy realm
(e.g. information provided by signaling or provisioning messages or
SLAs) without actually understanding the semantics of the
constraints. However, in a multi-PCE environment requesting PC
constraints would be of a little use, if the PC request with the
constraints is sent to a PCE that does not recognize or support the
constraints.
In this section we will discuss a PC capability as a policy that
could be used by a PCC while selecting a PCE for a given path
computation request. As in case of the PC constraints, it is
Bryskin & Berger Expires September 5, 2007 [Page 43]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
important for PCPIM (in order to be open for future path computation
process enhancements) to make it possible for a PCC to use/apply PC
capabilities without understanding their semantics.
Suppose an IP router is about to setup a tunnel going through an
optical domain. In order for such tunnel to be successfully set up
and operational, it is important to request the wavelength continuity
constraint (discussed in 3.1). However, neither of software
components on the router needs to understand what does the constraint
mean. Nor it needs to understand what does the capability to support
the constraint mean. The goal is to have the PCC, associated with the
router, request the constraint and send the request to a PCE capable
to support the constraint, solely because the PC policy instructs the
PCC to do so (one reason for such instruction could be the fact that
the tunnel is provisioned with the transparent optical switching
capability requirements).
In PCPIM a PC capability is modeled based on the
PcPolicyPcCapabilityComponent class (see the next sub-section).
Bryskin & Berger Expires September 5, 2007 [Page 44]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
+-----------------------+ +-------------------------+
| SimplePolicyCondition | | CompoundPolicyCondition |
| class instances | | class instances |
| (PCIMe) | | (PCIMe) |
+-----------------------+ +-------------------------+
* PolicyConditionInPolicyRule *
* class instances *
* (PCIM) *
*******************************
*
*
+--------------------------------+
| PcPolicyPcCapabilityComponent |
| sub-class instance |
| (PCPIM) |
+--------------------------------+
#
#
###############################
# PolicyActionInPolicyRule #
# class instances #
# (PCIM) #
+-----------------------+ +-------------------------+
| SimplePolicyAction | | CompoundPolicyAction |
| class instances | | class instances |
| (PCIMe) | | (PCIMe) |
+-----------------------+ +-------------------------+
Figure 8. Modeling PC Capability
The approach taken in PCPIM with respect to the use of sub-classes of
the PcPolicyPcCapabilityComponent class is similar to one taken for
the use of PcPolicyPcReqRspComponent sub-classes (described at the
top of 3.1).
Specifically, it was decided to limit:
- the conditions that could be associated with an instance of a
PcPolicyPcCapabilityComponent sub-class to be instances of the
SimplePolicyCondition class([RFC3460]) and/or sets of instances of
the SimplePolicyCondition class aggregated into instances of the
CompoundPolicyCondition class ([RFC3460]) via instances of the
PolicyConditionInPolicyCondition class ([RFC3460]) (see Figure 7);
- the actions that could be associated with an instance of a
PcPolicyPcCapabilityComponent sub-class to be instances of the
SimplePolicyAction class ([RFC3460]) and/or sets of instances of
the SimplePolicyAction class aggregated into instances of the
Bryskin & Berger Expires September 5, 2007 [Page 45]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
CompoundPolicyAction class ([RFC3460]) via instances of the
PolicyActionInPolicyAction class ([RFC3460]) (see Figure 7).
It should be noted that in the majority of cases PC capabilities
introduced in 3.2 match PC constraints introduced in 3.1. Therefore,
instances of matching PC constraint and capability classes may use
(that is, may be associated with) the same conditions (the same
instances of the SimplePolicyCondition sub-classes). For example, the
same conditions that cause a PCC PEP to ask for the end-to-end delay
optimization in a particular path computation request may "encourage"
the PCC PEP to select for the path computation a PCE that actually
supports this path computation objective.
3.2.1. PcPolicyPcCapabilityComponent class
PcPolicyPcCapabilityComponent is a class derived from the PolicyRule
class introduced in [RFC3060]. PcPolicyPcCapabilityComponent class is
an abstract class, that is, it cannot be directly instantiated. All
PC policy classes describing path computation capabilities SHOULD be
derived from the PcPolicyPcCapabilityComponent class. The class has
two properties: domains and pceMetric.
The domains property is a set of IPv4 or IPv6 values, each of which
uniquely identifying one path computation domain in the network. A
given PCE may perform differently when processing requests from
and/or computing paths across different path computation domains
Therefore, the domains property of the PcPolicyPcCapabilityComponent
class is necessary to specify for which of the domains the
information provided by the properties of a given instance of the
PcPolicyPcCapabilityComponent sub- class is valid.
The pceMetric property is a small integer expressing a PCC's
preference to use the PCE that claims this PC capability (modeled by
this instance of a PcPolicyPcCapabilityComponent sub-class) for a
particular path computation request. The pceMetric property has a
special role in the PCE evaluation process. This is the only writable
property of the PcPolicyPcCapabilityComponent class and any of its
sub-classes. In other words, this is the only property whose value
could be overwritten as a result of associated policy action(s). It
is important to note that in contrast with PcPolicyPcReqRspComponent
sub-classes (describing PC constraints, see 3.1), which properties
are set via associated policy actions, all properties of
PcPolicyPcCapabilityComponent sub-classes are pre-set (normally, by
Policy Management Tool), and, as far as a PCC PEP is concerned, are
read-only: they could be used as condition variables, but not as
action variables. The only exception is the pceMetric property, which
value is re-set during the PCE evaluation process. The process could
Bryskin & Berger Expires September 5, 2007 [Page 46]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
be described as follows. It starts after a PC request is built.
During the process policies, modeling PC capabilities (instances of
PcPolicyPcCapabilityComponent sub-classes) associated with a given
PCE are applied. If conditions of a such policy are evaluated to
TRUE, its actions are expected to set the pceMetric policy property
to some positive integer, thus, making the PCE "more attractive" for
the path computation request.
For example, an instance of the PcPolicyE2EDelayObjectiveSupport
class, modeling the PC capability to support minimal end-to-end delay
objective function, may be associated with one condition and one
action in a way that could be expressed as follows:
if(E2EDelayOptimizationIsRequested)
then e2eDelayOptimizationSupport.pceMetric =
E2E_DELAY_OPT_METRIC;
where
E2EDelayOptimizationIsRequested is a policy (Boolean) variable which
is set to TRUE if the minimal end-to-end delay optimization is
specified in the path computation request, for which a PCE is being
evaluated. E2E_DELAY_OPT_METRIC is a policy value expressing the
attractiveness of a PCE claiming to support such optimization.
After all PC capability policies associated with a given PCE are
applied, a PC policy action "Evaluate PCE For PC Request" (an
instance of the PcPolicyActionEvaluatePCE class) is expected to be
executed. The action enables the selection of PCE that suits the best
for a given path computation request (see more details in 3.4.5).
Multiple instances of PcPolicyPcCapabilityComponent sub-classes could
be aggregated into a capability set - an instance of the container
class PcPolicyPcCapabilitySet - using the aggregation class
PcPolicyPcCapabilityComponentInPcCapabilitySet. Instances of the
PcPolicyPcCapabilitySet class could be nested within each other. One
or more instances of the PcPolicyPcCapabilitySet class could be
associated with a given instance of the PcPolicyActionEvaluatePCE
class.
3.2.2. PcPolicyPCELocation class
PcPolicyPCELocation is a class derived from the
PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyPCELocation class specifies the IP address which the PCE
could be reached at.
Bryskin & Berger Expires September 5, 2007 [Page 47]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
The class has a single property:
pceAddress - IPv4 or IPv6 value specifying an IP address
associated with the PCE.
3.2.3. PcPolicyPCEAdminPriority class
PcPolicyPCEAdminPriority is a class derived from the
PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyPCEAdminPriority class specifies the network operator
preference for the associated PCE to be used for path computations.
The ability to express the PCE administrative priority is necessary
to balance path computation load.
The class has a single property:
pcePriority - an integer expressing the PCE's administratively
assigned priority
3.2.4. PcPolicyTEVisibilityDomains class
PcPolicyTEVisibilityDomains is a class derived from the
PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyTEVisibilityDomains class specifies a set of path computation
domains for which the associated PCE has an access to the information
about inventory and availability of network resources, and hence
across which it can compute explicit TE paths. This information is
useful in the PCE selection process, when it is known a prior which
domains the resulting path(s) will cross.
The class has a single property:
teDomains - a set of IPv4 or IPv6 addresses, each address from
the set identifies one path computation domain that
is TE visible to the PCE
3.2.5. PcPolicyDestinationDomains class
PcPolicyDestinationDomains is a class derived from the
PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyDestinationDomains class specifies a set of path computation
domains towards which the associated PCE can compute (perhaps, non-
explicit) TE paths, even when the PCE does not have full TE
visibility into these domains. This information is useful in the PCE
selection process, when it is known a prior which domains the
Bryskin & Berger Expires September 5, 2007 [Page 48]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
requested path destination(s) might be located.
The class has a single property:
destDomains - a set of IPv4 or IPv6 addresses, each address from
the set identifies one path computation domain in
direction towards which the PCE can compute paths
3.2.6. PcPolicyInterDomainCapability class
PcPolicyInterdomainCapability is a class derived from the
PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyPCELocation class specifies the scope(s) of the paths that
could be computed by the associated PCE.
The class has the following properties:
fIntraArea - a Boolean indicating whether the PCE is capable
(TRUE) to compute paths that do not cross IGP area
boundaries
fInterArea - a Boolean indicating whether the PCE is capable
(TRUE) to compute paths that may cross IGP area
boundaries, but not AS boundaries
fInterAS - a Boolean indicating whether the PCE is capable
(TRUE) to compute paths that may cross inter-AS
boundaries
fInterLayer - a Boolean indicating whether the PCE is capable
(TRUE) to compute paths that span multiple (more
than two) network layers
3.2.7. PcPolicyRequestPrioritizationSupport class
PcPolicyRequestPrioritizationSupport is a class derived from the
PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyRequestPrioritizationSupport class indicates that the
associated PCE honors the path computation request prioritization.
The class does not have any properties.
Bryskin & Berger Expires September 5, 2007 [Page 49]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
3.2.8. PcPolicyLinkBanwidthConstraintSupport class
PcPolicyLinkBanwidthConstraintSupport is a class derived from the
PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyLinkBanwidthConstraintSupport class indicates that the
associated PCE supports the link available bandwidth constraint (see
3.1.2).
The class does not have any properties.
3.2.9. PcPolicyLinkAffinitiesConstraintSupport class
PcPolicyLinkAffinitiesConstraintSupport is a class derived from the
PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyLinkAffinitiesConstraintSupport class indicates that the
associated PCE supports the link affinity constraint (see 3.1.3).
The class does not have any properties.
3.2.10. PcPolicyLinkProtectionConstraintSupport class
PcPolicyLinkProtectionConstraintSupport is a class derived from the
PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyLinkProtectionConstraintSupport class indicates that the
associated PCE supports the link protection capability constraint
(see 3.1.4).
The class does not have any properties.
3.2.11. PcPolicyLinkSwitchCapConstraintSupport class
PcPolicyLinkSwitchCapConstraintSupport is a class derived from the
PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyLinkSwitchCapConstraintSupport class indicates that the
associated PCE supports the link switching capability constraint (see
3.1.5).
The class does not have any properties.
Bryskin & Berger Expires September 5, 2007 [Page 50]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
3.2.12. PcPolicyExclusionConstraintSupport class
PcPolicyExclusionConstraintSupport is a class derived from the
PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyExclusionConstraintSupport class indicates that the
associated PCE supports the exclusion constraints (see 3.1.7).
The class does not have any properties.
3.2.13. PcPolicySharedLinkConstraintSupport class
PcPolicySharedLinkConstraintSupport is a class derived from the
PcPolicyPcCapabilityComponent class. An instance of the
PcPolicySharedLinkConstraintSupport class indicates that the
associated PCE supports the shared link constraint (see 3.1.8).
The class does not have any properties.
3.2.14. PcPolicyInclusionConstraintSupport class
PcPolicyInclusionConstraintSupport is a class derived from the
PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyInclusionConstraintSupport class indicates that the
associated PCE supports the inclusion constraints (see 3.1.10).
The class does not have any properties.
3.2.15. PcPolicyConcurrentPathComputationCapability class
PcPolicyConcurrentPathComputationCapability is a class derived from
the PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyConcurrentPathComputationCapability class indicates that the
associated PCE is capable of concurrent computation of several (more
than one) paths between the specified sets of sources and
destinations.
The class has the following properties:
maxPathNumber - an integer specifying the maximal number of paths
that could be computed concurrently
fLinkDisjoint - a Boolean indicating whether the PCE is capable
(TRUE) to compute link-disjoint paths (see
discussions on path disjointedness in 3.1.13)
fNodeDisjoint - a Boolean indicating whether the PCE is capable
(TRUE) to compute node-disjoint paths
Bryskin & Berger Expires September 5, 2007 [Page 51]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
fSRLGDisjoint - a Boolean indicating whether the PCE is capable
(TRUE) to compute SRLG-disjoint paths
fBestDisjoint - a Boolean indicating whether the PCE is capable
(TRUE) to compute best-disjoint paths
fConverged - a Boolean indicating whether the PCE is capable
(TRUE) to compute paths that share maximum TE links
3.2.16. PcPolicyShortestPathObjectiveSupport class
PcPolicyShortestPathObjectiveSupport is a class derived from the
PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyShortestPathObjectiveSupport class indicates that the
associated PCE supports path selection optimization according to the
shortest path criteria (see 3.1.14).
The class does not have any properties.
3.2.17. PcPolicyCostUpperBoundConstraintSupport class
PcPolicyCostUpperBoundConstraintSupport is a class derived from the
PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyCostUpperBoundConstraintSupport class indicates that the
associated PCE supports the upper bound path cost constraint (see
3.1.16).
The class does not have any properties.
3.2.18. PcPolicyE2EDelayObjectiveSupport class
PcPolicyE2EDelayObjectiveSupport is a class derived from the
PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyE2EDelayObjectiveSupport class indicates that the associated
PCE supports path selection optimization according to the minimal
end- to-end delay criteria (see 3.1.15).
The class does not have any properties.
3.2.19. PcPolicyE2EDelayUpperBoundConstraintSupport class
PcPolicyE2EDelayUpperBoundConstraintSupport is a class derived from
the PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyE2EDelayUpperBoundConstraintSupport class indicates that the
associated PCE supports the upper bound end-to-end delay constraint
(see 3.1.17).
Bryskin & Berger Expires September 5, 2007 [Page 52]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
The class does not have any properties.
3.2.20. PcPolicyGMPLSWavelengthContinuityConstraintSupport class
PcPolicyGMPLSWavelengthContinuityConstraintSupport is a class derived
from the PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyGMPLSWavelengthContinuityConstraintSupport class indicates
that the associated PCE supports the OS wavelength continuity
constraint (see 3.1.18).
The class does not have any properties.
3.2.21. PcPolicyGMPLSOSNRObjectiveSupport class
PcPolicyGMPLSOSNRObjectiveSupport is a class derived from the
PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyGMPLSOSNRObjectiveSupport class indicates that the associated
PCE supports path selection optimization according to the maximal
OSNR criteria (see 3.1.19).
The class does not have any properties.
3.2.22. PcPolicyGMPLSDispersionObjectiveSupport class
PcPolicyGMPLSDispersionObjectiveSupport is a class derived from the
PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyGMPLSDispersionObjectiveSupport class indicates that the
associated PCE supports path selection optimization according to the
minimal OS dispersion criteria (see 3.1.20).
The class does not have any properties.
3.2.23. PcPolicyGMPLSAttenuationObjectiveSupport class
PcPolicyGMPLSAttenuationObjectiveSupport is a class derived from the
PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyGMPLSAttenuationObjectiveSupport class indicates that the
associated PCE supports path selection optimization according to the
minimal OS attenuation criteria (see 3.1.21).
The class does not have any properties.
Bryskin & Berger Expires September 5, 2007 [Page 53]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
3.2.24. PcPolicyGMPLSMinimalRegenerationsObjectiveFunction class
PcPolicyGMPLSMinimalRegenerationsObjectiveFunction is a class derived
from the PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyGMPLSMinimalRegenerationsObjectiveFunction class indicates
that the associated PCE supports path selection optimization
according to the minimal number of OS regenerations criteria (see
3.1.22).
The class does not have any properties.
3.2.25. PcPolicyGMPLSOSNRLowerBoundConstraintSupport class
PcPolicyGMPLSOSNRLowerBoundConstraintSupport is a class derived from
the PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyGMPLSOSNRLowerBoundConstraintSupport class indicates that the
associated PCE supports the OSNR lower bound constraint (see 3.1.23).
The class does not have any properties.
3.2.26. PcPolicyGMPLSDispersionUpperBoundConstraintSupport class
PcPolicyGMPLSDispersionUpperBoundConstraintSupport is a class derived
from the PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyGMPLSDispersionUpperBoundConstraintSupport class indicates
that the associated PCE supports the OS dispersion upper bound
constraint (see 3.1.24).
The class does not have any properties.
3.2.27. PcPolicyGMPLSAttenuationUpperBoundConstraintSupport class
PcPolicyGMPLSAttenuationUpperBoundConstraintSupport is a class
derived from the PcPolicyPcCapabilityComponent class. An instance of
the PcPolicyGMPLSAttenuationUpperBoundConstraintSupport class
indicates that the associated PCE supports the OS attenuation upper
bound constraint (see 3.1.25).
The class does not have any properties.
Bryskin & Berger Expires September 5, 2007 [Page 54]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
3.2.28. PcPolicyGMPLSRegenerationsUpperBoundConstraintSupport class
PcPolicyGMPLSRegenerationsUpperBoundConstraintSupport is a class
derived from the PcPolicyPcCapabilityComponent class. An instance of
the PcPolicyGMPLSRegenerationsUpperBoundConstraintSupport class
indicates that the associated PCE supports the number of OS
regenerations upper bound constraint (see 3.1.26).
The class does not have any properties.
3.2.29. PcPolicyGMPLSTransparentPathUpperBoundConstraintSupport class
PcPolicyGMPLSTransparentPathUpperBoundConstraintSupport is a class
derived from the PcPolicyPcCapabilityComponent class. An instance of
the PcPolicyGMPLSTransparentPathUpperBoundConstraintSupport class
indicates that the associated PCE supports the maximal length
transparent segment constraint (see 3.1.27).
The class does not have any properties.
3.2.30. PcPolicyP2MPComutationSupport class
PcPolicyP2MPComutationSupport is a class derived from the
PcPolicyPcCapabilityComponent class. An instance of the
PcPolicyP2MPComutationSupport class indicates that the associated PCE
can perform point-to-multipoint tree computations.
The class does not have any properties.
3.3. Modeling PC policy relationships
PC policies of the same type need to be aggregated together, and,
then, associated with PC actions (for discussions on PC actions see
3.4). For example, in order for PC constraints to be considered in a
given path computation, they should be aggregated into one or more
constraint sets which, in turn, should be associated with the PC
action "Request Path Computation". In the PCPIM PC policy
aggregations and associations are modeled via container and
association classes described in this section.
Bryskin & Berger Expires September 5, 2007 [Page 55]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
3.3.1. PcPolicyPcReqRspSet class
PcPolicyPcReqRspSet is a class derived from the PolicyGroup class
(introduced in [RFC3060]). This is a container class. It allows for
aggregating of one or more instances of PcPolicyPcReqRspComponent
sub- classes (modeling PC constraints) into a single set, using
instances of the PcPolicyPcReqRspComponentInPcReqRspSet class.
The sets may be unlimitedly nested within each other via instances of
the PcPolicyPcReqRspSetInPcReqRspSet classes. The
PcPolicyPcReqRspComponentInPcReqRspSet and
PcPolicyPcReqRspSetInPcReqRspSet association classes are discussed
later in this section.
The PcPolicyPcReqRspSet does not have properties.
3.3.2. PcPolicyPcCapabilitySet class
PcPolicyPcCapabilitySet is a class derived from the PolicyGroup class
(introduced in [RFC3060]). This is a container class. It allows for
aggregating of one or more instances of PcPolicyPcCapabilityComponent
sub-classes (modeling PC capabilities) into a single set via
instances of the PcPolicyPcCapabilityComponentInPcCapabilitySet
class. The sets may be unlimitedly nested within each other via
instances of the PcPolicyPcCapabilitySetInPcCapabilitySet classes.
The PcPolicyPcCapabilityComponentInPcCapabilitySet and
PcPolicyPcCapabilitySetInPcCapabilitySet are discussed later in this
section.
The PcPolicyPcCapabilitySet does not have properties.
3.3.3. PcPolicyPcReqRspComponentInPcReqRspSet class
PcPolicyPcReqRspComponentInPcReqRspSet is a class derived from the
PolicyComponentSet class (introduced in [RFC3460]). This is an
association class. It is used for aggregating an instance of a
PcPolicyPcReqRspComponent sub-class into an instance of the
PcPolicyPcReqRspSet class.
The PcPolicyPcReqRspComponentInPcReqRspSet has the following
properties:
GroupComponent [ref PcPolicyPcReqRspSet[0..n]]- a pointer to the
instance of the containing (PcPolicyPcReqRspSet)
class; the cardinality [0..n] means that zero, one or
more instances of the PcPolicyPcReqRspSet class could
Bryskin & Berger Expires September 5, 2007 [Page 56]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
be associated with (that is, contain within itself)
the same instance of the PcPolicyPcReqRspComponent
sub-class by this association
PartComponent [ref PcPolicyPcReqRspComponent[1..n]]- a pointer to
the instance of the contained
(PcPolicyPcReqRspComponent sub-) class; the
cardinality [1..n] means that one or more instances
of PcPolicyPcReqRspComponent sub-classes could be
associated with (that is, contained in) the same
instance of the PcPolicyPcReqRspSet class by this
association
3.3.4. PcPolicyPcReqRspSetInPcReqRspSet class
PcPolicyPcReqRspSetInPcReqRspSet is a class derived from the
PolicyComponentSet class (introduced in [RFC3460]). This is an
association class. It is used for nesting an instance of the
PcPolicyPcReqRspSet class into another instance of the
PcPolicyPcReqRspSet class.
The PcPolicyPcReqRspSetInPcReqRspSet has the following properties:
GroupComponent [ref PcPolicyPcReqRspSet[0..n]]- a pointer to the
nesting instance of the PcPolicyPcReqRspSet class; the
cardinality [0..n] means that zero, one or more
instances of the PcPolicyPcReqRspSet class could nest
the same instance of this class by this association
PartComponent [ref PcPolicyPcReqRspSet [0..n]]- a pointer to the
nested instance of the PcPolicyPcReqRspSet class; the
cardinality [0..n] means that zero, one or more
instances of the PcPolicyPcReqRspSet class could be
nested within the same instance of this class by this
association
3.3.5. PcPolicyPcCapabilityComponentInPcCapabilitySet class
PcPolicyPcCapabilityComponentInPcCapabilitySet is a class derived
from the PolicyComponentSet class (introduced in [RFC3460]). This is
an association class. It is used for aggregating an instance of a
PcPolicyPcCapabilityComponent sub-class into an instance of the
PcPolicyPcCapabilitySet class.
The PcPolicyPcCapabilityComponentInPcCapabilitySet has the following
properties:
Bryskin & Berger Expires September 5, 2007 [Page 57]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
GroupComponent [ref PcPolicyPcCapabilitySet[1..n]]- a pointer to
the instance of the containing (PcPolicyPcCapabilitySet)
class; the cardinality [1..n] means that one or more
instances of the PcPolicyPcCapabilitySet class could be
associated with (that is, contain within itself) the same
instance of the PcPolicyPcCapabilityComponent sub-class by
this association
PartComponent [ref PcPolicyPcCapabilityComponent[1..n]]- a pointer
to the instance of the contained (PcPolicyPcCapabilityComponent
sub-) class; the cardinality [1..n] means that one or more
instances of PcPolicyPcCapabilityComponent sub-class could
be associated with (that is, contained in) the same instance
of the PcPolicyPcCapabilitySet class by this association
3.3.6. PcPolicyPcCapabilitySetInPcCapabilitySet class
PcPolicyPcCapabilitySetInPcCapabilitySet is a class derived from the
PolicyComponentSet class (introduced in [RFC3460]). This is an
association class. It is used for nesting an instance of the
PcPolicyPcCapabilitySet class into another instance of the same
class.
The PcPolicyPcCapabilitySetInPcCapabilitySet has the following
properties:
GroupComponent [ref PcPolicyPcCapabilitySet[0..n]]- a pointer to the
nesting instance of the PcPolicyPcCapabilitySet class;
the cardinality [0..n] means that zero, one or more
instances of the PcPolicyPcCapabilitySet class could nest
the same instance of this class by this association
PartComponent [ref PcPolicyPcCapabilitySet [0..n]]- a pointer to the
nested instance of the PcPolicyPcCapabilitySet class;
the cardinality [0..n] means that zero, one or more
instances of the PcPolicyPcCapabilitySet class could be
nested within the same instance of this class by this
association
3.3.7. PcPolicyPcReqRspComponentInPcSecondaryPathRequest class
It was mentioned in 3.1.12 that PCPIM allows for requesting a
distinct set of PC constraints for each of secondary paths that is
computed concurrently with the primary and zero or more other
secondary paths. Such a complex structure of the path computation
request is modeled by associating an instance of the
Bryskin & Berger Expires September 5, 2007 [Page 58]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
PcPolicyPcSecondaryPathRequest class with zero or more instances of
any of PcPolicyPcReqRspComponent sub-class via separate instances of
the PcPolicyPcReqRspComponentInPcSecondaryPathRequest class. The
class is derived from the Dependency class (introduced in [RFC3060]).
The PcPolicyPcReqRspComponentInPcSecondaryPathRequest has the
following properties:
Antecendent [ref PcPolicySecondaryPathRequest [0..n]]- a pointer to
an instance of the PcPolicySecondaryPathRequest class; the
cardinality [0..n] means that zero, one or more instances
of the PcPolicySecondaryPathRequest class could be associated
with (share) a given instance of a PcPolicyPcReqRspComponent
sub-class by this association
Dependent [ref PcPolicyPcReqRspComponent [0..n]]- a pointer to an
instance of a PcPolicyPcReqRspComponent sub-class; the
cardinality [0..n] means that zero, one or more instances of
PcPolicyPcReqRspComponent sub-classes could be associated
with the same instance of the PcPolicySecondaryPathRequest
class by this association
3.3.8. PcPolicyPcReqRspSetInPcPolicyAction and
PolicyImplicitVariableInPcPolicyAction classes
PC policy actions (such as "Request Path Computation" modeled by the
PcPolicyActionRequestPathComputation class (see 3.4) need to have an
access to the properties of the PC constraints and/or PC policy
variables related to the request.
The access to the PC constraints is modeled by associating an
instance of a PcPolicyAction sub-class with one or more instances of
the PcPolicyPcReqRspSet class via separate instances of the
PcPolicyPcReqRspSetInPcPolicyAction class.
The access to the PC policy variables is modeled by associating an
instance of a PcPolicyAction sub-class with one or more instances of
PolicyImplicitVariable ([RFC3460]) sub-class(es) via separate
instances of the PolicyImplicitVariableInPcPolicyAction class.
The PcPolicyPcReqRspSetInPcPolicyAction class is derived from the
Dependency class (introduced in [RFC3060]).
The class has the following properties:
Antecendent [ref PcPolicyAction [0..n]]- a pointer to an instance of
a PcPolicyAction sub-class; the cardinality [0..n] means that
Bryskin & Berger Expires September 5, 2007 [Page 59]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
zero, one or more instances of one or more PcPolicyAction
sub-class(es) could be associated with (share) a given
instance of the PcPolicyPcReqRspSet class by this association
Dependent [ref PcPolicyPcReqRspSet [0..n]]- a pointer to an instance
of the PcPolicyPcReqRspSet class; the cardinality [0..n]
means that zero, one or more instances of the
PcPolicyPcReqRspSet class could be associated with the
same instance of a PcPolicyAction sub-class by this
association
The PolicyImplicitVariableInPcPolicyAction class is also derived from
the Dependency class.
The class has the following properties:
Antecendent [ref PcPolicyAction [0..n]]- a pointer to an instance of
a PcPolicyAction sub-class; the cardinality [0..n] means that
zero, one or more instances of one or more PcPolicyAction
sub-class(es) could be associated with (share) a given
instance of a PolicyImplicitVariable sub-class by this
association
Dependent [ref PolicyImplicitVariable [0..n]]- a pointer to an
instance of a PolicyImplicitVariable sub-class; the
cardinality [0..n] means that zero, one or more instances
of one or more PolicyImplicitVariable sub-class(es) could
be associated with the same instance of a PcPolicyAction
sub-class by this association
3.3.9. PcPolicyPcCapabilitySetInPcPolicyActionEvaluatePCE class
The "Evaluate PCE" PC action (modeled by the
PcPolicyActionEvaluatePCE class (see 3.4)) needs to have an access to
the properties of the PC capabilities published for any given PCE.
This access is modeled by associating an instance of the
PcPolicyActionEvaluatePCE class with one or more instances of the
PcPolicyPcCapabilitySet class via separate instances of the
PcPolicyPcCapabilitySetInPcPolicyActionEvaluatePCE class. The class
is derived from the Dependency class (introduced in [RFC3060]).
The PcPolicyPcCapabilitySetInPcPolicyActionEvaluatePCE has the
following properties:
Antecendent [ref PcPolicyActionEvaluatePCE [0..n]]- a pointer to an
instance of the PcPolicyActionEvaluatePCE class; the
cardinality [0..n] means that zero, one or more instances
Bryskin & Berger Expires September 5, 2007 [Page 60]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
of the PcPolicyActionEvaluatePCE class could be associated
with (share) a given instance of the PcPolicyPcCapabilitySet
class by this association
Dependent [ref PcPolicyPcCapabilitySet [1..n]]- a pointer to an
instance of the PcPolicyPcCapabilitySet class; the
cardinality [1..n] means that one or more instances of the
PcPolicyPcCapabilitySet class could be associated with the
same instance of the PcPolicyActionEvaluatePCE class by this
association
3.4. Modeling PC actions
PC policies introduced in 3.1 and 3.2 - PC constraints and PC
capabilities - are modeled based on the SimplePolicyCondition and
SimplePolicyAction classes. Applying such policies on a PCC or PCE
PEP results in setting new values for properties of the policy class
instances and/or PC policy variables (see 3.5), but does not require
any processing outside of the rule engine, such as PCC/PCE
reconfiguration or invoking other PCC/PCE software modules. As was
mentioned on several occasions in this document, such approach is
beneficial, because it allows great deal of flexibility in
introducing new policies (that is, new PC constraints and
capabilities) without requiring modification of the PCC/PCE software.
Clearly, not all of the PC policies could be modeled this way. A PCC
PEP, for example, after applying all policies for building a path
computation request (setting necessary PC constraints) and selecting
suitable PCE for the request, needs to actually send the request to
the PCE, that is, invoke a PCC-PCE communication protocol to encode
and deliver the request. Let's call such PC action "Request Path
Computation" action (see more 3.4.2). Note that the PCC PEP rule
engine, while applying PC actions such as the "Request Path
Computation" action, (in sharp contrast with all previously discussed
PC policies) DOES need to understand the semantics of the action,
because it needs to translate the action into actual API call(s).
Also note that the same PC action may be interpreted differently on
different PEPs. For example, the result of the interpretation of the
"Request Path Computation" action on a PCE PEP is one or more calls
to local path computation engine(s), while on a PCC PEP is a local
call to a PCC- PCE communication protocol, such as one introduced in
[PCEP].
Furthermore, two PCC or PCE PEPs may translate the same PC action
into a different set of vendor- and device-specific operations.
An important design goal of PCPIM is to model PC actions via a small
Bryskin & Berger Expires September 5, 2007 [Page 61]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
number of well defined classes, while allowing and encouraging
unlimited introduction (by PC policy writers) of new PC constraints
and capabilities via sub-classing the PCPIM classes, introduced in
sections 3.1 and 3.2, as well as adding new similar classes. PCPIM
classes, modeling the PC actions, are discussed in the remainder of
this section.
3.4.1. PcPolicyAction class
PcPolicyAction is a class derived from the PolicyAction class
introduced in [RFC3060]. PcPolicyAction class is an abstract class,
and hence cannot be directly instantiated. The
PcPolicyActionRequestPathComputation,
PcPolicyActionSendPathComputationResponse and
PcPolicyActionProcessPathComputationResponse are derived from the
PcPolicyAction class. The class has the following properties:
PCEID - IPv4 or IPv6 value specifying the peer PCE ID
PCCID - IPv4 or IPv6 value specifying the peer PCC ID
3.4.2. PcPolicyActionRequestPathComputation class
PcPolicyActionRequestPathComputation is a class derived from the
PcPolicyAction class. The PcPolicyActionRequestPathComputation class
models the "Request Path Computation" PC policy action, mentioned at
the top of 3.4. An instance of the
PcPolicyActionRequestPathComputation class can be associated with
zero or more instances of the PcPolicyPcReqRspSet class(see 3.3.1)
via separate instances of the PcPolicyPcReqRspSetInPcPolicyAction
class (see 3.3.8) and zero or more instances of
PolicyImplicitVariable sub-class(es) (see 3.5) via separate instances
of the PolicyImplicitVariableInPcPolicyAction class (see 3.3.8).
This PC policy action could be informally stated as: "Request path
computation, using the specified set of path computation constraints
and/or path computation policy variables".
The interpretation of the "Request Path Computation" PC policy action
on a PCC PEP informally sounds as: "Encode the associated PC
constraints and PC policy variables into a path computation request;
send the request to the specified peer PCE and wait for the
response". It is assumed that:
a) the PCC-PCE protocol has a transport tool (an opaque object) which
could be used for delivery of the associated PC constraint
policies and PC policy variables;
Bryskin & Berger Expires September 5, 2007 [Page 62]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
b) the transferred by the PCC-PCE protocol PC constraint policies and
PC policy variables could be presented to the PCE PEP in the same
format as local policies (the ones that are delivered to the PCE
PEP from the PCE PDP)
The interpretation of the "Request Path Computation" PC policy action
on a PCE PEP informally could be expressed as follows:
a) Use associated with the path computation request constraints
(properties of PC constraint policy instances) to configure a call
to a local path computation engine;
b) Call the path computation engine;
c) If the path computation fails, relax optional constraints of the
first round of the constraint relaxation (see 3.1.1.) and call the
path computation engine again;
d) If the path computation fails, relax optional constraints of the
next round of the constraint relaxation, and call the path
computation engine again;
e) Repeat the previous step until either the path computation
succeeds or there are no more optional constraints left to relax.
Note that in addition to constraints arriving in the path computation
request a PCE may need to apply a set of local PC constraint policies
(those that are delivered by the PCE PDP). The latter policies could
be specific to a particular request and/or requesting PCC and/or
source/destination/transit PC domains. For example, for certain PCCs
there could be a policy to further constrain the path computation or,
on the contrary, relax some constraints, specified by the PCC. The PC
policy variables sent by the PCC in the request are likely to be an
input for the PCE PEP local policies.
Obviously, the final configuration of the call to the path
computation engine should reflect both local and remote (coming in
the request) policies. It is quite possible that some policies from
one set will contradict the similar policies from another set. For
example, a PCC may require the end-to-end delay optimization for the
path selection, and a local PCE policy may explicitly require not to
ask for such optimization. The PolicyRule priority mechanism,
introduced in [RFC3060] and further enhanced in [RFC3460], could be
used to make sure that local PCE policies always "win".
The PcPolicyActionRequestPathComputation class does not have any
properties.
Bryskin & Berger Expires September 5, 2007 [Page 63]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
3.4.3. PcPolicyActionSendPathComputationResponse class
PcPolicyActionSendPathComputationResponse is a class derived from the
PcPolicyAction class. The PcPolicyActionRequestPathComputation class
models the "Send Response For the Path Computation Request" PC policy
action. An instance of the PcPolicyActionSendPathComputationResponse
class can be associated with zero or more instances of the
PcPolicyPcReqRspSet class(see 3.3.1) via separate instances of the
PcPolicyPcReqRspSetInPcPolicyAction class (see 3.3.8) and zero or
more instances of PolicyImplicitVariable sub-class(es) (see 3.5) via
separate instances of the PolicyImplicitVariableInPcPolicyAction
class (see 3.3.8).
This PC policy action could be informally expressed as follows:
Send a path computation response for the processed path
computation request, providing details on the resulting path(s)
(e.g., actual path costs or end-to-end delay characteristics) and
conditions on which their computation was possible to achieve
(e.g., set of constraints that were relaxed, additionally imposed
or overruled by the PCE), and PC policy variables pertinent to the
response.
This PC policy action is meaningful/applicable only on PCE PEPs.
The PcPolicyActionSendPathComputationResponse class does not have
properties.
3.4.4. PcPolicyActionProcessPathComputationResponse class
PcPolicyActionProcessPathComputationResponse is a class derived from
the PcPolicyAction class. The
PcPolicyActionProcessPathComputationResponse class models the
"Process the Response For the Path Computation Request" PC policy
action. An instance of the
PcPolicyActionProcessPathComputationResponse class can be associated
with zero or more instances of the PcPolicyPcReqRspSet class(see
3.3.1) via separate instances of the
PcPolicyPcReqRspSetInPcPolicyAction class (see 3.3.8) and zero or
more instances of PolicyImplicitVariable sub- class(es) (see 3.5) via
separate instances of the PolicyImplicitVariableInPcPolicyAction
class (see 3.3.8).
The instances of the PcPolicyPcReqRspSet class and
PolicyImplicitVariable sub-class(es) model policy information sent by
the PCE to the requesting PCC about computed paths. Examples include
path costs, end-to-end delay characteristics, relaxed constraints,
Bryskin & Berger Expires September 5, 2007 [Page 64]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
constraints additionally imposed or overruled by the PCE, and the
list of path computation domain IDs the paths will traverse.
This PC policy action could be informally expressed as follows:
"Process a path computation response for the requested path
computation request, possibly generating a new set of constraints
and requesting an additional path computation possibly from a
different PCE".
For example, the result of the processing could be setting new values
for one or more PC policy variables, which PC policies for setting
constraints and selecting PCE depend on.
This PC policy action is meaningful/applicable only on PCC PEPs.
The PcPolicyActionProcessPathComputationResponse class does not have
properties.
3.4.5. PcPolicyActionEvaluatePCE class
PcPolicyActionEvaluatePCE is a class derived directly from the
PolicyAction [RFC3060] class, rather, than from the PcPolicyAction
class as each of the previously described PC policy action classes.
The PcPolicyActionEvaluatePCE class models the "Evaluate PCE For PC
Request" PC policy action. In order to be meaningful an instance of
the PcPolicyActionEvaluatePCE class needs to be associated with one
or more instances of the PcPolicyPcCapabilitySet class (see 3.3.2)
via separate instances of the
PcPolicyPcCapabilitySetInPcPolicyActionEvaluatePCE class (see 3.3.9).
The process of PCE evaluation is described in 3.2.1
This PC policy action could be informally expressed as follows:
"Summarize the pceMetric property of all associated instances of
PcPolicyPcCapabilityComponent sub-classes; store the computed sum
in the PcPolicyEvaluatedPCEMetricVariable and the PCEID of the
evaluated PCE in the PcPolicyEvaluatedPCEIDVariable".
The "Evaluate PCE For PC Request" PC policy action enables the
selection of a PCE for a given path computation request via an
instance of the PolicyRule class ([RFC3060], [RFC3460]) modeling the
following logic:
if(PcPolicyEvaluatedPCEMetricVariable >
PcPolicyPeerPCEMetricVariable)
Bryskin & Berger Expires September 5, 2007 [Page 65]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
then PcPolicyPeerPCEMetricVariable =
PcPolicyEvaluatedPCEMetricVariable;
PcPolicyPeerPCEIDVariable =
PcPolicyEvaluatedPCEIDVariable;
This PC policy action is meaningful/applicable only on PCC PEPs. The
PcPolicyActionEvaluatePCE does not have properties.
3.5. Modeling PC variables
PC policy provides the necessary flexibility for the network operator
to influence on a provisioned service path selection. To accomplish
this objective PC policy needs some input, generated outside of the
policy realm, to be used as conditions for the policy actions.
Specifically, PCPIM needs to connect the PC policies modeled by PCPIM
with the information that is important for the path selection such as
service provisioning/signaling message or SLA contents. For example,
in order to constrain the path computation for a given service, PC
policy needs information about the service setup parameters. In a
model, based on the [RFC3060]/[RFC3460] policy class hierarchies,
such input is modeled via policy implicit variables (the
PolicyImplicitVariable sub-classes). The policy framework defines the
value type and acceptable values for such variables, however, their
actual values are expected to be set before the policy is applied.
Under these circumstances the variables could be associated with
policy conditions and hence produce necessary connection between the
policy and the network state. For instance, the
PcPolicyServiceLinkProtectionFlagsVariable is expected to contain the
link protection flags provisioned for a GMPLS tunnel. The variable
could be associated with one or more instances of the
SimplePolicyCondition class ([RFC3460]), which, in turn, could be
associated with the PC policies, constraining the path computation
request (instances of PcPolicyPcReqRspComponent sub-classes) and/or
selecting a PCE for the computation (instances of
PcPolicyPcCapabilityComponent sub-classes).
The purpose of this section is to define frequently used variables in
PC policy domains that could be used to form PC policy conditions and
actions. The described set could be easily extended. Notice that this
section only adds to the variable classes as defined in [RFC3460] and
reuses the mechanism defined there.
Bryskin & Berger Expires September 5, 2007 [Page 66]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
3.5.1. PcPolicyServiceSourceIPv4Variable
PcPolicyServiceSourceIPv4Variable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
unordered set of IPv4 values specifying all source address(es) of the
provisioned service.
3.5.2. PcPolicyServiceSourceIPv6Variable
PcPolicyServiceSourceIPv6Variable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
unordered set of IPv6 values specifying all source address(es) of the
provisioned service.
3.5.3. PcPolicyServiceDestinationIPv4Variable
PcPolicyServiceDestinationIPv4Variable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
unordered set of IPv4 values specifying all destination address(es)
of the provisioned service.
3.5.4. PcPolicyServiceDestinationIPv6Variable
PcPolicyServiceDestinationIPv6Variable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
unordered set of IPv6 values specifying all destination address(es)
of the provisioned service.
3.5.5. PcPolicyServiceMcstGroupIDVariable
PcPolicyServiceMcstGroupIDVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
integer value specifying network scope unique multicast group ID of
the provisioned point-to-multipoint service.
3.5.6. PcPolicyServiceEncodingTypeVariable
PcPolicyServiceEncodingTypeVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
integer value specifying the provisioned service data encoding type
according to [RFC3471].
Bryskin & Berger Expires September 5, 2007 [Page 67]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
3.5.7. PcPolicyServiceSwitchingTypeVariable
PcPolicyServiceSwitchingTypeVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
integer value specifying the provisioned service data switching type
according to [RFC3471].
3.5.8. PcPolicyServiceGPIDVariable
PcPolicyServiceGPIDVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
integer value specifying the provisioned service GPID type according
to [RFC3471].
3.5.9. PcPolicyServiceBandwidthVariable
PcPolicyServiceBandwidthVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
IEEE floating point format value (PCPolicyFPValue class see 3.6.1)
specifying the provisioned service bandwidth requirements in bytes
per second units.
3.5.10. PcPolicyServiceBandwidthDirectionalityVariable
PcPolicyServiceBandwidthDirectionalityVariable is a class derived
from the PolicyImplicitVariable ([RFC3460]) class. The variable
contains an integer specifying the provisioned service bandwidth
directionality requirements. The acceptable values are:
1 - requested bandwidth must be available only in forward (from
service source to service destination) direction
2 - requested bandwidth must be available only in reverse (from
service destination to service source) direction
3 - requested bandwidth must be available in both directions
3.5.11. PcPolicyServiceBandwidthPriorityVariable
PcPolicyServiceBandwidthPriorityVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
integer from the range {0...7}, specifying the priority level at
which the bandwidth must be available for the service.
Bryskin & Berger Expires September 5, 2007 [Page 68]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
3.5.12. PcPolicyServicePathRecoveryFlagsVariable
PcPolicyServicePathRecoveryFlagsVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains a bit
field specifying the provisioned service path recovery flags as
encoded in the PROTECTION object according to [RFC3471] and
[E2ERECOVERY].
3.5.13. PcPolicyServiceLinkProtectionFlagsVariable
PcPolicyServiceLinkProtectionFlagsVariable is a class derived from
the PolicyImplicitVariable ([RFC3460]) class. The variable contains a
bit field specifying the provisioned service link protection flags as
encoded in the PROTECTION object according to [RFC3471].
3.5.14. PcPolicyServiceNameVariable
PcPolicyServiceNameVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains a
character string specifying the provisioned service readable name.
3.5.15. PcPolicyServiceIncludeAnyVariable
PcPolicyServiceIncludeAnyVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains a bit
field specifying the "IncludeAny" link affinities provisioned for the
service according to [RFC3209].
3.5.16. PcPolicyServiceExcludeAnyVariable
PcPolicyServiceExcludeAnyVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains a bit
field specifying the "ExcludeAny" link affinities provisioned for the
service according to [RFC3209].
3.5.17. PcPolicyServiceIncludeAllVariable
PcPolicyServiceIncludeAllVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains a bit
field specifying the "IncludeAll" link affinities provisioned for the
service according to [RFC3209].
Bryskin & Berger Expires September 5, 2007 [Page 69]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
3.5.18. PcPolicyServiceEROVariable
PcPolicyServiceEROVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
unordered set of the PCPolicyROValue (see 3.6.4 ) values specifying
all Explicit Route Objects (EROs), provisioned for the service
according to [RFC3209].
3.5.19. PcPolicyServiceRROVariable
PcPolicyServiceRROVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
unordered set of the PCPolicyROValue (see 3.6.4 ) values specifying
all Record Route Objects (EROs), generated for the service according
to [RFC3209].
One use of this PC policy variable is to associate it with a path
computation request for a service requiring the "make-before-break"
re- routing.
3.5.20. PcPolicyServiceReferencePointIDVariable
PcPolicyServiceReferencePointIDVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
integer specifying network unique ID of a reference point/SAP/port
the service provisioning/signaling SETUP message was received from.
3.5.21. PcPolicyUserIDVariable
PcPolicyUserIDVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
integer specifying network unique ID of the provisioned service
user/customer as stated in the SLA.
3.5.22. PcPolicyServiceQOSVariable
PcPolicyServiceQOSVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
integer specifying the provisioned service QOS as stated in the SLA.
Bryskin & Berger Expires September 5, 2007 [Page 70]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
3.5.23. PcPolicyServiceCOSVariable
PcPolicyServiceCOSVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
integer specifying the provisioned service COS as stated in the SLA.
3.5.24. PcPolicyServiceAvailabilityVariable
PcPolicyServiceAvailabilityVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
integer specifying the provisioned service availability
characteristic as stated in the SLA.
3.5.25. PcPolicyLocalPCCIDVariable
PcPolicyLocalPCCIDVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
IPv4 or IPv6 value specifying the local PCC ID (the ID of a PCC
controlled by the PCC-PEP applying the PC policy).
3.5.26. PcPolicyLocalPCEIDVariable
PcPolicyLocalPCEIDVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
IPv4 or IPv6 value specifying the local PCE ID ( the ID of a PCE
controlled by the PCE-PEP applying the PC policy).
3.5.27. PcPolicyPeerPCEIDVariable
PcPolicyPeerPCEIDVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
IPv4 or IPv6 value specifying the peer PCE ID ( the ID of a PCE
currently used or selected for a given path computation).
3.5.28. PcPolicyPeerPCEMetricVariable
PcPolicyPeerPCEMetricVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
integer value specifying the PCE metric of a PCE currently used or
selected for a given path computation (PCE metric is described in
3.2.1 and 3.4.5).
Bryskin & Berger Expires September 5, 2007 [Page 71]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
3.5.29. PcPolicyEvaluatedPCEIDVariable
PcPolicyEvaluatedPCEIDVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
IPv4 or IPv6 value specifying the ID of a PCE candidate (the ID of a
PCE currently evaluated for a given path computation).
3.5.30. PcPolicyEvaluatedPCEMetricVariable
PcPolicyEvaluatedPCEMetricVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
integer value specifying the PCE metric of a PCE candidate (a PCE
currently evaluated for a given path computation).
3.5.31. PcPolicyPeerPCCIDVariable
PcPolicyPeerPCCIDVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
IPv4 or IPv6 value specifying the peer PCC ID ( the ID of a PCC
requested currently undergoing path computation).
3.5.32. PcPolicyLocalPCDomainIDVariable
PcPolicyLocalPCDomainIDVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
IPv4 or IPv6 value specifying a network unique ID of the local path
computation domain.
3.5.33. PcPolicySourcePCDomainIDVariable
PcPolicySourcePCDomainIDVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
unordered set of IPv4 or IPv6 values, specifying network unique IDs
of all path computation domains, where the sources of the provisioned
service are located.
3.5.34. PcPolicyDestinationPCDomainIDVariable
PcPolicyDestinationPCDomainIDVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
unordered set of IPv4 or IPv6 values, specifying network unique IDs
of all path computation domains, where the destinations of the
provisioned service are located.
Bryskin & Berger Expires September 5, 2007 [Page 72]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
3.5.35. PcPolicyTransitPCDomainIDVariable
PcPolicyTransitPCDomainIDVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
ordered set of IPv4 or IPv6 values, specifying network unique IDs of
all path computation domains which the provisioned service paths are
expected to traverse.
3.5.36. PcPolicyPcRequestResponseCodeVariable
PcPolicyPcRequestResponseCodeVariable is a class derived from the
PolicyImplicitVariable ([RFC3460]) class. The variable contains an
integer value, specifying the response code for the completed path
computation request.
3.6. Modeling PC values
Values are used in the policy information model as building blocks
for the policy conditions and policy actions, as described in
[RFC3060] and [RFC3460]. This section defines a set of value types
that are used for PC policies. All value classes extend the
PolicyValue class [RFC3460]. The sub-classes specify specific
data/value types that are not defined in [RFC3460].
3.6.1. PCPolicyFPValue
PCPolicyFPValue is a class derived from the PolicyValue ([RFC3460])
class. The values of PC variables and properties of PCPIM classes of
this type must be interpreted as IEEE floating point format values.
For example, this is the only acceptable value type for the
PcPolicyServiceBandwidthVariable class (introduced in 3.5.8).
3.6.2. PCPolicyUnnumLinkIDValue
PCPolicyUnnumLinkIDValue is a class derived from the PolicyValue
([RFC3460]) class. This value type is a combination of IPv4 and
integer values. The values of PC variables and properties of PCPIM
classes, containing unnumbered TE link IDs, are of the
PCPolicyUnnumLinkIDValue type.
Bryskin & Berger Expires September 5, 2007 [Page 73]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
3.6.3. PCPolicyROElementValue
PCPolicyROElementValue is a class derived from the PolicyValue
([RFC3460]) class. This value type is a union of IPv4, IPv6,
PCPolicyUnnumLinkIDValue and integer value types used to specify
values for IPv4 numbered TE link IDs, IPv6 numbered TE link IDs,
unnumbered TE link IDs and resource labels respectively in the RSVP-
TE style Route Objects (EROs and RROs).
3.6.4. PCPolicyROValue
PCPolicyROValue is a class derived from the PolicyValue ([RFC3460])
class. This value type describes an ordered set of
PCPolicyROElementValue values, specifying one RSVP-TE style route
object (ERO or RRO).
4. PCPIM class definition
[This section to be completed based on Section 3.]
5. Security Considerations
The Policy Core Information Model [RFC3060] describes the general
security considerations related to the general core policy model. The
extensions defined in this document do not introduce any additional
considerations related to security.
6. IANA Considerations
None.
7. References
7.1. Normative References
[PCE-POLICY] I. Bryskin, D. Papadimitriou, L. Berger, J. Ash,
"Policy-Enabled Path Computation Framework",
draft-ietf-pce-policy-enabled-path-comp-01.txt,
March 2007
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Bryskin & Berger Expires September 5, 2007 [Page 74]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
[RFC3060] Moore, B., Ellesson, E., Strassner, J. and
A. Westerinen, "Policy Core Information Model --
Version 1 Specification", RFC 3060, February 2001.
[RFC3460] Moore, B., Ed., "Policy Core Information Model
Extensions", RFC 3460, January 2003.
7.2. Informative References
[E2ERECOVERY] J.P. Lang, Ed., Y. Rekhter, Ed., D. Papadimitriou, Ed.,
"RSVP-TE Extensions in support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)-
based Recovery",
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt,
April 2005
[PCEP] J. P. Vasseur, Ed., "Path Computation Element (PCE)
communication Protocol PCEP) - Version 1",
draft-ietf-pce-pcep-02.txt, June 2006
[RFC3198] Westerinen, A., et al., "Terminology for Policy-based
Management", RFC 3198, November 2001
[RFC3209] Awduche, D., et al., "Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3471] L. Berger, Ed.," Generalized Multi-Protocol Label Switching
(GMPLS). Signaling Functional Description", RFC 3741,
January 2003
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling - Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[RFC4202] K. Kompella, Ed., Y. Rekhter, Ed. "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005
[RFC4655] A. Farrel, J. P. Vasseur, J. Ash "A Path Computation
Element (PCE)-based Architecture", RFC 4655, August 2006
Bryskin & Berger Expires September 5, 2007 [Page 75]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
8. Authors' Addresses
Igor Bryskin
Email: i_bryskin@yahoo.com
Lou Berger
LabN Consulting, L.L.C.
Email: lberger@labn.net
9. Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
10. Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
Bryskin & Berger Expires September 5, 2007 [Page 76]
Internet-Draft draft-bryskin-pce-pcpim-01.txt March 5, 2007
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Bryskin & Berger Expires September 5, 2007 [Page 77]
Generated on: Sun Mar 4 09:16:35 EST 2007