RFC 5394
Policy-Enabled Path Computation Framework
Policy-Enabled Path Computation Framework 🎀
Network Working Group I. Bryskin
Request for Comments: 5394 Adva Optical
Category: Informational D. Papadimitriou
Alcatel
L. Berger
LabN Consulting
J. Ash
AT&T
December 2008Okay bestie, the header facts first 💖 This is RFC 5394, called "Policy-Enabled Path Computation Framework," from the Network Working Group. It's Informational 🦋, so it shares info but doesn't set an Internet standard. The authors are I. Bryskin (Adva Optical), D. Papadimitriou (Alcatel), L. Berger (LabN Consulting), and J. Ash (AT&T), and it's dated December 2008 🌸. The header doesn't list anything it obsoletes or updates, so there's nothing to flag there ✨.
Status of This Memo 🌈
This memo is just giving info to the Internet community. It is not a standard of any kind 🫶 Anyone can distribute it freely, no limits 💅.
Copyright Notice ✨
It's copyright 2008, held by the IETF Trust and the document authors, all rights reserved 💜. It's governed by BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as of the publication date. Read those carefully, because they spell out your rights and restrictions with this doc 🙈.
Abstract 🦋
Okay so the Path Computation Element (PCE) architecture brings in the idea of policy for path computation, and this doc gives you way more detail on that. It also gives context for supporting PCE Policy 💖. The big move here is using the Policy Core Information Model (PCIM) as a framework for path computation policy 🔥. Plus, there are some representative scenarios showing how it all plays out 🧚.
Table of Contents 🎀
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Background ......................................................4
2.1. Motivation .................................................4
2.2. Policy Attributes ..........................................6
2.3. Representative Policy Scenarios ............................7
2.3.1. Scenario: Policy Configured Paths ...................7
2.3.2. Scenario: Provider Selection Policy ................10
2.3.3. Scenario: Policy Based Constraints .................12
2.3.4. Scenario: Advanced Load Balancing (ALB) Example ....14
3. Requirements ...................................................16
4. Path Computation Policy Information Model (PCPIM) ..............18
5. Policy-Enabled Path Computation Framework Components ...........20
6. Policy Component Configurations ................................21
6.1. PCC-PCE Configurations ....................................21
6.2. Policy Repositories .......................................24
6.3. Cooperating PCE Configurations ............................25
6.4. Policy Configuration Management ...........................27
7. Inter-Component Communication ..................................27
7.1. Policy Communication ......................................27
7.2. PCE Discovery Policy Considerations .......................29
8. Path Computation Sequence of Events ............................29
8.1. Policy-Enabled PCC, Policy-Enabled PCE ....................29
8.2. Policy-Ignorant PCC, Policy-Enabled PCE ...................31
9. Introduction of New Constraints ................................32
10. Security Considerations .......................................33
11. Acknowledgments ...............................................33
12. References ....................................................34
12.1. Normative References .....................................34
12.2. Informative References ...................................341. Introduction ✨
Okay so the PCE Architecture is introduced in [RFC4655] 💖. This doc is all about what happens when policy-based decision making gets plugged into that architecture, plus extra details and context for applying policy inside the PCE architecture 🫶.
Now, Policy-based Management (PBM), see [RFC3198], is a network management approach where the network can automatically do things in response to events or conditions, based on pre-set rules (aka policies) from a network admin 🦋. It lets admins work at a high level using rule-based strategy, where policies are sets of rules and actions. Those get automatically turned into individual device config directives, dynamically and with no human in the loop, to control the whole network 🔥. Two IETF Working Groups have looked at policy networking before: the Resource Allocation Protocol (RAP) working group and the Policy Framework working group 🌸.
A framework for policy-based admission control was defined in [RFC2753] 💅, and a protocol for talking between Policy Enforcement Points (PEP) and Policy Decision Points (PDP) was specified: Common Open Policy Service (COPS) [RFC2748] ✨. This doc uses PEP and PDP to mean the functions as defined in the COPS context. It doesn't assume or require that the actual COPS protocol gets used 🙈. Any suitable policy exchange protocol can be swapped in, like Simple Object Access Protocol (SOAP) [W3CSOAP] 🧚.
The IETF has also put out a general framework for representing, managing, sharing, and reusing policies in a way that's vendor-independent, interoperable, and scalable 👑. It also defined an extensible information model for representing policies called the Policy Core Information Model (PCIM) [RFC3060] 💜. There's an extension to that for QoS management, the QoS Policy Information Model (QPIM) [RFC3644] 🌈. BUT, extra mechanisms are still needed to specify policies related to the path computation logic and how it's controlled 💀.
Here's the roadmap 🎀. Section 2 gives policy background and scenarios for context. Section 3 lists the requirements that mechanisms and protocols must address to enable policy-based control over path computation requests and decisions 🦋. Section 4 brings in PCIM as a core piece of a framework for 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 cover possible component configurations, communication, and events 🔥. Section 10 talks about introducing new constraints with minimal impact ✨. Heads up though: in Section 4, this doc only introduces PCIM. Specific PCIM definitions for path computation will be covered in a separate document 🙈.
1.1. Terminology 🌸
The reader is assumed to already know these terms 💅:
BEEP: Blocks Extensible Exchange Protocol, see [RFC3080].
CIM: Common Information Model, see [DMTF].
COPS: Common Open Policy Service, see [RFC2748].
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].
PCEP: Path Computation Element Communication Protocol,
see [PCEP].
PCIM: Policy Core Information Model, see [RFC3060].
PDP: Policy Decision Point, see [RFC2753].
PEP: Policy Enforcement Point, see [RFC2753].
QPIM: QoS Policy Information Model, see [RFC3644].
SLA: Service Level Agreement.
SOAP: Simple Object Access Protocol, see [W3CSOAP].
TE: Traffic Engineering, see [RFC3209] and [RFC3473].
TED: Traffic Engineering Database, see [RFC3209] and [RFC3473].
TE LSP: Traffic Engineering MPLS Label Switched Path, see
[RFC3209] and [RFC3473].
WDM: Wavelength Division Multiplexing2. Background 🦋
Okay this section gives some general background on using policies inside the PCE architecture 💖. It explains why policies are useful in the TE path computation process, and it shows some representative policy usage scenarios 🫶. The whole point is to give context for the PCE policy framework being presented 🔥. And tbh, it's not trying to be an exhaustive list of reasons or scenarios, so don't expect every possible one 🙈✨
To be continued in Part 2 of 8 🧚💜
2.1. Motivation ✨
okay so the PCE architecture from [RFC4655] has policy built right in as a core part of the whole thing 🎀 and this section is basically the "why would we do that??" explainer, bestie 💅
first up, network operators need a real amount of flexibility to shape how TE path computation works, so it can actually line up with their business and ops goals 🧚 a lot of the path computation can be governed by policies. like, a PCC might use operator-configured policies to decide which optimization criteria, constraints, diversities, and relaxation strategies to ask for when it's computing path(s) for a specific service 👑 depending on SLAs, TE goals, and cost/performance ratio goals, path computation requests can look totally different for different services 🌈
for example, Service A might need two Shared Risk Link Group (SRLG)-disjoint paths to build an end-to-end recovery scheme 🦋 meanwhile Service B only needs link-disjoint paths, and that's totally fine for it 💖 Service A might want paths with minimal end-to-end delay, while Service B is chillin' with shortest (minimal-cost) paths 🍓 different constraint relaxation strategies can get applied when computing paths for Service A versus Service B, and so on and so forth ✨ so, based on each service's distinct requirements, distinct or similar policies might get adopted when requests are issued or handled 🫶
then there's the PCE side of things 🔥 a PCE might apply policies to decide which algorithm(s) to run when it's doing path computations for a particular PCC or a particular domain, see [RFC4927] 💜 it could also decide whether to ask other PCEs for help with a request or just handle it on its own (maybe replying with non-explicit paths) 🌸 or how a request should get modified before it gets sent off to other member(s) of a group of cooperating PCEs, etc. 💀
here's some more motivation for putting policies into the PCE architecture 🙈 historically, a path computation entity was basically a part of an LSR's control plane, always co-located with the LSR's signaling and routing subsystems 🍓 that gave you unlimited flexibility for path computation upgrades, like adding new types of constraints, diversities, and their relaxation strategies, adopting new objective functions and optimization criteria, and so forth ✨ all you had to do to support an enhancement was upgrade the control plane software of one particular LSR (and no other LSRs or any other network elements) 💅
but once the PCE architecture came along, adding new PCE capabilities got way more complicated 😭 it isn't enough for a PCE to just upgrade its own software 🎀 to take advantage of a PCE's new capabilities, new advertising and signaling objects might need to be standardized, all PCCs might need new software, and new interoperability problems might need to get sorted out, etc. 💀
so within the PCE architecture, it's highly desirable to find a way to add new path computation capabilities WITHOUT having to modify either the discovery/communication protocols or the PCC software 🦋 one way to pull that off is to treat path selection constraints, their relaxations, and objective functions as path computation request-specific policies 🌈 and then those policies can be configured and managed by a network operator like any other policies, and interpreted in real time by PCCs and PCEs ⭐
there are a bunch of advantages and useful by-products of this approach, bestie 👑
- new path computation capabilities can be introduced without changing PCE-PCC communication and discovery protocols or PCC software 💖 only the PCE module providing the path computation capabilities (referred to in this document as a path computation engine) needs an update 🫶
- existing constraints, objective functions, and their relaxations can be aggregated and otherwise associated, which makes brand-new, more complex objective functions that don't need a code change even on the PCEs supporting the functions 🔥
- different elements like conditions, actions, variables, etc. can be reused by multiple constraints, diversities, and optimizations 🧚
- PCCs and PCEs need to handle other (that is, not request-specific) policies too 🌸 path computation-related policies of all types can live in the same policy repositories, be managed by the same policy management tools, and be interpreted using the same mechanisms 💜 also, policies need to be supported by PCCs and PCEs no matter the peculiarities of a specific PCC-PCE communication protocol, see [PCEP] 🍓 so introducing a new (request-specific) type of policy describing constraints and other elements of a path computation request is a natural and relatively inexpensive addition to the policy-enabled path computation architecture 👑 iykyk 💅
2.2. Policy Attributes ✨
this section gives a summary listing of the policy attributes that may be included in the policy exchanges described in the scenarios that follow 🎀 it's provided for guidance and isn't meant to be exclusive, so an implementation of this framework might include additional policy attributes not listed here 🦋
Identities
- LSP head-end
- LSP destination
- PCC
- PCE
LSP identifiers
- LSP head-end
- LSP destination
- Tunnel identifier
- Extended tunnel identifier
- LSP ID
- Tunnel name
Requested LSP qualities
- bandwidth
- traffic parameters
- LSP attributes
- explicit path inclusions
- explicit path exclusions
- link protection level
- setup priority
- holding priority
- preexisting LSP route
Requested path computation behavior
- objective function
- other LSPs to be considered
Additional policy information
- Transparent policy information as received in Resource
Reservation Protocol (RSVP)-TE2.3. Representative Policy Scenarios 🧚
this section gives example scenarios of how policies may be applied using the PCE policy framework within the PCE architecture context 💖 real networks might deploy one of the scenarios discussed, some combo of the presented scenarios, or other scenarios that aren't discussed here 🌈 and this section should not be viewed as limiting other applications of policies within the PCE architecture 💅🫶
2.3.1. Scenario: Policy Configured Paths ✨
okay so the simplest way to use PCE policy is to have the PCE centrally manage configured paths 🗺️ these are built from strict and loose hops written as Explicit Route Objects (EROs), see [RFC3209], and one or more LSPs can use them. usually the LSP ingress is where they get set up, but with policy-enabled path computation there's a cuter option 🎀
you can install service-specific policies that hand over configured path(s) for one specific service request. the request can be matched on things like endpoints, requested QoS, or even a token that identifies whoever started the request 🔑 those configured path(s) then feed into the path computation process, which returns explicit routes by expanding all of the specified loose hops 💅
Example of policy:
if(service_destination matches 10.132.12.0/24)
Use path: 10.125.13.1 => 10.125.15.1 => 10.132.12.1.
else
Compute path dynamically.and here's the vibe check of how everything connects 👀
----------------------
| ----- |
| | 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 PCEpath computation policies can live at either a PCC or a PCE, see Figure 1 🦋 if it's the PCC, the configured path gets processed at the PCC first and then passed along to the PCE with the PCE request, probably as (inclusion) constraints. if it's the PCE, the configured path just gets used locally. both options need some way to configure and manage those policies 📋 and for the PCC case, the real glow-up happens when there's an automated policy 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 Computationpolicy-configured paths also work in environments with multiple cooperating PCEs (see Figures 2 and 3) 🌈 picture this: TE visibility is limited, so independent PCEs figure out path(s) inside each area of TE visibility. in that case it might not be possible (or desirable) to configure entire explicit path(s) on one single PCE 🙈 BUT you can configure explicit path(s) for each area of TE visibility and each responsible PCE. then the PCEs take turns, one by one, mapping an incoming signaling request to the right configured path(s) 🧚 to make this work, the configured paths would likely need to start and finish on TE domain boundary nodes. and honestly? consistent PCE Policy Repositories are critical here, no cap 💜
------------------ ------------------
| | 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 Communication2.3.2. Scenario: Provider Selection Policy 🏙️
okay this one is giving big "multi-provider drama" energy 😭 applying PC policies in multi-provider topologies is potentially even more interesting, and there are tons of cool policy applications in these setups. a basic one is simple access control, aka deciding which PCCs are allowed to request inter-domain path computation 🔐
the more complicated one is using policy to decide which domain or network provider will support a particular PCE request 💅 check out the topology in Figure 4. here there are multiple transit domains that could get a path from a source domain to a destination domain, and each transit domain might have one or more ways to reach a particular domain. so every domain has to pick which of those multiple available paths gets used for a given PCE request 🛤️
in today's typical path computation process, TE reachability, availability, and metric are the basic criteria for picking a path 📊 but policies can add an important extra consideration to the decision. for example, transit domain A might be more expensive but offer lower delay or loss than transit domain B 💸 and a transit domain might want to treat PCE requests from its own customers differently than requests from other providers 🫶 in both cases, computation based on traffic engineering databases will give you multiple transit domains that provide reachability, and policies can decide which PCE requests get the better service 👑
+-------+
+----------+Transit+----------+
+---+---+ | Domain| +---+---+
|Transit| | C | |Transit|
+--------+ Domain| +---+---+ | Domain+--------+
| | A +--+ | +--+ F | |
+--+---+ +---+---+ | | | +---+---+ +--+---+
|Source| | | +---+---+ | | |Target|
|Domain| | +---+Transit+---+ | |Domain|
+--+---+ | +---+ Domain|---+ | +--+---+
| +---+---+ | | D | | +---+---+ |
| |Transit| | +---+---+ | |Transit| |
+--------+ Domain+--+ | +--+ Domain+--------+
| B | | | G |
+---+---+ +---+---+ +---+---+
| |Transit| |
+----------+ Domain+----------+
| E |
+-------+
Figure 4: Multi-Domain Network with Multiple Transit Optionsthere are a bunch of ways to tell which PCE requests get to use a particular transit domain and what level of service (better or worse) they get 🎀 for example, a PCE in the source domain can use user- and request-specific policies to decide the level of service to provide 🧁 a PCE in the source domain can also use domain-specific policies to choose which transit domains are acceptable 🚦 and a PCE in a transit domain can use request-specific policies to figure out whether a request is from a direct customer or another provider, then use domain-specific policies to decide how that request should be processed 🌸
Example of policy:
if(path computation request issued by a PCC within Source Domain)
Route the path through Transit Domain A.
else
Route the path through Transit Domain B.2.3.3. Scenario: Policy Based Constraints 💅
Okay bestie, next up is using policy to put constraints on a PCE request 🎀. Picture an LSR with a policy-enabled PCC (see Figure 1). It gets a service request through signaling, either over an NNI or a UNI reference point, or it gets a configuration request through a management interface to set up a service. Either way, the message doesn't spell out the path(s) the service needs, so path computation is required 🧚.
The PCC can use user- or service-specific policies to decide how path selection should be constrained 💖. That means picking which constraints, diversities, optimization criteria, and constraint relaxation strategies to apply, so the service LSP(s) have a good shot at being established and deliver the QoS and resilience against network failures that are needed 🛡️. To make that call, the PCC uses everything it knows about the user and the service as input: the contents of the received message, the port ID it came in on, the associated VPN ID, the signaling/reference point type, the request time, and so on ✨. Once the constraints and other parameters are settled, the PCC builds a path computation request. That request includes the request-specific policies, which describe the chosen constraints, optimizations, and other parameters and tell the PCE how to consider the request during path computation 🦋.
Example of policy:
if(LSP belongs to a WDM layer network)
Compute the path with wavelength continuity constraint with the
maximum Optical Signal Noise Ratio (OSNR) at the path end
optimization.
else if(LSP belongs to a connection oriented Ethernet layer network)
Compute the path with minimum end-to-end delay.
else
Compute the shortest path.The PCC can also apply server-specific policies to pick which PCE to use from the set of known (discovered or configured) PCEs 🔍. It can use those policies to shape the request so it matches the PCE's capabilities 🎯. That way the request won't get rejected and has a better chance of being satisfied efficiently 🙌. For example, the PCC might remove a constraint the PCE doesn't support 💀. Once the PCC finishes policy processing and the path computation request has been updated to reflect it, the request goes off to the PCE 🚀.
Example of policy:
if(LSP belongs to a WDM layer network)
Identify a PCE supporting wavelength continuity and optical
impairment constraints;
Send a request to such PCE, requesting path computation with the
following constraints:
a) wavelength continuity;
b) maximum Polarization Mode Dispersion (PMD) at the path end.
if(the path computation fails) remove the maximum PMD constraint
and try the computation again.The PCE that receives the request validates and processes it, applying the policies found in the request as well as any policies available at the PCE itself, such as client- and domain-specific policies 🌸. After that policy processing, the PCE may decide to reject the request 🙈.
Example of policy:
Authenticate the PCC requesting the path computation using the
PCC ID found in the path computation request;
Reject the request if the authentication fails.The PCE may also respond with one or several pre-computed paths if user- or client-specific policies tell it to do so 🍓. If the PCE decides to satisfy the request with a path computation, it figures out whether it needs help from other PCEs, and it sets the parameters for the computations to run locally and remotely 🧠. Then it tells a co-located path computation engine to do the local path computation(s) and, if necessary, sends path computation requests to one or more other PCEs 📡. It waits for responses from the local engine and, if used, the remote PCE. Once those are in, it combines the resulting paths and sends the result back to the requesting PCC 🫶. The response may include policies describing the resulting paths and their characteristics (summary cost, expected end-to-end delay, etc.), along with extra info about the request. That extra info can cover which constraints were honored, which were dismissed, and which were relaxed and how 👑.
Example of policy:
if(the path destination belongs to domain A)
Instruct local path computation engine to perform the path
computation;
else
Identify the PCE supporting the destination domain;
Send path computation request to such PCE;
Wait for and process the response.
Send the path computation response to the requesting PCC.Last step: the PCC processes the response and tells the LSR to encode the received path(s) into the outgoing signaling message(s) 💜.
2.3.4. Scenario: Advanced Load Balancing (ALB) Example 🌈
Figure 5 shows a problem caused by the coupling between BGP and the IGP in the BGP decision process 😭. Say a big chunk of the traffic headed for the data center (or customer network) enters a PCE-enabled network from AS 1, and every IGP link has the same weight. Then both PE3 and PE4 will prefer to reach the data center using the routes advertised by PE2 🙃. PE5 breaks the tie using the router-IDs of PE1 and PE2, so it might also pick the path through PE2 if PE2's router ID is smaller than PE1's 🤷♀️. Either way, the link between PE2 and CE ends up carrying most of the traffic while the link between PE1 and the Customer Edge (CE) sits 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 BalancingThis is a common headache for providers and customers alike 😩. Analysis of Netflow records, see [IRSCP], from a large ISP network on a typical day found that 71.8% of multi-homed customers had a complete imbalance. In that case, the most loaded link carries all the traffic and the least loaded link carries none 📉.
PCE policies can fix this by basing the routing decision at the ingress routers on the offered load toward the multi-homed customer 💅. For example, in Figure 5, PCE policies could be set up so traffic load is monitored (e.g., based on Netflow data) at ingress routers PE3 to PE7, toward the data center prefixes served by egress routers PE1 and PE2 👀. Using that offered load information, the path computations the PCE returns, based on the enabled PCE policies, can steer traffic to the right egress router on a per-ingress-router basis 🎯. For instance, the PCE path computation might direct traffic from both PE4 and PE5 to egress PE1, overriding the default IGP-based selection 🔁. Alternatively, traffic from each ingress router to each egress link could be split 50-50 ⚖️.
This scenario shows how a policy-governed PCE can account for info that was not or cannot be advertised as TE link/node attributes, which means it can't be used as an explicit path computation constraint 🧩. Honestly, that info can be pretty much anything: traffic demand forecasts, flow monitoring feedback, any administrative policies, and more ✨. [IRSCP] has more examples of how PCE policies might handle other routing problems, like selective distributed denial-of-service (DDoS) blackholing, planned maintenance, and VPN gateway selection 🌷.
Example of policy:
for(all traffic flows destined to Customer Network)
if(flow ingresses on PE3, PE4, or PE5)
Route the flow over PE1.
else
Route the flow over PE2.3. Requirements ✨
okay so bestie, here's the checklist of stuff the mechanisms must handle for policy-based control over path computation requests and decisions 📋💖
- (G)MPLS path computation-specific 🔥 The mechanisms must meet the policy-based control requirements specific to path computation using RSVP-TE as the signaling protocol on MPLS and GMPLS LSRs. ⚡
- Support for non-(G)MPLS PCCs 🌈 The mechanisms must be generic enough to support non-(G)MPLS (LSR) clients, like a Network Management System (NMS) or a network planner, etc. 🧚
- Support for many policies 💅 The mechanisms must support many policies and policy configurations. Figuring out and configuring which policies are viable is the service provider's job, not the mechanism's. 🎀
- Provision for monitoring and accounting information 📊 The mechanisms must support monitoring policy state and provide access information. Specifically, they must provide usage and access information that can be used for accounting purposes. 💜
- Fault tolerance and recovery 🛟 The mechanisms must include provisions for fault tolerance and recovery from failure cases, like failure of PCC/PCE PDPs, or a disruption in communication that separates a PCC/PCE PDP from its associated PCC/PCE PEPs. 😭
- Support for policy-ignorant nodes 🙈 The mechanisms should not be mandatory for every node in a network. Policy-based path computation control may be enforced at a subset of nodes, for example on boundary nodes within an administrative domain. These policy-capable nodes will act as trusted nodes from the point of view of the policy-ignorant nodes in that domain. Alternatively, policy may be applied solely on PCEs, with all PCCs being policy-ignorant nodes. 🫶
- Scalability 📈 Scalability is one of the big requirements here. The mechanisms must scale at least as well as RSVP-TE signaling does when it comes to accommodating multiple LSPs and network nodes in the path of an LSP. There are a few sensitive areas. First, not every policy-aware node in an infrastructure should be expected to contact a remote PDP, because that would cause potentially long delays in verifying requests. Also, the policy control architecture must scale at least as well as the RSVP-TE protocol, based on factors like the size of RSVP-TE messages, the time the network needs to service an RSVP-TE request, the local processing time required per node, and the local memory consumed per node. These scaling considerations matter especially during re-routing of a set of LSPs. 🔥
- Security and denial-of-service considerations 🚨 The policy control architecture, protocols, and mechanisms must be secure in the following ways:
- First, the mechanisms proposed must minimize theft and denial-of-service threats. 💀
- Second, it must be ensured that the entities (such as PEPs and PDPs) involved in policy control can verify each other's identity and establish the necessary trust before communicating. 🔐
- Inter-AS and inter-area requirements 🗺️ There are several inter-AS policy-related requirements discussed in [RFC4216] and [RFC5376], and inter-area policy-related requirements discussed in [RFC4927]. These requirements must be addressed by policy-enabled PCE mechanisms and protocols. 👑
It should be noted that this document only outlines the communication elements and mechanisms needed to allow a wide variety of possible policies to be applied for path computation control. It does not include any discussion of specific policy behavior, nor does it define or require the use of specific policies. 🦋
4. Path Computation Policy Information Model (PCPIM) 💖
The Policy Core Information Model (PCIM), introduced in [RFC3060] and expanded in [RFC3460], presents the object-oriented information model for representing general policy information. 🧠
This model defines two hierarchies of object classes:
- Structural classes, representing policy information and control of policies. 🏗️
- Association classes, which indicate how instances of the structural classes are related to each other. 🔗
These classes can be mapped to various concrete implementations, for example to a directory that uses Lightweight Directory Access Protocol version 3 (LDAPv3) as its access protocol. 📁
Figure 6 shows an abstract from the class inheritance hierarchy for PCIM. 👀
ManagedElement (abstract)
|
+--Policy (abstract)
| |
| +---PolicySet (abstract)
| | |
| | +---PolicyGroup
| | |
| | +---PolicyRule
| |
| +---PolicyCondition (abstract)
| | |
| | +---PolicyTimePeriodCondition
| | |
| | +---VendorPolicyCondition
| | |
| | +---SimplePolicyCondition
| | |
| | +---CompoundPolicyCondition
| | |
| | +---CompoundFilterCondition
| |
| +---PolicyAction (abstract)
| | |
| | +---VendorPolicyAction
| | |
| | +---SimplePolicyAction
| | |
| | +---CompoundPolicyAction
| |
| +---PolicyVariable (abstract)
| | |
| | +---PolicyExplicitVariable
| | |
| | +---PolicyImplicitVariable
| | |
| | +---(subtree of more specific classes)
| |
| +---PolicyValue (abstract)
| |
| +---(subtree of more specific classes)
Figure 6: PCIM Class InheritanceThe policy classes and associations defined in PCIM are generic enough to represent policies related to anything. 🌍
Policy models for application-specific areas, such as the Path Computation Service, may extend the PCIM in several ways. The preferred way is to use the PolicyGroup, PolicyRule, and PolicyTimePeriodCondition classes directly as a foundation for representing and communicating policy information. Then, specific subclasses derived from PolicyCondition and PolicyAction can capture application-specific definitions of policy conditions and actions. 🎀
The Policy Quality of Service Information Model [RFC3644] further extends the PCIM to represent QoS policy information for large-scale policy domains. New classes introduced in this document, describing QoS- and RSVP-related variables, conditions, and actions, can be used as a foundation for the PCPIM. ✨
A detailed description of the PCPIM will be provided in a separate document. 📚
5. Policy-Enabled Path Computation Framework Components 🎀
The following components are defined as part of the framework to support policy-enabled path computation: 🧩
- PCE Policy Repository 🗄️ A database from which PCE policies are available in the form of instances of PCPIM classes. PCE policies are configured and managed by PCE Policy Management Tools;
- PCE Policy Decision Point (PCE-PDP) 🧠 A logical entity capable of retrieving relevant path computation policies from one or more Policy Repositories and delivering the information to associated PCE-PEP(s);
- PCE Policy Enforcement Point (PCE-PEP) 🛡️ A logical entity capable of issuing device-specific Path Computation Engine configuration requests for the purpose of enforcing the policies;
- PCC Policy Decision Point (PCC-PDP) 🧠 A logical entity capable of retrieving relevant path computation policies from one or more Policy Repositories and delivering the information to associated PCC-PEP(s);
- PCC Policy Enforcement Point (PCC-PEP) 🛡️ A logical entity capable of issuing device-specific Path Computation Service User configuration requests for the purpose of enforcing the policies.
From the policy perspective, a PCC is logically split into two 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 computation (for example, the GMPLS control plane of an LSR). The PCC-PEP and PCC-PDP may be physically co-located (as per [RFC2748]) or separated. In the latter case, they talk to each other via protocols such as SOAP [W3CSOAP] or BEEP [RFC3080]. 🤝
Likewise, a PCE is logically split into two parts: PCE-PEP and PCE-PDP. When present, the PCE-PEP is co-located with a Path Computation Engine entity that actually provides the Path Computation Service (that is, runs the path computation algorithms). The PCE-PEP and PCE-PDP may be physically co-located or separated. In the latter case, they communicate using protocols such as SOAP and/or BEEP. 💫
PCC-PDP/PCE-PDP may be co-located with, or separated from, an associated PCE Policy Repository. In the latter case, the PDPs use some access protocol (for example, LDAPv3 or SNMP). The job of the PDPs is to retrieve policies from the repository (or repositories) and convey them to the respective PEPs, either unsolicited or upon the PEP's requests. 📬
A PCC-PEP may receive policy information not only from PCC-PDP(s) but also from PCE-PEP(s), via PCC-PCE communication and/or PCE discovery protocols. Likewise, a PCE-PEP may receive policy information not only from PCE-PDP(s) but also from PCC-PEP(s), via the PCC-PCE communication protocol [PCEP]. 🔁
Any given policy can be interpreted (that is, translated into a sequence of concrete device-specific configuration requests) either on a PDP, on the associated PEP, or partly on the PDP and partly on the PEP. 🧠🛡️
Generally speaking, the PCC-PEP's job is to select the PCE and build path computation requests, applying service-specific policies provided by the PCC-PDP. The PCE-PEP's job is to control path computations by applying request-specific policies found in the requests, as well as client-specific and domain-specific policies supplied by the PCE-PDP. 👑
6. Policy Component Configurations 🦋
6.1. PCC-PCE Configurations ✨
okay so the PCE policy architecture is giving flexibility 💅 it supports policy being applied at a PCC and at a PCE. but here's the tea: there's no requirement that policy shows up at both, or even at either one 🫶 where policy lives in a network, on PCCs and on PCEs, is a specific network design choice. some networks go PCC-only (Figure 7), some go PCE-only (Figure 8), and some do both (Figure 9). no matter where policy lives, it must be applied in a consistent fashion or the results won't be what anyone intended 😭
.........................
. .
. PCE Policy Management .
. .
.........................
.
.
--------- Policy -----------------------
| PCC-PDP |<--------- | PCE Policy Repository |
--------- -----------------------
^
| e.g., SOAP
v
--------- PCEP ---------
| PCC-PEP |<------------------------------------------->| PCE |
--------- PCC-PCE Communication Protocol ---------
Figure 7: Policies Applied on PCC Onlyalong with flexibility about where policy goes, the PCE architecture is also flexible about where specific types of policies get applied 🦋 it even lets you apply only a subset of policy types. [RFC4655] defines several PC policy types, and each one can be applied at a PCC, a PCE, or both. ngl, when policy is only at PCCs or only at PCEs, every PCE policy type used in the network has to be applied at those locations 🙈
.........................
. .
. PCE Policy Management .
. .
.........................
.
.
----------------------- Policy ---------
| PCE Policy Repository | -------->| PCE-PDP |
----------------------- ---------
^
e.g., SOAP |
v
--------- PCEP ---------
| PCC |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol ---------
Figure 8: Policies Applied on Onlyin the PCE-only case, the PCC is expected to hand the PCE all the info about the service it can gather in the path computation request (most likely as PCPIM policy variables) 🧚 the PCE is expected to understand that info and apply appropriate policies while defining the actual parameters of the path computation. just know that in this setup the PCC can't apply server-specific or any other policies, and PCE selection is static 💀
when you apply policy at both the PCC and the PCE, you have to pick which types go where 🎀 the policy types usually get split across the PCC and PCE instead of all of them doubling up. for example, user-specific and server-specific policies might live at a PCC, request- and client-specific policies at a PCE, and domain-specific policies at both 👑
in the PCC-only case, the PCC must apply all the types of required policies, like user-, service-, server-, and domain-specific ones 💅 the PCC uses those policies to build a path computation request that properly represents them. the request is necessarily limited to the set of "basic" (that is, non-policy capable) constraints explicitly defined by the PCC-PCE communication protocol 🥲
6.2. Policy Repositories 🌸
within the policy-enabled path computation framework, policy repositories can be used in a single or multiple PCE policy repository configuration:
- Single PCE Policy Repository
in this configuration, there's one PCE Policy Repository shared between PCCs and PCEs 🦋
.........................
. .
. PCE Policy Management .
. .
.........................
.
.
--------- Policy a ----------------------- Policy b ---------
| PCC-PDP |<--------- | PCE Policy Repository | -------->| PCE-PDP |
--------- ----------------------- ---------
^ ^
| e.g., SOAP e.g., SOAP |
v v
--------- PCEP ---------
| PCC-PEP |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol ---------
Figure 9: Single PCC/PCE Policy Repository- Multiple PCE Policy Repositories
these repositories may be fully or partially synchronized by some discovery/synchronization management protocol, or they may be completely independent 🌈 fun fact: if PCE Policy Repository A exactly matches PC Policy Repository B, you've just got the single PCE Policy Repository configuration case 😭
-------------- --------------
| PCE Policy | | PCE Policy |
---| Repository A | | Repository B |---
| -------------- -------------- |
| |
| Policy a Policy b |
| |
v v
--------- ---------
| PCC-PDP | | PCE-PDP |
--------- ---------
^ ^
| e.g., SOAP e.g., SOAP |
v v
--------- PCEP ---------
| PCC-PEP |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol ---------
Figure 10: Multiple PCE/PCC Policy Repositories6.3. Cooperating PCE Configurations 🧚
okay so the previous section showed how PCCs and PCEs relate 💖 a parallel relationship exists between cooperating PCEs, and honestly it can be viewed as the same as the PCC-PCE relationship. the one big difference: there will be cases where a shared PCE Policy Repository isn't desirable, like when the PCEs are managed by different entities. even then, policies still have to be consistent across the domains in order to identify usable paths 🫶 the other notable difference is that a PCE, while processing a path computation request, may need to apply requester-specific (that is, client-specific) policies to modify the request before sending it on to other cooperating PCE(s). this relationship matters a lot because the PCE architecture allows for configurations where not all PCCs are policy-enabled 🔥
here are some example configurations. they aren't an exhaustive list, and other configurations are expected 🌸
- Single Policy Repository
in this configuration, there's a single PCE Policy Repository shared between PCEs. this is likely to be useful within a single administrative domain where multiple PCEs are provided for redundancy or load distribution purposes 💅
.........................
. .
. PCE Policy Management .
. .
.........................
.
.
--------- Policy a ----------------------- Policy b ---------
| PCE-PDP |<--------- | PCE Policy Repository | -------->| PCE-PDP |
--------- ----------------------- ---------
^ ^
| e.g., SOAP e.g., SOAP |
v v
--------- ---------
| PCE-PEP |<------------------------------------------->| PCE-PEP |
--------- PCE-PCE Communication Protocol ---------
Figure 11: Single PCC Policy Repository- Multiple Policy Repositories
these repositories may be fully or partially synchronized by some discovery/synchronization management protocol(s), or they may be completely independent 🦋 in the multi-domain case, the repositories are expected to be distinct, while still providing consistent policies 🎀
-------------- --------------
| PCE Policy | | PCE Policy |
---| Repository A | | Repository B |---
| -------------- -------------- |
| |
| Policy a Policy b |
| |
v v
--------- ---------
| PCE-PDP | | PCE-PDP |
--------- ---------
^ ^
| e.g., SOAP e.g., SOAP |
v v
--------- PCEP ---------
| PCE-PEP |<------------------------------------------->| PCE-PEP |
--------- PCC-PCE Communication Protocol ---------
Figure 12: Multiple PCC Policy Repositories6.4. Policy Configuration Management 💜
the management of path computation policy information used by PCCs and PCEs is mostly out of scope of this framework 🙈 the framework just assumes that this info gets installed, removed, and otherwise managed using typical policy management techniques. policy repositories can be populated and managed via static configuration, standard and proprietary policy management tools, or even dynamically through policy management/discovery protocols and applications ✨
7. Inter-Component Communication ✨
7.1. Policy Communication 💅
Okay so flexibility in applying policy types is imperative from the architecture point of view 🫶. Ngl though, that flexibility comes with extra complexity on the side of the PCE communication protocols 😭.
One added complexity is that PCE communication protocols must carry certain information to support the various policy types that may be applied. For example, if policy is only applied at a PCE, a PCC-PCE request must carry enough info for the PCE to apply service- or user-specific policies. This does imply that a PCC must have sufficient understanding of what policies can be applied at the PCE. That info can come from local configuration, static coding, or even a PCE discovery mechanism 🧚. The PCC must also have sufficient understanding to properly encode the required information for each policy type ✨.
Another added complexity is that PCE communication protocols must also be able to carry information that may result from a policy decision. For example, a user- or service-specific policy applied at a PCC may result in policy-related information that must be carried along with the request for use by a PCE. This is super important, because it may be used to introduce new path computation parameters (e.g., constraints, objective functions, etc.) without modifying the core PCC and PCE 👑. This will likely simply require the PCE communication protocols to support opaque policy-related information elements 🔥.
A final added complexity is that PCE communication protocols must also be able to support updated or unsolicited responses from a PCE. For example, changes in PCE policy may force a change to a previously provided path 💀. Such updated or unsolicited responses may contain information that the PCC must act on, and may contain policy information that must be provided to a PCC 🌈.
PCC-PEP and PCE-PEP, or a pair of PCE-PEPs, communicate via a request-response type PCC-PCE Communication Protocol, i.e., [PCEP] 🦋. This document makes no assumptions as to what exact protocol is used to support this communication. It does assume that the semantics of a path computation request are sufficiently abstract and general, and support both PCE-PCC and PCE-PCE communication 💜.
From a policy perspective, a path computation request should include at a minimum:
- One or more source addresses
- One or more destination addresses
- Computation type (P2P (point to point), P2MP (point to multipoint), MP2P (multipoint to point), etc.)
- Number of required paths
- Zero or more policy descriptors in the following format:
<policy name>,
<policy variable1 name>, <param11>, <param12>,...,<param1N>
<policy variable2 name>, <param21>, <param12>,...,<param2N>
...
<policy variableM name>, <paramM1>, <paramM2>,...,<paramMN>A successful path computation response, at minimum, should include the list of computed paths, and it may include policies (in the form of policy descriptors as in the path computation request, see above) for use in evaluating and otherwise applying the computed paths 🍓.
PCC-PCE Communication Protocol provides transport for policy information and should not understand nor make any assumptions about the semantics of policies specified in path computation requests and responses 🎀.
Note: This document explicitly allows for (but does not require) the PCC to decide that all necessary constraints, objective functions, etc. pertinent to the computation of paths for the service in question are to be determined by the PCE performing the computation. In this case, the PCC will use a set of policies (more precisely, PCPIM policy variables) describing the service-specific information. These policies may be placed within the path computation request and delivered to the PCE via a PCC-PCE communication protocol such as [PCEP]. The PCE (more precisely, PCE-PEP) is expected to understand this information and use it to determine the constraints and optimization functions applying local policies (that is, policies locally configured or provided by the associated PCE-PDP(s)) 🫶.
7.2. PCE Discovery Policy Considerations 🌸
Dynamic PCE discovery lets PCCs and PCEs automatically discover a set of PCEs (including the info required for PCE selection) 🔍. It also lets them dynamically detect new PCEs or any modification of PCE status. Policy can be applied in two ways in this context:
- Restricting the scope of information distribution for the mandatory set of information (in particular the PCE presence and location).
- Restricting the type and nature of the optional information distributed by the discovery protocol. The latter is also subject to policy, since the PCE architecture allows this information to be distributed using either PCE discovery protocol(s) or PCC-PCE communication protocol(s). One important policy decision in this context is the nature of the information to be distributed, especially when this information is not strictly speaking "discovery" information, but rather PCE state changes 🙈. Client-specific and domain-specific policies may be applied when deciding whether this information should be distributed, and to which clients of the path computation service (that is, which PCCs and/or PCEs).
Another place where policy applies is at administrative boundaries 🚧. In multi-domain networks, multiple PCEs will communicate with each other across administrative boundaries. In such cases, domain-specific policies would be applied to 1) filter the information exchanged between peering PCEs during the discovery process (to the bare minimum in most cases, if at all allowed by the security policy) and 2) limit the content of information being passed in path computation requests and responses 🌈.
8. Path Computation Sequence of Events 🦋
This section presents a non-exhaustive list of representative scenarios ✨.
8.1. Policy-Enabled PCC, Policy-Enabled PCE 🎀
When a GMPLS LSR receives a Setup (RSVP Path) message from an upstream LSR, the LSR may decide to use a remote Path Computation Entity. The following sequence of events occurs in this case 💅:
- A PCC-PEP co-located with the LSR applies the service-specific policies to select a PCE for the service path computation, as well as to build the path computation request (that is, to select a list of policies, their variables, conditions and actions expressing constraints, diversities, objective functions and relaxation strategies appropriate for the service path computation). The policies may be:
- a) Statically configured on the PCC-PEP;
- b) Communicated to the PCC-PEP by a remote or local PCC-PDP via protocol such as SOAP, either proactively (most of the cases) or upon an explicit request by the PCC-PEP in cases when some specifics of the new service have not been covered yet by the policies so far known to the PCC-PEP).
- The input for the decision process on the PCC-PEP is the information found in the signaling message, as well as any other service-specific information such as the port ID over which the message was received, the associated VPN ID, the reference point type (UNI, E-NNI, etc.) and so forth. After the path computation request is built, it is sent directly to the PCE-PEP using the PCC-PCE Communication Protocol, e.g., [PCEP] 🧚.
- PCE-PEP validates and otherwise processes the request, applying the policies found in the request, as well as client- and domain-specific policies. The latter, again, may be either statically configured on the PCE-PEP or provided by the associated local or remote PCE-PDP via a protocol such as SOAP. The outcome of the decision process is the following information:
- a) Whether the request should be satisfied, rejected, or dismissed.
- b) The sets of sources and destinations for which paths should be locally computed.
- c) The set of constraints, diversities, optimization functions, and relaxations to be considered in each of the locally performed path computations.
- d) The address of the next-in-chain PCE.
- e) The path computation request to be sent to the next-in-chain PCE.
The PCE-PEP instructs a co-located path computation engine to perform the local path computation(s) and, if necessary, sends the path computation request to the next-in-chain PCE using a PCC-PCE Communication Protocol. Then it waits for the responses from the local path computation engine and the remote PCE, combines the resulting paths, and sends them back to the PCC-PEP using the PCC-PCE Communication Protocol. The response contains the resulting paths, as well as policies describing some additional information (for example, which of the constraints were honored, which were dismissed, and which were relaxed and in what way) 🔥.
- PCC-PEP instructs the signaling subsystem of the GMPLS LSR to encode the received path(s) into the outgoing Setup message(s) 💖.
8.2. Policy-Ignorant PCC, Policy-Enabled PCE 🦋
okay bestie, this one is basically the last example but flipped 🙃 The PCC is policy ignorant, so the user- and service-specific policies should be applied at the PCE instead. 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-located Path Computation Entity. Here's how it goes down ✨
- The PCC builds a PCE request using info from the signaling/provisioning message, plus other service-specific stuff like the port ID the message came in on, the associated VPN ID, the reference point type (UNI, E-NNI, etc.), and so forth. All of that gets encoded in the request as policy variables. Once the request is built, it's sent straight to the PCE-PEP using a PCC-PCE Communication Protocol 📨
- PCE-PEP validates and otherwise processes the request 🧠 It interprets the policy variables and applies user-, service-, client-, and domain-specific policies to build the actual path computation request. The policies, again, may be either statically configured on the PCE-PEP or provided by the associated local or remote PCE-PDP via a protocol such as SOAP. The outcome of the decision process is:
- a) Whether the request should be satisfied, rejected, or dismissed.
- b) The sets of sources and destinations for which paths should be locally computed.
- c) The set of constraints, diversities, optimization functions, and relaxations to be considered in each of the locally performed path computations.
- d) The address of the next-in-chain PCE.
- e) The path computation request to be sent to the next-in-chain PCE.
- The PCE-PEP instructs a co-located path computation engine to perform the local path computation(s) and, if necessary, sends the path computation request to the next-in-chain PCE using the PCC-PCE Communication Protocol. Then it waits for the responses from the local path computation engine and the remote PCE, combines the resulting paths, and sends them back to the PCC-PEP using the PCC-PCE Communication Protocol. The response contains the resulting paths as well as policies describing some additional information (for example, which of the constraints were honored, which were dismissed, and which were relaxed and in what way) this is the part where everything comes together 💖
- PCC-PEP instructs the signaling sub-system of the GMPLS LSR to encode the received path(s) into the outgoing Setup message(s) 🎀
9. Introduction of New Constraints ✨
ngl this is one of my favourite parts 😭 The whole point of the policy-enabled path computation framework is that you can introduce new constraints with minimal impact. Only the components and mechanisms that are going to use a new constraint need to be updated to support it. The stuff that won't use the new constraint must not need any change in order for the new constraint to be utilized. For example, the PCE communication protocols must not require any changes to support new constraints. Likewise, PCCs and PCEs that won't process new constraints must not require any modification 🫶
Let's say a PCE has been upgraded with software that supports an optical physical impairment constraint, like Polarization Mode Dispersion (PMD), which wasn't supported in the domain before. In this case, one or more new policies get installed in the PCE Policy Repository (associated with the PCE). Those policies define the constraint (the rules that determine application criteria, the set of policy variables, conditions, actions, etc.) and its relaxation strategy (or strategies). The new policies are also propagated into other PCE Policy Repositories within the domain via discovery and synchronization protocols or via local configuration. PCE-PDPs and PCC-PDPs then retrieve the corresponding policies from the repository (or repositories). From then on, PCC-PDPs instruct associated PCC-PEPs to add the new policy information into path computation requests for services with certain parameters (for example, for services provisioned in the optical channel (OCh) layer) the new constraint just slides right in 🌈
It's important to note that the policy-enabled path computation model naturally solves the PCE capability discovery issues 👑 Suppose a PCE working in a single PCE Policy Repository configuration starts to support a new constraint. Once a corresponding policy is installed in the repository, it automatically becomes available for all repository users, that is, PCCs. In the multi-repository case, some policy synchronization must be provided; however, this problem is one of the management plane, which is already solved 🧚
10. Security Considerations 🙈
⚠️ bestie, this section is serious, so read it carefully. It is not a drill 💀
This document adds to the policy security considerations mentioned in [RFC4655]. In particular, it is now necessary to consider the security issues related to policy information maintained in PCE Policy Repositories and to policy-related transactions. The most notable issues, some of which are also listed in [RFC4655], are:
- Unauthorized access to the PCE Policy Repositories;
- Interception of policy information when it is retrieved from the repositories and/or transported from PDPs to PEPs;
- Interception of policy-related information in path computation requests and responses;
- Impersonation of user and client identities;
- Falsification of policy information and/or PCE capabilities;
- Denial-of-service attacks on policy-related communication mechanisms.
As with [RFC4655], it is expected that PCE solutions will address the PCE aspects of these issues in detail 🔒
11. Acknowledgments 🫶
Adrian Farrel contributed significantly to this document 👏 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 der Merwe for providing insights and examples regarding PCE policy applications 💜
12. References 📚
12.1. Normative References
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
for Policy-based Admission Control", RFC 2753, January
2000.
[RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen,
"Policy Core Information Model -- Version 1
Specification", RFC 3060, February 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM)
Extensions", RFC 3460, January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B.
Moore, "Policy Quality of Service (QoS) Information
Model", RFC 3644, November 2003.
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-
Autonomous System (AS) Traffic Engineering (TE)
Requirements", RFC 4216, November 2005.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
[RFC4927] Le Roux, J.-L., Ed., "Path Computation Element
Communication Protocol (PCECP) Specific Requirements for
Inter-Area MPLS and GMPLS Traffic Engineering", RFC 4927,
June 2007.12.2. Informative References
[DMTF] Common Information Model (CIM) Schema, version 2.x.
Distributed Management Task Force, Inc. The components of
the CIM v2.x schema are available via links on the
following DMTF web page:
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.
[PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", Work in
Progress, November 2008.
[RFC2748] Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan,
R., and A. Sastry, "The COPS (Common Open Policy Service)
Protocol", RFC 2748, January 2000.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
RFC 3080, March 2001.
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
J., and S. Waldbusser, "Terminology for Policy-Based
Management", RFC 3198, November 2001.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September
2003.
[RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS
Requirements for the Path Computation Element
Communication Protocol (PCECP)", RFC 5376, November 2008.
[W3CSOAP] Hadley, M., Mendelsohn, N., Moreau, J., Nielsen, H., and
Gudgin, M., "SOAP Version 1.2 Part 1: Messaging
Framework", W3C REC REC-soap12-part1-20030624, June 2003.Authors' Addresses 🌸
Igor Bryskin
ADVA Optical
7926 Jones Branch Drive
Suite 615
McLean, VA 22102
EMail: ibryskin@advaoptical.com
Dimitri Papadimitriou
Alcatel
Fr. Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be
Lou Berger
LabN Consulting, LLC
Phone: +1 301 468 9228
EMail: lberger@labn.net
Jerry Ash
AT&T
EMail: gash5107@yahoo.com📦 where this page comes from
- ietf: rfc5394 2008-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms