draft-ietf-pce-policy-enabled-path-comp-03.txt   draft-ietf-pce-policy-enabled-path-comp-04.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: April 31, 2008 Lou Berger (LabN Consulting) Expiration Date: April 31, 2009 Lou Berger (LabN Consulting)
Jerry Ash (AT&T) Jerry Ash (AT&T)
October 31, 2007 October 31, 2008
Policy-Enabled Path Computation Framework Policy-Enabled Path Computation Framework
draft-ietf-pce-policy-enabled-path-comp-03.txt draft-ietf-pce-policy-enabled-path-comp-04.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 April 31, 2008. This Internet-Draft will expire on April 31, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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
also provides context for the support of PCE Policy. This document also provides context for the support of PCE Policy. This document
introduces the use of the Policy Core Information Model (PCIM) as a introduces the use of the Policy Core Information Model (PCIM) as a
framework for supporting path computation policy. This document also framework for supporting path computation policy. This document also
provides representative scenarios for the support of PCE Policy. provides representative scenarios for the support of PCE Policy.
Contents Table of Contents
1 Introduction .............................................. 3 1 Introduction .............................................. 3
1.1 Terminology ............................................... 4 1.1 Terminology ............................................... 4
2 Background ................................................ 4 2 Background ................................................ 4
2.1 Motivation ................................................ 5 2.1 Motivation ................................................ 5
2.2 Representative Policy Scenarios ........................... 7 2.2 Policy Attributes ......................................... 7
2.2.1 Scenario: Policy Configured Paths ......................... 7 2.3 Representative Policy Scenarios ........................... 8
2.2.2 Scenario: Provider Selection Policy ....................... 10 2.3.1 Scenario: Policy Configured Paths ......................... 8
2.2.3 Scenario: Policy Based Constraints ........................ 11 2.3.2 Scenario: Provider Selection Policy ....................... 11
2.2.4 Scenario: Advanced Load Balancing (ALB) Example .......... 13 2.3.3 Scenario: Policy Based Constraints ........................ 12
3 Requirements .............................................. 14 2.3.4 Scenario: Advanced Load Balancing (ALB) Example .......... 15
4 Path Computation Policy Information Model (PCPIM) ......... 16 3 Requirements .............................................. 16
5 Policy-Enabled Path Computation Framework Components ...... 18 4 Path Computation Policy Information Model (PCPIM) ......... 18
6 Policy Component Configurations ........................... 19 5 Policy-Enabled Path Computation Framework Components ...... 20
6.1 PCC-PCE Configurations .................................... 19 6 Policy Component Configurations ........................... 21
6.2 Policy Repositories ....................................... 21 6.1 PCC-PCE Configurations .................................... 21
6.3 Cooperating PCE Configurations ............................ 23 6.2 Policy Repositories ....................................... 23
6.4 Policy Configuration Management ........................... 24 6.3 Cooperating PCE Configurations ............................ 25
7 Inter-Component Communication ............................. 24 6.4 Policy Configuration Management ........................... 26
7.1 Policy Communication ..................................... 24 7 Inter-Component Communication ............................. 26
7.2 PCE Discovery Policy Considerations ....................... 26 7.1 Policy Communication ..................................... 26
8 Path Computation Sequence of Events ....................... 27 7.2 PCE Discovery Policy Considerations ....................... 28
8.1 Policy-enabled PCC, Policy-enabled PCE .................... 27 8 Path Computation Sequence of Events ....................... 29
8.2 Policy-ignorant PCC, Policy-enabled PCE ................... 28 8.1 Policy-enabled PCC, Policy-enabled PCE .................... 29
9 Introduction of New Constraints ........................... 30 8.2 Policy-ignorant PCC, Policy-enabled PCE ................... 30
10 Security Considerations ................................... 30 9 Introduction of New Constraints ........................... 32
11 Acknowledgments ........................................... 31 10 Security Considerations ................................... 32
12 IANA Considerations ....................................... 31 11 Acknowledgments ........................................... 33
13 References ................................................ 31 12 IANA Considerations ....................................... 33
13.1 Normative References ...................................... 31 13 References ................................................ 33
13.2 Informative References .................................... 32 13.1 Normative References ...................................... 33
14 Authors' Addresses ........................................ 33 13.2 Informative References .................................... 34
Full Copyright Statement .................................. 33 14 Authors' Addresses ........................................ 35
Intellectual Property ..................................... 34 15 Full Copyright Statement .................................. 36
16 Intellectual Property ..................................... 36
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-based [RFC4655]. This document describes the impact of policy-based
decision making when incorporated into the PCE decision making when incorporated into the PCE architecture and
provides additional details on, and context for applying policy
architecture and provides additional details on, and context for within the PCE Architecture.
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
rules, also denoted as policies, from a network administrator. PBM rules, also denoted as policies, from a network administrator. PBM
enables network administrators to operate in a high-level manner enables network administrators to operate in a high-level manner
through rule-based strategy (policies can be defined as a set of through rule-based strategy (policies can be defined as a set of
rules and actions); the latter are translated automatically (i.e., rules and actions); the latter are translated automatically (i.e.,
dynamically, without human interference) into individual device dynamically, without human interference) into individual device
configuration directives, aimed at controlling a network as a whole. configuration directives, aimed at controlling a network as a whole.
Two IETF Working Groups have considered policy networking in the Two IETF Working Groups have considered policy networking in the
past: The Resource Allocation Protocol (RAP) working group and the past: The Resource Allocation Protocol (RAP) working group and the
Policy Framework working group. 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. Any suitable policy exchange protocol (for example, SOAP
[W3CSOAP]) may be substituted.
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.
skipping to change at page 4, line 13 skipping to change at page 4, line 15
enabled path computation. Sections 6, 7 and 8 provide details on enabled path computation. Sections 6, 7 and 8 provide details on
possible component configurations, communication and events. Section possible component configurations, communication and events. Section
10 discusses the ability to introduce new constraints with minimal 10 discusses the ability to introduce new constraints with minimal
impact. It should be noted that this document, in Section 4, only impact. It should be noted that this document, in Section 4, only
introduces PCIM, specific PCIM definitions to support path introduces PCIM, specific PCIM definitions to support path
computation will be discussed in a separate document. computation will be discussed in a separate document.
1.1. Terminology 1.1. Terminology
The reader is assumed to be familiar with the following terms: The reader is assumed to be familiar with the following terms:
BEEP: Blocks Extensible Exchange Protocol, see [RFC3080].
CIM: Common Information Model, see [DMTF]. CIM: Common Information Model, see [DMTF].
COPS: Common Open Policy Service, see [RFC2748]. COPS: Common Open Policy Service, see [RFC2748].
COPS-PR: COPS Usage for Policy Provisioning, see [RFC3084].
CSPF: Constraint-based Shortest Path First, see [RFC3630]. CSPF: Constraint-based Shortest Path First, see [RFC3630].
LSP: Label Switched Path, see [RFC3031]. LSP: Label Switched Path, see [RFC3031].
LSR: Label Switching Router, see [RFC3031]. LSR: Label Switching Router, see [RFC3031].
PBM: Policy-based Management, see [RFC3198]. PBM: Policy-based Management, see [RFC3198].
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].
PCEP: Path Computation Element Communication Protocol,
see [PCEP].
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.
SOAP: Simple Object Access Protocol, see [W3CSOAP].
TE: Traffic Engineering, see [RFC3209] and [RFC3473]. TE: Traffic Engineering, see [RFC3209] and [RFC3473].
TED: Traffic Engineering Database, 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 policies 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 policies in the TE path computation process, as well as of policies in the TE path computation process, as well as
skipping to change at page 6, line 44 skipping to change at page 6, line 43
- Different elements such as conditions, actions, variables, - Different elements such as conditions, actions, variables,
etc., may be re-used by multiple constraints, diversities, and etc., may be re-used by multiple constraints, diversities, and
optimizations. optimizations.
- PCCs and PCEs need to handle other (that is, not request- - PCCs and PCEs need to handle other (that is, not request-
specific) policies. Path computation-related policies of all specific) policies. Path computation-related policies of all
types can be placed within the same policy repositories, can be types can be placed within the same policy repositories, can be
managed by the same policy management tools, and can be managed by the same policy management tools, and can be
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, see [PCEP]. Thus,
(request-specific) type of policies describing constraints and introducing a new (request-specific) type of policies describing
other elements of a path computation request will be a natural constraints and other elements of a path computation request
and relatively inexpensive addition to the policy-enabled path will be a natural and relatively inexpensive addition to the
computation architecture. policy-enabled path computation architecture.
2.2. Representative Policy Scenarios 2.2. Policy Attributes
This section provides a summary listing of the policy attributes that
may be included in the policy exchanges described in the scenarios
that follow. This list is provided for guidance and is not intended
to be exclusive. Implementation of this framework might include
additional policy attributes not listed here.
Identities
- LSP head-end
- LSP destination
- PCC
- PCE
LSP identifiers
- LSP head-end
- LSP destination
- Tunnel identifier
- Extended tunnel identifier
- LSP ID
- Tunnel name
Requested LSP qualities
- bandwidth
- traffic parameters
- LSP attributes
- explicit path inclusions
- explicit path exclusions
- link protection level
- setup priority
- holding priority
- preexisting LSP route
Requested path computation behavior
- objective function
- other LSPs to be considered
Additional policy information
- Transparent policy information as received in RSVP-TE
2.3. Representative Policy Scenarios
This section provides example scenarios of how policies may be This section provides example scenarios of how policies may be
applied using the PCE policy framework within the PCE architecture applied using the PCE policy framework within the PCE architecture
context. Actual networks may deploy one of the scenarios discussed, context. Actual networks may deploy one of the scenarios discussed,
some 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 policies within the PCE architecture. applications of policies within the PCE architecture.
2.2.1. Scenario: Policy Configured Paths 2.3.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 path 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.
Example of policy:
if(service_destination matches 10.132.12.0/24)
use path: 10.125.13.1=>10.125.15.1=>10.132.12.1
else
compute path dynamically
---------------------- ----------------------
| ----- | | ----- |
| | 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
| |Policy|<-->| PCE |<.+...........> (when present) | |Policy|<-->| PCE |<.+...........> (when present)
| ------ ----- | | ------ ----- |
skipping to change at page 10, line 7 skipping to change at page 11, line 5
multiple (more than one) cooperating PCEs (see Figures 2 and 3). For multiple (more than one) cooperating PCEs (see Figures 2 and 3). For
example, consider the case when there is limited TE visibility and example, consider the case when there is limited TE visibility and
independent PCEs are used to determine path(s) within each area of independent PCEs are used to determine path(s) within each area of
the TE visibility. In such a case, it may not be possible (or the TE visibility. In such a case, it may not be possible (or
desirable) to configure entire explicit path(s) on a single PCE. desirable) to configure entire explicit path(s) on a single PCE.
However, it is possible to configure explicit path(s) for each area However, it is possible to configure explicit path(s) for each area
of the TE visibility and each responsible PCE. One by one, the PCEs of the TE visibility and each responsible PCE. One by one, the PCEs
would then map an incoming signaling request to appropriate would then map an incoming signaling request to appropriate
configured path(s). Note that to make such a scenario work it would configured path(s). Note that to make such a scenario work it would
likely be necessary to start and finish the configured paths on TE likely be necessary to start and finish the configured paths on TE
domain boundary nodes. Clearly, consistent PC Policy Repositories are domain boundary nodes. Clearly, consistent PCE Policy Repositories
also critical in this example. are also critical in this example.
2.2.2. Scenario: Provider Selection Policy 2.3.2. Scenario: Provider Selection Policy
A potentially more interesting scenario is applying PC policies in A potentially more interesting scenario is applying PC policies in
multi-provider topologies. There are numerous interesting policy multi-provider topologies. There are numerous interesting policy
applications in such topologies. A rudimentary example is simple applications in such topologies. A rudimentary example is simple
access control, that is, deciding which PCCs are permitted to request access control, that is, deciding which PCCs are 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
skipping to change at page 11, line 38 skipping to change at page 12, line 38
a particular transit domain and get a particular (better or worse) a particular transit domain and get a particular (better or worse)
level of service. For example, a PCE in the source domain may use level of service. For example, a PCE in the source domain may use
user and request-specific policies to determine the level of service user and request-specific policies to determine the level of service
to provide. A PCE in the source domain may also use domain-specific to provide. A PCE in the source domain may also use domain-specific
policies to choose which transit domains are acceptable. A PCE in a policies to choose which transit domains are acceptable. A PCE in a
transit domain may use request-specific policies to determine if a transit domain may use request-specific policies to determine if a
request is from a direct customer or another provider, and then use request is from a direct customer or another provider, and then use
domain-specific policies to identify how the request should be domain-specific policies to identify how the request should be
processed. processed.
2.2.3. Scenario: Policy Based Constraints Example of policy:
if(path computation request issued by a PCC within Source Domain)
route the path through Transit Domain A
else
route the path through Transit Domain B
2.3.3. Scenario: Policy Based Constraints
Another usage scenario is the use of policy to provide constraints in Another usage scenario is the use of policy to provide constraints in
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.
skipping to change at page 12, line 19 skipping to change at page 13, line 26
information it knows about the user and service, such as the contents information it knows about the user and service, such as the contents
of the received message, port ID over which message was received, of the received message, port ID over which message was received,
associated VPN ID, signaling/reference point type, request time, etc. associated VPN ID, signaling/reference point type, request time, etc.
Once the constraints and other parameters of the required path Once the constraints and other parameters of the required path
computation are determined, the PCC generates a path computation computation are determined, the PCC generates a path computation
request which includes the request-specific policies that describe request which includes the request-specific policies that describe
the determined set of constraints, optimizations, and other the determined set of constraints, optimizations, and other
parameters that indicate how the request is to be considered in the parameters that indicate how the request is to be considered in the
path computation process. path computation process.
Example of policy:
if(LSP belongs to a WDM layer network)
Compute the path with wavelength continuity constraint with the
maximum OSNR at the path end optimization
else if(LSP belongs to a connection oriented Ethernet layer network)
Compute the path with minimum end-to-end delay
else
Compute the shortest path
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
service request is updated by the policy processing, the request is service request is updated by the policy processing, the request is
sent to the PCE. sent to the PCE.
Example of policy:
if(LSP belongs to a WDM layer network)
Identify a PCE supporting wavelength continuity and optical
impairment constraints; send a request to such PCE, requesting
path computation with the following constraints:
a) wavelength continuity;
b) maximum PMD at the path end.
if(the path computation fails)
remove the maximum PMD constraint and try the computation again
The PCE that receives the request validates and otherwise processes The PCE that receives the request validates and otherwise processes
the request, applying the policies found in the request as well as the request, applying the policies found in the request as well as
any policies that are available at the PCE, e.g., client and domain- any policies that are available at the PCE, e.g., client and domain-
specific polices. As a result of the policy processing, the PCE may 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 decide to reject the request.
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 Example of policy:
by performing a path computation, it determines if it needs the Authenticate the PCC requesting the path computation using the
cooperation of other PCEs and defines parameters for path PCC ID found in the path computation request;
computations to be performed locally and remotely. After that, the Reject the request if the authentication fails
PCE instructs a co-located path computation engine to perform the
local path computation(s) and, if necessary, sends path computation
requests 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 the result back
to the requesting PCC. The response may indicate 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 constraints were honored, which were
dismissed, and which were relaxed and in what way.
It The PCE 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 requests 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 the result back to the requesting PCC. The response
may indicate 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
constraints were honored, which were dismissed, and which were
relaxed and in what way.
Example of policy:
if(the path destination belongs to domain A)
Instruct local path computation engine to perform the path
computation;
else
Identify the PCE supporting the destination domain;
Send path computation request to such PCE;
Wait for and process the response
Send the path computation response to the requesting PCC
The PCC processes the response and instructs the LSR to encode the The PCC processes the response and instructs the LSR to encode the
received path(s) into the outgoing signaling message(s). received path(s) into the outgoing signaling message(s).
2.2.4. Scenario: Advanced Load Balancing (ALB) Example 2.3.4. Scenario: Advanced Load Balancing (ALB) Example
Figure 5 illustrates a problem that stems from the coupling between Figure 5 illustrates a problem that stems from the coupling between
BGP and IGP in the BGP decision process. If a significant portion of BGP and IGP in the BGP decision process. If a significant portion of
the traffic destined to the data center (or customer network) enters the traffic destined to the data center (or customer network) enters
a PCE-enabled network from AS 1 and all IGP links weights are the a PCE-enabled network from AS 1 and all IGP links weights are the
same, then both PE3 and PE4 will prefer to reach the data center same, then both PE3 and PE4 will prefer to reach the data center
using the routes advertised by PE2. PE5 will use the router-IDs of using the routes advertised by PE2. PE5 will use the router-IDs of
PE1 and PE2 to break the tie and might therefore also select to use PE1 and PE2 to break the tie and might therefore also select to use
the path through PE2 (if the router ID of PE2 is smaller than that of the path through PE2 (if the router ID of PE2 is smaller than that of
PE1). Either way the net result is that the link between PE2 and CE PE1). Either way the net result is that the link between PE2 and CE
skipping to change at page 14, line 29 skipping to change at page 16, line 28
This scenario is a good example of how a policy governed PCE can This scenario is a good example of how a policy governed PCE can
account for some information that was not or cannot be advertised as account for some information that was not or cannot be advertised as
TE link/node attributes, and, therefore, cannot be subject for TE link/node attributes, and, therefore, cannot be subject for
explicit path computation constraints. More generally, such explicit path computation constraints. More generally, such
information can be pretty much anything. For example, traffic demand information can be pretty much anything. For example, traffic demand
forecasts, flow monitoring feedback, any administrative policies, forecasts, flow monitoring feedback, any administrative policies,
etc. Further examples are described in [IRSCP] of how PCE policies etc. Further examples are described in [IRSCP] of how PCE policies
might address certain network routing problems, such as selective might address certain network routing problems, such as selective
DDoS blackholing, planned maintenance, and VPN gateway selection. DDoS blackholing, planned maintenance, and VPN gateway selection.
Example of policy:
for(all traffic flows destined to Customer Network)
if(flow ingresses on PE3, PE4 or PE5)
route the flow over PE1
else
route the flow over PE2
3. Requirements 3. Requirements
The following requirements must be addressed by mechanisms and The following requirements must be addressed by mechanisms and
protocols that enable policy-based control over path computation protocols that enable policy-based control over path computation
requests and decisions: requests and decisions:
- (G)MPLS path computation-specific - (G)MPLS path computation-specific
The mechanisms must meet the policy-based control requirements The mechanisms must meet the policy-based control requirements
specific to the problem of path computation using RSVP-TE as the specific to the problem of path computation using RSVP-TE as the
signaling protocol on MPLS and GMPLS LSRs. signaling protocol on MPLS and GMPLS LSRs.
skipping to change at page 18, line 11 skipping to change at page 20, line 17
foundation for the PCPIM. foundation for the PCPIM.
Detailed description of the PCPIM will be provided in a separate Detailed description of the PCPIM will be provided in a separate
documents. documents.
5. Policy-Enabled Path Computation Framework Components 5. Policy-Enabled Path Computation Framework Components
The following components are defined as part of the framework to The following components are defined as part of the framework to
support policy-enabled path computation: support policy-enabled path computation:
- PC Policy Repository - PCE Policy Repository
A database from which PC policies are available in the form of A database from which PCE policies are available in the form of
instances of PCPIM classes. PC Policies are configured and instances of PCPIM classes. PCE Policies are configured and
managed by PC Policy Management Tools; managed by PCE Policy Management Tools;
- PCE Policy Decision Point (PCE-PDP) - PCE Policy Decision Point (PCE-PDP)
A logical entity capable of retrieving relevant path computation A logical entity capable of retrieving relevant path computation
policies from one or more Policy Repositories and delivering the policies from one or more Policy Repositories and delivering the
information to associated PCE-PEP(s); information to associated PCE-PEP(s);
- PCE Policy Enforcement Point (PCE-PEP) - PCE Policy Enforcement Point (PCE-PEP)
A logical entity capable of issuing device specific Path A logical entity capable of issuing device specific Path
Computation Engine configuration requests for the purpose of Computation Engine configuration requests for the purpose of
enforcing the policies; enforcing the policies;
skipping to change at page 18, line 42 skipping to change at page 20, line 48
A logical entity capable of issuing device specific Path A logical entity capable of issuing device specific Path
Computation Service User configuration requests for the purpose Computation Service User configuration requests for the purpose
of enforcing the policies. of enforcing the policies.
From the policy perspective a PCC is logically decomposed into two From the policy perspective a PCC is logically decomposed into two
parts: PCC-PDP and PCC-PEP. When present, a PCC-PEP is co-located parts: PCC-PDP and PCC-PEP. When present, a PCC-PEP is co-located
with a Path Computation Service User entity that requires remote path with a Path Computation Service User entity that requires remote path
computation (for example, the GMPLS control plane of an LSR). The computation (for example, the GMPLS control plane of an LSR). The
PCC-PEP and PCC-PDP may be physically co-located (as per [RFC2748]) PCC-PEP and PCC-PDP may be physically co-located (as per [RFC2748])
or separated. In the later case they talk to each other via such or separated. In the later case they talk to each other via such
protocols as COPS and/or COPS-PR [RFC3084]. protocols as SOAP [W3CSOAP] or BEEP [RFC3080].
Likewise, a PCE is logically decomposed into two parts: PCE-PEP and Likewise, a PCE is logically decomposed into two parts: PCE-PEP and
PCE-PDP. When present, PCE-PEP is co-located with a Path Computation PCE-PDP. When present, PCE-PEP is co-located with a Path Computation
Engine entity that actually provides the Path Computation Service Engine entity that actually provides the Path Computation Service
(that is, runs path computation algorithms). PCE-PEP and PCE-PDP may (that is, runs path computation algorithms). PCE-PEP and PCE-PDP may
be physically co-located or separated. In the later case they be physically co-located or separated. In the later case they
communicate using such protocols as COPS and/or COPS-PR. communicate using such protocols as SOAP and/or BEEP.
PCC-PDP/PCE-PDP may be co-located with, or separated from, an PCC-PDP/PCE-PDP may be co-located with, or separated from, an
associated PC Policy Repository. In the latter case, the PDPs use associated PCE Policy Repository. In the latter case, the PDPs use
some access protocol (for example, LDAPv3 or SNMP). The task of PDPs some access protocol (for example, LDAPv3 or SNMP). The task of PDPs
is to retrieve policies from the repository(ies) and convey them to is to retrieve policies from the repository(ies) and convey them to
respective PEPs either in unsolicited way or upon the PEPs requests. respective PEPs either in unsolicited way or upon the PEPs requests.
A PCC-PEP may receive policy information not only from PCC-PDPs(s) A PCC-PEP may receive policy information not only from PCC-PDPs(s)
but also from PCE-PEP(s) via PCC-PCE communication and/or PCE but also from PCE-PEP(s) via PCC-PCE communication and/or PCE
discovery protocols. Likewise, a PCE-PEP may receive policy discovery protocols. Likewise, a PCE-PEP may receive policy
information not only from PCE-PDPs(s) but also from PCC-PEP(s), via information not only from PCE-PDPs(s) but also from PCC-PEP(s), via
PCC-PCE communication protocol. the PCC-PCE communication protocol [PCEP].
Any given policy can be interpreted (that is, translated into a Any given policy can be interpreted (that is, translated into a
sequence of concrete device specific configuration requests) either sequence of concrete device specific configuration requests) either
on a PDP or on the associated PEP or partly on the PDP and partly on on a PDP or on the associated PEP or partly on the PDP and partly on
the PEP. the PEP.
Generally speaking, the task of the PCC-PEP is to select the PCE and Generally speaking, the task of the PCC-PEP is to select the PCE and
build path computation requests applying service-specific policies build path computation requests applying service-specific policies
provided by the PCC-PDP. The task of the PCE-PEP is to control path provided by the PCC-PDP. The task of the PCE-PEP is to control path
computations by applying request-specific policies found in the computations by applying request-specific policies found in the
skipping to change at page 20, line 5 skipping to change at page 22, line 5
The PCE policy architecture supports policy being applied at a PCC The PCE policy architecture supports policy being applied at a PCC
and at a PCE. While the architecture supports policy being applied at and at a PCE. While the architecture supports policy being applied at
both, there is no requirement for policy to always be applied at both, there is no requirement for policy to always be applied at
both, or even at either. The use of policy in a network, on PCCs and both, or even at either. The use of policy in a network, on PCCs and
on PCEs, is a specific network design choice. Some networks may on PCEs, is a specific network design choice. Some networks may
choose to apply policy only at PCCs (Figure 7), some at PCEs (Figure choose to apply policy only at PCCs (Figure 7), some at PCEs (Figure
8), and others at both PCCs and PCEs (Figure 9). Regardless of where 8), and others at both PCCs and PCEs (Figure 9). Regardless of where
policy is applied it must be applied in a consistent fashion in order policy is applied it must be applied in a consistent fashion in order
to achieve the intended results. to achieve the intended results.
........................ .........................
. . . .
. PC Policy Management . . PCE Policy Management .
. . . .
........................ .........................
. .
. .
--------- Policy ---------------------- --------- Policy -----------------------
| PCC-PDP |<--------- | PC Policy Repository | | PCC-PDP |<--------- | PCE Policy Repository |
--------- ---------------------- --------- -----------------------
^ ^
| e.g., COPS | e.g., SOAP
v v
--------- --------- --------- PCEP ---------
| PCC-PEP |<------------------------------------------->| PCE | | PCC-PEP |<------------------------------------------->| PCE |
--------- PCC-PCE Communication Protocol --------- --------- PCC-PCE Communication Protocol ---------
Figure 7: Policies Applied On PCC Only Figure 7: Policies Applied On PCC Only
Along with supporting flexibility in where policy may be applied, the Along with supporting flexibility in where policy may be applied, the
PCE architecture is also flexible in terms of where specific types of PCE architecture is also flexible in terms of where specific types of
policies may be applied. Also the PCE architecture allows for the policies may be applied. Also the PCE architecture allows for the
application of only a subset of policy types. [RFC4655] defines application of only a subset of policy types. [RFC4655] defines
several PC policy types. Each of these may be applied at either a PCC several PC policy types. Each of these may be applied at either a PCC
or a PCE or both. Clearly when policy is only applied at PCCs or at or a PCE or both. Clearly when policy is only applied at PCCs or at
PCEs, all PC policy types used in the network must be applied at PCEs, all PCE policy types used in the network must be applied at
those locations. those locations.
........................ .........................
. . . .
. PC Policy Management . . PCE Policy Management .
. . . .
........................ .........................
. .
. .
---------------------- Policy --------- ----------------------- Policy ---------
| PC Policy Repository | -------->| PCE-PDP | | PCE Policy Repository | -------->| PCE-PDP |
---------------------- --------- ----------------------- ---------
^ ^
e.g., COPS | e.g., SOAP |
v v
--------- --------- --------- PCEP ---------
| PCC |<------------------------------------------->| PCE-PEP | | PCC |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol --------- --------- PCC-PCE Communication Protocol ---------
Figure 8: Policies Applied On Only Figure 8: Policies Applied On Only
In the case where policy is only applied at a PCE, it is expected In the case where policy is only applied at a PCE, it is expected
that the PCC will pass to the PCE all information about the service that the PCC will pass to the PCE all information about the service
that it can gather in the path computation request (most likely in that it can gather in the path computation request (most likely in
the form of PCPIM policy variables). The PCE is expected to the form of PCPIM policy variables). The PCE is expected to
understand this information and apply appropriate policies while understand this information and apply appropriate policies while
skipping to change at page 21, line 27 skipping to change at page 23, line 27
a PCC, request and client specific policies may be applied at a PCE, a PCC, request and client specific policies may be applied at a PCE,
while domain-specific policies may be applied at both the PCC and while domain-specific policies may be applied at both the PCC and
PCE. PCE.
In the case when policy is only applied at a PCC, the PCC must apply 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, server all the types of required policies, for example user, service, server
and domain-specific policies. The PCC uses the policies to construct and domain-specific policies. The PCC uses the policies to construct
a path computation request that appropriately represents the applied a path computation request that appropriately represents the applied
policies. The request will necessarily be limited to the set of policies. The request will necessarily be limited to the set of
"basic" (that is, non-policy capable) constraints explicitly defined "basic" (that is, non-policy capable) constraints explicitly defined
by the PCC-PCE communication protocol in use. by the PCC-PCE communication protocol.
6.2. Policy Repositories 6.2. Policy Repositories
Within the policy-enabled path computation framework policy Within the policy-enabled path computation framework policy
repositories may be used in a single or multiple PC policy repository repositories may be used in a single or multiple PCE policy
configuration: repository configuration:
o) Single PC Policy Repository o) Single PCE Policy Repository
In this configuration there is a single PC Policy Repository shared In this configuration there is a single PCE Policy Repository shared
between PCCs and PCEs. between PCCs and PCEs.
........................ .........................
. . . .
. PC Policy Management . . PCE Policy Management .
. . . .
........................ .........................
. .
. .
--------- Policy a ---------------------- Policy b --------- --------- Policy a ----------------------- Policy b ---------
| PCC-PDP |<--------- | PC Policy Repository | -------->| PCE-PDP | | PCC-PDP |<--------- | PCE Policy Repository | -------->| PCE-PDP |
--------- ---------------------- --------- --------- ----------------------- ---------
^ ^ ^ ^
| e.g., COPS e.g., COPS | | e.g., SOAP e.g., SOAP |
v v v v
--------- --------- --------- PCEP ---------
| PCC-PEP |<------------------------------------------->| PCE-PEP | | PCC-PEP |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol --------- --------- PCC-PCE Communication Protocol ---------
Figure 9: Single PCC/PCE Policy Repository Figure 9: Single PCC/PCE Policy Repository
o) Multiple PC Policy Repositories o) Multiple PCE Policy Repositories
The repositories in this case may be fully or partially synchronized The repositories in this case may be fully or partially synchronized
by some discovery/ synchronization management protocol or may be by some discovery/ synchronization management protocol or may be
completely independent. Note that the situation when PC Policy completely independent. Note that the situation when PCE Policy
Repository A exactly matches PC Policy Repository B, results in the Repository A exactly matches PC Policy Repository B, results in the
single PC Policy Repository configuration case. single PCE Policy Repository configuration case.
-------------- -------------- -------------- --------------
| PC Policy | | PC Policy | | PCE Policy | | PCE Policy |
---| Repository A | | Repository B |--- ---| Repository A | | Repository B |---
| -------------- -------------- | | -------------- -------------- |
| | | |
| Policy a Policy b | | Policy a Policy b |
| | | |
v v v v
--------- --------- --------- ---------
| PCC-PDP | | PCE-PDP | | PCC-PDP | | PCE-PDP |
--------- --------- --------- ---------
^ ^ ^ ^
| e.g., COPS e.g., COPS | | e.g., SOAP e.g., SOAP |
v v v v
--------- --------- --------- PCEP ---------
| PCC-PEP |<------------------------------------------->| PCE-PEP | | PCC-PEP |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol --------- --------- PCC-PCE Communication Protocol ---------
Figure 10: Multiple PCE/PCC Policy Repositories Figure 10: Multiple PCE/PCC Policy Repositories
6.3. Cooperating PCE Configurations 6.3. Cooperating PCE Configurations
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 PCE 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 requester- 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
In this configuration there is a single PC Policy repository shared In this configuration there is a single PCE Policy repository shared
between PCEs. This configuration is likely to be useful within a between PCEs. This configuration is likely to be useful within a
single administrative domain where multiple PCEs are provided for single administrative domain where multiple PCEs are provided for
redundancy or load distribution purposes. redundancy or load distribution purposes.
........................ .........................
. . . .
. PC Policy Management . . PCE Policy Management .
. . . .
........................ .........................
. .
. .
--------- Policy a ---------------------- Policy b --------- --------- Policy a ----------------------- Policy b ---------
| PCE-PDP |<--------- | PC Policy Repository | -------->| PCE-PDP | | PCE-PDP |<--------- | PCE Policy Repository | -------->| PCE-PDP |
--------- ---------------------- --------- --------- ----------------------- ---------
^ ^ ^ ^
| e.g., COPS e.g., COPS | | e.g., SOAP e.g., SOAP |
v v v v
--------- --------- --------- ---------
| PCE-PEP |<------------------------------------------->| PCE-PEP | | PCE-PEP |<------------------------------------------->| PCE-PEP |
--------- PCE-PCE Communication Protocol --------- --------- PCE-PCE Communication Protocol ---------
Figure 11: Single PCC Policy Repository Figure 11: Single PCC Policy Repository
o) Multiple Policy Repositories o) Multiple Policy Repositories
The repositories in this case may be fully or partially synchronized The repositories in this case may be fully or partially synchronized
by some discovery/synchronization management protocol(s) or may be by some discovery/synchronization management protocol(s) or may be
completely independent. In the multi-domain case it is expected that completely independent. In the multi-domain case it is expected that
the repositories will be distinct, providing, however. consistent the repositories will be distinct, providing, however. consistent
policies. policies.
-------------- -------------- -------------- --------------
| PC Policy | | PC Policy | | PCE Policy | | PCE Policy |
---| Repository A | | Repository B |--- ---| Repository A | | Repository B |---
| -------------- -------------- | | -------------- -------------- |
| | | |
| Policy a Policy b | | Policy a Policy b |
| | | |
v v v v
--------- --------- --------- ---------
| PCE-PDP | | PCE-PDP | | PCE-PDP | | PCE-PDP |
--------- --------- --------- ---------
^ ^ ^ ^
| e.g., COPS e.g., COPS | | e.g., SOAP e.g., SOAP |
v v v v
--------- --------- --------- PCEP ---------
| PCE-PEP |<------------------------------------------->| PCE-PEP | | PCE-PEP |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol --------- --------- PCC-PCE Communication Protocol ---------
Figure 12: Multiple PCC Policy Repositories Figure 12: Multiple PCC Policy Repositories
6.4. Policy Configuration Management 6.4. Policy Configuration Management
The management of path computation policy information used by PCCs The management of path computation policy information used by PCCs
and PCEs is largely out of scope of the described framework. The and PCEs is largely out of scope of the described framework. The
framework assumes that such information is installed, removed and framework assumes that such information is installed, removed and
skipping to change at page 25, line 32 skipping to change at page 27, line 32
opaque policy related information elements. opaque policy related information elements.
A final added complexity is that PCE communication protocols must A final added complexity is that PCE communication protocols must
also be able to support updated or unsolicited responses from a PCE. 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 For example, changes in PCE policy may force a change to a previously
provided path. Such updated or unsolicited responses may contain provided path. Such updated or unsolicited responses may contain
information that the PCC must act on, and may contain policy information that the PCC must act on, and may contain policy
information that must be provided to a PCC. information that must be provided to a PCC.
PCC-PEP and PCE-PEP or a pair of PCE-PEPs communicate via a request- PCC-PEP and PCE-PEP or a pair of PCE-PEPs communicate via a request-
response type PCC-PCE Communication Protocol. This document makes no response type PCC-PCE Communication Protocol, i.e., [PCEP]. This
assumptions as to what exact protocol is used to support this document makes no assumptions as to what exact protocol is used to
communication. This document does assume that the semantics of a support this communication. This document does assume that the
path computation request are sufficiently abstract and general, and semantics of a path computation request are sufficiently abstract and
support both PCE-PCC and PCE-PCE communication. general, and support both PCE-PCC and PCE-PCE communication.
From a policy perspective, a path computation request should include From a policy perspective, a path computation request should include
at a minimum: at a minimum:
o One or more source addresses; o One or more source addresses;
o One or more destination addresses; o One or more destination addresses;
o Computation type (P2P, P2MP, MP2P, etc.); o Computation type (P2P, P2MP, MP2P, etc.);
o Number of required paths; o Number of required paths;
o Zero or more policy descriptors in the following format: o Zero or more policy descriptors in the following format:
<policy name>, <policy name>,
<policy variable1 name>, <param11>, <param12>,...,<param1N> <policy variable1 name>, <param11>, <param12>,...,<param1N>
skipping to change at page 26, line 20 skipping to change at page 28, line 20
the semantics of policies specified in path computation requests and the semantics of policies specified in path computation requests and
responses. responses.
Note: This document explicitly allows for (but does not require) the Note: This document explicitly allows for (but does not require) the
PCC to decide that all necessary constraints, objective functions, PCC to decide that all necessary constraints, objective functions,
etc. pertinent to the computation of paths for the service in etc. pertinent to the computation of paths for the service in
question are to be determined by the PCE performing the computation. question are to be determined by the PCE performing the computation.
In this case the PCC will use a set of policies (more precisely, In this case the PCC will use a set of policies (more precisely,
PCPIM policy variables) describing the service-specific information. PCPIM policy variables) describing the service-specific information.
These policies may be placed within the path computation request and These policies may be placed within the path computation request and
delivered to the PCE via a PCC-PCE communication protocol. The PCE delivered to the PCE via a PCC-PCE communication protocol such as
(more precisely, PCE-PEP) is expected to understand this information [PCEP]. The PCE (more precisely, PCE-PEP) is expected to understand
and use it to determine the constraints and optimization functions this information and use it to determine the constraints and
applying local policies (that is, policies locally configured or optimization functions applying local policies (that is, policies
provided by the associated PCE-PDP(s)). locally configured or 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 status. Policy can be applied in new PCEs or any modification of PCEs status. Policy can be 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
skipping to change at page 27, line 35 skipping to change at page 29, line 35
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
select a list of policies, their variables, conditions and select a list of policies, their variables, conditions and
actions expressing constraints, diversities, objective functions actions expressing constraints, diversities, objective functions
and relaxation strategies appropriate for the service path and relaxation strategies appropriate for the service path
computation). The policies may be: computation). The policies may be:
a) Statically configured on the PCC-PEP; a) Statically configured on the PCC-PEP;
b) Communicated to the PCC-PEP by a remote or local PCC-PDP b) Communicated to the PCC-PEP by a remote or local PCC-PDP
via protocol such as COPS either pro-actively (most of the via protocol such as SOAP either pro-actively (most of the
cases) or upon an explicit request by the PCC-PEP in case when 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 some specifics of the new service have not been covered yet by
the policies so far known to the PCC-PEP) the policies so far known to the PCC-PEP)
The input for the decision process on the PCC-PEP is the The input for the decision process on the PCC-PEP is the
information found in the signaling message as well as any other information found in the signaling message as well as any other
service-specific information such as port ID over which the message service-specific information such as port ID over which the message
was received, associated VPN ID, the reference point type (UNI, E- was received, associated VPN ID, the reference point type (UNI, E-
NNI, etc.) and so forth. After the path computation request is NNI, etc.) and so forth. After the path computation request is
built it is sent directly to the PCE-PEP using the PCC-PCE built it is sent directly to the PCE-PEP using the PCC-PCE
Communication Protocol. Communication Protocol, e.g., [PCEP].
- PCE-PEP validates and otherwise processes the request applying - PCE-PEP validates and otherwise processes the request applying
the policies found in the request as well as client and domain the policies found in the request as well as client and domain
specific polices. The latter, again, may be either statically specific polices. The latter, again, may be either statically
configured on the PCE-PEP or provided by the associated local or 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 remote PCE-PDP via a protocol such as SOAP. The outcome of the
decision process is the following information: decision process is the following information:
a) Whether the request should be satisfied, rejected or a) Whether the request should be satisfied, rejected or
dismissed. dismissed.
b) The sets of sources and destinations for which paths should b) The sets of sources and destinations for which paths should
be locally computed. be locally computed.
c) The set of constraints, diversities, optimization functions c) The set of constraints, diversities, optimization functions
and relaxations to be considered in each of locally performed and relaxations to be considered in each of locally performed
skipping to change at page 29, line 15 skipping to change at page 31, line 15
request in the form of policy variables. After the request is request in the form of policy variables. After the request is
built it is sent directly to the PCE-PEP using a PCC-PCE built it is sent directly to the PCE-PEP using a PCC-PCE
Communication Protocol. Communication Protocol.
- PCE-PEP validates and otherwise processes the request - PCE-PEP validates and otherwise processes the request
interpreting the policy variables found in the request and interpreting the policy variables found in the request and
applying user, service- and also client- and domain- specific applying user, service- and also client- and domain- specific
polices to build the actual path computation request. The polices to build the actual path computation request. The
policies, again, may be either statically configured on the policies, again, may be either statically configured on the
PCE-PEP or provided by the associated local or remote PCE-PDP via 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 a protocol such as SOAP. The outcome of the decision process is
the following information: the following information:
a) Whether the request should be satisfied, rejected or a) Whether the request should be satisfied, rejected or
dismissed. dismissed.
b) The sets of sources and destinations for which paths should b) The sets of sources and destinations for which paths should
be locally computed. be locally computed.
c) The set of constraints, diversities, optimization functions c) The set of constraints, diversities, optimization functions
and relaxations to be considered in each of locally performed and relaxations to be considered in each of locally performed
skipping to change at page 30, line 22 skipping to change at page 32, line 22
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
installed in the PC Policy Repository (associated with the PCE) installed in the PCE Policy Repository (associated with the PCE)
defining the constraint (rules that determine application criteria, defining the constraint (rules that determine application criteria,
set of policy variables, conditions, actions, etc.) and its set of policy variables, conditions, actions, etc.) and its
relaxation strategy(ies). The new policies will be also propagated relaxation strategy(ies). The new policies will be also propagated
into other PC Policy Repositories within the domain via discovery and into other PCE Policy Repositories within the domain via discovery
synchronization protocols or via local configuration. PCE-PDPs and and synchronization protocols or via local configuration. PCE-PDPs
PCC-PDPs will then retrieve the corresponding policies from the and PCC-PDPs will then retrieve the corresponding policies from the
repository(ies). From then on PCC-PDPs will instruct associated PCC- repository(ies). From then on PCC-PDPs will instruct associated PCC-
PEPs to add the new policy information into path computation requests PEPs to add the new policy information into path computation requests
for services with certain parameters (for example, for services for services with certain parameters (for example, for services
provisioned in the OCh layer). provisioned in the OCh layer).
It is important to note that policy-enabled path computation model It is important to note that policy-enabled path computation model
naturally solves the PCE capability discovery issues. Suppose a PCE naturally solves the PCE capability discovery issues. Suppose a PCE
working in a single PC Policy Repository configuration starts to working in a single PCE Policy Repository configuration starts to
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
issues related to policy information maintained in PC Policy issues related to policy information maintained in PCE Policy
Repositories and policy related transactions. The most notable Repositories and policy related transactions. The most notable
issues, some of which are also 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 PCE 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;
o Falsification of policy information and/or PCE capabilities; o Falsification of policy information and/or PCE capabilities;
o Denial of service attacks on policy related communication o Denial of service attacks on policy related communication
mechanisms. mechanisms.
As with [RFC4655], it is expected that PCE solutions will address the As with [RFC4655], it is expected that PCE solutions will address the
PCE aspects of these issues in detail. PCE aspects of these issues in detail.
11. Acknowledgments 11. Acknowledgments
We would like to thank Bela Berde for fruitful discussions on PBM and Adrian Farrel contributed significantly to this document. We would
Policy-driven path computation, Adrian Farrel for his detailed input. like to thank Bela Berde for fruitful discussions on PBM and Policy-
We would also like to thank Kobus Van der Merwe for providing driven path computation. We would also like to thank Kobus Van der
insights and examples regarding PCE policy applications. Merwe for providing insights and examples regarding PCE policy
applications.
12. IANA Considerations 12. IANA Considerations
None. None.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2753] R. Yavatkar, D. Pendarakis, R. Guerin, A Framework for [RFC2753] R. Yavatkar, D. Pendarakis, R. Guerin, A Framework for
Policy Based Admission Control, RFC 2753, January 2000. 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 Core Information Model -- [RFC3060] B. Moore, et al., Policy Core Information Model --
Version 1 Specification, RFC 3060, February 2001. Version 1 Specification, RFC 3060, February 2001.
[RFC3209] Awduche, D., et al., "Extensions to RSVP for LSP [RFC3209] Awduche, D., et al., "Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3460] Moore, B. Ed., "Policy Core Information Model (PCIM) [RFC3460] Moore, B. Ed., "Policy Core Information Model (PCIM)
Extensions", RFC 3460, January 2003. Extensions", RFC 3460, January 2003.
[RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label [RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label
skipping to change at page 32, line 35 skipping to change at page 34, line 32
MPLS and GMPLS Traffic Engineering", June 2007. MPLS and GMPLS Traffic Engineering", June 2007.
13.2. Informative References 13.2. Informative References
[DMTF] Common Information Model (CIM) Schema, version 2.x. [DMTF] Common Information Model (CIM) Schema, version 2.x.
Distributed Management Task Force, Inc. The components Distributed Management Task Force, Inc. The components
of the CIM v2.x schema are available via links on the of the CIM v2.x schema are available via links on the
following DMTF web page: following DMTF web page:
http://www.dmtf.org/standards/standard_cim.php. http://www.dmtf.org/standards/standard_cim.php.
[IRSCP] Van der Merwe, J., et. al., "Dynamic Connectivity [IRSCP] Van der Merwe, J., et al., "Dynamic Connectivity
Management with an Intelligent Route Service Control Management with an Intelligent Route Service Control
Point," ACM SIGCOMM Workshop on Internet Network Point," ACM SIGCOMM Workshop on Internet Network
Management (INM), Pisa, Italy, September 11, 2006. Management (INM), Pisa, Italy, September 11, 2006.
[PCEP] Vasseur, J., Le Roux, J., Eds., "Path Computation Element
(PCE) Communication Protocol (PCEP)", Work in Progress,
draft-ietf-pce-pcep-16.txt, October 14, 2008.
[RFC2748] D. Durham, et al., The COPS (Common Open Policy Service)
protocol, RFC 2748, IETF, January 2000.
[RFC3031] Rosen, E,. Viswanathan, V. Callon, R., "Multiprotocol [RFC3031] Rosen, E,. Viswanathan, V. Callon, R., "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol
K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Core", RFC 3080, March 2001.
Smith, "COPS Usage for Policy Provisioning (COPS-PR)",
RFC 3084, February 2001.
[RFC3198] Westerinen, A., et al., "Terminology for Policy-Based [RFC3198] Westerinen, A., et al., "Terminology for Policy-Based
Management", RFC 3198, November 2001. Management", RFC 3198, November 2001.
[RFC3630] Katz, D., Kompella, K., Yeung., D., "Traffic Engineering [RFC3630] Katz, D., Kompella, K., Yeung., D., "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September (TE) Extensions to OSPF Version 2", RFC 3630, September
2003. 2003.
[INTERAS-PCEP] Bitar, N., Zhang, R., Kumaki, K., Eds., "Inter-AS [INTERAS-PCEP] Bitar, N., Zhang, R., Kumaki, K., Eds., "Inter-AS
Requirements for the Path Computation Element Requirements for the Path Computation Element
Communication Protocol (PCECP)", February 2006. Communication Protocol (PCECP)", February 2006.
[W3CSOAP] Hadley, M., Mendelsohn, N., Moreau, J., Nielsen, H.,
and Gudgin, M., "SOAP Version 1.2 Part 1: Messaging
Framework", W3C REC REC-soap12-part1-20030624, June
2003.
14. Authors' Addresses 14. Authors' Addresses
Igor Bryskin Igor Bryskin
ADVA Optical ADVA Optical
7926 Jones Branch Drive 7926 Jones Branch Drive
Suite 615 Suite 615
McLean, VA 22102 McLean, VA 22102
Email: ibryskin@advaoptical.com Email: ibryskin@advaoptical.com
Dimitri Papadimitriou (Alcatel) Dimitri Papadimitriou (Alcatel)
skipping to change at page 33, line 37 skipping to change at page 36, line 5
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
Full Copyright Statement 15. Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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.
Intellectual Property 16. 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
pertain to the implementation or use of the technology described in to pertain to the implementation or use of the technology
this document or the extent to which any license under such rights described in this document or the extent to which any license
might or might not be available; nor does it represent that it has under such rights might or might not be available; nor does it
made any independent effort to identify any such rights. Information represent that it has made any independent effort to identify any
on the procedures with respect to rights in RFC documents can be such rights. Information on the procedures with respect to rights
found in BCP 78 and BCP 79. in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use
such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository
http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention
copyrights, patents or patent applications, or other proprietary any copyrights, patents or patent applications, or other
rights that may cover technology that may be required to implement proprietary rights that may cover technology that may be required
this standard. Please address the information to the IETF at ietf- to implement this standard. Please address the information to the
ipr@ietf.org. IETF at ietf-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: Fri Oct 26 16:05:21 EDT 2007 Generated on: Tue Oct 28 19:31:33 EDT 2008
 End of changes. 94 change blocks. 
177 lines changed or deleted 287 lines changed or added

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