draft-ietf-pce-policy-enabled-path-comp-00.txt   draft-ietf-pce-policy-enabled-path-comp-01.txt 
Internet Draft Igor Bryskin (Movaz Networks) Internet Draft Igor Bryskin (Adva Optical)
Category: Informational Dimitri Papadimitriou (Alcatel) Category: Informational Dimitri Papadimitriou (Alcatel)
Expiration Date: January 2007 Lou Berger (LabN Consulting, LLC) Expiration Date: September 2, 2007 Lou Berger (LabN Consulting)
Jerry Ash (AT&T)
March 2, 2007
Policy-Enabled Path Computation Framework Policy-Enabled Path Computation Framework
draft-ietf-pce-policy-enabled-path-comp-00.txt draft-ietf-pce-policy-enabled-path-comp-01.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 32 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.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract Abstract
The PCE architecture [PCE-ARCH] introduces the concept of policy in The PCE architecture [RFC4655] introduces the concept of policy in
the context of path computation. This document provides additional the context of path computation. This document provides additional
details on policy within the PCE Architecture and also provides details on policy within the PCE Architecture and also provides
context for the support of PCE Policy. This document introduces the context for the support of PCE Policy. This document introduces the
use of the Policy Core Information Model (PCIM) as a framework for use of the Policy Core Information Model (PCIM) as a framework for
supporting path computation policy. This document also provides supporting path computation policy. This document also provides
representative scenarios for the support of PCE Policy. representative scenarios for the support of PCE Policy.
Contents Contents
1 Terminology ............................................... 3 1 Terminology ............................................... 3
2 Introduction .............................................. 3 2 Introduction .............................................. 3
3 Background ................................................ 4 3 Background ................................................ 4
3.1 Motivations ............................................... 4 3.1 Motivations ............................................... 4
3.2 Representative Policy Scenarios ........................... 6 3.2 Representative Policy Scenarios ........................... 6
3.2.1 Scenario: Policy Configured Paths ......................... 6 3.2.1 Scenario: Policy Configured Paths ......................... 6
3.2.2 Scenario: Provider Selection Policy ....................... 7 3.2.2 Scenario: Provider Selection Policy ....................... 9
3.2.3 Scenario: Policy Based Constraints ........................ 8 3.2.3 Scenario: Policy Based Constraints ........................ 10
4 Requirements .............................................. 10 3.2.4 Scenario: Advanced Load Balancing (ALB) Example .......... 11
5 Path Computation Policy Information Model (PCPIM) ......... 11 4 Requirements .............................................. 13
6 Policy-Enabled Path Computation Framework Components ...... 13 5 Path Computation Policy Information Model (PCPIM) ......... 15
7 Policy Component Configurations ........................... 15 6 Policy-Enabled Path Computation Framework Components ...... 16
7.1 PCC-PCE Configurations .................................... 15 7 Policy Component Configurations ........................... 18
7.2 Policy Repositories ....................................... 17 7.1 PCC-PCE Configurations .................................... 18
7.3 Cooperating PCE Configurations ............................ 18 7.2 Policy Repositories ....................................... 20
7.4 Policy Configuration Management ........................... 20 7.3 Cooperating PCE Configurations ............................ 21
8 Inter-Component Communication ............................. 20 7.4 Policy Configuration Management ........................... 23
8.1 Policy Communication ..................................... 20 8 Inter-Component Communication ............................. 23
8.2 PCE Discovery Policy Considerations ....................... 22 8.1 Policy Communication ..................................... 23
9 Path Computation Sequence of Events ....................... 22 8.2 PCE Discovery Policy Considerations ....................... 25
9.1 Policy-enabled PCC, Policy-enabled PCE .................... 23 9 Path Computation Sequence of Events ....................... 25
9.2 Policy-ignorant PCC, Policy-enabled PCE ................... 24 9.1 Policy-enabled PCC, Policy-enabled PCE .................... 26
10 Introduction of New Constraints ........................... 25 9.2 Policy-ignorant PCC, Policy-enabled PCE ................... 27
11 Security Considerations ................................... 26 10 Introduction of New Constraints ........................... 28
12 Acknowledgements .......................................... 27 11 Security Considerations ................................... 29
13 IANA Considerations ....................................... 27 12 Acknowledgements .......................................... 30
14 References ................................................ 27 13 IANA Considerations ....................................... 30
14.1 Normative References ...................................... 27 14 References ................................................ 30
14.2 Informative References .................................... 28 14.1 Normative References ...................................... 30
15 Authors' Addresses ........................................ 28 14.2 Informative References .................................... 31
16 Full Copyright Statement .................................. 29 15 Authors' Addresses ........................................ 32
17 Intellectual Property ..................................... 29 16 Full Copyright Statement .................................. 32
17 Intellectual Property ..................................... 33
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1. Terminology 1. Terminology
The reader is assumed to be familiar with the following terms: The reader is assumed to be familiar with the following terms:
CSPF: Constraint-based Shortest Path First, see [RFC3630]. CSPF: Constraint-based Shortest Path First, see [RFC3630].
LSP: Label Switched Path, see [RFC3031]. LSP: Label Switched Path, see [RFC3031].
LSR: Label Switching Router, see [RFC3031]. LSR: Label Switching Router, see [RFC3031].
PCC: Path Computation Client, see [PCE-ARCH]. PCC: Path Computation Client, see [RFC4655].
PCE: Path Computation Element, see [PCE-ARCH]. PCE: Path Computation Element, see [RFC4655].
TE LSP: Traffic Engineering MPLS Label Switched Path, see TE LSP: Traffic Engineering MPLS Label Switched Path, see
[RFC3209] and [RFC3473]. [RFC3209] and [RFC3473].
CIM: Common Information Model, see [DMTF]. CIM: Common Information Model, see [DMTF].
PCIM: Policy Core Information Model, see [RFC3060]. PCIM: Policy Core Information Model, see [RFC3060].
PC: Path Computation. PC: Path Computation.
PCCIM: Path Computation Core Information Model. PCCIM: Path Computation Core Information Model.
QPIM: QoS Policy Information Model, see [RFC3644]. QPIM: QoS Policy Information Model, see [RFC3644].
PBM: Policy-based Management, see [RFC3198]. PBM: Policy-based Management, see [RFC3198].
PEP: Policy Enforcement Points, see [RFC2753]. PEP: Policy Enforcement Points, see [RFC2753].
PDP: Policy Decision Points, see [RFC2753]. PDP: Policy Decision Points, see [RFC2753].
COPS: Common Open Policy Service, see [RFC2748]. COPS: Common Open Policy Service, see [RFC2748].
COPS-PR: COPS Usage for Policy Provisioning, see [RFC3084]. COPS-PR: COPS Usage for Policy Provisioning, see [RFC3084].
2. Introduction 2. Introduction
The PCE architecture is introduced in [PCE-ARCH]. This document The PCE architecture is introduced in [RFC4655]. This document
describes the impact of policy on the PCE architecture and provides describes the impact of policy on the PCE architecture and provides
additional details on, and context for, policy within the PCE additional details on, and context for, policy within the PCE
Architecture. Architecture.
Policy-based Management (PBM) enables network administrators to Policy-based Management (PBM) enables network administrators to
operate in a high-level manner through rule-based policies; the operate in a high-level manner through rule-based policies; the
latter are translated automatically into individual device latter are translated automatically into individual device
configuration directives, aimed at controlling a network as a whole. configuration directives, aimed at controlling a network as a whole.
Two IETF Working Groups have considered policy networking in the Two IETF Working Groups have considered policy networking in the
past: The Resource Allocation Protocol working group and the Policy past: The Resource Allocation Protocol working group and the Policy
skipping to change at page 4, line 36 skipping to change at page 4, line 36
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 some rational behind the use
of policy, as well as representative policy usage scenarios. This of policy, as well as representative policy usage scenarios. This
information is intended to provide context for the presented policy information is intended to provide context for the presented policy
framework. This section does not attempt to present an exhaustive framework. This section does not attempt to present an exhaustive
list of rational or scenarios. list of rational or scenarios.
3.1. Motivations 3.1. Motivations
The PCE architecture is introduced in [PCE-ARCH]. 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 rational 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,
skipping to change at page 5, line 44 skipping to change at page 5, line 44
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 PCC software. One way to achieve
this objective is to consider path selection constraints, their this objective is to consider path selection constraints, their
relaxations and objective functions, as path computation request relaxations and objective functions, as path computation request
specific policies. Furthermore that such policies may, on one hand, specific policies. Furthermore such policies may, on one hand, be
be configured and managed by an operator as any other policies or, on configured and managed by an operator as any other policies or, on
the other hand, may be interpreted in real time by PCCs and PCEs. 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 in this document as path computation
engine) needs to be updated. engine) needs to be updated.
skipping to change at page 7, line 10 skipping to change at page 7, line 10
alternate approach is possible. 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 end-user.
The configured path(s) would then be used as input to PCE computation The configured path(s) would then be used as input to PCE computation
process, which would return explicit routes by expanding of all process, which would return explicit routes by expanding of all
specified loose hops. specified loose hops.
----------------------
| ----- |
| | TED |<-+------------>
| ----- | TED synchronization
| | | mechanism (e.g., routing protocol)
| | |
| v |
| ------ ----- | Inter-PCE Request/Response
| |Policy|<-->| PCE |<.+...........> (when present)
| ------ ----- |
----------------------
^
| Request/
| Response
v
Service ------------- Signaling
Request|[PCC][Policy]| Protocol
...--->| Node |<----....
or Signaling -------------
Protocol
Figure 1: Policy Enabled PCC and PCE
The described policies may be applied at either PCC or PCE, see The described policies may be applied at either PCC or PCE, see
Figure 5. In the PCC case, the configured path would be processed at Figure 1. In the PCC case, the configured path would be processed at
the PCC and then passed to the PCE along with the PCE request, 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 |
| | | |
| ------ ----- | | ----- ------ |
| |Policy| | TED | | | | TED | |Policy| |
| ------ ----- | | ----- ------ |
------------------ -------------------
^ ^
| Request/ | Request/
| Response | Response
v v
Service -------- Signaling ------------ Signaling ------------
Request|Head-End| Protocol |Intermediate| Protocol |Intermediate|
---->| Node |<--------->| Node |<--------->| Node |
-------- ------------ ------------
Figure 2. Multiple PCE Path Computation
------------------ ------------------
| | Inter-PCE Request/Response | |
| PCE |<-------------------------->| PCE |
| | | |
| ------ ----- | | ------ ----- |
| |Policy| | TED | | | |Policy| | TED | |
| ------ ----- | | ------ ----- |
------------------ ------------------
^
| Request/
| Response
v
Service ---------- Signaling ---------- Signaling ----------
Request| Head-End | Protocol | Adjacent | Protocol | Adjacent |
---->| Node |<---------->| Node |<---------->| Node |
---------- ---------- ----------
Figure 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 7 and 8). 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 scenario work
it would likely be necessary to start and finish the configured paths it would likely be necessary to start and finish the configured paths
on TE domain boundary nodes. Clearly, consistent PC Policy on TE domain boundary nodes. Clearly, consistent PC Policy
Repositories are also critical in this example. Repositories are also critical in this example.
skipping to change at page 7, line 42 skipping to change at page 9, line 17
3.2.2. Scenario: Provider Selection Policy 3.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 networks. There are numerous
interesting policy applications in such networks. A rudimentary interesting policy applications in such networks. 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 provider network will be used to support a particular PCE
request. Consider the topology presented in Figure 1. 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 networks available to provide a path from
a source domain to a destination domain. Furthermore, each transit a source domain to a destination domain. Furthermore, each transit
network may have one or more options for reaching a particular network may have one or more options for reaching a particular
domain. Each domain will need to select which of the multiple domain. Each domain will need to select which of the multiple
available paths will be used to satisfy a particular PCE request. available paths will be used to satisfy a particular PCE request.
Clearly, TE reachability, availability and optimality are the basic Clearly, TE reachability, availability and length are the basic
criterions for path selection, however, policies can provide an criterions for path selection, however, policies can provide an
important added consideration in the decision process. For example, important added consideration in the decision process. For example,
transit network A may be more expensive and provide lower delay or transit network A may be more expensive and provide lower delay or
loss than transit network C. Likewise, a transit network may wish to loss than transit network C. Likewise, a transit network may wish to
treat PCE requests from its own customers differently than requests treat PCE requests from its own customers differently than requests
from other providers. In both cases, computation based on traffic from other providers. In both cases, computation based on traffic
engineering databases will result in multiple transit networks that engineering databases will result in multiple transit networks that
provide reachability, and policies can be used to govern which PCE provide reachability, and policies can be used to govern which PCE
requests get better service. requests get better service.
skipping to change at page 8, line 24 skipping to change at page 9, line 46
|Transit Domain A| +----------------+ |Transit Domain A| +----------------+
+----------------+ |Transit Domain D| +----------------+ |Transit Domain D|
+------+ +----------------+ +----------------+ +------+ +------+ +----------------+ +----------------+ +------+
|Source| |Transit Domain B| +----------------+ |Target| |Source| |Transit Domain B| +----------------+ |Target|
|Domain| +----------------+ |Transit Domain E| |Domain| |Domain| +----------------+ |Transit Domain E| |Domain|
+------+ +----------------+ +----------------+ +------+ +------+ +----------------+ +----------------+ +------+
|Transit Domain C| +----------------+ |Transit Domain C| +----------------+
+----------------+ |Transit Domain F| +----------------+ |Transit Domain F|
+----------------+ +----------------+
Figure 1: 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 3.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 new
constraints in a PCE request. Consider an LSR with a policy enabled constraints in a PCE request. Consider an LSR with a policy enabled
PCC, as shown in Figure 3, which receives a service request via PCC, as shown in Figure 1, which receives a service request via
signaling, including over a NNI or UNI reference point, or receives a signaling, including over a NNI or UNI reference point, or receives a
configuration request over a management interface to establish a configuration request over a management interface to establish a
service. In either case the path(s) needed to support the service are service. In either case the path(s) needed to support the service are
not explicitly specified in the message/request, and hence path not explicitly specified in the message/request, and hence path
computation is needed. computation is 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
skipping to change at page 10, line 5 skipping to change at page 11, line 27
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 of 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
Figure 5 illustrates a problem that stems from the coupling between
BGP and IGP in the BGP decision process. If a significant portion of
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
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
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
PE1). Either way the net result is that the link between PE2 and CE
will carry most of the traffic while the link between PE1 and CE will
be mostly idle.
..............................
. AS 1 .
. .
. +---+ +---+ +----+ .
....|PE8|...|PE9|...|PE10|....
+---+ +---+ +----+
| | |
+---+ +---+ +---+
......|PE3|...|PE4|...|PE5|......
. +---+ +---+ +---+ .
.............. +---+ \ / ___/ +---+
. . _|PE2|_____+--+__/ / _|PE6|
. +--+ / +---+ |P1|_____+--+_______/ +---+
. Customer |CE|= . +--+ |P2| .
. Network +--+ \_+---+ \ +--+ .
. . |PE1|________+--+___/| x===x . PCE used
.............. +---+ |P3| | |PCE| . by all
. +--+ | x===x . AS0 nodes
. AS 0 +---+ .
..................|PE7|..........
+---+
Figure 5: Advanced Load Balancing
This is a common problem for providers and customers alike. Analysis
of Netflow records, see [IRSCP], for a large ISP network on a typical
day has shown that for 71.8% of multi-homed customers there is a
complete imbalance, where the most loaded link carries all the
traffic and the least loaded link carries none.
PCE policies can address this problem by basing the routing decision
at the ingress routers on the offered load towards the multi-homed
customer. For example, in Figure 5 PCE policies could be configured
such that traffic load is monitored (e.g., based on Netflow data) at
ingress routers PE3 to PE7 towards the data center prefixes served by
egress routers PE1 and PE2. Using this offered load information, the
path computations returned by PCE, based on the enabled PCE policies,
can direct traffic to the appropriate egress router, on a per-ingress
router basis. For example, the PCE path computation might direct
traffic from both PE4 and PE5 to egress PE1, thus overriding the
default IGP based selection. Alternatively, traffic from each
ingress router to each egress link could be split 50-50.
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
TE link/node attributes, and, therefore, cannot be subject for
explicit path computation constraints. More generally, such
information can be pretty much anything. For example, traffic demand
forecasts, flow monitoring feedback, any administrative policies,
etc. Further examples are described in [IRSCP] of how PCE policies
might address certain network routing problems, such as selective
DDoS blackholing, planned maintenance dryout, and VPN gateway
selection.
4. Requirements 4. Requirements
The following requirements must be addressed by mechanisms and The following requirements must be addressed by mechanisms and
protocols that enable policy-based control over path computation protocols that enable policy-based control over path computation
requests and decisions: requests and decisions:
- (G)MPLS path computation-specific - (G)MPLS path computation-specific
The mechanisms must meet the policy-based control requirements The mechanisms must meet the policy-based control requirements
specific to the problem of path computation using RSVP-TE as the specific to the problem of path computation using RSVP-TE as the
signaling protocol on MPLS and GMPLS LSRs. signaling protocol on MPLS and GMPLS LSRs.
skipping to change at page 12, line 9 skipping to change at page 15, line 22
- 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 2 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)
| |
+--Policy (abstract) +--Policy (abstract)
| | | |
| +---PolicySet (abstract) | +---PolicySet (abstract)
| | | | | |
| | +---PolicyGroup | | +---PolicyGroup
| | | | | |
skipping to change at page 13, line 7 skipping to change at page 16, line 19
| | | | | |
| | +---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 2: 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
representing and communicating policy information. Then, specific representing and communicating policy information. Then, specific
subclasses derived from PolicyCondition and PolicyAction can capture subclasses derived from PolicyCondition and PolicyAction can capture
application-specific definitions of conditions and actions of application-specific definitions of conditions and actions of
policies. Two subclasses, VendorPolicyCondition and policies.
VendorPolicyAction, are also defined to provide a standard extension
mechanism for vendor-specific extensions to the Policy Core
Information Model.
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.
skipping to change at page 15, line 16 skipping to change at page 18, line 24
7. Policy Component Configurations 7. Policy Component Configurations
7.1. PCC-PCE Configurations 7.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 3), some at PCEs (Figure choose to apply policy only at PCCs (Figure 7), some at PCEs (Figure
4), and others at both PCCs and PCEs (Figure 5). Regardless of where 8), and others at both PCCs and PCEs (Figure 9). Regardless of where
policy is applied it must be applied in a consistent fashion in order policy is applied it must be applied in a consistent fashion in order
to achieve the intended results. to achieve the intended results.
........................ ........................
. . . .
. PC Policy Management . . PC Policy Management .
. . . .
........................ ........................
. .
. .
--------- 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 3: Policies are applied on PCC only Figure 7: Policies are 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. [PCE-ARCH] 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.
........................ ........................
. . . .
. PC Policy Management . . PC Policy Management .
. . . .
........................ ........................
skipping to change at page 16, line 22 skipping to change at page 19, line 27
---------------------- 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 4: Policies are applied on PCE only Figure 8: Policies are applied on PCE 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.
skipping to change at page 17, line 33 skipping to change at page 20, line 35
--------- Policy a ---------------------- Policy b --------- --------- Policy a ---------------------- Policy b ---------
| PCC-PDP |<--------- | PC Policy Repository | -------->| PCE-PDP | | PCC-PDP |<--------- | PC Policy Repository | -------->| PCE-PDP |
--------- ---------------------- --------- --------- ---------------------- ---------
^ ^ ^ ^
| 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 5: Single PCC/PCE Policy Repository Figure 9: Single PCC/PCE Policy Repository
o) Multiple PC Policy Repositories o) Multiple PC Policy Repositories
The repositories in this case may be fully or partially synchronized The repositories in this case may be fully or partially synchronized
by some discovery/ synchronization management protocol or may be by some discovery/ synchronization management protocol or may be
completely independent. Note that the situation when PC Policy completely independent. Note that the situation when PC Policy
Repository A exactly matches PC Policy Repository B, results in the Repository A exactly matches PC Policy Repository B, results in the
single PC Policy Repository configuration case. single PC Policy Repository configuration case.
-------------- -------------- -------------- --------------
skipping to change at page 18, line 23 skipping to change at page 21, line 23
--------- --------- --------- ---------
| PCC-PDP | | PCE-PDP | | PCC-PDP | | PCE-PDP |
--------- --------- --------- ---------
^ ^ ^ ^
| 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 6: Multiple PCE/PCC Policy Repositories Figure 10: Multiple PCE/PCC Policy Repositories
7.3. Cooperating PCE Configurations 7.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
skipping to change at page 19, line 22 skipping to change at page 22, line 22
--------- Policy a ---------------------- Policy b --------- --------- Policy a ---------------------- Policy b ---------
| PCE-PDP |<--------- | PC Policy Repository | -------->| PCE-PDP | | PCE-PDP |<--------- | PC Policy Repository | -------->| PCE-PDP |
--------- ---------------------- --------- --------- ---------------------- ---------
^ ^ ^ ^
| e.g., COPS e.g., COPS | | e.g., COPS e.g., COPS |
v v v v
--------- --------- --------- ---------
| PCE-PEP |<------------------------------------------->| PCE-PEP | | PCE-PEP |<------------------------------------------->| PCE-PEP |
--------- PCE-PCE Communication Protocol --------- --------- PCE-PCE Communication Protocol ---------
Figure 7: Single PCC Policy Repository Figure 11: Single PCC Policy Repository
o) Multiple Policy Repositories o) Multiple Policy Repositories
The repositories in this case may be fully or partially synchronized The repositories in this case may be fully or partially synchronized
by some discovery/synchronization management protocol(s) or may be by some discovery/synchronization management protocol(s) or may be
completely independent. In the multi-domain case it is expected that completely independent. In the multi-domain case it is expected that
the repositories will be distinct, providing, however. consistent the repositories will be distinct, providing, however. consistent
policies. policies.
-------------- -------------- -------------- --------------
skipping to change at page 19, line 50 skipping to change at page 22, line 50
--------- --------- --------- ---------
| PCE-PDP | | PCE-PDP | | PCE-PDP | | PCE-PDP |
--------- --------- --------- ---------
^ ^ ^ ^
| 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 8: Multiple PCC Policy Repositories Figure 12: Multiple PCC Policy Repositories
7.4. Policy Configuration Management 7.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.
skipping to change at page 25, line 36 skipping to change at page 28, line 36
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 10. 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 a that will use a new constraint need to change in order to support the
new constraints. Importantly, those components and mechanisms that new constraint. Importantly, those components and mechanisms that
will not use a new constraint must not require change for a new will not use the new constraint, must not require any change in order
constraint to be utilized. For example, the PCE communication for the new constraint to be utilized. For example, the PCE
protocols must not require any changes to support a new constraint. communication protocols must not require any changes to support new
Likewise, PCC and PCEs that will not process a new constraint must constraints. Likewise, PCC and PCEs that will not process new
not require any modification. constraints must not require any modification.
Consider the case where a PCE has been upgraded with software Consider the case where a PCE has been upgraded with software
supporting optical physical impairment constraint, such as supporting optical physical impairment constraint, such as
Polarization Mode Dispersion (PMD), that previously was not supported Polarization Mode Dispersion (PMD), that previously was not supported
in the domain. In this case, one or more new policies will be in the domain. In this case, one or more new policies will be
installed in the PC Policy Repository (associated with the PCE) installed in the PC Policy Repository (associated with the PCE)
defining the constraint (rules that determine application criteria, defining the constraint (rules that determine application criteria,
set of policy variables, conditions, actions, etc.) and its set of policy variables, conditions, actions, etc.) and its
relaxation strategy(ies). The new policies will be also propagated relaxation strategy(ies). The new policies will be also propagated
into other PC Policy Repositories within the domain via discovery and into other PC Policy Repositories within the domain via discovery and
skipping to change at page 26, line 24 skipping to change at page 29, line 24
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 11. Security Considerations
This document adds to the policy security considerations mentioned in This document adds to the policy security considerations mentioned in
[PCE-ARCH]. In particular it is now necessary to consider the [RFC4655]. In particular it is now necessary to consider the security
security of policy information maintained in PC Policy Repositories of policy information maintained in PC Policy Repositories and policy
and policy related transactions. The most notable issues, some of related transactions. The most notable issues, some of which are also
which are also listed in [PCE-ARCH], 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;
o Denial of service attacks on policy related communication o Denial of service attacks on policy related communication
mechanisms. mechanisms.
As with [PCE-ARCH], it is expected that PCE solutions will address As with [RFC4655], it is expected that PCE solutions will address
these issues in detail. these issues in detail.
12. Acknowledgements 12. Acknowledgements
We would like to thank Bela Berde for fruitful discussions on PBM We would like to thank Bela Berde for fruitful discussions on PBM and
and Policy-driven path computation. Policy-driven path computation. We would also like to thank Kobus Van
der Merwe for providing insights and examples regarding PCE policy
applications.
13. IANA Considerations 13. IANA Considerations
None. None.
14. References 14. References
14.1. Normative References 14.1. Normative References
[PCE-ARCH] Farrel, A., Vasseur, JP., Ash, J., "Path Computation
Element (PCE) Architecture", April 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997. 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 Information Model Version1 [RFC3060] B. Moore, et al., Policy Core Information Model --
Specification, RFC 3060, February 2001. Version 1 Specification, RFC 3060, February 2001.
[RFC3209] Awduche, D., et al., "Extensions to RSVP for LSP [RFC3209] Awduche, D., et al., "Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3460] Moore, B. Ed., "Policy Core Information Model (PCIM) [RFC3460] Moore, B. Ed., "Policy Core Information Model (PCIM)
Extensions", RFC 3460, January 2003. Extensions", RFC 3460, January 2003.
[RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label [RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003. 3473, January 2003.
[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
Element (PCE) Architecture", RFC 4655, August 2006.
[INTERAS-PCEP] Bitar, N., Zhang, R., Kumaki, K., Eds., "Inter-AS [INTERAS-PCEP] Bitar, N., Zhang, R., Kumaki, K., Eds., "Inter-AS
Requirements for the Path Computation Element Requirements for the Path Computation Element
Communication Protocol (PCECP)", February 2006. Communication Protocol (PCECP)", February 2006.
[PCECP-IA-REQ] Le Roux, J-L., Ed., "PCE Communication Protocol [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. (G)MPLS Traffic Engineering", February 2006.
14.2. Informative References 14.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
Management with an Intelligent Route Service Control
Point," ACM SIGCOMM Workshop on Internet Network
Management (INM), Pisa, Italy, September 11, 2006.
[RFC3031] Rosen, E,. Viswanathan, V. Callon, R., "Multiprotocol [RFC3031] Rosen, E,. Viswanathan, V. Callon, R., "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie,
K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A. K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A.
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 15. Authors' Addresses
Igor Bryskin Igor Bryskin
Movaz Networks, Inc. ADVA Optical
7926 Jones Branch Drive 7926 Jones Branch Drive
Suite 615 Suite 615
McLean, VA 22102 McLean, VA 22102
Email: ibryskin@movaz.com Email: ibryskin@advaoptical.com
Dimitri Papadimitriou (Alcatel) Dimitri Papadimitriou (Alcatel)
Fr. Wellesplein 1, Fr. Wellesplein 1,
B-2018 Antwerpen, Belgium B-2018 Antwerpen, Belgium
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
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: (732)-420-4578
Fax: (732)-368-8659
Email: gash@att.com
16. Full Copyright Statement 16. Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The IETF Trust (2007).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an 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 AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
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 17. 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
skipping to change at line 1312 skipping to change at page 33, line 29
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
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.
Generated on: Thu Jun 22 19:34:07 EDT 2006 Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Generated on: Fri Mar 2 08:55:00 EST 2007
 End of changes. 45 change blocks. 
85 lines changed or deleted 241 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/