draft-ietf-pce-policy-enabled-path-comp-02.txt   draft-ietf-pce-policy-enabled-path-comp-03.txt 
Internet Draft Igor Bryskin (Adva Optical) Internet Draft Igor Bryskin (Adva Optical)
Category: Informational Dimitri Papadimitriou (Alcatel) Category: Informational Dimitri Papadimitriou (Alcatel)
Expiration Date: January 6, 2008 Lou Berger (LabN Consulting) Expiration Date: April 31, 2008 Lou Berger (LabN Consulting)
Jerry Ash (AT&T) Jerry Ash (AT&T)
July 6, 2007 October 31, 2007
Policy-Enabled Path Computation Framework Policy-Enabled Path Computation Framework
draft-ietf-pce-policy-enabled-path-comp-02.txt draft-ietf-pce-policy-enabled-path-comp-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 6, 2008. This Internet-Draft will expire on April 31, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The Path Computation Element (PCE) Architecture introduces the The Path Computation Element (PCE) Architecture introduces the
concept of policy in the context of path computation. This document concept of policy in the context of path computation. This document
provides additional details on policy within the PCE Architecture and provides additional details on policy within the PCE Architecture and
skipping to change at page 3, line 4 skipping to change at page 2, line 35
7.1 Policy Communication ..................................... 24 7.1 Policy Communication ..................................... 24
7.2 PCE Discovery Policy Considerations ....................... 26 7.2 PCE Discovery Policy Considerations ....................... 26
8 Path Computation Sequence of Events ....................... 27 8 Path Computation Sequence of Events ....................... 27
8.1 Policy-enabled PCC, Policy-enabled PCE .................... 27 8.1 Policy-enabled PCC, Policy-enabled PCE .................... 27
8.2 Policy-ignorant PCC, Policy-enabled PCE ................... 28 8.2 Policy-ignorant PCC, Policy-enabled PCE ................... 28
9 Introduction of New Constraints ........................... 30 9 Introduction of New Constraints ........................... 30
10 Security Considerations ................................... 30 10 Security Considerations ................................... 30
11 Acknowledgments ........................................... 31 11 Acknowledgments ........................................... 31
12 IANA Considerations ....................................... 31 12 IANA Considerations ....................................... 31
13 References ................................................ 31 13 References ................................................ 31
13.1 Normative References ...................................... 31 13.1 Normative References ...................................... 31
13.2 Informative References .................................... 32 13.2 Informative References .................................... 32
14 Authors' Addresses ........................................ 33 14 Authors' Addresses ........................................ 33
15 Full Copyright Statement .................................. 33 Full Copyright Statement .................................. 33
16 Intellectual Property ..................................... 34 Intellectual Property ..................................... 34
1. Introduction 1. Introduction
The Path Computation Element (PCE) Architecture is introduced in The Path Computation Element (PCE) Architecture is introduced in
[RFC4655]. This document describes the impact of policy on the PCE [RFC4655]. This document describes the impact of policy-based
architecture and provides additional details on, and context for, decision making when incorporated into the PCE
policy within the PCE Architecture.
architecture and provides additional details on, and context for
applying policy within the PCE Architecture.
Policy-based Management (PBM), see [RFC3198], is a network management Policy-based Management (PBM), see [RFC3198], is a network management
approach that enables a network to automatically perform actions in approach that enables a network to automatically perform actions in
response to network events or conditions based on pre-established response to network events or conditions based on pre-established
direction, i.e., policies, from a network administrator. PBM enables rules, also denoted as policies, from a network administrator. PBM
network administrators to operate in a high-level manner through enables network administrators to operate in a high-level manner
rule-based policies; the latter are translated automatically into through rule-based strategy (policies can be defined as a set of
individual device configuration directives, aimed at controlling a rules and actions); the latter are translated automatically (i.e.,
network as a whole. Two IETF Working Groups have considered policy dynamically, without human interference) into individual device
networking in the past: The Resource Allocation Protocol working configuration directives, aimed at controlling a network as a whole.
group and the Policy Framework working group. Two IETF Working Groups have considered policy networking in the
past: The Resource Allocation Protocol (RAP) working group and the
Policy Framework working group.
A framework for policy-based admission control [RFC2753] was defined A framework for policy-based admission control [RFC2753] was defined
and a protocol for use between Policy Enforcement Points (PEP) and and a protocol for use between Policy Enforcement Points (PEP) and
Policy Decision Points (PDP) was specified: Common Open Policy Policy Decision Points (PDP) was specified: Common Open Policy
Service (COPS) [RFC2748]. This document uses the terms PEP and PDP to Service (COPS) [RFC2748]. This document uses the terms PEP and PDP to
refer to the functions defined in the COPS context. This document refer to the functions defined in the COPS context. This document
makes no assumptions nor requires that the actual COPS protocol be makes no assumptions nor requires that the actual COPS protocol be
used. used.
The IETF has also produced a general framework for representing, The IETF has also produced a general framework for representing,
managing, sharing, and reusing policies in a vendor-independent, managing, sharing, and reusing policies in a vendor-independent,
interoperable, and scalable manner. It has also defined an extensible interoperable, and scalable manner. It has also defined an extensible
information model for representing policies, called the Policy Core information model for representing policies, called the Policy Core
Information Model (PCIM) [RFC3060], and an extension to this model to Information Model (PCIM) [RFC3060]; and an extension to this model to
address the need for QoS management, called the QoS Policy address the need for QoS management, called the QoS Policy
Information Model (QPIM) [RFC3644]. However, additional mechanisms Information Model (QPIM) [RFC3644]. However, additional mechanisms
are needed in order to specify policies related to the path are needed in order to specify policies related to the path
computation logic as well as its control. computation logic as well as its control.
In Section 2, this document presents policy related background and In Section 2, this document presents policy related background and
scenarios to provide a context for this work. Section 3 provides scenarios to provide a context for this work. Section 3 provides
requirements that must be addressed by mechanisms and protocols that requirements that must be addressed by mechanisms and protocols that
enable policy-based control over path computation requests and enable policy-based control over path computation requests and
decisions. Section 4 introduces PCIM as a core component in a decisions. Section 4 introduces PCIM as a core component in a
skipping to change at page 4, line 39 skipping to change at page 4, line 30
PC: Path Computation. PC: Path Computation.
PCC: Path Computation Client, see [RFC4655]. PCC: Path Computation Client, see [RFC4655].
PCCIM: Path Computation Core Information Model. PCCIM: Path Computation Core Information Model.
PCE: Path Computation Element, see [RFC4655]. PCE: Path Computation Element, see [RFC4655].
PCIM: Policy Core Information Model, see [RFC3060]. PCIM: Policy Core Information Model, see [RFC3060].
PDP: Policy Decision Points, see [RFC2753]. PDP: Policy Decision Points, see [RFC2753].
PEP: Policy Enforcement Points, see [RFC2753]. PEP: Policy Enforcement Points, see [RFC2753].
QPIM: QoS Policy Information Model, see [RFC3644]. QPIM: QoS Policy Information Model, see [RFC3644].
SLA: Service Level Agreement. SLA: Service Level Agreement.
TE: Traffic Engineering, see [RFC3209] and [RFC3473]. TE: Traffic Engineering, see [RFC3209] and [RFC3473].
TED: Traffic Engineering Database, see [RFC3209] and [RFC3473].
TE LSP: Traffic Engineering MPLS Label Switched Path, see TE LSP: Traffic Engineering MPLS Label Switched Path, see
[RFC3209] and [RFC3473]. [RFC3209] and [RFC3473].
2. Background 2. Background
This section provides some general background on the use of policy This section provides some general background on the use of policies
within the PCE architecture. It presents the rationale behind the use within the PCE architecture. It presents the rationale behind the use
of policy in path computation, as well as representative policy usage of policies in the TE path computation process, as well as
scenarios. This information is intended to provide context for the representative policies usage scenarios. This information is intended
presented PCE policy framework. This section does not attempt to to provide context for the presented PCE policy framework. This
present an exhaustive list of rationales or scenarios. section does not attempt to present an exhaustive list of rationales
or scenarios.
2.1. Motivation 2.1. Motivation
The PCE architecture is introduced in [RFC4655]. It includes policy The PCE architecture as introduced in [RFC4655] includes policy as an
as an integral part of the PCE architecture. This section presents integral part of the PCE architecture. This section presents some of
some of the rationale for this inclusion. the rationale for this inclusion.
Network operators require a certain level of flexibility to shape the Network operators require a certain level of flexibility to shape the
TE path computation process, so that the process can be aligned with TE path computation process, so that the process can be aligned with
their business and operational needs. Many aspects of the path their business and operational needs. Many aspects of the path
computation may be governed by policies. For example, a PCC may use computation may be governed by policies. For example, a PCC may use
policies configured by the operator to decide which optimizations, policies configured by the operator to decide which optimization
constraints, diversities and their relaxation strategies to request criteria, constraints, diversities and their relaxation strategies to
while computing path(s) for a particular service. Depending on SLAs, request while computing path(s) for a particular service. Depending
TE and cost/performance ratio goals, path computation requests may be on SLAs, TE and cost/performance ratio goals, path computation
built differently for different services. Service A, for instance, requests may be issued differently for different services. A given
may require two SRLG-disjoint paths for building end-to-end recovery Service A, for instance, may require two SRLG-disjoint paths for
scheme, while for service B link-disjoint paths may be sufficient. building end-to-end recovery scheme, while for a Service B link-
Service A may need paths with minimal end-to-end delay, while service disjoint paths may be sufficient. Service A may need paths with
B may be looking for shortest (minimal-cost) paths. Different minimal end-to-end delay, while Service B may be looking for shortest
constraint relaxation strategies may be applied while computing paths (minimal-cost) paths. Different constraint relaxation strategies may
for service A and for service B, and so forth. be applied while computing paths for Service A and for Service B, and
so forth. So based on distinct service requirements distinct or
similar policies may be adopted when issuing/handling path
computation requests.
Likewise, a PCE may apply policies to decide which algorithm or Likewise, a PCE may apply policies to decide which algorithm(s) to
algorithms to use while performing path computations requested from a use while performing path computations requested from a particular
particular PCC or for a particular domain, see [RFC4927]; whether to PCC or for a particular domain, see [RFC4927]; whether to seek the
seek the cooperation of other PCEs to satisfy a particular request or cooperation of other PCEs to satisfy a particular request or to
to handle a request on its own (possibly responding with non explicit handle a request on its own (possibly responding with non explicit
paths); or how the request should be modified before being sent to paths); or how the request should be modified before being sent to
other member(s) of a group of cooperating PCEs, etc. other member(s) of a group of cooperating PCEs, etc.
Additional motivation for supporting policy within the PCE Additional motivation for supporting policies within the PCE
architecture can be described as follows. Historically, a path architecture can be described as follows. Historically, a path
computation entity was an intrinsic part of an LSR's control plane computation entity was an intrinsic part of an LSR's control plane
and always co-located with the LSR's signaling and routing and always co-located with the LSR's signaling and routing
subsystems. This approach allowed for unlimited flexibility in subsystems. This approach allowed for unlimited flexibility in
providing various path computation enhancements, such as: adding new providing various path computation enhancements, such as: adding new
types of constraints, diversities and their relaxation strategies, types of constraints, diversities and their relaxation strategies,
adopting new objective functions and optimization criteria, etc. All adopting new objective functions and optimization criteria, etc. All
that had to be done to support an enhancement was to upgrade the that had to be done to support an enhancement was to upgrade the
control plane software of a particular LSR (and no other LSRs or any control plane software of a particular LSR (and no other LSRs or any
other network elements). other network elements).
skipping to change at page 6, line 12 skipping to change at page 6, line 16
need to be standardized, all PCCs may need to be upgraded with new need to be standardized, all PCCs may need to be upgraded with new
software, and new interoperability problems may need to be resolved, software, and new interoperability problems may need to be resolved,
etc. etc.
Within the context of the PCE architecture, it is therefore highly Within the context of the PCE architecture, it is therefore highly
desirable to find a way to introduce new path computation desirable to find a way to introduce new path computation
capabilities without requiring modifying either the capabilities without requiring modifying either the
discovery/communication protocols or the PCC software. One way to discovery/communication protocols or the PCC software. One way to
achieve this objective is to consider path selection constraints, achieve this objective is to consider path selection constraints,
their relaxations and objective functions, as path computation their relaxations and objective functions, as path computation
request-specific policies. Furthermore, such policies may, on the one request-specific policies. Furthermore, such policies may be
hand, be configured and managed by an operator as any other policies configured and managed by a network operator as any other policies
or, on the other hand, may be interpreted in real time by PCCs and and may be interpreted in real time by PCCs and PCEs.
PCEs.
There are a number of advantages and useful by-products of such an There are a number of advantages and useful by-products of such an
approach: approach:
- New path computation capabilities may be introduced without - New path computation capabilities may be introduced without
changing PCE-PCC communication and discovery protocols or PCC changing PCE-PCC communication and discovery protocols or PCC
software. Only the PCE module providing the path computation software. Only the PCE module providing the path computation
capabilities (referred to in this document as a path capabilities (referred to in this document as a path
computation engine) needs to be updated. computation engine) needs to be updated.
skipping to change at page 7, line 7 skipping to change at page 7, line 7
interpreted using the same mechanisms. Also policies need to be interpreted using the same mechanisms. Also policies need to be
supported by PCCs and PCEs independent of the peculiarities of a supported by PCCs and PCEs independent of the peculiarities of a
specific PCC-PCE communication protocol. Thus, introducing a new specific PCC-PCE communication protocol. Thus, introducing a new
(request-specific) type of policies describing constraints and (request-specific) type of policies describing constraints and
other elements of a path computation request will be a natural other elements of a path computation request will be a natural
and relatively inexpensive addition to the policy-enabled path and relatively inexpensive addition to the policy-enabled path
computation architecture. computation architecture.
2.2. Representative Policy Scenarios 2.2. Representative Policy Scenarios
This section provides example scenarios of how policy may be applied This section provides example scenarios of how policies may be
using the PCE policy framework within the PCE architecture context. applied using the PCE policy framework within the PCE architecture
Actual networks may use one of the scenarios discussed, some context. Actual networks may deploy one of the scenarios discussed,
combination of the presented scenarios, or other scenarios (not some combination of the presented scenarios, or other scenarios (not
discussed). This section should not be viewed as limiting other discussed). This section should not be viewed as limiting other
applications of policy within the PCE architecture. applications of policies within the PCE architecture.
2.2.1. Scenario: Policy Configured Paths 2.2.1. Scenario: Policy Configured Paths
A very simple usage scenario for PCE policy would be to use PCE to A very simple usage scenario for PCE policy would be to use PCE to
centrally administer configured paths. Configured paths are composed centrally administer configured paths. Configured paths are composed
of strict and loose hops in the form of Explicit Route Objects of strict and loose hops in the form of Explicit Route Objects
(EROs), see [RFC3209], and are used by one or more LSPs. Typically, (EROs), see [RFC3209], and are used by one or more LSPs. Typically,
such paths are configured at the LSP ingress. In the context of such paths are configured at the LSP ingress. In the context of
policy-enabled path computation, an alternate approach is possible. policy-enabled path computation, an alternate approach is possible.
In particular, service-specific policies can be installed that will In particular, service-specific policies can be installed that will
provide configured path(s) for a specific service request. The provide configured path(s) for a specific service request. The
request may be identified based on service parameters such as end- request may be identified based on service parameters such as end-
points, requested QoS, or even a token that identifies the initiator points, requested QoS, or even a token that identifies the initiator
of a service request. The configured path(s) would then be used as of a service request. The configured path(s) would then be used as
input to the PCE computation process, which would return explicit input to the path computation process, which would return explicit
routes by expanding of all specified loose hops. routes by expanding of all specified loose hops.
---------------------- ----------------------
| ----- | | ----- |
| | TED |<-+------------> | | TED |<-+------------>
| ----- | TED synchronization | ----- | TED synchronization
| | | mechanism (e.g., routing protocol) | | | mechanism (e.g., routing protocol)
| | | | | |
| v | | v |
| ------ ----- | Inter-PCE Request/Response | ------ ----- | Inter-PCE Request/Response
skipping to change at page 9, line 43 skipping to change at page 9, line 43
| Request/ | Request/
| Response | Response
v v
Service ---------- Signaling ---------- Signaling ---------- Service ---------- Signaling ---------- Signaling ----------
Request| Head-End | Protocol | Adjacent | Protocol | Adjacent | Request| Head-End | Protocol | Adjacent | Protocol | Adjacent |
---->| Node |<---------->| Node |<---------->| Node | ---->| Node |<---------->| Node |<---------->| Node |
---------- ---------- ---------- ---------- ---------- ----------
Figure 3. Multiple PCE Path Computation with Inter-PCE Communication Figure 3. Multiple PCE Path Computation with Inter-PCE Communication
Policy-configured paths may also be used in multiple PCE environments Policy-configured paths may also be used in environments with
(see Figures 2 and 3). For example, consider the case when there is multiple (more than one) cooperating PCEs (see Figures 2 and 3). For
limited TE visibility and independent PCEs are used to determine example, consider the case when there is limited TE visibility and
path(s) within each area of the TE visibility. In such a case, it may independent PCEs are used to determine path(s) within each area of
not be possible (or desirable) to configure entire explicit path(s) the TE visibility. In such a case, it may not be possible (or
on a single PCE. However, it is possible to configure explicit desirable) to configure entire explicit path(s) on a single PCE.
path(s) for each area of the TE visibility and each responsible PCE. However, it is possible to configure explicit path(s) for each area
One by one, the PCEs would then map an incoming signaling request to of the TE visibility and each responsible PCE. One by one, the PCEs
appropriate configured path(s). Note that to make such a scenario would then map an incoming signaling request to appropriate
work it would likely be necessary to start and finish the configured configured path(s). Note that to make such a scenario work it would
paths on TE domain boundary nodes. Clearly, consistent PC Policy likely be necessary to start and finish the configured paths on TE
Repositories are also critical in this example. domain boundary nodes. Clearly, consistent PC Policy Repositories are
also critical in this example.
2.2.2. Scenario: Provider Selection Policy 2.2.2. Scenario: Provider Selection Policy
A potentially more interesting usage scenario is applying PC policies A potentially more interesting scenario is applying PC policies in
in multi-domain multi-provider topologies. There are numerous multi-provider topologies. There are numerous interesting policy
interesting policy applications in such topologies. A rudimentary applications in such topologies. A rudimentary example is simple
example is simple access control, that is, deciding which clients are access control, that is, deciding which PCCs are permitted to request
permitted to request inter-domain path computation. inter-domain path computation.
A more complicated example is applying policy to determine which A more complicated example is applying policy to determine which
domain or network provider will be used to support a particular PCE domain or network provider will be used to support a particular PCE
request. Consider the topology presented in Figure 4. In this example request. Consider the topology presented in Figure 4. In this example
there are multiple transit domains available to provide a path from a there are multiple transit domains available to provide a path from a
source domain to a destination domain. Furthermore, each transit source domain to a destination domain. Furthermore, each transit
domain may have one or more options for reaching a particular domain. domain may have one or more options for reaching a particular domain.
Each domain will need to select which of the multiple available paths Each domain will need to select which of the multiple available paths
will be used to satisfy a particular PCE request. will be used to satisfy a particular PCE request.
skipping to change at page 12, line 4 skipping to change at page 12, line 4
a PCE request. Consider an LSR with a policy enabled PCC, as shown in a PCE request. Consider an LSR with a policy enabled PCC, as shown in
Figure 1, which receives a service request via signaling, including Figure 1, which receives a service request via signaling, including
over a NNI or UNI reference point, or receives a configuration over a NNI or UNI reference point, or receives a configuration
request over a management interface to establish a service. In either request over a management interface to establish a service. In either
case the path(s) needed to support the service are not explicitly case the path(s) needed to support the service are not explicitly
specified in the message/request, and hence path computation is specified in the message/request, and hence path computation is
needed. needed.
In this case, the PCC may apply user or service-specific policies to In this case, the PCC may apply user or service-specific policies to
decide how the path selection process should be constrained, that is, decide how the path selection process should be constrained, that is,
which constraints, diversities, optimizations and relaxations should which constraints, diversities, optimization criterion and constraint
be applied in order for the service LSP(s) to have a likelihood to be relaxation strategies should be applied in order for the service
successfully established and provide necessary QoS and resilience LSP(s) to have a likelihood to be successfully established and
against network failures. When deciding on the set of constraints the provide necessary QoS and resilience against network failures. When
PCC uses as an input all information it knows about the user and deciding on the set of constraints the PCC uses as an input all
service, such as the contents of the received message, port ID over information it knows about the user and service, such as the contents
which message was received, associated VPN ID, signaling/reference of the received message, port ID over which message was received,
point type, request time, etc. Once the constraints and other associated VPN ID, signaling/reference point type, request time, etc.
parameters of the required path computation are determined, the PCC Once the constraints and other parameters of the required path
generates a path computation request which includes the request- computation are determined, the PCC generates a path computation
specific policies that describe the determined set of constraints, request which includes the request-specific policies that describe
optimizations, and other parameters that indicate how the request is the determined set of constraints, optimizations, and other
to be considered in the path computation process. parameters that indicate how the request is to be considered in the
path computation process.
The PCC may also apply server-specific policies in order to select The PCC may also apply server-specific policies in order to select
which PCE to use from the set of known (i.e., discovered or which PCE to use from the set of known (i.e., discovered or
configured) PCEs. The PCC may also use server-specific policies to configured) PCEs. The PCC may also use server-specific policies to
form the request to match the PCE's capabilities so that the request form the request to match the PCE's capabilities so that the request
will not be rejected and has a higher likelihood of being satisfied will not be rejected and has a higher likelihood of being satisfied
in an efficient way. An example of a request modification as the in an efficient way. An example of a request modification as the
result of a server-specific policy is removing a constraint not result of a server-specific policy is removing a constraint not
supported by the PCE. Once the policy processing is completed at the supported by the PCE. Once the policy processing is completed at the
PCC, and the path computation request resulting from the original PCC, and the path computation request resulting from the original
skipping to change at page 23, line 16 skipping to change at page 23, line 16
The previous section shows the relationship between PCCs and PCEs. A The previous section shows the relationship between PCCs and PCEs. A
parallel relationship exists between cooperating PCEs, and, in fact, parallel relationship exists between cooperating PCEs, and, in fact,
this relationship can be viewed as the same as the relationship this relationship can be viewed as the same as the relationship
between PCCs and PCEs. The one notable difference is that there will between PCCs and PCEs. The one notable difference is that there will
be cases where having a shared PC Policy Repository will not be be cases where having a shared PC Policy Repository will not be
desirable, for example, when the PCEs are managed by different desirable, for example, when the PCEs are managed by different
entities. Note that in this case it still remains necessary for the entities. Note that in this case it still remains necessary for the
policies to be consistent across the domains in order to identify policies to be consistent across the domains in order to identify
usable paths. The other notable difference is that a PCE, while usable paths. The other notable difference is that a PCE, while
processing a path computation request, may need to apply requestor- processing a path computation request, may need to apply requester-
specific (that is, client-specific) policies in order to modify the specific (that is, client-specific) policies in order to modify the
request before sending it to other cooperating PCE(s). This request before sending it to other cooperating PCE(s). This
relationship is particularly important as the PCE Architecture allows relationship is particularly important as the PCE Architecture allows
for configuration where all PCCs are not policy-enabled. for configuration where all PCCs are not policy-enabled.
The following are example configurations. These examples do not The following are example configurations. These examples do not
represent an exhaustive list and other configurations are expected. represent an exhaustive list and other configurations are expected.
o) Single Policy Repository o) Single Policy Repository
skipping to change at page 26, line 31 skipping to change at page 26, line 31
(more precisely, PCE-PEP) is expected to understand this information (more precisely, PCE-PEP) is expected to understand this information
and use it to determine the constraints and optimization functions and use it to determine the constraints and optimization functions
applying local policies (that is, policies locally configured or applying local policies (that is, policies locally configured or
provided by the associated PCE-PDP(s)). provided by the associated PCE-PDP(s)).
7.2. PCE Discovery Policy Considerations 7.2. PCE Discovery Policy Considerations
Dynamic PCE discovery allows for PCCs and PCEs to automatically Dynamic PCE discovery allows for PCCs and PCEs to automatically
discover a set of PCEs (including information required for the PCE discover a set of PCEs (including information required for the PCE
selection). It also allows for PCCs and PCEs to dynamically detect selection). It also allows for PCCs and PCEs to dynamically detect
new PCEs or any modification of PCEs information. Policy can be new PCEs or any modification of PCEs status. Policy can be applied in
applied in two ways in this context: two ways in this context:
1. Restricting the scope of information distribution for the 1. Restricting the scope of information distribution for the
mandatory set of information (in particular the PCE presence mandatory set of information (in particular the PCE presence
and location). and location).
2. Restricting the type and nature of the optional information 2. Restricting the type and nature of the optional information
distributed by the discovery protocol. The latter is also distributed by the discovery protocol. The latter is also
subject to policy since the PCE architecture allows for subject to policy since the PCE architecture allows for
distributing this information using either PCE discovery distributing this information using either PCE discovery
protocol(s) or PCC-PCE communication protocol(s). One important protocol(s) or PCC-PCE communication protocol(s). One important
skipping to change at page 27, line 15 skipping to change at page 27, line 15
boundaries. In multi-domain networks multiple PCEs will communicate boundaries. In multi-domain networks multiple PCEs will communicate
with each other and across administrative boundaries. In such cases, with each other and across administrative boundaries. In such cases,
domain-specific polices would be applied to 1) filter the information domain-specific polices would be applied to 1) filter the information
exchanged between peering PCEs during the discovery process (to the exchanged between peering PCEs during the discovery process (to the
bare minimum in most cases if at all allowed by the security policy) bare minimum in most cases if at all allowed by the security policy)
and 2) limit the content of information being passed in path and 2) limit the content of information being passed in path
computation request and responses. computation request and responses.
8. Path Computation Sequence of Events 8. Path Computation Sequence of Events
This section presents representative scenarios; other scenarios are This section presents a non-exhaustive list of representative
also possible. scenarios.
8.1. Policy-enabled PCC, Policy-enabled PCE 8.1. Policy-enabled PCC, Policy-enabled PCE
When a GMPLS LSR receives a Setup (RSVP Path) message from an When a GMPLS LSR receives a Setup (RSVP Path) message from an
upstream LSR, the LSR may decide to use a remote Path Computation upstream LSR, the LSR may decide to use a remote Path Computation
Entity. The following sequence of events occurs in this case: Entity. The following sequence of events occurs in this case:
- A PCC-PEP co-located with the LSR applies the service-specific - A PCC-PEP co-located with the LSR applies the service-specific
policies to select a PCE for the service path computation as policies to select a PCE for the service path computation as
well as to build the path computation request (that is, to well as to build the path computation request (that is, to
skipping to change at page 30, line 10 skipping to change at page 30, line 10
dismissed and which were relaxed and in what way) dismissed and which were relaxed and in what way)
- PCC-PEP instructs the signaling sub-system of the GMPLS LSR to - PCC-PEP instructs the signaling sub-system of the GMPLS LSR to
encode the received path(s) into the outgoing Setup message(s). encode the received path(s) into the outgoing Setup message(s).
9. Introduction of New Constraints 9. Introduction of New Constraints
An important aspect of the policy-enable path computation framework An important aspect of the policy-enable path computation framework
discussed above is the ability to introduce new constraints with discussed above is the ability to introduce new constraints with
minimal impact. In particular, only those components and mechanisms minimal impact. In particular, only those components and mechanisms
that will use a new constraint need to change in order to support the that will use a new constraint need to be updated in order to support
new constraint. Importantly, those components and mechanisms that the new constraint. Importantly, those components and mechanisms that
will not use the new constraint, must not require any change in order will not use the new constraint, must not require any change in order
for the new constraint to be utilized. For example, the PCE for the new constraint to be utilized. For example, the PCE
communication protocols must not require any changes to support new communication protocols must not require any changes to support new
constraints. Likewise, PCC and PCEs that will not process new constraints. Likewise, PCC and PCEs that will not process new
constraints must not require any modification. constraints must not require any modification.
Consider the case where a PCE has been upgraded with software Consider the case where a PCE has been upgraded with software
supporting optical physical impairment constraint, such as supporting optical physical impairment constraint, such as
Polarization Mode Dispersion (PMD), that previously was not supported Polarization Mode Dispersion (PMD), that previously was not supported
in the domain. In this case, one or more new policies will be in the domain. In this case, one or more new policies will be
skipping to change at page 30, line 47 skipping to change at page 30, line 47
support a new constraint. Once a corresponding policy installed in support a new constraint. Once a corresponding policy installed in
the repository, it automatically becomes available for all repository the repository, it automatically becomes available for all repository
users, that is, PCCs. In the multi-repository case some policy users, that is, PCCs. In the multi-repository case some policy
synchronization must be provided, however, this problem is one of the synchronization must be provided, however, this problem is one of the
management plane which is solved already. management plane which is solved already.
10. Security Considerations 10. Security Considerations
This document adds to the policy security considerations mentioned in This document adds to the policy security considerations mentioned in
[RFC4655]. In particular it is now necessary to consider the security [RFC4655]. In particular it is now necessary to consider the security
of policy information maintained in PC Policy Repositories and policy issues related to policy information maintained in PC Policy
related transactions. The most notable issues, some of which are also Repositories and policy related transactions. The most notable
listed in [RFC4655], are: issues, some of which are also listed in [RFC4655], are:
- Unauthorized access to the PC Policy Repositories; - Unauthorized access to the PC Policy Repositories;
- Interception of policy information when it is retrieved from - Interception of policy information when it is retrieved from
the repositories and/or transported from PDPs to PEPs; the repositories and/or transported from PDPs to PEPs;
- Interception of policy related information in path computation - Interception of policy related information in path computation
requests and responses; requests and responses;
o Impersonation of user and client identities; o Impersonation of user and client identities;
skipping to change at page 33, line 37 skipping to change at page 33, line 37
Lou Berger Lou Berger
LabN Consulting, LLC LabN Consulting, LLC
Phone: +1 301 468 9228 Phone: +1 301 468 9228
Email: lberger@labn.net Email: lberger@labn.net
Jerry Ash Jerry Ash
AT&T AT&T
Email: gash5107@yahoo.com Email: gash5107@yahoo.com
15. Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
16. Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at line 1479 skipping to change at line 1488
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). Administrative Support Activity (IASA).
Generated on: Thu Jul 5 19:48:55 EDT 2007 Generated on: Fri Oct 26 16:05:21 EDT 2007
 End of changes. 31 change blocks. 
95 lines changed or deleted 104 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/