draft-ietf-pce-policy-enabled-path-comp-01.txt   draft-ietf-pce-policy-enabled-path-comp-02.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: September 2, 2007 Lou Berger (LabN Consulting) Expiration Date: January 6, 2008 Lou Berger (LabN Consulting)
Jerry Ash (AT&T) Jerry Ash (AT&T)
March 2, 2007 July 6, 2007
Policy-Enabled Path Computation Framework Policy-Enabled Path Computation Framework
draft-ietf-pce-policy-enabled-path-comp-01.txt draft-ietf-pce-policy-enabled-path-comp-02.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 September 2, 2007. This Internet-Draft will expire on January 6, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The PCE architecture [RFC4655] introduces the concept of policy in The Path Computation Element (PCE) Architecture introduces the
the context of path computation. This document provides additional concept of policy in the context of path computation. This document
details on policy within the PCE Architecture and also provides provides additional details on policy within the PCE Architecture and
context for the support of PCE Policy. This document introduces the also provides context for the support of PCE Policy. This document
use of the Policy Core Information Model (PCIM) as a framework for introduces the use of the Policy Core Information Model (PCIM) as a
supporting path computation policy. This document also provides framework for supporting path computation policy. This document also
representative scenarios for the support of PCE Policy. provides representative scenarios for the support of PCE Policy.
Contents Contents
1 Terminology ............................................... 3 1 Introduction .............................................. 3
2 Introduction .............................................. 3 1.1 Terminology ............................................... 4
3 Background ................................................ 4 2 Background ................................................ 4
3.1 Motivations ............................................... 4 2.1 Motivation ................................................ 5
3.2 Representative Policy Scenarios ........................... 6 2.2 Representative Policy Scenarios ........................... 7
3.2.1 Scenario: Policy Configured Paths ......................... 6 2.2.1 Scenario: Policy Configured Paths ......................... 7
3.2.2 Scenario: Provider Selection Policy ....................... 9 2.2.2 Scenario: Provider Selection Policy ....................... 10
3.2.3 Scenario: Policy Based Constraints ........................ 10 2.2.3 Scenario: Policy Based Constraints ........................ 11
3.2.4 Scenario: Advanced Load Balancing (ALB) Example .......... 11 2.2.4 Scenario: Advanced Load Balancing (ALB) Example .......... 13
4 Requirements .............................................. 13 3 Requirements .............................................. 14
5 Path Computation Policy Information Model (PCPIM) ......... 15 4 Path Computation Policy Information Model (PCPIM) ......... 16
6 Policy-Enabled Path Computation Framework Components ...... 16 5 Policy-Enabled Path Computation Framework Components ...... 18
7 Policy Component Configurations ........................... 18 6 Policy Component Configurations ........................... 19
7.1 PCC-PCE Configurations .................................... 18 6.1 PCC-PCE Configurations .................................... 19
7.2 Policy Repositories ....................................... 20 6.2 Policy Repositories ....................................... 21
7.3 Cooperating PCE Configurations ............................ 21 6.3 Cooperating PCE Configurations ............................ 23
7.4 Policy Configuration Management ........................... 23 6.4 Policy Configuration Management ........................... 24
8 Inter-Component Communication ............................. 23 7 Inter-Component Communication ............................. 24
8.1 Policy Communication ..................................... 23 7.1 Policy Communication ..................................... 24
8.2 PCE Discovery Policy Considerations ....................... 25 7.2 PCE Discovery Policy Considerations ....................... 26
9 Path Computation Sequence of Events ....................... 25 8 Path Computation Sequence of Events ....................... 27
9.1 Policy-enabled PCC, Policy-enabled PCE .................... 26 8.1 Policy-enabled PCC, Policy-enabled PCE .................... 27
9.2 Policy-ignorant PCC, Policy-enabled PCE ................... 27 8.2 Policy-ignorant PCC, Policy-enabled PCE ................... 28
10 Introduction of New Constraints ........................... 28 9 Introduction of New Constraints ........................... 30
11 Security Considerations ................................... 29 10 Security Considerations ................................... 30
12 Acknowledgements .......................................... 30 11 Acknowledgments ........................................... 31
13 IANA Considerations ....................................... 30 12 IANA Considerations ....................................... 31
14 References ................................................ 30 13 References ................................................ 31
14.1 Normative References ...................................... 30
14.2 Informative References .................................... 31
15 Authors' Addresses ........................................ 32
16 Full Copyright Statement .................................. 32
17 Intellectual Property ..................................... 33
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1. Terminology
The reader is assumed to be familiar with the following terms: 13.1 Normative References ...................................... 31
CSPF: Constraint-based Shortest Path First, see [RFC3630]. 13.2 Informative References .................................... 32
LSP: Label Switched Path, see [RFC3031]. 14 Authors' Addresses ........................................ 33
LSR: Label Switching Router, see [RFC3031]. 15 Full Copyright Statement .................................. 33
PCC: Path Computation Client, see [RFC4655]. 16 Intellectual Property ..................................... 34
PCE: Path Computation Element, see [RFC4655].
TE LSP: Traffic Engineering MPLS Label Switched Path, see
[RFC3209] and [RFC3473].
CIM: Common Information Model, see [DMTF].
PCIM: Policy Core Information Model, see [RFC3060].
PC: Path Computation.
PCCIM: Path Computation Core Information Model.
QPIM: QoS Policy Information Model, see [RFC3644].
PBM: Policy-based Management, see [RFC3198].
PEP: Policy Enforcement Points, see [RFC2753].
PDP: Policy Decision Points, see [RFC2753].
COPS: Common Open Policy Service, see [RFC2748].
COPS-PR: COPS Usage for Policy Provisioning, see [RFC3084].
2. Introduction 1. Introduction
The PCE architecture is introduced in [RFC4655]. This document The Path Computation Element (PCE) Architecture is introduced in
describes the impact of policy on the PCE architecture and provides [RFC4655]. This document describes the impact of policy on the PCE
additional details on, and context for, policy within the PCE architecture and provides additional details on, and context for,
Architecture. policy within the PCE Architecture.
Policy-based Management (PBM) enables network administrators to Policy-based Management (PBM), see [RFC3198], is a network management
operate in a high-level manner through rule-based policies; the approach that enables a network to automatically perform actions in
latter are translated automatically into individual device response to network events or conditions based on pre-established
configuration directives, aimed at controlling a network as a whole. direction, i.e., policies, from a network administrator. PBM enables
Two IETF Working Groups have considered policy networking in the network administrators to operate in a high-level manner through
past: The Resource Allocation Protocol working group and the Policy rule-based policies; the latter are translated automatically into
Framework working group. individual device configuration directives, aimed at controlling a
network as a whole. Two IETF Working Groups have considered policy
networking in the past: The Resource Allocation Protocol 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.
This document introduces PCIM as a core component in a framework for In Section 2, this document presents policy related background and
providing policy-enabled path computation. This document also covers scenarios to provide a context for this work. Section 3 provides
the other aspects of the framework. It also discusses related requirements that must be addressed by mechanisms and protocols that
background to provide a context for this work. Specific PCIM enable policy-based control over path computation requests and
definition to support path computation will be discussed in a decisions. Section 4 introduces PCIM as a core component in a
separate document. framework for providing policy-enabled path computation. Section 5
introduces a set of components that may be used to support policy-
enabled path computation. Sections 6, 7 and 8 provide details on
possible component configurations, communication and events. Section
10 discusses the ability to introduce new constraints with minimal
impact. It should be noted that this document, in Section 4, only
introduces PCIM, specific PCIM definitions to support path
computation will be discussed in a separate document.
3. Background 1.1. Terminology
The reader is assumed to be familiar with the following terms:
CIM: Common Information Model, see [DMTF].
COPS: Common Open Policy Service, see [RFC2748].
COPS-PR: COPS Usage for Policy Provisioning, see [RFC3084].
CSPF: Constraint-based Shortest Path First, see [RFC3630].
LSP: Label Switched Path, see [RFC3031].
LSR: Label Switching Router, see [RFC3031].
PBM: Policy-based Management, see [RFC3198].
PC: Path Computation.
PCC: Path Computation Client, see [RFC4655].
PCCIM: Path Computation Core Information Model.
PCE: Path Computation Element, see [RFC4655].
PCIM: Policy Core Information Model, see [RFC3060].
PDP: Policy Decision Points, see [RFC2753].
PEP: Policy Enforcement Points, see [RFC2753].
QPIM: QoS Policy Information Model, see [RFC3644].
SLA: Service Level Agreement.
TE: Traffic Engineering, see [RFC3209] and [RFC3473].
TE LSP: Traffic Engineering MPLS Label Switched Path, see
[RFC3209] and [RFC3473].
2. Background
This section provides some general background on the use of policy This section provides some general background on the use of policy
within the PCE architecture. It presents some rational behind the use within the PCE architecture. It presents the rationale behind the use
of policy, as well as representative policy usage scenarios. This of policy in path computation, as well as representative policy usage
information is intended to provide context for the presented policy scenarios. This information is intended to provide context for the
framework. This section does not attempt to present an exhaustive presented PCE policy framework. This section does not attempt to
list of rational or scenarios. present an exhaustive list of rationales or scenarios.
3.1. Motivations 2.1. Motivation
The PCE architecture is introduced in [RFC4655]. It includes policy The PCE architecture is introduced in [RFC4655]. It includes policy
as an integral part of the PCE architecture. This section presents as an integral part of the PCE architecture. This section presents
some of the rational for this inclusion. some of 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 optimizations,
constraints, diversities and their relaxation strategies to request constraints, diversities and their relaxation strategies to request
while computing path(s) for a particular service. Depending on SLAs, while computing path(s) for a particular service. Depending on SLAs,
TE and cost/performance ratio goals, path computation requests may be TE and cost/performance ratio goals, path computation requests may be
built differently for different services. Service A, for instance, built differently for different services. Service A, for instance,
may require two SRLG-disjoint paths for building end-to-end recovery may require two SRLG-disjoint paths for building end-to-end recovery
scheme, while for service B link-disjoint paths may be sufficient. scheme, while for service B link-disjoint paths may be sufficient.
Service A may need paths with minimal end-to-end delay, while service Service A may need paths with minimal end-to-end delay, while service
B may be looking for shortest (minimal-cost) paths. Different B may be looking for shortest (minimal-cost) paths. Different
constraint relaxation strategies may be applied while computing paths constraint relaxation strategies may be applied while computing paths
for service A and for service B, and so forth. for service A and for service B, and so forth.
Likewise, a PCE may apply policies to decide which algorithm or Likewise, a PCE may apply policies to decide which algorithm or
algorithms to use while performing path computations requested from a algorithms to use while performing path computations requested from a
particular PCC or for a particular domain, see [PCECP-IA-REQ]; particular PCC or for a particular domain, see [RFC4927]; whether to
whether to seek the cooperation of other PCEs to satisfy a particular seek the cooperation of other PCEs to satisfy a particular request or
request or to handle a request on its own (possibly responding with to handle a request on its own (possibly responding with non explicit
non explicit paths); or how the request should be modified before paths); or how the request should be modified before being sent to
being sent to other member(s) of a group of cooperating PCEs, etc. other member(s) of a group of cooperating PCEs, etc.
Additional motivations for supporting policy within the PCE Additional motivation for supporting policy 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 criterions, etc. adopting new objective functions and optimization criteria, etc. All
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).
With the introduction of the PCE architecture, the introduction of With the introduction of the PCE architecture, the introduction of
new PCE capabilities becomes more complicated: it isn't enough for a new PCE capabilities becomes more complicated: it isn't enough for a
PCE to upgrade its own software. In order to take advantage of a PCE to upgrade its own software. In order to take advantage of a
PCE's new capabilities, new advertising and signaling objects may PCE's new capabilities, new advertising and signaling objects may
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 PCC software. One way to achieve discovery/communication protocols or the PCC software. One way to
this objective is to consider path selection constraints, their achieve this objective is to consider path selection constraints,
relaxations and objective functions, as path computation request their relaxations and objective functions, as path computation
specific policies. Furthermore such policies may, on one hand, be request-specific policies. Furthermore, such policies may, on the one
configured and managed by an operator as any other policies or, on hand, be configured and managed by an operator as any other policies
the other hand, may be interpreted in real time by PCCs and PCEs. or, on the other hand, may be interpreted in real time by PCCs and
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 in this document as path computation capabilities (referred to in this document as a path
engine) needs to be updated. computation engine) needs to be updated.
- Existing constraints, objective functions and their relaxations - Existing constraints, objective functions and their relaxations
may be aggregated and otherwise associated together, thus, may be aggregated and otherwise associated, thus producing new,
producing new more complex ones that do not require change of more complex objective functions that do not require a change
code even on PCEs supporting them. of code even on the PCEs supporting the functions.
- 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 independently from 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.
3.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 policy may be applied
using the PCE policy framework within the PCE architecture context. using the PCE policy framework within the PCE architecture context.
Actual networks may use one of the scenarios discussed, some Actual networks may use one of the scenarios discussed, some
combination of the presented scenarios or other scenarios (not 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 policy within the PCE architecture.
3.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 EROs (see [RFC3209]), and are of strict and loose hops in the form of Explicit Route Objects
used by one or more LSPs. Typically such paths are configured at the (EROs), see [RFC3209], and are used by one or more LSPs. Typically,
LSP ingress. In the context of policy-enabled path computation, an such paths are configured at the LSP ingress. In the context of
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 end-user. points, requested QoS, or even a token that identifies the initiator
The configured path(s) would then be used as input to PCE computation of a service request. The configured path(s) would then be used as
process, which would return explicit routes by expanding of all input to the PCE computation process, which would return explicit
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
| |Policy|<-->| PCE |<.+...........> (when present) | |Policy|<-->| PCE |<.+...........> (when present)
| ------ ----- | | ------ ----- |
---------------------- ----------------------
^ ^
| Request/ | Request/
| Response | Response
v v
Service ------------- Signaling Service ------------- Signaling
Request|[PCC][Policy]| Protocol Request|[PCC][Policy]| Protocol
...--->| Node |<----.... <------>| Node |<------->
or Signaling ------------- or Signaling -------------
Protocol Protocol
Figure 1: Policy Enabled PCC and PCE Figure 1: Policy Enabled PCC and PCE
The described policies may be applied at either PCC or PCE, see Path computation policies may be applied at either a PCC or a PCE,
Figure 1. In the PCC case, the configured path would be processed at see Figure 1. In the PCC case, the configured path would be processed
the PCC and then passed to the PCE along with the PCE request, at the PCC and then passed to the PCE along with the PCE request,
probably in the form of (inclusion) constraints. When applied at the probably in the form of (inclusion) constraints. When applied at the
PCE, the configured path would be used locally. Both cases require PCE, the configured path would be used locally. Both cases require
some method to configure and manage policies. In the PCC case, the some method to configure and manage policies. In the PCC case, the
real benefit would come when there is an automated policy real benefit would come when there is an automated policy
distribution mechanism. distribution mechanism.
------------------ ------------------- ------------------ -------------------
| | | | | | | |
| PCE | | PCE | | PCE | | PCE |
| | | | | | | |
skipping to change at page 8, line 51 skipping to change at page 10, line 4
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 multiple PCE environments
(see Figures 2 and 3). For example, consider the case when there is (see Figures 2 and 3). For example, consider the case when there is
limited TE visibility and independent PCEs are used to determine limited TE visibility and independent PCEs are used to determine
path(s) within each area of the TE visibility. In such a case, it may path(s) within each area of the TE visibility. In such a case, it may
not be possible (or desirable) to configure entire explicit path(s) not be possible (or desirable) to configure entire explicit path(s)
on a single PCE. However, it is possible to configure explicit on a single PCE. However, it is possible to configure explicit
path(s) for each area of the TE visibility and each responsible PCE. path(s) for each area of the TE visibility and each responsible PCE.
One by one, the PCEs would then map an incoming signaling request to One by one, the PCEs would then map an incoming signaling request to
appropriate configured path(s). Note that to make such scenario work appropriate configured path(s). Note that to make such a scenario
it would likely be necessary to start and finish the configured paths work it would likely be necessary to start and finish the configured
on TE domain boundary nodes. Clearly, consistent PC Policy paths on TE domain boundary nodes. Clearly, consistent PC Policy
Repositories are also critical in this example. Repositories are also critical in this example.
3.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 usage scenario is applying PC policies
in multi-domain multi-provider networks. There are numerous in multi-domain multi-provider topologies. There are numerous
interesting policy applications in such networks. A rudimentary interesting policy applications in such topologies. A rudimentary
example is simple access control, that is, deciding which clients are example is simple access control, that is, deciding which clients are
permitted to request inter-domain path computation. permitted to request 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 provider network 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 networks available to provide a path from there are multiple transit domains available to provide a path from a
a source domain to a destination domain. Furthermore, each transit source domain to a destination domain. Furthermore, each transit
network may have one or more options for reaching a particular domain may have one or more options for reaching a particular domain.
domain. Each domain will need to select which of the multiple Each domain will need to select which of the multiple available paths
available paths will be used to satisfy a particular PCE request. will be used to satisfy a particular PCE request.
Clearly, TE reachability, availability and length are the basic In today's typical path computation process, TE reachability,
criterions for path selection, however, policies can provide an availability and metric are the basic criteria for path selection.
important added consideration in the decision process. For example, However, policies can provide an important added consideration in the
transit network A may be more expensive and provide lower delay or decision process. For example, transit domain A may be more expensive
loss than transit network C. Likewise, a transit network may wish to and provide lower delay or loss than transit domain B. Likewise, a
treat PCE requests from its own customers differently than requests transit domain may wish to treat PCE requests from its own customers
from other providers. In both cases, computation based on traffic differently than requests from other providers. In both cases,
engineering databases will result in multiple transit networks that computation based on traffic engineering databases will result in
provide reachability, and policies can be used to govern which PCE multiple transit domain that provide reachability, and policies can
requests get better service. be used to govern which PCE requests get better service.
+----------------+ +-------+
|Transit Domain A| +----------------+ +----------+Transit+----------+
+----------------+ |Transit Domain D| +---+---+ | Domain| +---+---+
+------+ +----------------+ +----------------+ +------+ |Transit| | C | |Transit|
|Source| |Transit Domain B| +----------------+ |Target| +--------+ Domain| +---+---+ | Domain+--------+
|Domain| +----------------+ |Transit Domain E| |Domain| | | A +--+ | +--+ F | |
+------+ +----------------+ +----------------+ +------+ +--+---+ +---+---+ | | | +---+---+ +--+---+
|Transit Domain C| +----------------+ |Source| | | +---+---+ | | |Target|
+----------------+ |Transit Domain F| |Domain| | +---+Transit+---+ | |Domain|
+----------------+ +--+---+ | +---+ Domain|---+ | +--+---+
| +---+---+ | | D | | +---+---+ |
| |Transit| | +---+---+ | |Transit| |
+--------+ Domain+--+ | +--+ Domain+--------+
| B | | | G |
+---+---+ +---+---+ +---+---+
| |Transit| |
+----------+ Domain+----------+
| E |
+-------+
Figure 4: Multi-domain network with multiple transit options Figure 4: Multi-Domain Network with Multiple Transit Options
There are multiple options for differentiating which PCE requests use There are multiple options for differentiating which PCE requests use
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.
3.2.3. Scenario: Policy Based Constraints 2.2.3. Scenario: Policy Based Constraints
Another usage scenario is the use of policy to provide new Another usage scenario is the use of policy to provide constraints in
constraints in a PCE request. Consider an LSR with a policy enabled a PCE request. Consider an LSR with a policy enabled PCC, as shown in
PCC, as shown in Figure 1, which receives a service request via Figure 1, which receives a service request via signaling, including
signaling, including over a NNI or UNI reference point, or receives a over a NNI or UNI reference point, or receives a configuration
configuration request over a management interface to establish a request over a management interface to establish a service. In either
service. In either case the path(s) needed to support the service are case the path(s) needed to support the service are not explicitly
not explicitly specified in the message/request, and hence path specified in the message/request, and hence path computation is
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, optimizations and relaxations should
be applied in order for the service LSP(s) to have a likelihood to be be applied in order for the service LSP(s) to have a likelihood to be
successfully established and provide necessary QoS and resilience successfully established and provide necessary QoS and resilience
against network failures. When deciding on the set of constraints the against network failures. When deciding on the set of constraints the
PCC uses as an input all information it knows about the user and PCC uses as an input all information it knows about the user and
service, such as the contents of the received message, port ID over service, such as the contents of the received message, port ID over
which message was received, associated VPN ID, signaling/reference which message was received, associated VPN ID, signaling/reference
point type, request time, etc. Once the constraints and other point type, request time, etc. Once the constraints and other
parameters of the required path computation are determined, the PCC parameters of the required path computation are determined, the PCC
generates a path computation request which includes the request- generates a path computation request which includes the request-
specific policies that describe the determined set of constraints, specific policies that describe the determined set of constraints,
optimizations, and other parameters that indicate how the request is optimizations, and other parameters that indicate how the request is
to be considered in the path computation process. to be considered in the path computation process.
The PCC may also apply server specific policies for each of the known The PCC may also apply server-specific policies in order to select
(i.e., discovered or configured) PCEs in order to select which PCE to which PCE to use from the set of known (i.e., discovered or
use. The PCC may also use server specific policies to form the configured) PCEs. The PCC may also use server-specific policies to
request to match the PCE's capabilities so that the request will not form the request to match the PCE's capabilities so that the request
be rejected and has a higher likelihood of being satisfied in an will not be rejected and has a higher likelihood of being satisfied
efficient way. An example of a request modification as the result of in an efficient way. An example of a request modification as the
a server specific policy is removing a constraint not supported by result of a server-specific policy is removing a constraint not
the PCE. Once the policy processing is completed at the PCC, and the supported by the PCE. Once the policy processing is completed at the
path computation request resulting from the original service request PCC, and the path computation request resulting from the original
is updated by the policy processing, the request is sent to the PCE. service request is updated by the policy processing, the request is
sent to the PCE.
The PCE that receives the request validates and otherwise processes The 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. It also may decide to respond with one
or several pre-computed paths if user or client specific polices 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 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 by performing a path computation, it determines if it needs the
cooperation of other PCEs and defines parameters for path cooperation of other PCEs and defines parameters for path
computations to be performed locally and remotely. After that, the computations to be performed locally and remotely. After that, the
PCE instructs a co-located path computation engine to perform the PCE instructs a co-located path computation engine to perform the
local path computation(s) and, if necessary, sends path computation local path computation(s) and, if necessary, sends path computation
requests to one or more other PCEs. It then waits for the responses requests to one or more other PCEs. It then waits for the responses
from the local path computation engine and, when used, the remote from the local path computation engine and, when used, the remote
PCE. It then combines the resulting paths and sends the result back PCE. It then combines the resulting paths and sends the result back
to the requesting PCC. The response may indicate policies describing to the requesting PCC. The response may indicate policies describing
the resulting paths, their characteristics (summary cost, expected the resulting paths, their characteristics (summary cost, expected
end-to-end delay, etc.) as well as additional information related to end-to-end delay, etc.). as well as additional information related to
the request, e.g., which of constraints were honored, which were the request, e.g., which constraints were honored, which were
dismissed and which were relaxed and in what way. dismissed, and which were relaxed and in what way.
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).
3.2.4. Scenario: Advanced Load Balancing (ALB) Example 2.2.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 13, line 8 skipping to change at page 14, line 26
ingress router to each egress link could be split 50-50. ingress router to each egress link could be split 50-50.
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 dryout, and VPN gateway DDoS blackholing, planned maintenance, and VPN gateway selection.
selection.
4. 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.
- Support for non (G)MPLS PCCs - Support for non-(G)MPLS PCCs
The mechanisms must be sufficiently generic to support The mechanisms must be sufficiently generic to support
non-(G)MPLS (LSR) clients such as an NMS, or network planner, non-(G)MPLS (LSR) clients such as an NMS, or network planner,
etc. etc.
- Support for many policies - Support for many policies
The mechanisms must include support for many policies and policy The mechanisms must include support for many policies and policy
configurations. In general, the determination and configuration configurations. In general, the determination and configuration
of viable policies are the responsibility of the service of viable policies are the responsibility of the service
provider. provider.
skipping to change at page 14, line 38 skipping to change at page 16, line 6
o First, the mechanisms proposed must minimize theft and denial o First, the mechanisms proposed must minimize theft and denial
of service threats. of service threats.
o Second, it must be ensured that the entities (such as PEPs o Second, it must be ensured that the entities (such as PEPs
and PDPs) involved in policy control can verify each other's and PDPs) involved in policy control can verify each other's
identity and establish necessary trust before communicating. identity and establish necessary trust before communicating.
- Inter-AS and inter-area requirements - Inter-AS and inter-area requirements
There are several inter-AS policy related requirements discussed There are several inter-AS policy related requirements discussed
in [RFC4216] and [INTERAS-PCEP], and inter-area policy related in [RFC4216] and [INTERAS-PCEP], and inter-area policy related
requirements discussed in [PCECP-IA-REQ]. These requirements requirements discussed in [RFC4927]. These requirements
must be addressed by policy-enabled PCE mechanisms and protocols. must be addressed by policy-enabled PCE mechanisms and protocols.
It should be noted that this document only outlines the communication It should be noted that this document only outlines the communication
elements and mechanisms needed to allow a wide variety of possible elements and mechanisms needed to allow a wide variety of possible
policies to be applied for path computation control. It does not policies to be applied for path computation control. It does not
include any discussion of any specific policy behavior. Nor does it include any discussion of any specific policy behavior. Nor does it
define or require use of specific policies. define or require use of specific policies.
5. Path Computation Policy Information Model (PCPIM) 4. Path Computation Policy Information Model (PCPIM)
The Policy Core Information Model (PCIM) introduced in [RFC3060] and The Policy Core Information Model (PCIM) introduced in [RFC3060] and
expanded in [RFC3460] presents the object-oriented information model expanded in [RFC3460] presents the object-oriented information model
for representing general policy information. for representing general policy information.
This model defines two hierarchies of object classes: This model defines two hierarchies of object classes:
- structural classes representing policy information and control of - Structural classes representing policy information and control of
policies policies.
- association classes that indicate how instances of the structural - Association classes that indicate how instances of the structural
classes are related to each other. classes are related to each other.
These classes can be mapped to various concrete implementations, for These classes can be mapped to various concrete implementations, for
example, to a directory that uses LDAPv3 as its access protocol. example, to a directory that uses LDAPv3 as its access protocol.
Figure 6 shows an abstract from the class inheritance hierarchy for Figure 6 shows an abstract from the class inheritance hierarchy for
PCIM. PCIM.
ManagedElement (abstract) ManagedElement (abstract)
| |
skipping to change at page 16, line 17 skipping to change at page 17, line 29
| | | | | |
| | +---PolicyExplicitVariable | | +---PolicyExplicitVariable
| | | | | |
| | +---PolicyImplicitVariable | | +---PolicyImplicitVariable
| | | | | |
| | +---(subtree of more specific classes) | | +---(subtree of more specific classes)
| | | |
| +---PolicyValue (abstract) | +---PolicyValue (abstract)
| | | |
| +---(subtree of more specific classes) | +---(subtree of more specific classes)
|
Figure 6: PCIM Class Inheritance Figure 6: PCIM Class Inheritance
The policy classes and associations defined in PCIM are sufficiently The policy classes and associations defined in PCIM are sufficiently
generic to allow them to represent policies related to anything. generic to allow them to represent policies related to anything.
Policy models for application-specific areas such as the Path Policy models for application-specific areas such as the Path
Computation Service may extend the PCIM in several ways. The Computation Service may extend the PCIM in several ways. The
preferred way is to use the PolicyGroup, PolicyRule, and preferred way is to use the PolicyGroup, PolicyRule, and
PolicyTimePeriodCondition classes directly as a foundation for PolicyTimePeriodCondition classes directly as a foundation for
skipping to change at page 16, line 42 skipping to change at page 18, line 5
Policy Quality of Service Information Model [RFC3644] further extends Policy Quality of Service Information Model [RFC3644] further extends
the PCIM to represent QoS policy information for large-scale policy the PCIM to represent QoS policy information for large-scale policy
domains. New classes introduced in this document describing QoS and domains. New classes introduced in this document describing QoS and
RSVP related variables, conditions and actions can be used as a RSVP related variables, conditions and actions can be used as a
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.
6. 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 - PC Policy Repository
A database from which PC policies are available in the form of A database from which PC policies are available in the form of
instances of PCPIM classes. PC Policies are configured and instances of PCPIM classes. PC Policies are configured and
managed by PC Policy Management Tools. managed by PC 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;
- PCC Policy Decision Point (PCC-PDP) - PCC Policy Decision Point (PCC-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 PCC-PEP(s; information to associated PCC-PEP(s);
- PCC Policy Enforcement Point (PCC-PEP) - PCC Policy Enforcement Point (PCC-PEP)
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
skipping to change at page 17, line 49 skipping to change at page 19, line 10
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 PC 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. PCC-PCE communication protocol.
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
requests as well as client-specific and domain-specific policies requests as well as client-specific and domain-specific policies
supplied by the PCE-PDP. supplied by the PCE-PDP.
7. Policy Component Configurations 6. Policy Component Configurations
7.1. PCC-PCE Configurations 6.1. PCC-PCE Configurations
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.
skipping to change at page 18, line 46 skipping to change at page 20, line 22
--------- Policy ---------------------- --------- Policy ----------------------
| PCC-PDP |<--------- | PC Policy Repository | | PCC-PDP |<--------- | PC Policy Repository |
--------- ---------------------- --------- ----------------------
^ ^
| e.g., COPS | e.g., COPS
v v
--------- --------- --------- ---------
| PCC-PEP |<------------------------------------------->| PCE | | PCC-PEP |<------------------------------------------->| PCE |
--------- PCC-PCE Communication Protocol --------- --------- PCC-PCE Communication Protocol ---------
Figure 7: Policies are 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 PC policy types used in the network must be applied at
those locations. those locations.
skipping to change at page 19, line 27 skipping to change at page 20, line 50
---------------------- Policy --------- ---------------------- Policy ---------
| PC Policy Repository | -------->| PCE-PDP | | PC Policy Repository | -------->| PCE-PDP |
---------------------- --------- ---------------------- ---------
^ ^
e.g., COPS | e.g., COPS |
v v
--------- --------- --------- ---------
| PCC |<------------------------------------------->| PCE-PEP | | PCC |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol --------- --------- PCC-PCE Communication Protocol ---------
Figure 8: Policies are applied on PCE 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
defining the actual parameters of the path computation to be defining the actual parameters of the path computation to be
performed. Note that in this scenario the PCC cannot apply server- performed. Note that in this scenario the PCC cannot apply server-
specific or any other policies, and PCE selection is static. specific or any other policies, and PCE selection is static.
When applying policy at both PCC and PCE, it is necessary to select When applying policy at both PCC and PCE, it is necessary to select
which types of policies are applied at each. In such configurations, which types of policies are applied at each. In such configurations,
it is likely that the application of policy types will be distributed it is likely that the application of policy types will be distributed
across PCC and PCE rather than applying all of them at both. For across PCC and PCE rather than applying all of them at both. For
example, user specific and server specific policies may be applied at example, user-specific and server-specific policies may be applied at
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 in use.
7.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 PC policy repository
configuration: configuration:
o) Single PC Policy Repository o) Single PC Policy Repository
In this configuration there is a single PC Policy Repository shared In this configuration there is a single PC Policy Repository shared
between PCCs and PCEs. between PCCs and PCEs.
skipping to change at page 21, line 25 skipping to change at page 23, line 5
--------- --------- --------- ---------
^ ^ ^ ^
| e.g., COPS e.g., COPS | | e.g., COPS e.g., COPS |
v v v v
--------- --------- --------- ---------
| 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
7.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 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
skipping to change at page 23, line 5 skipping to change at page 24, line 30
--------- --------- --------- ---------
^ ^ ^ ^
| e.g., COPS e.g., COPS | | e.g., COPS e.g., COPS |
v v v v
--------- --------- --------- ---------
| 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
7.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
otherwise managed using typical policy management techniques. Policy otherwise managed using typical policy management techniques. Policy
Repositories may be populated and managed via static configuration, Repositories may be populated and managed via static configuration,
standard and proprietary policy management tools, or even dynamically standard and proprietary policy management tools, or even dynamically
via policy management/discovery protocols and applications. via policy management/discovery protocols and applications.
8. Inter-Component Communication 7. Inter-Component Communication
8.1. Policy Communication 7.1. Policy Communication
Flexibility in the application of policy types is imperative from the Flexibility in the application of policy types is imperative from the
architecture perspective. However, this commodity implies added architecture perspective. However, this commodity implies added
complexity on the part of the PCE related communication protocols. complexity on the part of the PCE related communication protocols.
One added complexity is that PCE communication protocols must carry One added complexity is that PCE communication protocols must carry
certain information to support various policy types that may be certain information to support various policy types that may be
applied. For example, in the case where policy is only applied at a applied. For example, in the case where policy is only applied at a
PCE, a PCC-PCE request must carry sufficient information for the PCE PCE, a PCC-PCE request must carry sufficient information for the PCE
to apply service or user specific policies. This does imply that a to apply service or user-specific policies. This does imply that a
PCC must have sufficient understanding of what policies can be PCC must have sufficient understanding of what policies can be
applied at the PCE. Such information may be obtained via local applied at the PCE. Such information may be obtained via local
configuration, static coding or even via a PCE discovery mechanism. configuration, static coding or even via a PCE discovery mechanism.
The PCC must also have sufficient understanding to properly encode The PCC must also have sufficient understanding to properly encode
the required information for each policy type. the required information for each policy type.
Another added complexity is that PCE communication protocols must Another added complexity is that PCE communication protocols must
also be able to carry information that may result from a policy also be able to carry information that may result from a policy
decision. For example, user or service specific policy applied at a decision. For example, user or service-specific policy applied at a
PCC may result in policy related information that must be carried PCC may result in policy related information that must be carried
along with the request for use by a PCE. This complexity is along with the request for use by a PCE. This complexity is
particularly important as it may be used to introduce new path particularly important as it may be used to introduce new path
computation parameters (e.g. constraints, objection functions, etc.) computation parameters (e.g., constraints, objection functions, etc.)
without modification of the core PCC and PCE. This communication will without modification of the core PCC and PCE. This communication will
likely simply require the PCE communication protocols to support likely simply require the PCE communication protocols to support
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. This document makes no
assumptions as to what exact protocol is used to support this assumptions as to what exact protocol is used to support this
communication. This document does assume that the semantics of a communication. This document does assume that the semantics of a
path computation request are sufficiently abstract and general, and path computation request are sufficiently abstract and general, and
support both PCE-PCC and PCE-PCE communication. support both PCE-PCC and PCE-PCE communication.
A path computation request at minimum should include: From a policy perspective, a path computation request should include
o One or several source addresses; at a minimum:
o One or several destination addresses; o One or more source 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>
<policy variable2 name>, <param21>, <param12>,...,<param2N> <policy variable2 name>, <param21>, <param12>,...,<param2N>
... ...
<policy variableM name>, <paramM1>, <paramM2>,...,<paramMN> <policy variableM name>, <paramM1>, <paramM2>,...,<paramMN>
A successful path computation response, at minimum, should include A successful path computation response, at minimum, should include
skipping to change at page 24, line 39 skipping to change at page 26, line 18
PCC-PCE Communication Protocol provides transport for policy PCC-PCE Communication Protocol provides transport for policy
information and should not understand nor make any assumptions about information and should not understand nor make any assumptions about
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. The PCE
(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)).
8.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 information. Policy can be
applied in two ways in this context: applied in 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).
skipping to change at page 25, line 29 skipping to change at page 27, line 4
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
policy decision in this context is the nature of the information policy decision in this context is the nature of the information
to be distributed, especially, when this information is not to be distributed, especially, when this information is not
strictly speaking a "discovery" information, rather, the PCE strictly speaking a "discovery" information, rather, the PCE
state changes. Client-specific and domain-specific policies may state changes. Client-specific and domain-specific policies may
be applied when deciding whether this information should be be applied when deciding whether this information should be
distributed and to which clients of the path computation service distributed and to which clients of the path computation service
(that is, which PCCs and/or PCEs) (that is, which PCCs and/or PCEs)
Another place where policy applies is at the administrative Another place where policy applies is at the administrative
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.
9. Path Computation Sequence of Events 8. Path Computation Sequence of Events
This section presents representative scenarios; other scenarios are This section presents representative scenarios; other scenarios are
also possible. also possible.
9.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
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 COPS 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.
- 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 COPS. The outcome of the
skipping to change at page 27, line 22 skipping to change at page 28, line 38
local path computation engine and the remote PCE, combines the local path computation engine and the remote PCE, combines the
resulting paths and sends them back to the PCC-PEP using the PCC- resulting paths and sends them back to the PCC-PEP using the PCC-
PCE Communication Protocol. The response contains the resulting PCE Communication Protocol. The response contains the resulting
paths as well as policies describing some additional information paths as well as policies describing some additional information
(for example, which of constraints were honored, which were (for example, which of constraints were honored, which were
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.2. Policy-ignorant PCC, Policy-enabled PCE 8.2. Policy-ignorant PCC, Policy-enabled PCE
This case parallels the previous example, but the user and service This case parallels the previous example, but the user and service-
specific policies should be applied at the PCE as the PCC is policy specific policies should be applied at the PCE as the PCC is policy
ignorant. Again, when a GMPLS LSR has received a Setup (RSVP Path) ignorant. Again, when a GMPLS LSR has received a Setup (RSVP Path)
message from an upstream LSR, the LSR may decide to use a non co- message from an upstream LSR, the LSR may decide to use a non co-
located Path Computation Entity. The following sequence of events located Path Computation Entity. The following sequence of events
occurs in this case: occurs in this case:
- The PCC constructs a PCE request using information found in the - The PCC constructs a PCE request using information found in the
signaling/provisioning message as well as any other service signaling/provisioning message as well as any other service
specific information such as port ID over which the message was specific information such as port ID over which the message was
received, associated VPN ID, the reference point type (UNI, E- received, associated VPN ID, the reference point type (UNI, E-
skipping to change at page 28, line 31 skipping to change at page 30, line 5
local path computation engine and the remote PCE, combines the local path computation engine and the remote PCE, combines the
resulting paths and sends them back to the PCC-PEP using the PCC- resulting paths and sends them back to the PCC-PEP using the PCC-
PCE Communication Protocol. The response contains the resulting PCE Communication Protocol. The response contains the resulting
paths as well as policies describing some additional information paths as well as policies describing some additional information
(for example, which of constraints were honored, which were (for example, which of constraints were honored, which were
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).
10. 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 change in order to support the
new constraint. Importantly, those components and mechanisms that 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
skipping to change at page 29, line 21 skipping to change at page 30, line 43
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 PC 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.
11. 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 of policy information maintained in PC Policy Repositories and policy
related transactions. The most notable issues, some of which are also related transactions. The most notable issues, some of which are also
listed in [RFC4655], are: 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;
o Falsification of policy information and/or PCE capabilities; o Falsification of policy information and/or PCE capabilities;
skipping to change at page 29, line 44 skipping to change at page 31, line 17
- 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 As with [RFC4655], it is expected that PCE solutions will address the
these issues in detail. PCE aspects of these issues in detail.
12. Acknowledgements 11. Acknowledgments
We would like to thank Bela Berde for fruitful discussions on PBM and We would like to thank Bela Berde for fruitful discussions on PBM and
Policy-driven path computation. We would also like to thank Kobus Van Policy-driven path computation, Adrian Farrel for his detailed input.
der Merwe for providing insights and examples regarding PCE policy We would also like to thank Kobus Van der Merwe for providing
applications. insights and examples regarding PCE policy applications.
13. IANA Considerations 12. IANA Considerations
None. None.
14. References 13. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 13.1. Normative References
Requirement Levels," BCP 14, RFC 2119, March 1997.
[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) [RFC2748] D. Durham, et al., The COPS (Common Open Policy Service)
protocol, RFC 2748, IETF, January 2000. 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.
skipping to change at page 31, line 8 skipping to change at page 32, line 23
[RFC3644] Y. Snir, et al., Policy Quality of Service (QoS) [RFC3644] Y. Snir, et al., Policy Quality of Service (QoS)
Information Model, RFC 3644, November 2003. Information Model, RFC 3644, November 2003.
[RFC4216] Zhang, R., Vasseur, J-P., Eds., "MPLS Inter-Autonomous [RFC4216] Zhang, R., Vasseur, J-P., Eds., "MPLS Inter-Autonomous
System (AS) Traffic Engineering (TE) Requirements", System (AS) Traffic Engineering (TE) Requirements",
RFC4216, November 2005. RFC4216, November 2005.
[RFC4655] Farrel, A., Vasseur, JP., Ash, J., "Path Computation [RFC4655] Farrel, A., Vasseur, JP., Ash, J., "Path Computation
Element (PCE) Architecture", RFC 4655, August 2006. Element (PCE) Architecture", RFC 4655, August 2006.
[INTERAS-PCEP] Bitar, N., Zhang, R., Kumaki, K., Eds., "Inter-AS [RFC4927] Le Roux, J-L., Ed., "PCE Communication Protocol
Requirements for the Path Computation Element
Communication Protocol (PCECP)", February 2006.
[PCECP-IA-REQ] Le Roux, J-L., Ed., "PCE Communication Protocol
(PCECP) Specific Requirements for Inter-Area (PCECP) Specific Requirements for Inter-Area
(G)MPLS Traffic Engineering", February 2006. MPLS and GMPLS Traffic Engineering", June 2007.
14.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
skipping to change at page 32, line 5 skipping to change at page 33, line 9
Smith, "COPS Usage for Policy Provisioning (COPS-PR)", Smith, "COPS Usage for Policy Provisioning (COPS-PR)",
RFC 3084, February 2001. 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.
15. Authors' Addresses [INTERAS-PCEP] Bitar, N., Zhang, R., Kumaki, K., Eds., "Inter-AS
Requirements for the Path Computation Element
Communication Protocol (PCECP)", February 2006.
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)
Fr. Wellesplein 1, Fr. Wellesplein 1,
skipping to change at page 32, line 27 skipping to change at page 33, line 35
Phone: +32 3 240-8491 Phone: +32 3 240-8491
Email: dimitri.papadimitriou@alcatel.be Email: dimitri.papadimitriou@alcatel.be
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
Room MT D5-2A01 Email: gash5107@yahoo.com
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: (732)-420-4578
Fax: (732)-368-8659
Email: gash@att.com
16. Full Copyright Statement 15. 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.
17. 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 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 1473 skipping to change at line 1479
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: Fri Mar 2 08:55:00 EST 2007 Generated on: Thu Jul 5 19:48:55 EDT 2007
 End of changes. 108 change blocks. 
273 lines changed or deleted 280 lines changed or added

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