--- 1/draft-ietf-pce-policy-enabled-path-comp-03.txt 2008-10-31 18:12:07.000000000 +0100 +++ 2/draft-ietf-pce-policy-enabled-path-comp-04.txt 2008-10-31 18:12:07.000000000 +0100 @@ -1,20 +1,20 @@ Internet Draft Igor Bryskin (Adva Optical) Category: Informational Dimitri Papadimitriou (Alcatel) -Expiration Date: April 31, 2008 Lou Berger (LabN Consulting) +Expiration Date: April 31, 2009 Lou Berger (LabN Consulting) Jerry Ash (AT&T) - October 31, 2007 + October 31, 2008 Policy-Enabled Path Computation Framework - draft-ietf-pce-policy-enabled-path-comp-03.txt + draft-ietf-pce-policy-enabled-path-comp-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -25,101 +25,102 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html - This Internet-Draft will expire on April 31, 2008. + This Internet-Draft will expire on April 31, 2009. Copyright Notice - Copyright (C) The IETF Trust (2007). + Copyright (C) The IETF Trust (2008). Abstract The Path Computation Element (PCE) Architecture introduces the concept of policy in the context of path computation. This document provides additional details on policy within the PCE Architecture and also provides context for the support of PCE Policy. This document introduces the use of the Policy Core Information Model (PCIM) as a framework for supporting path computation policy. This document also provides representative scenarios for the support of PCE Policy. -Contents +Table of Contents 1 Introduction .............................................. 3 1.1 Terminology ............................................... 4 2 Background ................................................ 4 2.1 Motivation ................................................ 5 - 2.2 Representative Policy Scenarios ........................... 7 - 2.2.1 Scenario: Policy Configured Paths ......................... 7 - 2.2.2 Scenario: Provider Selection Policy ....................... 10 - 2.2.3 Scenario: Policy Based Constraints ........................ 11 - 2.2.4 Scenario: Advanced Load Balancing (ALB) Example .......... 13 - 3 Requirements .............................................. 14 - 4 Path Computation Policy Information Model (PCPIM) ......... 16 - 5 Policy-Enabled Path Computation Framework Components ...... 18 - 6 Policy Component Configurations ........................... 19 - 6.1 PCC-PCE Configurations .................................... 19 - 6.2 Policy Repositories ....................................... 21 - 6.3 Cooperating PCE Configurations ............................ 23 - 6.4 Policy Configuration Management ........................... 24 - 7 Inter-Component Communication ............................. 24 - 7.1 Policy Communication ..................................... 24 - 7.2 PCE Discovery Policy Considerations ....................... 26 - 8 Path Computation Sequence of Events ....................... 27 - 8.1 Policy-enabled PCC, Policy-enabled PCE .................... 27 - 8.2 Policy-ignorant PCC, Policy-enabled PCE ................... 28 - 9 Introduction of New Constraints ........................... 30 -10 Security Considerations ................................... 30 -11 Acknowledgments ........................................... 31 -12 IANA Considerations ....................................... 31 -13 References ................................................ 31 -13.1 Normative References ...................................... 31 -13.2 Informative References .................................... 32 -14 Authors' Addresses ........................................ 33 - Full Copyright Statement .................................. 33 - Intellectual Property ..................................... 34 + 2.2 Policy Attributes ......................................... 7 + 2.3 Representative Policy Scenarios ........................... 8 + 2.3.1 Scenario: Policy Configured Paths ......................... 8 + 2.3.2 Scenario: Provider Selection Policy ....................... 11 + 2.3.3 Scenario: Policy Based Constraints ........................ 12 + 2.3.4 Scenario: Advanced Load Balancing (ALB) Example .......... 15 + 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 ....................................... 23 + 6.3 Cooperating PCE Configurations ............................ 25 + 6.4 Policy Configuration Management ........................... 26 + 7 Inter-Component Communication ............................. 26 + 7.1 Policy Communication ..................................... 26 + 7.2 PCE Discovery Policy Considerations ....................... 28 + 8 Path Computation Sequence of Events ....................... 29 + 8.1 Policy-enabled PCC, Policy-enabled PCE .................... 29 + 8.2 Policy-ignorant PCC, Policy-enabled PCE ................... 30 + 9 Introduction of New Constraints ........................... 32 +10 Security Considerations ................................... 32 +11 Acknowledgments ........................................... 33 +12 IANA Considerations ....................................... 33 +13 References ................................................ 33 +13.1 Normative References ...................................... 33 +13.2 Informative References .................................... 34 +14 Authors' Addresses ........................................ 35 +15 Full Copyright Statement .................................. 36 +16 Intellectual Property ..................................... 36 1. Introduction The Path Computation Element (PCE) Architecture is introduced in [RFC4655]. This document describes the impact of policy-based - decision making when incorporated into the PCE - - architecture and provides additional details on, and context for - applying policy within the PCE Architecture. + decision making when incorporated into the PCE architecture and + provides additional details on, and context for applying policy + within the PCE Architecture. Policy-based Management (PBM), see [RFC3198], is a network management approach that enables a network to automatically perform actions in response to network events or conditions based on pre-established rules, also denoted as policies, from a network administrator. PBM enables network administrators to operate in a high-level manner through rule-based strategy (policies can be defined as a set of rules and actions); the latter are translated automatically (i.e., dynamically, without human interference) into individual device configuration directives, aimed at controlling a network as a whole. Two IETF Working Groups have considered policy networking in the past: The Resource Allocation Protocol (RAP) working group and the Policy Framework working group. A framework for policy-based admission control [RFC2753] was defined and a protocol for use between Policy Enforcement Points (PEP) and Policy Decision Points (PDP) was specified: Common Open Policy Service (COPS) [RFC2748]. This document uses the terms PEP and PDP to refer to the functions defined in the COPS context. This document makes no assumptions nor requires that the actual COPS protocol be - used. + used. Any suitable policy exchange protocol (for example, SOAP + [W3CSOAP]) may be substituted. The IETF has also produced a general framework for representing, managing, sharing, and reusing policies in a vendor-independent, interoperable, and scalable manner. It has also defined an extensible information model for representing policies, called the Policy Core Information Model (PCIM) [RFC3060]; and an extension to this model to address the need for QoS management, called the QoS Policy Information Model (QPIM) [RFC3644]. However, additional mechanisms are needed in order to specify policies related to the path computation logic as well as its control. @@ -134,36 +135,39 @@ enabled path computation. Sections 6, 7 and 8 provide details on possible component configurations, communication and events. Section 10 discusses the ability to introduce new constraints with minimal impact. It should be noted that this document, in Section 4, only introduces PCIM, specific PCIM definitions to support path computation will be discussed in a separate document. 1.1. Terminology The reader is assumed to be familiar with the following terms: + BEEP: Blocks Extensible Exchange Protocol, see [RFC3080]. CIM: Common Information Model, see [DMTF]. COPS: Common Open Policy Service, see [RFC2748]. - COPS-PR: COPS Usage for Policy Provisioning, see [RFC3084]. CSPF: Constraint-based Shortest Path First, see [RFC3630]. LSP: Label Switched Path, see [RFC3031]. LSR: Label Switching Router, see [RFC3031]. PBM: Policy-based Management, see [RFC3198]. PC: Path Computation. PCC: Path Computation Client, see [RFC4655]. PCCIM: Path Computation Core Information Model. PCE: Path Computation Element, see [RFC4655]. + PCEP: Path Computation Element Communication Protocol, + see [PCEP]. PCIM: Policy Core Information Model, see [RFC3060]. PDP: Policy Decision Points, see [RFC2753]. PEP: Policy Enforcement Points, see [RFC2753]. QPIM: QoS Policy Information Model, see [RFC3644]. SLA: Service Level Agreement. + 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]. 2. Background This section provides some general background on the use of policies within the PCE architecture. It presents the rationale behind the use of policies in the TE path computation process, as well as @@ -252,52 +256,102 @@ - Different elements such as conditions, actions, variables, etc., may be re-used by multiple constraints, diversities, and optimizations. - PCCs and PCEs need to handle other (that is, not request- specific) policies. Path computation-related policies of all types can be placed within the same policy repositories, can be managed by the same policy management tools, and can be interpreted using the same mechanisms. Also policies need to be supported by PCCs and PCEs independent of the peculiarities of a - specific PCC-PCE communication protocol. Thus, introducing a new - (request-specific) type of policies describing constraints and - other elements of a path computation request will be a natural - and relatively inexpensive addition to the policy-enabled path - computation architecture. + specific PCC-PCE communication protocol, see [PCEP]. Thus, + introducing a new (request-specific) type of policies describing + constraints and other elements of a path computation request + will be a natural and relatively inexpensive addition to the + policy-enabled path computation architecture. -2.2. Representative Policy Scenarios +2.2. Policy Attributes + + This section provides a summary listing of the policy attributes that + may be included in the policy exchanges described in the scenarios + that follow. This list is provided for guidance and is not intended + to be exclusive. Implementation of this framework might include + additional policy attributes not listed here. + + Identities + + - LSP head-end + - LSP destination + - PCC + - PCE + + LSP identifiers + + - LSP head-end + - LSP destination + - Tunnel identifier + - Extended tunnel identifier + - LSP ID + - Tunnel name + + Requested LSP qualities + + - bandwidth + - traffic parameters + - LSP attributes + - explicit path inclusions + - explicit path exclusions + - link protection level + - setup priority + - holding priority + - preexisting LSP route + + Requested path computation behavior + + - objective function + - other LSPs to be considered + + Additional policy information + + - Transparent policy information as received in RSVP-TE + +2.3. Representative Policy Scenarios This section provides example scenarios of how policies may be applied using the PCE policy framework within the PCE architecture context. Actual networks may deploy one of the scenarios discussed, some combination of the presented scenarios, or other scenarios (not discussed). This section should not be viewed as limiting other applications of policies within the PCE architecture. -2.2.1. Scenario: Policy Configured Paths +2.3.1. Scenario: Policy Configured Paths A very simple usage scenario for PCE policy would be to use PCE to centrally administer configured paths. Configured paths are composed of strict and loose hops in the form of Explicit Route Objects (EROs), see [RFC3209], and are used by one or more LSPs. Typically, such paths are configured at the LSP ingress. In the context of policy-enabled path computation, an alternate approach is possible. In particular, service-specific policies can be installed that will provide configured path(s) for a specific service request. The request may be identified based on service parameters such as end- points, requested QoS, or even a token that identifies the initiator of a service request. The configured path(s) would then be used as input to the path computation process, which would return explicit routes by expanding of all specified loose hops. + Example of policy: + if(service_destination matches 10.132.12.0/24) + use path: 10.125.13.1=>10.125.15.1=>10.132.12.1 + else + compute path dynamically ---------------------- | ----- | | | TED |<-+------------> | ----- | TED synchronization | | | mechanism (e.g., routing protocol) | | | | v | | ------ ----- | Inter-PCE Request/Response | |Policy|<-->| PCE |<.+...........> (when present) | ------ ----- | @@ -365,24 +419,24 @@ multiple (more than one) cooperating PCEs (see Figures 2 and 3). For example, consider the case when there is 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 not be possible (or desirable) to configure entire explicit path(s) on a single PCE. However, it is possible to configure explicit path(s) for each area of the TE visibility and each responsible PCE. One by one, the PCEs would then map an incoming signaling request to appropriate configured path(s). Note that to make such a scenario work it would likely be necessary to start and finish the configured paths on TE - domain boundary nodes. Clearly, consistent PC Policy Repositories are - also critical in this example. + domain boundary nodes. Clearly, consistent PCE Policy Repositories + are also critical in this example. -2.2.2. Scenario: Provider Selection Policy +2.3.2. Scenario: Provider Selection Policy A potentially more interesting scenario is applying PC policies in multi-provider topologies. There are numerous interesting policy applications in such topologies. A rudimentary example is simple access control, that is, deciding which PCCs are permitted to request inter-domain path computation. A more complicated example is applying policy to determine which domain or network provider will be used to support a particular PCE request. Consider the topology presented in Figure 4. In this example @@ -429,21 +483,27 @@ a particular transit domain and get a particular (better or worse) level of service. For example, a PCE in the source domain may use user and request-specific policies to determine the level of service 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 transit domain may use request-specific policies to determine if a request is from a direct customer or another provider, and then use domain-specific policies to identify how the request should be processed. -2.2.3. Scenario: Policy Based Constraints + Example of policy: + if(path computation request issued by a PCC within Source Domain) + route the path through Transit Domain A + else + route the path through Transit Domain B + +2.3.3. Scenario: Policy Based Constraints Another usage scenario is the use of policy to provide constraints in a PCE request. Consider an LSR with a policy enabled PCC, as shown in Figure 1, which receives a service request via signaling, including over a NNI or UNI reference point, or receives a configuration request over a management interface to establish a service. In either case the path(s) needed to support the service are not explicitly specified in the message/request, and hence path computation is needed. @@ -457,57 +517,92 @@ information it knows about the user and service, such as the contents of the received message, port ID over which message was received, associated VPN ID, signaling/reference point type, request time, etc. Once the constraints and other parameters of the required path computation are determined, the PCC generates a path computation request which includes the request-specific policies that describe the determined set of constraints, optimizations, and other parameters that indicate how the request is to be considered in the path computation process. + Example of policy: + if(LSP belongs to a WDM layer network) + Compute the path with wavelength continuity constraint with the + maximum OSNR at the path end optimization + else if(LSP belongs to a connection oriented Ethernet layer network) + Compute the path with minimum end-to-end delay + else + Compute the shortest path + The PCC may also apply server-specific policies in order to select which PCE to use from the set of known (i.e., discovered or configured) PCEs. The PCC may also use server-specific policies to form the request to match the PCE's capabilities so that the request will not be rejected and has a higher likelihood of being satisfied in an efficient way. An example of a request modification as the result of a server-specific policy is removing a constraint not supported by the PCE. Once the policy processing is completed at the PCC, and the path computation request resulting from the original service request is updated by the policy processing, the request is sent to the PCE. + Example of policy: + if(LSP belongs to a WDM layer network) + Identify a PCE supporting wavelength continuity and optical + impairment constraints; send a request to such PCE, requesting + path computation with the following constraints: + a) wavelength continuity; + b) maximum PMD at the path end. + if(the path computation fails) + remove the maximum PMD constraint and try the computation again + The PCE that receives the request validates and otherwise processes the request, applying the policies found in the request as well as any policies that are available at the PCE, e.g., client and domain- specific polices. As a result of the policy processing, the PCE may - decide to reject the request. It also may decide to respond with one - or several pre-computed paths if user or client specific polices - instruct the PCE to do so. If the PCE decides to satisfy the request - by performing a path computation, it determines if it needs the - cooperation of other PCEs and defines parameters for path - computations to be performed locally and remotely. After that, the - PCE instructs a co-located path computation engine to perform the - local path computation(s) and, if necessary, sends path computation - requests to one or more other PCEs. It then waits for the responses - from the local path computation engine and, when used, the remote - PCE. It then combines the resulting paths and sends the result back - to the requesting PCC. The response may indicate policies describing - the resulting paths, their characteristics (summary cost, expected - end-to-end delay, etc.). as well as additional information related to - the request, e.g., which constraints were honored, which were - dismissed, and which were relaxed and in what way. + 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 + It The PCE also may decide to respond with one or several pre- + computed paths if user or client specific polices instruct the PCE to + do so. If the PCE decides to satisfy the request by performing a path + computation, it determines if it needs the cooperation of other PCEs + and defines parameters for path computations to be performed locally + and remotely. After that, the PCE instructs a co-located path + computation engine to perform the local path computation(s) and, if + necessary, sends path computation requests to one or more other PCEs. + It then waits for the responses from the local path computation + engine and, when used, the remote PCE. It then combines the resulting + paths and sends the result back to the requesting PCC. The response + may indicate policies describing the resulting paths, their + characteristics (summary cost, expected end-to-end delay, etc.). as + well as additional information related to the request, e.g., which + constraints were honored, which were dismissed, and which were + relaxed and in what way. + + Example of policy: + if(the path destination belongs to domain A) + Instruct local path computation engine to perform the path + computation; + else + Identify the PCE supporting the destination domain; + Send path computation request to such PCE; + Wait for and process the response + Send the path computation response to the requesting PCC The PCC processes the response and instructs the LSR to encode the received path(s) into the outgoing signaling message(s). -2.2.4. Scenario: Advanced Load Balancing (ALB) Example +2.3.4. Scenario: Advanced Load Balancing (ALB) Example Figure 5 illustrates a problem that stems from the coupling between 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 @@ -560,20 +655,27 @@ 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, 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 The following requirements must be addressed by mechanisms and protocols that enable 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 the problem of path computation using RSVP-TE as the signaling protocol on MPLS and GMPLS LSRs. @@ -733,24 +835,24 @@ foundation for the PCPIM. Detailed description of the PCPIM will be provided in a separate documents. 5. Policy-Enabled Path Computation Framework Components The following components are defined as part of the framework to support policy-enabled path computation: - - PC Policy Repository - A database from which PC policies are available in the form of - instances of PCPIM classes. PC Policies are configured and - managed by PC Policy Management Tools; + - 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; @@ -764,40 +866,40 @@ 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 decomposed 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 later case they talk to each other via such - protocols as COPS and/or COPS-PR [RFC3084]. + protocols as SOAP [W3CSOAP] or BEEP [RFC3080]. Likewise, a PCE is logically decomposed into two parts: PCE-PEP and PCE-PDP. When present, PCE-PEP is co-located with a Path Computation Engine entity that actually provides the Path Computation Service (that is, runs path computation algorithms). PCE-PEP and PCE-PDP may be physically co-located or separated. In the later case they - communicate using such protocols as COPS and/or COPS-PR. + communicate using such protocols as SOAP and/or BEEP. PCC-PDP/PCE-PDP may be co-located with, or separated from, an - associated PC Policy Repository. In the latter case, the PDPs use + associated PCE Policy Repository. In the latter case, the PDPs use some access protocol (for example, LDAPv3 or SNMP). The task of PDPs is to retrieve policies from the repository(ies) and convey them to respective PEPs either in unsolicited way or upon the PEPs requests. A PCC-PEP may receive policy information not only from PCC-PDPs(s) but also from PCE-PEP(s) via PCC-PCE communication and/or PCE discovery protocols. Likewise, a PCE-PEP may receive policy information not only from PCE-PDPs(s) but also from PCC-PEP(s), via - PCC-PCE communication protocol. + the PCC-PCE communication protocol [PCEP]. Any given policy can be interpreted (that is, translated into a sequence of concrete device specific configuration requests) either on a PDP or on the associated PEP or partly on the PDP and partly on the PEP. Generally speaking, the task of the PCC-PEP is to select the PCE and build path computation requests applying service-specific policies provided by the PCC-PDP. The task of the PCE-PEP is to control path computations by applying request-specific policies found in the @@ -811,62 +913,62 @@ The PCE policy architecture supports policy being applied at a PCC 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, 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 choose to apply policy only at PCCs (Figure 7), some at PCEs (Figure 8), and others at both PCCs and PCEs (Figure 9). Regardless of where policy is applied it must be applied in a consistent fashion in order to achieve the intended results. - ........................ + ......................... . . - . PC Policy Management . + . PCE Policy Management . . . - ........................ + ......................... . . - --------- Policy ---------------------- - | PCC-PDP |<--------- | PC Policy Repository | - --------- ---------------------- + --------- Policy ----------------------- + | PCC-PDP |<--------- | PCE Policy Repository | + --------- ----------------------- ^ - | e.g., COPS + | e.g., SOAP v - --------- --------- + --------- PCEP --------- | PCC-PEP |<------------------------------------------->| PCE | --------- PCC-PCE Communication Protocol --------- Figure 7: Policies Applied On PCC Only Along with supporting flexibility in where policy may be applied, the PCE architecture is also flexible in terms of where specific types of policies may be applied. Also the PCE architecture allows for the application of only a subset of policy types. [RFC4655] defines 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 - PCEs, all PC policy types used in the network must be applied at + PCEs, all PCE policy types used in the network must be applied at those locations. - ........................ + ......................... . . - . PC Policy Management . + . PCE Policy Management . . . - ........................ + ......................... . . - ---------------------- Policy --------- - | PC Policy Repository | -------->| PCE-PDP | - ---------------------- --------- + ----------------------- Policy --------- + | PCE Policy Repository | -------->| PCE-PDP | + ----------------------- --------- ^ - e.g., COPS | + e.g., SOAP | v - --------- --------- + --------- PCEP --------- | PCC |<------------------------------------------->| PCE-PEP | --------- PCC-PCE Communication Protocol --------- Figure 8: Policies Applied On Only 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 it can gather in the path computation request (most likely in the form of PCPIM policy variables). The PCE is expected to understand this information and apply appropriate policies while @@ -882,148 +984,148 @@ a PCC, request and client specific policies may be applied at a PCE, while domain-specific policies may be applied at both the PCC and PCE. In the case when policy is only applied at a PCC, the PCC must apply all the types of required policies, for example user, service, server and domain-specific policies. The PCC uses the policies to construct a path computation request that appropriately represents the applied policies. The request will necessarily be limited to the set of "basic" (that is, non-policy capable) constraints explicitly defined - by the PCC-PCE communication protocol in use. + by the PCC-PCE communication protocol. 6.2. Policy Repositories Within the policy-enabled path computation framework policy - repositories may be used in a single or multiple PC policy repository - configuration: + repositories may be used in a single or multiple PCE policy + repository configuration: - o) Single PC Policy Repository + o) Single PCE Policy Repository - In this configuration there is a single PC Policy Repository shared + In this configuration there is a single PCE Policy Repository shared between PCCs and PCEs. - ........................ + ......................... . . - . PC Policy Management . + . PCE Policy Management . . . - ........................ + ......................... . . - --------- Policy a ---------------------- Policy b --------- - | PCC-PDP |<--------- | PC Policy Repository | -------->| PCE-PDP | - --------- ---------------------- --------- + --------- Policy a ----------------------- Policy b --------- + | PCC-PDP |<--------- | PCE Policy Repository | -------->| PCE-PDP | + --------- ----------------------- --------- ^ ^ - | e.g., COPS e.g., COPS | + | e.g., SOAP e.g., SOAP | v v - --------- --------- + --------- PCEP --------- | PCC-PEP |<------------------------------------------->| PCE-PEP | --------- PCC-PCE Communication Protocol --------- Figure 9: Single PCC/PCE Policy Repository - o) Multiple PC Policy Repositories + o) Multiple PCE Policy Repositories The repositories in this case may be fully or partially synchronized by some discovery/ synchronization management protocol or may be - completely independent. Note that the situation when PC Policy + completely independent. Note that the situation when PCE Policy Repository A exactly matches PC Policy Repository B, results in the - single PC Policy Repository configuration case. + single PCE Policy Repository configuration case. -------------- -------------- - | PC Policy | | PC Policy | + | PCE Policy | | PCE Policy | ---| Repository A | | Repository B |--- | -------------- -------------- | | | | Policy a Policy b | | | v v --------- --------- | PCC-PDP | | PCE-PDP | --------- --------- ^ ^ - | e.g., COPS e.g., COPS | + | e.g., SOAP e.g., SOAP | v v - --------- --------- + --------- PCEP --------- | PCC-PEP |<------------------------------------------->| PCE-PEP | --------- PCC-PCE Communication Protocol --------- Figure 10: Multiple PCE/PCC Policy Repositories 6.3. Cooperating PCE Configurations The previous section shows the relationship between PCCs and PCEs. A parallel relationship exists between cooperating PCEs, and, in fact, this relationship can be viewed as the same as the relationship between PCCs and PCEs. The one notable difference is that there will - be cases where having a shared PC Policy Repository will not be + be cases where having a shared PCE Policy Repository will not be desirable, for example, when the PCEs are managed by different entities. Note that in this case it still remains necessary for the policies 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 in order to modify the request before sending it to other cooperating PCE(s). This relationship is particularly important as the PCE Architecture allows for configuration where all PCCs are not policy-enabled. The following are example configurations. These examples do not represent an exhaustive list and other configurations are expected. o) Single Policy Repository - In this configuration there is a single PC Policy repository shared + In this configuration there is a single PCE Policy repository shared between PCEs. This configuration is likely to be useful within a single administrative domain where multiple PCEs are provided for redundancy or load distribution purposes. - ........................ + ......................... . . - . PC Policy Management . + . PCE Policy Management . . . - ........................ + ......................... . . - --------- Policy a ---------------------- Policy b --------- - | PCE-PDP |<--------- | PC Policy Repository | -------->| PCE-PDP | - --------- ---------------------- --------- + --------- Policy a ----------------------- Policy b --------- + | PCE-PDP |<--------- | PCE Policy Repository | -------->| PCE-PDP | + --------- ----------------------- --------- ^ ^ - | e.g., COPS e.g., COPS | + | e.g., SOAP e.g., SOAP | v v --------- --------- | PCE-PEP |<------------------------------------------->| PCE-PEP | --------- PCE-PCE Communication Protocol --------- Figure 11: Single PCC Policy Repository o) Multiple Policy Repositories The repositories in this case may be fully or partially synchronized by some discovery/synchronization management protocol(s) or may be completely independent. In the multi-domain case it is expected that the repositories will be distinct, providing, however. consistent policies. -------------- -------------- - | PC Policy | | PC Policy | + | PCE Policy | | PCE Policy | ---| Repository A | | Repository B |--- | -------------- -------------- | | | | Policy a Policy b | | | v v --------- --------- | PCE-PDP | | PCE-PDP | --------- --------- ^ ^ - | e.g., COPS e.g., COPS | + | e.g., SOAP e.g., SOAP | v v - --------- --------- + --------- PCEP --------- | PCE-PEP |<------------------------------------------->| PCE-PEP | --------- PCC-PCE Communication Protocol --------- Figure 12: Multiple PCC Policy Repositories 6.4. Policy Configuration Management The management of path computation policy information used by PCCs and PCEs is largely out of scope of the described framework. The framework assumes that such information is installed, removed and @@ -1063,25 +1165,25 @@ 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. This document makes no - assumptions as to what exact protocol is used to support this - communication. This document does assume that the semantics of a - path computation request are sufficiently abstract and general, and - support both PCE-PCC and PCE-PCE communication. + 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. This document 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: o One or more source addresses; o One or more destination addresses; o Computation type (P2P, P2MP, MP2P, etc.); o Number of required paths; o Zero or more policy descriptors in the following format: , , , ,..., @@ -1099,25 +1201,25 @@ 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. 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)). + 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 allows for PCCs and PCEs to automatically discover a set of PCEs (including information required for the PCE selection). It also allows for PCCs and PCEs to dynamically detect new PCEs or any modification of PCEs status. Policy can be applied in two ways in this context: 1. Restricting the scope of information distribution for the @@ -1160,38 +1262,38 @@ 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 COPS either pro-actively (most of the + via protocol such as SOAP either pro-actively (most of the cases) or upon an explicit request by the PCC-PEP in case when 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 port ID over which the message was received, 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. + 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 polices. 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 COPS. The outcome of the + 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 locally performed @@ -1233,21 +1335,21 @@ request in the form of policy variables. After the request is built it is sent directly to the PCE-PEP using a PCC-PCE Communication Protocol. - PCE-PEP validates and otherwise processes the request interpreting the policy variables found in the request and applying user, service- and also client- and domain- specific polices 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 COPS. The outcome of the decision process is + 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 locally performed @@ -1282,87 +1384,85 @@ will not use the new constraint, must not require 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, PCC and PCEs that will not process new constraints must not require any modification. Consider the case where a PCE has been upgraded with software supporting optical physical impairment constraint, such as Polarization Mode Dispersion (PMD), that previously was not supported in the domain. In this case, one or more new policies will be - installed in the PC Policy Repository (associated with the PCE) + installed in the PCE Policy Repository (associated with the PCE) defining the constraint (rules that determine application criteria, set of policy variables, conditions, actions, etc.) and its relaxation strategy(ies). The new policies will be also propagated - into other PC Policy Repositories within the domain via discovery and - synchronization protocols or via local configuration. PCE-PDPs and - PCC-PDPs will then retrieve the corresponding policies from the + into other PCE Policy Repositories within the domain via discovery + and synchronization protocols or via local configuration. PCE-PDPs + and PCC-PDPs will then retrieve the corresponding policies from the repository(ies). From then on PCC-PDPs will 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 OCh layer). It is important to note that policy-enabled path computation model naturally solves the PCE capability discovery issues. Suppose a PCE - working in a single PC Policy Repository configuration starts to + working in a single PCE Policy Repository configuration starts to support a new constraint. Once a corresponding policy installed in 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 solved already. 10. Security Considerations 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 PC Policy + issues related to policy information maintained in PCE Policy Repositories and policy related transactions. The most notable issues, some of which are also listed in [RFC4655], are: - - Unauthorized access to the PC Policy Repositories; + - Unauthorized access to the PCE Policy Repositories; - Interception of policy information when it is retrieved from the repositories and/or transported from PDPs to PEPs; - Interception of policy related information in path computation requests and responses; o Impersonation of user and client identities; o Falsification of policy information and/or PCE capabilities; o 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 - We would like to thank Bela Berde for fruitful discussions on PBM and - Policy-driven path computation, Adrian Farrel for his detailed input. - We would also like to thank Kobus Van der Merwe for providing - insights and examples regarding PCE policy applications. + 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. IANA Considerations None. 13. References 13.1. Normative References [RFC2753] R. Yavatkar, D. Pendarakis, R. Guerin, A Framework for Policy Based Admission Control, RFC 2753, January 2000. - [RFC2748] D. Durham, et al., The COPS (Common Open Policy Service) - protocol, RFC 2748, IETF, January 2000. - [RFC3060] B. Moore, et al., Policy Core Information Model -- Version 1 Specification, RFC 3060, February 2001. [RFC3209] Awduche, D., et al., "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., et al., "Generalized Multi-Protocol Label @@ -1385,44 +1485,54 @@ MPLS and GMPLS Traffic Engineering", June 2007. 13.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 + [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, J., Le Roux, J., Eds., "Path Computation Element + (PCE) Communication Protocol (PCEP)", Work in Progress, + draft-ietf-pce-pcep-16.txt, October 14, 2008. + + [RFC2748] D. Durham, et al., The COPS (Common Open Policy Service) + protocol, RFC 2748, IETF, January 2000. + [RFC3031] Rosen, E,. Viswanathan, V. Callon, R., "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. - [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, - K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A. - Smith, "COPS Usage for Policy Provisioning (COPS-PR)", - RFC 3084, February 2001. + [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol + Core", RFC 3080, March 2001. [RFC3198] Westerinen, A., et al., "Terminology for Policy-Based Management", RFC 3198, November 2001. [RFC3630] Katz, D., Kompella, K., Yeung., D., "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [INTERAS-PCEP] Bitar, N., Zhang, R., Kumaki, K., Eds., "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", February 2006. + [W3CSOAP] Hadley, M., Mendelsohn, N., Moreau, J., Nielsen, H., + and Gudgin, M., "SOAP Version 1.2 Part 1: Messaging + Framework", W3C REC REC-soap12-part1-20030624, June + 2003. + 14. Authors' Addresses Igor Bryskin ADVA Optical 7926 Jones Branch Drive Suite 615 McLean, VA 22102 Email: ibryskin@advaoptical.com Dimitri Papadimitriou (Alcatel) @@ -1433,56 +1543,56 @@ Lou Berger LabN Consulting, LLC Phone: +1 301 468 9228 Email: lberger@labn.net Jerry Ash AT&T Email: gash5107@yahoo.com -Full Copyright Statement +15. Full Copyright Statement - Copyright (C) The IETF Trust (2007). + Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions 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 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. -Intellectual Property +16. Intellectual Property The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - 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 - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. + Intellectual Property Rights or other rights that might be claimed + to pertain to the implementation or use of the technology + described in 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 made any independent effort to identify any + such rights. Information on the procedures with respect to rights + in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. + attempt made to obtain a general license or permission for the use + of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository + at http://www.ietf.org/ipr. - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. + The IETF invites any interested party to bring to its attention + any copyrights, patents or patent applications, or other + proprietary rights that may cover technology that may be required + to implement this standard. Please address the information to the + IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). -Generated on: Fri Oct 26 16:05:21 EDT 2007 +Generated on: Tue Oct 28 19:31:33 EDT 2008