One document matched: draft-bryskin-pce-policy-enabled-path-comp-00.txt
Network Working Group Igor Bryskin
Internet Draft Movaz Networks
Category: Informational Dimitri Papadimitriou
Expires: March 2006 Alcatel
Lou Berger
Movaz Networks
October 2005
Policy-Enabled Path Computation Communication Requirements
draft-bryskin-pce-policy-enabled-path-comp-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
Traditionally, path computation entity used to be an intrinsic part
of an LSR's control plane always co-located with the LSRs signaling
I. Bryskin et al. Expires March 2006 Page 1
draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005
and routing subsystems. With introduction of non co-located PCE
capability things in this respect became more complicated. In order
to take advantage of the PCEs new capabilities, it is highly
desirable to introduce new path computation capabilities that
require modifying neither the discovery/communication protocols nor
PCC software.
This document details the requirements to be addressed while
designing and developing mechanisms and protocols enabling policy-
based control over path computation request/decision.
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 RFC 2119 [RFC2119].
1. Terminology and Acronyms
CSPF: Constraint-based Shortest Path First.
LSP: Label Switched Path.
LSR: Label Switching Router.
PCC: Path Computation Client
PCE: Path Computation Element:
TE LSP: Traffic Engineering MPLS Label Switched Path.
CIM: Core Information Model
PCIM: Policy Core Information Model
PCCIM: Path Computation Core Information Model
QPIM: QoS Policy Information Model
PBM: Policy-based Management
PEP: Policy Enforcement Points
PDP: Policy Decision Points
COPS: Common Open Policy Service
COPS-PR: COPS Usage for Policy Provisioning
2. Motivation
Traditionally, path computation entity used to be an intrinsic part
of an LSR's control plane always co-located with the LSRs signaling
and routing subsystems. Such architectural approach allowed for
unlimited flexibility in providing various path computation
enhancements û adding new types of constraints, diversities and
their relaxation strategies, adopting new objection functions and
optimization criterions, etc. All what had to be done was to upgrade
the control plane software of only this particular LSR (and no other
LSRs or any other network elements).
With introduction of non co-located PCE capability things in this
respect became more complicated: with the TLV-style PCE discovery
I. Bryskin et al. Expires March 2006 Page 2
draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005
and PCC-PCE communication protocols that are currently discussed
within PCE WG, it won't be enough for a PCE to upgrade its own
software. In order to take advantage of the PCEs new capabilities,
new TLVs for both protocols need to be standardized, all PCCs need
to be upgraded with new software, new interoperability problems need
to be resolved, etc. It would be highly desirable to find a way of
introducing new path computation capabilities that requires
modifying neither the discovery/communication protocols nor PCC
software.
3. Overview
Policy-based Management (PBM) enables network administrators to
operate in a high-level manner through rule-based policies; the
latter are translated automatically into individual device
configuration directives, aiming at controlling a network as a
whole. Two IETF Working Groups have in the past considered policy
networking: The Resource Allocation Protocol working group and the
Policy Framework working group.
A framework for policy-based admission control [RFC2753] was defined
and a protocol for use between Policy Enforcement Points (PEP) and
Policy Decision Points (PDP) was specified: Common Open Policy
Service (COPS) [RFC2748]. This document uses the terms PEP and PDP
to refer to the functions defined in the COPS context. This document
makes no assumptions nor requires that the actual COPS protocol be
used.
The IETF has also produced a general framework for representing,
managing, sharing, and reusing policies in a vendor independent,
interoperable, and scalable manner. It has also defined an
extensible information model for representing policies, called the
Policy Core Information Model (PCIM) [RFC3060], and an extension to
this model to address the need for QoS management, called the QoS
Policy Information Model (QPIM) [RFC3644]. However, additional
mechanisms are needed in order to specify policies related to the
path computation logic as well as its control.
One way to achieve this objective is to consider constraints, their
relaxations and objection functions as path computation request
specific policies that on one hand could be configured and managed
by an operator, and on the other hand could be interpreted in real
time by both PCCs and PCEs.
4. Rationale
There is a number of advantages and useful by-products of such
approach:
I. Bryskin et al. Expires March 2006 Page 3
draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005
- New path computation capabilities could be introduced with
changing neither PCE-PCC communication and discovery protocols nor
PCC software. Only software of a PCE supporting new capabilities
needs to be updated
- Existing constraints, objection functions and their relaxations
could be aggregated and otherwise associated together, thus,
producing new more complex ones that do not require change of code
even on PCEs supporting them
- Different elements such as conditions, actions, variables, etc.
could be re-used by multiple constraints/diversities/optimizations
- Both PCCs and PCEs need to handle other (that is, not request
specific) policies (see below). Such policies could be placed within
the same policy repositories, could be managed by the same policy
management tools and could be interpreted using the same mechanisms
as request-specific policies.
The last bullet requires some more explanations. A PCE should be
capable to apply client- and/or domain-specific policies, and, in
some cases, service-specific policies, to decide on which algorithms
to use while performing path computations requested from a
particular PCC or for a particular domain; whether to seek for
cooperation of other PCEs to satisfy a particular request or handle
it on its own (possibly responding with non ûexplicit paths), etc.
Likewise, a PCC should be capable to handle service-specific
policies to decide which optimizations, constraints, diversities and
their relaxation strategies to request while computing path(s) for a
particular service. Depending on SLAs, TE and price-performance
goals path computation requests could be built differently for
different services. Service A, for instance, may require two SRLG-
disjoint paths for building end-to-end recovery scheme, while for
service B link-disjoint paths may be sufficient. Service A may need
paths with minimal end-to-end delay, while service B may be looking
for shortest (minimal-cost) paths. Different constraint relaxation
strategies could be applied while computing paths for service A and
for service B, and so forth. Another, simpler example is that
Service A may use one PCE while Service B uses another.
Finally, additional policies need to be supported by a PCE.
Consider, for example, the case when a group of PCEs cooperate
together in satisfying a particular path computation request. A PCE
needs to decide how the request should be modified (perhaps, using
identity of the original PCC and/or domain specific information)
before being sent to other PCE(s) in the group.
Note that in the context of this document "service-specific" means
"user service ûspecific", that is, specific to a user service for
which path computation needs to be performed and LSPs set up. This
should not be confused with "request specific", that is, specific to
I. Bryskin et al. Expires March 2006 Page 4
draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005
a particular path computation request. Service-specific policies are
applied by policy-capable PCCs or conveyed to and applied by PCEs in
case the latter deal with policy incapable PCCs.
The described (non-request specific) policies need to be supported
by PCCs and PCEs independently from the style of PCC-PCE
communication protocols. Thus, introducing a new (request specific)
type of policies describing constraints and other elements of a path
computation request seems to be a natural and relatively inexpensive
addition to the policy enabled path computation architecture.
5. Goals and Requirements
The following requirements need to be addressed while designing and
developing mechanisms and protocols enabling policy-based control
over path computation request/decision.
- Policies vs Mechanisms: this document only outlines the
communication elements and mechanisms needed to allow a wide variety
of possible policies to be applied for path computation control but
it does not include any discussion of any specific policy behavior
or does not require use of specific policies
- GMPLS path computation-specific: the mechanisms must be designed
to meet the policy-based control requirements specific to the
problem of path computation using RSVP-TE as the signaling protocol
on MPLS LSR, GMPLS LSR, but not limited to this as the mechanisms
should work just as well for other types of PCCs such as NMS,
network planner, etc.
- Support for many policies: the mechanisms designed must include
support for many policies and policy configurations. In general, the
determination and configuration of viable policies are the
responsibility of the service provider.
- Provision for Monitoring and Accounting Information: The
mechanisms must include support for monitoring policy state, and
provide access information. In particular, mechanisms must be
included to provide usage and access information that may be used
for accounting purposes.
- Fault tolerance and recovery: The mechanisms designed on the basis
of this framework must include provisions for fault tolerance and
recovery from failure cases such as failure of PCC/PCE PDPs,
disruption in communication that separate a PCC/PCE PDP from its
associated PCC/PCE PEPs.
- Support for policy-ignorant nodes: Support for the mechanisms
described in this document should not be mandatory for every node in
I. Bryskin et al. Expires March 2006 Page 5
draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005
a network. Policy based path computation control could be enforced
at a subset of nodes, for example the boundary nodes within an
administrative domain. These capable nodes would function as trusted
nodes from the point of view of the policy-ignorant nodes in that
administrative domain. Alternatively, policy may be applied solely
on PCEs with all PCCs being policy-ignorant nodes.
- Scalability: One of the important requirements for the mechanisms
designed for policy control is scalability. The mechanisms must
scale at least to the same extent that RSVP-TE signaling scales in
terms of accommodating multiple LSPs and network nodes in the path
of an LSP. There are several sensitive areas in terms of scalability
policy based path computation control. First, not every policy aware
node in an infrastructure should be expected to contact a remote
PDP. This would cause potentially long delays in verifying requests.
Then, the policy control architecture must scale at least as well as
RSVP-TE based on factors such as the size of RSVP-TE messages, the
time required for the network to service an RSVP-TE request, local
processing time required per node, and local memory consumed per
node. These scaling considerations are of particular importance
during re-routing of a set of LSPs.
- Security and denial of service considerations: The policy control
architecture must be secure as far as the following aspects are
concerned. First, the mechanisms proposed must minimize theft and
denial of service threats. Second, it must be ensured that the
entities (such as PEPs and PDPs) involved in policy control can
verify each other's identity and establish necessary trust before
communicating.
6. Path Computation Core Information Model (PCCIM)
The Policy Core Information Model (PCIM) introduced in RFC3060 and
expanded in RFC 3460 presents the object-oriented information model
for representing general policy information.
This model defines two hierarchies of object classes:
- structural classes representing policy information and control of
policies
- association classes that indicate how instances of the structural
classes are related to each other.
These classes could be mapped to various concrete implementations,
for example, to a directory that uses LDAPv3 as its access protocol.
Figure 1 shows an abstract from the class inheritance hierarchy for
PCIM.
ManagedElement (abstract)
I. Bryskin et al. Expires March 2006 Page 6
draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005
|
+--Policy (abstract)
| |
| +---PolicySet (abstract)
| | |
| | +---PolicyGroup
| | |
| | +---PolicyRule
| |
| +---PolicyCondition (abstract)
| | |
| | +---PolicyTimePeriodCondition
| | |
| | +---VendorPolicyCondition
| | |
| | +---SimplePolicyCondition
| | |
| | +---CompoundPolicyCondition
| | |
| | +---CompoundFilterCondition
| |
| +---PolicyAction (abstract)
| | |
| | +---VendorPolicyAction
| | |
| | +---SimplePolicyAction
| | |
| | +---CompoundPolicyAction
| |
| +---PolicyVariable (abstract)
| | |
| | +---PolicyExplicitVariable
| | |
| | +---PolicyImplicitVariable
| | |
| | +---(subtree of more specific classes)
| |
| +---PolicyValue (abstract)
| |
| +---(subtree of more specific classes)
|
Figure 1: PCIM Class Inheritance
The policy classes and associations defined in PCIM are sufficiently
generic to allow them to represent policies related to anything.
Policy models for application-specific areas such as the Path
Computation Service may extend the PCIM in several ways. The
I. Bryskin et al. Expires March 2006 Page 7
draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005
preferred way is to use the PolicyGroup, PolicyRule, and
PolicyTimePeriodCondition classes directly as a foundation for
representing and communicating policy information. Then, specific
subclasses derived from PolicyCondition and PolicyAction can capture
application-specific definitions of conditions and actions of
policies. Two subclasses, VendorPolicyCondition and
VendorPolicyAction, are also defined to provide a standard extension
mechanism for vendor-specific extensions to the Policy Core
Information Model.
Thus, Path Computation Core Information model could be built with
the PCConstraint, PCDiversity, PCConstraintRelaxation,
PCDiversityRelaxation, PCObjectionFunction, etc. as examples of the
PCCIM basic objects.
7. Policy Enabled Path Computation Framework
7.1 PCC-PCE Configurations
Path Computation Policies are instantiated using the PCCIM objects
created using the PCIM class library as a foundation. PC Policies
are configured and managed within the PC Policy Repository by the PC
Policy Management Tool.
There could be configurations with:
o) Single Policy Repository
In this configuration there is a single policy repository shared
between PCCs and PCEs.
I. Bryskin et al. Expires March 2006 Page 8
draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005
........................
. .
. PC Policy Management .
. .
........................
.
.
--------- Policy a ---------------------- Policy b ---------
| PCC-PDP |<--------- | PC Policy Repository | -------->| PCE-PDP |
--------- ---------------------- ---------
^ ^
| e.g., COPS e.g., COPS |
v v
--------- ---------
| PCC-PEP |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol ---------
Figure 2: Single PCC/PCE Policy Repository
o) Multiple Policy Repositories
The repositories in this case could be fully or partially
synchronized by some discovery/ synchronization management protocol
or could be completely independent. Note when PC Policy Repository A
= B the result is the single policy repository.
-------------- --------------
| PC Policy | | PC Policy |
---| Repository A | | Repository B |---
| -------------- -------------- |
| |
| Policy a Policy b |
| |
v v
--------- ---------
| PCC-PDP | | PCE-PDP |
--------- ---------
^ ^
| e.g., COPS e.g., COPS |
v v
--------- ---------
| PCC-PEP |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol ---------
Figure 3: Multiple PCE/PCC Policy Repositories
I. Bryskin et al. Expires March 2006 Page 9
draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005
A PCC is logically split into two parts: PCC-PDP (Policy Decision
Point) and PCC-PEP (Policy Enforcement Point). When present, a PCC-
PEP is co-located with a Path Computation Service User û entity that
requires remote path computation (for example, the GMPLS control
plane of an LSR). The PCC-PEP and PCC-PDP could be physically co-
located (as per [RFC2748]) or separated. In the later case they talk
to each other via such protocols as COPS and/or COPS-PR [RFC3084].
Likewise, a PCE is logically split into two parts: PCE-PEP and PCE-
PDP. When present, PCE-PEP is co-located with a Path Computation
Engineû entity that actually provides the actual Path Computation
Service (that is, runs path computation algorithms). PCE-PEP and
PCE-PDP could be physically co-located or separated. In the later
case they communicate using such protocols as COPS and/or COPS-PR.
PCC-PDP/PCE-PDP could be co-located with or separated from the
associated PC Policy Repository. In the latter case the PDPs use
some access protocol (for example, LDAPv3 or SNMP). The task of PDPs
is to retrieve policies from the repository(ies) and convey them to
respective PEPs either in unsolicited way or upon the PEP requests.
The task of the PCC-PEP is to select the PCE and build path
computation requests applying service specific policies provided by
the PCC-PDP. The task of the PCE-PEP is to control path computations
by applying requests-specific policies found in the requests as well
as client- and domain-specific policies supplied by the PCE-PDP.
Note that a PCC request may include service specific information,
for which the PCE-PEP must apply service specific policies in order
to define actual path computation parameters. Figure 4 shows an
example where PCCs are policy ignorant and the PCE/PCC request would
always include service specific information. Another example would
use the components shown in ether Figure 2 or 3, but the policy
applied at the PCC would be limited to selecting a PCE. In this case
the path computation request should contain service specific
information, so that the chosen PCE could identify actual path
computation parameters (applying local service specific policies).
I. Bryskin et al. Expires March 2006 Page 10
draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005
........................
. .
. PC Policy Management .
. .
........................
.
.
---------------------- Policy ---------
| PC Policy Repository | -------->| PCE-PDP |
---------------------- ---------
^
e.g., COPS |
v
--------- ---------
| PCC |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol ---------
Figure 4: PCE Policy Repository with Policy Ignorant PCC
On the other hand, it is also possible for policy to only be applied
at the PCC. In this case the applied policy would be embodied in any
requests to the PCE, e.g., in the form of constraints.
This configuration is shown in Figure 5.
........................
. .
. PC Policy Management .
. .
........................
.
.
--------- Policy ----------------------
| PCC-PDP |<--------- | PC Policy Repository |
--------- ----------------------
^
| e.g., COPS
v
--------- ---------
| PCC-PEP |<------------------------------------------->| PCE |
--------- PCC-PCE Communication Protocol ---------
Figure 5: PCC Policy Repository with Policy Ignorant PCE
7.2 Cooperating PCE Configurations
The previous section shows the relationship between PCCs and PCEs.
I. Bryskin et al. Expires March 2006 Page 11
draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005
A parallel relationship exists between cooperating PCEs, and in fact
this relationship can be viewed as the same as the relationship
between PCCs and PCEs. The one notable difference is that there will
be cases where having a shared Policy Repository will not be
desirable, for example when the PCEs are managed by different
entities. Although, to identify a usable path it remains necessary
for there to be consistent policies across domains.
The following are example configurations. These examples do not
represent an exhaustive list and other configurations are expected.
o) Single Policy Repository
In this configuration there is a single policy repository shared
between PCEs. This configuration is likely to be useful within a
single administrative domain where multiple PCEs are provided for
redundancy or load distribution purposes. This configuration is also
applicable for administrative domains with single PCE.
........................
. .
. PC Policy Management .
. .
........................
.
.
--------- Policy a ---------------------- Policy b ---------
| PCE-PDP |<--------- | PC Policy Repository | -------->| PCE-PDP |
--------- ---------------------- ---------
^ ^
| e.g., COPS e.g., COPS |
v v
--------- ---------
| PCE-PEP |<------------------------------------------->| PCE-PEP |
--------- PCE-PCE Communication Protocol ---------
Figure 6: Single PCC Policy Repository
o) Multiple Policy Repositories
The repositories in this case could be fully or partially
synchronized by some discovery/synchronization management protocol
or could be completely independent. In the multi-domain case, it is
expected that these repositories would be distinct, but provide
consistent policies.
I. Bryskin et al. Expires March 2006 Page 12
draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005
-------------- --------------
| PC Policy | | PC Policy |
---| Repository A | | Repository B |---
| -------------- -------------- |
| |
| Policy a Policy b |
| |
v v
--------- ---------
| PCE-PDP | | PCE-PDP |
--------- ---------
^ ^
| e.g., COPS e.g., COPS |
v v
--------- ---------
| PCE-PEP |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol ---------
Figure 7: Multiple PCC Policy Repositories
7.3 Inter-Component Communication
PCC-PEP and PCE-PEP, and PCE-PEPs communicate via a PCC-PCE
(request-response) Communication Protocol. This document makes no
assumptions as to what protocol is used to support this protocol.
This document does assume that the semantics of a Path computation
requests are very abstract and general, and supports both PCE-PCC
and PCE-PCE communication].
The Path computation request includes:
. One or several source addresses;
. One or several destination addresses;
. Computation type (P2P, P2MP, MP2P, etc.);
. Number of required paths;
. Zero or more policy descriptors in the following format:
<policy name>,
<policy variable1 name>, <param11>, <param12>,...,<param1N>
<policy variable2 name>, <param21>, <param12>,...,<param2N>
...
<policy variableM name>, <paramM1>, <paramM2>,...,<paramMN>
The Path computation response would include the list of computed
path using the same format
The PCC-PCE Communication Protocol should not understand nor makes
any assumptions about the semantics of policies specified in the
path computation requests.
I. Bryskin et al. Expires March 2006 Page 13
draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005
Note: This document explicitly allows for the PCC-PDP to decide that
all necessary constraints, objection functions, etc. pertinent for
the computation of paths for the service in question are to be
determined by the PCE performing the computation. In this case the
PCC-PDP will use a set of policies describing the above mentioned
service specific information. These policies could be placed within
the path computation request and delivered to the PCE via PCC-PCE
Communication Protocol. The PCE (more precisely, PCE-PEP) is
expected to understand this information and use it to determine the
constraints and optimization functions applying local policies (that
is, policies locally configured or provided by the PCE-PDP).
8. Sequence of events happening during path computation
This section presents representative scenarios; other scenarios are
also possible.
8.1 Policy-enabled PCC, Policy-enabled PCE
Let us consider what happens after a service has been provisioned to
originate from a GMPLS LSR (or the LSR has received a Setup (RSVP
Path) message from an upstream LSR), and the LSR decides to use a
non co-located Path Computation Entity.
- A PCC-PEP co-located with the LSR applies the service specific
policies to select a PCE for the service path computation as well
as to build the path computation request (that is, to select a
list of policies, their variables and parameters expressing
constraints, diversities, objection functions and relaxation
strategies appropriate for the service path computation). The
policies could be:
a) Statically configured on the PCC-PEP;
b) Communicated to the PCC-PEP by a remote or local PCC-PDP
via protocol such as COPS either pro-actively (most of
the cases) or upon an explicit request by the PCC-PEP
(in case when some specifics of the new service have not
been covered yet by the policies so far known to the
PCC-PEP)
The input for the decision process on the PCC-PEP is the
information found in the signaling/provisioning message as well
as any other service specific information such as port ID
over which the message was received, associated VPN ID, the
reference point type (UNI, E-NNI, etc.) and so forth. After the
path computation request is built it is sent directly to the PCE-
PEP using the PCC-PCE Communication Protocol.
- PCE-PEP validates and otherwise processes the request applying
the policies found in the request as well as client and domain
specific polices. The latter, again, could be either statically
I. Bryskin et al. Expires March 2006 Page 14
draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005
configured on the PCE-PEP or provided by the associated local or
remote PCE-PDP via a protocol such as COPS. The outcome of the
decision process is the following information:
a) Whether the request should be satisfied, rejected or
dismissed
b) The sets of sources and destinations for which paths
should be locally computed
c) The set of constraints, diversities, optimization
functions and relaxations to be considered in each of
locally performed path computation
d) The address of the next-in-chain PCE;
e) The path computation request to be sent to the next-in-
chain PCE
The PCE-PEP instructs a co-located path computation engine to
perform the local path computation(s) and, if necessary, sends
the path computation request to the next-in-chain PCE using the
PCC-PCE Communication Protocol. Then it waits for the responses
from the local path computation engine and the remote PCE,
combines the resulting paths and sends them back to the PCC-PEP
using the PCC-PCE Communication Protocol. The response contains
policies describing the resulting paths as well as some
additional information (for example, which of constraints were
honored, which were dismissed and which were relaxed and in what
way)
- PCC-PEP instructs the signaling sub-system of the GMPLS LSR to
encode the received path(s) into the outgoing Setup message(s)
8.2 Policy-ignorant PCC, Policy-enabled PCE
This case parallels the previous example, but the service level
policy must be applied at the PCE as the PCC is policy ignorant.
Again, we consider what happens after a service has been provisioned
to originate from a GMPLS LSR (or the LSR has received a Setup (RSVP
Path) message from an upstream LSR), and the LSR decides to use a
non co-located Path Computation Entity.
- The PCC constructs a PCE request using information found in the
signaling/provisioning message as well as any other service
specific information such as port ID over which the message was
received, associated VPN ID, the reference point type (UNI, E-
NNI, etc.) and so forth. After the path computation request is
built it is sent directly to the PCE-PEP using the PCC-PCE
Communication Protocol.
- PCE-PEP validates and otherwise processes the request applying
the policies found in the request as well as client and domain
specific polices. The PCE-PEP applies the service specific
policies to select a PCE for the service path computation as well
I. Bryskin et al. Expires March 2006 Page 15
draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005
as to build the path computation request (that is, to select a
list of policies, their variables and parameters expressing
constraints, diversities, objection functions and relaxation
strategies appropriate for the service path computation). The
policies, again, could be either statically configured on the
PCE-PEP or provided by the associated local or remote PCE-PDP via
a protocol such as COPS. The outcome of the decision process is
the following information:
a) Whether the request should be satisfied, rejected or
dismissed
b) The sets of sources and destinations for which paths
should be locally computed
c) The set of constraints, diversities, optimization
functions and relaxations to be considered in each of
locally performed path computation
d) The address of the next-in-chain PCE;
e) The path computation request to be sent to the next-in-
chain PCE
The PCE-PEP instructs a co-located path computation engine to
perform the local path computation(s) and, if necessary, sends
the path computation request to the next-in-chain PCE using the
PCC-PCE Communication Protocol. Then it waits for the responses
from the local path computation engine and the remote PCE,
combines the resulting paths and sends them back to the PCC-PEP
using the PCC-PCE Communication Protocol. The response contains
policies describing the resulting paths as well as some
additional information (for example, which of constraints were
honored, which were dismissed and which were relaxed and in what
way)
- PCC-PEP instructs the signaling sub-system of the GMPLS LSR to
encode the received path(s) into the outgoing Setup message(s)
9. Introducing a new constraint supported by a PCE
Let us assume that a PCE has been upgraded with software supporting,
optical physical impairment constraint such as Polarization Mode
Dispersion (PMD) that previously has not been supported in the
domain. In this case one or more new policies will be installed in
the PC Policy Repository (associated with the PCE) defining the
constraint (rules that determine application criteria, set of
variables and valid parameters, etc.) and its relaxation
strategy(ies). The new policies will be also propagated into other
PC Policy Repositories within the domain via discovery/
synchronization protocols or via local configuration. PCE and PCC
PDPs will then retrieve the corresponding policies from the
repository(ies). From then on PCC-PDPs will instruct associated PCC-
PEPs to add the new policies into path computation requests for
I. Bryskin et al. Expires March 2006 Page 16
draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005
services with certain parameters (for example, for services
provisioned in the OCh layer).
It is important to note that policy enabled path computation model
naturally solves the PCE capability discovery issues. Suppose a
PCE working in a single PC Policy Repository configuration starts to
support a new constraint. Once a corresponding policy installed in
the repository, it automatically becomes available for all
repository users, that is, PCCs. In the multi-repository case some
policy synchronization must be provided, however, this problem is
one of the management plane, it is solved already and in a much
scalable way than using IGP-TE.
10. Acknowledgements
We would like to thank Bela Berde for fruitful discussions on PBM
and Policy-driven path computation.
11. IANA Considerations
None.
12. Reference
12.1 Normative Reference
[RFC2205] Braden, R., et al., "Resource ReSerVation Protocol
(RSVP) - Version 1, Functional Specification", RFC 2205,
September 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997.
[RFC2753] R. Yavatkar, D. Pendarakis, R. Guerin, A Framework for
Policy Based Admission Control, RFC 2753, January 2000.
[RFC2748] D. Durham, et al., The COPS (Common Open Policy Service)
protocol, RFC 2748, IETF, January 2000.
[RFC3060] B. Moore, et al., Policy Information Model Version1
Specification, RFC 3060, February 2001.
[RFC3209] Awduche, D., et al., "Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., et al., Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description, RFC
3471, January 2003.
I. Bryskin et al. Expires March 2006 Page 17
draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005
[RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[RFC3644] Y. Snir, et al., Policy Quality of Service (QoS)
Information Model, RFC 3644, November 2003.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3667, February 2004.
[RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
12.2 Informative Reference
13. Author's Addresses
Igor Bryskin
Movaz Networks, Inc
Phone: +1 703-847-4208
Email: ibryskin@movaz.com
Dimitri Papadimitriou (Alcatel)
Fr. Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: dimitri.papadimitriou@alcatel.be
Lou Berger
Movaz Networks, Inc
Phone: +1 703-847-1801
Email: lberger@movaz.com
I. Bryskin et al. Expires March 2006 Page 18
draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
I. Bryskin et al. Expires March 2006 Page 19
| PAFTECH AB 2003-2026 | 2026-04-23 03:42:32 |