Internet DRAFT - draft-berger-pce-policy-architecture
draft-berger-pce-policy-architecture
Internet Draft Lou Berger (Movaz Networks)
Category: Informational Igor Bryskin (Movaz Networks)
Expiration Date: April 2006 Dimitri Papadimitriou (Alcatel)
October 2005
PCE Policy Architecture
draft-berger-pce-policy-architecture-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
The PCE architecture [PCE-ARCH] introduces the concept of path
computation related policy at a high level. This document provides
additional details on policy as applied to the PCE architecture.
Berger, et. al. & [Page 1]
Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005
Contents
1 Introduction .............................................. 3
1.1 PCE Components ............................................ 3
1.2 Areas for Standardization ................................. 9
2 PCE Policy Architecture ................................... 10
2.1 Types of Policies ......................................... 10
2.1.1 User and Request Specific Policies ........................ 10
2.1.2 Client and Server Specific Policies ....................... 10
2.1.3 Local and Domain Specific Policies ........................ 11
2.2 Policy Application ........................................ 11
2.3 Policy Communication Support .............................. 13
2.4 PCE Discovery Policy Considerations ....................... 13
2.5 Policy Management ......................................... 14
3 Representative Policy Scenario ............................ 14
3.1 Scenario: Policy Configured Paths ......................... 15
3.2 Scenario: Provider Selection Policy ....................... 16
3.3 Scenario: Policy Based Constraints ........................ 17
4 Security Considerations ................................... 18
5 IANA Considerations ....................................... 19
6 References ................................................ 19
6.1 Normative References ...................................... 19
6.2 Informative References .................................... 19
7 Authors' Addresses ........................................ 20
8 Full Copyright Statement .................................. 20
9 Intellectual Property ..................................... 20
Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005
1. Introduction
The PCE architecture is introduced in [PCE-ARCH]. This document
describes the impact policy on the PCE architecture. Other
documents, for example [PCE-POL-COMMS], will provide implications on
more detailed aspects of PCE implementation.
Policy impacts multiple aspects of the PCE architecture. The first
is internal impact; the second is impact on PCE related
communication.
It is envisioned that policy will be largely applied as a local mater
within each PCE. That said, it is necessary to define the policy
models that the PCE architecture can support. Some example policies
include rejection of a request based on requesting PCC or identified
constraints, selection of a path based on the computation target, or
the selection of a path based on the time of day. The definition of
supported policy models will drive PCE solutions and will enable
proper and complete evaluation of specific PCE solutions. PCE
supported policy models are discussed later in this document.
While the implementation and enforcement of policy is largely a local
matter, the policies that may be applied impact the communication
protocols used to support PCE. This includes PCC-PCE, PCE-PCE and
PCE discovery communication. The primary impact is to the
information carried by the protocols. To a lesser degree, policy
support requirements may also drive the required protocol
transactions. As the more detailed requirements for each PCE
communication protocol is defined, it is important for these
documents to articulate supported (and unsupported) policy models and
the related requirements. Also, any defined solution must be
evaluated on its ability to support these policy models and
requirements.
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.1. PCE Components
From a component perspective, PCE policy is supported via a Policy
Database. The Policy database provides non-TE information and is
used by a PCE when responding to a requested path computation.
Additionally, policy may also be used to govern what requests are
made to the PCE from a PCC. [PCE-ARCH] shows the PCE architecture
applied to four different node configurations. Figures 1 through
Figure 4 shows these configurations updated to reflect PCE Policy.
Berger, et. al. & [Page 3]
Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005
In each configuration, policy is consulted before a response is
provided by a PCE. A PCE may have local policy information that
impacts the one or more paths selected to satisfy a particular PCE
request. A local policy may be applied based on any information
provided from a PCC. The policy may have any number of results
including, for example, rejecting the request, identifying one or
more paths that provide different quality of service, or providing
one or more paths that have different costs, different end-to-end
delays or other different characteristics. Additionally, changes in
PCE policy may lead to a change to a previously provided path.
Another, important policy decision is the one related to the TED
selection. Indeed, the selection of the TED repository for the path
computation itself can be subject to policing. This means that this
document extends the PCE architecture by allowing the access point to
the PCE to be disjoint from the access point to the TED that will be
used for path computation purposes. This extension will likely
impact inter-PCE communication, and selection of a "next PCE" when
multiple PCEs are involved during the path computation.
Path computation related policy must also be sensitive to where it is
being applied. For example, a different set of policies may be
applied for an intra-area or single-layer PCE request, than would be
provided for an inter-area or multi-layer PCE request.
In each configuration, all policy decisions are made independently at
each PCE based on information passed from the previous PCE.
Alternatively, in the multiple PCE path computation with inter-PCE
communication configuration, see Figure 4, there is likely to be
explicit communication of policy information between PCEs. The type
of information conveyed to support policy will have significant
implications on what policies may be applied at each PCE.
Note that while the policy component is shown as co-resident, the
policy database may be implemented using some form of distributed
database. Such distributed approaches have no impact on the PCE
policy architecture and are therefore out of scope of this document.
Berger, et. al. & [Page 4]
Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005
------------------------------
| --------- | Routing ----------
| | | | Protocol | |
| | TED |<-+----------+-> |
| | | | | |
| --------- | | |
| | | | |
| | Input | | |
| v | | |
| --------- --------- | | |
| | Policy | | | | | Adjacent |
| | Database|<-->| PCE | | | Node |
| | | | | | | |
| --------- --------- | | |
| ^ | | |
| |Request | | |
| |Response| | |
| v | | |
| --------- | | |
Service | | | | Signaling| |
Request | |Signaling| | Protocol | |
------+---------------->| Engine |<-+----------+-> |
| | | | | |
| --------- | ----------
------------------------------
Figure 1. Composite PCE Node
Berger, et. al. & [Page 5]
Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005
----------------------
| ----- |
| | TED |<-+------------>
| ----- | TED synchronization
| | | mechanism (e.g.,, routing protocol)
| | |
| v |
| ------ ----- |
| |Policy|<-->| PCE | |
| ------ ----- |
----------------------
^
| Request/
| Response
v
Service ---------- Signaling ----------
Request| Head-End | Protocol | Adjacent |
---->| Node |<---------->| Node |
---------- ----------
Figure 2. External PCE Node
------------------ -------------------
| | | |
| PCE | | PCE |
| | | |
| ------ ----- | | ----- ------ |
| |Policy| | TED | | | | TED | |Policy| |
| ------ ----- | | ----- ------ |
------------------ -------------------
^ ^
| Request/ | Request/
| Response | Response
v v
Service -------- Signaling ------------ Signaling ------------
Request|Head-End| Protocol |Intermediate| Protocol |Intermediate|
---->| Node |<--------->| Node |<--------->| Node |
-------- ------------ ------------
Figure 3. Multiple PCE Path Computation
Berger, et. al. & [Page 6]
Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005
------------------ ------------------
| | Inter-PCE Request/Response | |
| PCE |<-------------------------->| PCE |
| | | |
| ------ ----- | | ------ ----- |
| |Policy| | TED | | | |Policy| | TED | |
| ------ ----- | | ------ ----- |
------------------ ------------------
^
| Request/
| Response
v
Service ---------- Signaling ---------- Signaling ----------
Request| Head-End | Protocol | Adjacent | Protocol | Adjacent |
---->| Node |<---------->| Node |<---------->| Node |
---------- ---------- ----------
Figure 4. Multiple PCE Path Computation with Inter-PCE Communication
The PCE architecture allows for there to be multiple PCEs for a
number of reasons, including for redundancy or for distributed path
computation purposes. Independent of purpose, in the configurations
where multiple PCEs exist, the Policy Databases should be consistent
across the PCEs in order for a PCE request to be satisfied as
intended. The means by which such consistency is established is
viewed as a configuration issue. The policy configuration interface
is not specified or restricted by the PCE Policy Architecture. The
interface may be purely a local matter, or may be supported via a
standardized interface or policy distribution mechanism (e.g., MIB or
LDAP.)
Policy may also play a part in the selection of a PCE by a PCC when
multiple PCEs exists, see Figures 3 and 4. Policy may also influence
a request made by a PCC to a PCE. Figure 5, shows the PCC components
used to support the application of such policy. Note Figure 5 also
allows for multiple PCEs.
Berger, et. al. & [Page 7]
Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005
----------------------
| ----- |
| | TED |<-+------------>
| ----- | TED synchronization
| | | mechanism (e.g., routing protocol)
| | |
| v |
| ------ ----- | Inter-PCE Request/Response
| |Policy|<-->| PCE |<.+...........> (when present)
| ------ ----- |
----------------------
^
| Request/
| Response
v
Service ------------- Signaling
Request|[PCC][Policy]| Protocol
...--->| Node |<----....
or Signaling -------------
Protocol
Figure 5: Policy Enabled PCC
As stated in [PCE-ARCH], the PCC is not necessarily an LSR. Policy
also is applied in such configurations. The example shown in [PCE-
ARCH] is of an NMS. Figure 6 shows this example updated to support
policy.
Berger, et. al. & [Page 8]
Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005
----------------------
| ----- |
Service | | TED |<------------+------------>
Request | ----- | TED synchronization
| | | | mechanism (e.g.,
v | | | routing protocol)
------------- Request/ | v |
| | Response| ----- ------ |
| NMS |<--------+->| PCE |<-->|Policy| |
| | | ----- ------ |
------------- ----------------------
Service |
Request |
v
---------- Signaling ----------
| Head-End | Protocol | Adjacent |
| Node |<---------->| Node |
---------- ----------
Figure 6. Management-based PCE Usage
1.2. Areas for Standardization
The following areas require standardization within the PCE policy
architecture:
- Communication between PCCs and PCEs, and between cooperating
PCEs, including the definition of policy related information
communication.
- Communication of policy related information dissemination e.g. as
part of the PCE discovery or some other communication process.
- Definition of metrics to evaluate policy support of path
computation models. The focal point of this effort is to evaluate
potential solutions to the Policy aspects of the PCE architecture.
- MIB modules related to policy support.
- Configuration related support for policy databases.
Berger, et. al. & [Page 9]
Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005
2. PCE Policy Architecture
This section provides definitions and other aspects related to the
support of policy by the PCE architecture.
2.1. Types of Policies
For the purposes of PCE, we breakdown policy into multiple
categories: user specific, request specific, client specific, server
specific and domain specific.
2.1.1. User and Request Specific Policies
User specific policies are policies that use as conditions user or
service specified information. Examples of such information includes
the contents of objects of a signaling or provisioning message, port
ID over which the message was received, VPN ID, reference point type,
or even the identity of the user initiating the request. User
specific policies could be applied while building a path computation
request. For example, Service A may require two SRLG disjoint paths
for building end-to-end recovery scheme, while for service B link-
disjoint paths may be sufficient. Alternatively, service A may need
paths with minimal end-to-end delay, while service B may be looking
for shortest (minimal-cost) paths. A final example is that different
constraint relaxation strategies could be applied while computing
paths for service A and for service B.
Request specific policies are policies that use as conditions
information found in a path computation request. Examples of request
specific policies include constraints, diversities, constraint and
diversity relaxation strategies, and optimization functions.
Request-specific policies directly affect the path selection process
because they specify which links, nodes, path segments and/or paths
that are not acceptable or, on the contrary, may be desirable to
appear in the resulting paths.
2.1.2. Client and Server Specific Policies
Client specific policies are policies that use as a condition the
requesting Path Computation Client (PCC) or, in the inter-PCE
requesting case, a requesting Path Computation Engine (PCE). A PCE
may take specific action depending on the identity of the requester.
Some examples are the PCE may choose to drop or relax certain
specified constraints or impose additional ones, select an algorithm
or heuristic for the path computation, decide whether cooperation of
Berger, et. al. & [Page 10]
Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005
other PCEs are needed and whether explicit resulting paths should be
generated or loose ones are sufficient.
Server specific policies are policies that are associated with a
particular Path Computation Engine and applied at a PCC or at a PCE
initiating a inter-PCE request. A PCC or PCE may take specific
action depending on the identity of the identity of the PCE to which
it may make a request. One examples of this is that a requester may
select a PCE based on its capabilities. Another example is that a
requester may include different information in a path computation
request based on the capabilities of a specific PCE. Capabilities in
this context mean the ability of a PCE to provide specific functions,
such as support for certain path computation constraints or
optimization functions, method of PCE related communication
authentication, or billing.
2.1.3. Local and Domain Specific Policies
Local specific policies are policies that use as a condition the ID
the PCC acting on behalf one (or more) LSRs. These policies uses
conditions that are specific to the PCC to which they apply. In a
network including multiple PCCs these conditions can be applied
independently of the policies applying to the other PCC policies.
Domain specific policies are policies that use as a condition the ID
of a path computation domain the requesting PCC belongs to and/or IDs
of domains the resulting paths go through. These policies have the
same affect on the path computation process as client specific
policies with the difference that they could be associated
with/applied for a group of clients rather than individual clients.
One example of domain-specific policy is a policy restricting which
information a PCE should publish within a given domain. In such a
case, PCEs in some domains may advertise just its presence while
others may advertise details regarding its capabilities, client
authentication process, billing, and computation resource
availability.
2.2. Policy Application
The PCE policy architecture supports policy being applied at a PCC
and at a PCE. While the architecture supports policy being applied
at both, there is no requirement for policy to always being applied
at both or even at either. The use of policy in a network, on PCCs
and on PCEs, is specific network design choice. Some networks may
choose to apply policy only at PCCs, some may choose to only apply
policies at PCEs, and others will may choose to apply policies at
Berger, et. al. & [Page 11]
Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005
both. Regardless of how policy is applied, as previously mentioned,
it must be applied in a consistent fashion in order to achieve the
results intended.
Section 1.1 shows some possible example configurations of where
policy can be applied within the PCE architecture. Figures 1 through
6 show policy being applied at a PCE. Figure 5 shows policy being
applied at both a PCC and a PCE.
Along with supporting a flexibility in where policy may be applied,
the PCE policy architecture is also flexible in terms of where
specific types of policies may be applied. Also the PCE policy
architecture allows for the application of only a subset of policy
types. Section 2.1 defines multiple types of policies. Each of
these may be applied at either a PCC or a PCE. Clearly when policy
is only applied at PCCs or at PCEs, all policy types used in a
network must be applied at those locations.
In the case when policy is only applied at a PCE, it is expected that
the PCC will pass to the PCE all information about the service that
it could gather in the path computation request, most likely in the
form of policy information. The PCE is expected to understand this
policy information and apply appropriate policies while defining the
actual parameters of the path computation to be performed. Note that
in this case, the PCC cannot use local or server policy information
to select a PCE.
When applying policy at both PCCs and PCEs, it is necessary to select
which types of policies are applied at each. In such configurations,
it is likely that the application of policy types will be distributed
across PCCs and PCEs rather than applying all types at both.
Particularly for those policy types that apply to the role being
performed by the component. For example, user specific, server
specific and request specific policies may be applied at PCCs, domain
specific policies may be applied at PCEs and client specific policies
may be applied at both. Client specific policies may also be
relative to the location where the policy is applied, i.e., at the
PCC the client is the service requester, while at the PCE the client
is the requesting PCC or PCE.
In the case when policy is only applied at a PCC, the PCC must apply
all the types of required policies, for example user, service, and
domain-specific policies. The PCC uses the policies to construct a
path computation request that appropriately represents the applied
policies. The request will necessarily be limited to the set of
"basic", non-policy capable, constraints explicitly defined by the
PCC-PCE communication protocol.
Berger, et. al. & [Page 12]
Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005
2.3. Policy Communication Support
The described PCE policy architecture allows for a fair bit of
flexibility in where and in what types of policy is applied. This is
critical from the architecture perspective, but it does imply added
complexity on the part of the PCE related communication protocols.
The first added complexity is that the PCE communication protocols
must carry sufficient information to support the types of policies
that may be applied. For example, in the case where policy is only
applied at a PCE, a PCC-PCE request must carry sufficient information
for the PCE to apply request or even user specific policies. This
does imply that a PCC must have sufficient understanding of what
policy types may be applied at a PCE. Such information may be
obtained via such approaches as configuration, static coding, or even
via a PCE discovery mechanism. The PCC must also have sufficient
understanding to properly encode the required information for each
type of policy.
The second added complexity is that the PCE communication protocols
must also be able to carry information that may result from a policy
decision. For example, user specific policy applied at a PCC may
result in policy related information that must be carried along with
the request for use by a PCE policy component. This complexity is
particularly important as it may be used to introduce new path
computation related constraints without modification of the core PCC
and PCE. This communication will likely simply require the PCE
communication protocol(s) to support opaque policy related
information elements.
The final added complexity is that the PCE communication protocols
must also be able to support updated or unsolicited responses from a
PCE. For example, changes in PCE policy may force a change to a
previously provided path. Such updated or unsolicited responses may
contain information that the PCC must act on, and may contain policy
(opaque) information that must be provided to a PCC's policy
component.
2.4. PCE Discovery Policy Considerations
Dynamic PCE discovery allows PCCs/PCEs to automatically discover a
set of PCEs, including information required for PCE selection, and to
dynamically detect new PCEs or any modification of PCE's information.
Policy can be applied in two ways in this context:
1. Restricting the scope of information distribution for the
mandatory set of information (in particular the PCE location).
Berger, et. al. & [Page 13]
Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005
2. Restricting the type and nature of the optional information
distributed by the discovery protocol. The latter is also subject to
policy since the PCE architecture allows for distributing this
information using either the discovery protocol or the specific PCC-
PCE communication protocol. Here the most important policy decision
is determined by the nature of the information to be discovered in
particular when this information is not strictly speaking a
"discovery" information, but a PCE state information exchange the
policy should allow for making use of the appropriate protocol to
exchange that information with the client PCC/PCE
Another level where policing applies is at the administrative
boundaries. This class of polices applies in particular when
multiple PCEs would have to communicate one each other and cross an
administrative boundary. In this context, several specific polices
would be applied to 1) filter the information exchanged with peering
PCEs during the discovery process (to the bare minimum in most cases
if at all allowed by the security policy) and 2) strictly limit the
exchange of information during path computation request/responses.
2.5. Policy Management
The management of policy information used at PCCs and PCEs is largely
out of scope of the PCE architecture. The architecture assumes that
such information is installed using typical policy management
techniques and are available for use by policy components co-resident
with PCCs and PCEs. The policy management techniques may be
statically configured, managed via an information or policy
management protocol, e.g., LDAPv3 [RFC3377], or even dynamically
established.
3. Representative Policy Scenario
This section provides some example of policy may be applied using the
PCE policy architecture. The intent of this section is to provide
several diverse examples of how policy may be applied within the PCE
architecture. Actual networks may use one of the scenarios
discussed, some combination of the presented scenarios, or other
scenarios not discussed. This section should not be viewed as
limiting other applications of policy within the PCE architecture.
[Authors' note: it is expected that this section will generate a
number of divergent views of how PCE policy may be applied within the
architecture. We view this as beneficial and that it is imperative
for the PCE policy architecture to be sufficiently flexible to
accommodate all views, and that each perspective be suitably
Berger, et. al. & [Page 14]
Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005
represented in this section.]
3.1. Scenario: Policy Configured Paths
A very simple usage scenario for PCE policy would be to use PCE to
centrally administer configured path. Configured paths are composed
of strict and loose explicit hops, EROs see [RFC3209], and are used
by one or more LSPs. Typically such paths are configured at the LSP
ingress. With PCE policy, an alternate approach is possible.
Using PCE policy, user specific policies can be created that will
provide a configured path for a specific user request. The user
request could be identified based on service parameters such as end-
points, requested service/QoS, or even a token that identifies the
end-user. The configured path would then be used as input to PCE
computation process. The PCE process would return any explicit
routes and expand all possible loose hops.
This described policy could be applied at either PCC or PCE, see
Figure 5. In the PCC case, the configured path would be expanded at
the PCC and then passed to the PCE along with the PCE request,
probably in the form of constraints. When applied at the PCE, the
configured path would be internally expanded and used. Both cases
require some method to configure and manage policies. In the PCC
case, the real benefit would come when there is an automated policy
distribution mechanism.
Policy configured paths can also be used in multiple PCE
environments, see Figures 3 and 4. For example, consider the case
where there is limited visibility and multiple PCEs are used to
resolve each region of visibility. In this example, it may not be
possible, or desirable to configure the whole explicit path on the
first PCE. What could be done, is to configure the explicit path for
each area of visibility with each responsible PCE. Each PCE would
then map an incoming request to the matching configured path. For
this example to work, it would likely be necessary to include the
exit point from, or the entry point into, each area of visibility.
Clearly, policy database consistent is also critical in this example.
Berger, et. al. & [Page 15]
Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005
3.2. Scenario: Provider Selection Policy
A more interesting usage scenario is applying policy to multi-domain,
multi-provider, networks. There a number of interesting applications
of policy in such networks. A rudimentary example is simple access
control, i.e., which users, clients or PCEs are permitted to request
inter-domain path computation.
A more interesting example is applying policy to select which domain,
or provider, is used to support a particular PCE request. Consider a
topology that has multiple transit networks, see Figure 7. In this
case, there are multiple transit networks available to provide a path
from a source domain to a destination (or target) domain.
Furthermore, each transit network may have one or more options for
reaching the target domain. Each domain may need to select which of
the multiple available paths can be used to satisfy a particular PCE
request.
Clear reachability is a base criteria for path selection, but policy
may be a more interesting and important criteria. For example
transit network A may be more expensive and provide lower delay or
loss than transit network C. Likewise, a transit network may wish to
treat PCE requests from its own customers differently than requests
from another provider. In both cases, computation based on traffic
engineering databases will result in multiple transit networks that
provide reachability, but policy can be used to dictate which PCE
requests get the better service.
+----------------+
|Transit Domain A| +----------------+
+----------------+ |Transit Domain D|
+------+ +----------------+ +----------------+ +------+
|Source| |Transit Domain B| +----------------+ |Target|
|Domain| +----------------+ |Transit Domain E| |Domain|
+------+ +----------------+ +----------------+ +------+
|Transit Domain C| +----------------+
+----------------+ |Transit Domain F|
+----------------+
Figure 7: Multi-domain network with multiple transit options
There are multiple options for differentiating which PCE requests use
a particular transit domain and get better service. For example, the
source domain may use user and client specific policies, to determine
the level of service to provide and use domain specific policies to
choose which transit domains are acceptable. A transit domain may
use a combination of client specific policies to determine if a
request is from a direct customer or another provider, and then use
Berger, et. al. & [Page 16]
Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005
domain specific policies to identify how the request should be
processed.
While this description presumes multiple PCEs, while envisioned to be
less common, it is also possible to apply provider selection policy
in single PCE environments. In this case, the single PCE will apply
all policies, (e.g., user, client and domain specific policies) to
determine the appropriate constraints for a particular PCE request.
While less likely, the described policy could be also applied at a
PCC. In the PCC case, the provider related policy would be expanded
at the PCC and then passed to the PCE along with the PCE request,
probably in the form of constraints.
Independent of the number of PCEs, or the application of policy at
PCCs, there must be some method to configure and manage policies
consistently.
It is also worth noting that this basic approach can also be used
within a domain to provide different paths and services based on
users, PCC, VPN ID, or even application.
3.3. Scenario: Policy Based Constraints
Another usage scenario is to use policy to provide additional
constraints for PCE request. Consider an LSR with a policy capable
PCC, as shown in Figure 5, which receives a signaling message via
signaling, including over a NNI or UNI reference point, or receives
configuration request over a management interface to establish a
service. The path(s) for LSP(s) that are needed to support the
service are not explicitly specified in the message/request; hence
path computation is needed.
In this case, the PCC may apply user or service specific policies to
decide how the path selection process should be constrained, that is,
which constraints, diversities, optimizations and relaxations should
be applied in order for the service LSP(s) to have a likelihood to be
successfully established and provide necessary QoS and resilience
against network failures. When deciding on the set of constraints
the PCC uses as an input all information it knows about the user and
service, including the contents of the received message, port ID over
which message was received, associated VPN ID, signaling/reference
point type, request time, etc. Once the constraints and other
parameters of the required path computation is determined, the PCC
generates a path computation request which includes the request-
specific policies that describe the determined set of constraints,
optimizations, and other parameters that describe how the request
Berger, et. al. & [Page 17]
Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005
must considered in the path computation process.
The PCC may also apply server specific policies for each of known,
i.e., discovered or configured, PCE in order to select which PCE to
use. The PCC may also use server specific policies to form the
request to match the PCE's capabilities so that the request will not
be rejected and so that it has a higher likelihood of being satisfied
in an efficient way. An example of modification as a result of a
server specific policy is to remove a constraint not supported by the
PCE. Once the policy processing is complete one the PCC, and the PCE
request resulting from the original service request is updated by the
policy processing, the request is sent to the PCE.
The PCE that receives the request validates and otherwise processes
the request applying the policies found in the request as well as any
policies that are applied at the PCE, e.g., client and domain
specific polices. As a result of the policy processing the PCE may
decide to reject the request. It also may decide to respond with one
or several pre-computed paths if user or client-specific polices
instruct the PCE to do so. If the PCE decides to satisfy the request
by performing a path computation, it determines if it needs the
cooperation of other PCEs and defines parameters for path
computations to be performed locally and remotely. After that the
PCE instructs a co-located path computation engine to perform the
local path computation(s) and, if necessary, sends path computation
request(s) to one or more other PCEs. It then waits for the
responses from the local path computation engine and, when used, the
remote PCE. It then combines the resulting paths and sends them back
to the requesting PCC. The response may represent policies
describing the resulting paths, their characteristics (summary cost,
expected end-to-end delay, etc.) as well as additional information
related to the request, e.g., which of constraints were honored,
which were dismissed and which were relaxed and in what way.
PCC processes the response and instructs the LSR to encode the
received path(s) into the outgoing signaling message(s).
4. Security Considerations
This document adds a policy dimension to the considerations mentioned
in [PCE-ARCH]. In particular it is now necessary to consider the
security of policy information and policy related transactions. The
most notable of these are:
- Interception of policy related information in PCE requests
and responses.
Berger, et. al. & [Page 18]
Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005
- Impersonation of user and client identities.
- Falsification of policy information or PCE capabilities.
- Denial of service attacks on policy related communication
mechanisms.
As with [PCE-ARCH], it is expected that PCE solutions will address
these issues in detail.
5. IANA Considerations
This document makes no requests to IANA.
6. References
6.1. Normative References
[PCE-ARCH] Farrel, A., Vasseur, JP., Ash, J., "Path Computation
Element (PCE) Architecture", July 2005.
6.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
[RFC3209] Awduche, et al, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[RFC3377] Hodges, J., Morgan, R., "Lightweight Directory Access
Protocol (v3): Technical Specification", September 2002.
[PCE-POL-COMMS] Bryskin, I., Papadimitriou, D., Berger, L.,
"Policy-Enabled Path Computation Communication
Requirements", October 2005.
Berger, et. al. & [Page 19]
Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005
7. Authors' Addresses
Lou Berger
Movaz Networks, Inc
Phone: +1 703-847-1801
Email: lberger@movaz.com
Igor Bryskin
Movaz Networks, Inc
Phone: +1 703-847-4208
Email: ibryskin@movaz.com
Dimitri Papadimitriou
Alcatel
Francis Wellensplein 1,
B-2018 Antwerpen, Belgium
Phone : +32 3 240 8491
Email: dimitri.papadimitriou@alcatel.be
8. Full 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.
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.
9. Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
Berger, et. al. & [Page 20]
Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005
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.
Berger, et. al. & [Page 21]
Generated on: Mon Oct 17 00:29:11 EDT 2005
