--- 1/draft-ietf-pce-policy-enabled-path-comp-02.txt 2007-11-02 00:12:06.000000000 +0100 +++ 2/draft-ietf-pce-policy-enabled-path-comp-03.txt 2007-11-02 00:12:06.000000000 +0100 @@ -1,20 +1,20 @@ Internet Draft Igor Bryskin (Adva Optical) Category: Informational Dimitri Papadimitriou (Alcatel) -Expiration Date: January 6, 2008 Lou Berger (LabN Consulting) +Expiration Date: April 31, 2008 Lou Berger (LabN Consulting) Jerry Ash (AT&T) - July 6, 2007 + October 31, 2007 Policy-Enabled Path Computation Framework - draft-ietf-pce-policy-enabled-path-comp-02.txt + draft-ietf-pce-policy-enabled-path-comp-03.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,21 +25,21 @@ 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 January 6, 2008. + This Internet-Draft will expire on April 31, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). 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 @@ -71,58 +71,61 @@ 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 -15 Full Copyright Statement .................................. 33 -16 Intellectual Property ..................................... 34 + Full Copyright Statement .................................. 33 + Intellectual Property ..................................... 34 1. Introduction The Path Computation Element (PCE) Architecture is introduced in - [RFC4655]. This document describes the impact of policy on the PCE - architecture and provides additional details on, and context for, - policy within the PCE Architecture. + [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. 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 - direction, i.e., policies, from a network administrator. PBM enables - network administrators to operate in a high-level manner through - rule-based policies; the latter are translated automatically 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 working - group and the Policy Framework working group. + 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. 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 + 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. In Section 2, this document presents policy related background and scenarios to provide a context for this work. Section 3 provides requirements that must be addressed by mechanisms and protocols that enable policy-based control over path computation requests and decisions. Section 4 introduces PCIM as a core component in a @@ -148,63 +151,68 @@ PC: Path Computation. PCC: Path Computation Client, see [RFC4655]. PCCIM: Path Computation Core Information Model. PCE: Path Computation Element, see [RFC4655]. PCIM: Policy Core Information Model, see [RFC3060]. PDP: Policy Decision Points, see [RFC2753]. PEP: Policy Enforcement Points, see [RFC2753]. QPIM: QoS Policy Information Model, see [RFC3644]. SLA: Service Level Agreement. TE: Traffic Engineering, see [RFC3209] and [RFC3473]. + 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 policy + This section provides some general background on the use of policies within the PCE architecture. It presents the rationale behind the use - of policy in path computation, as well as representative policy usage - scenarios. This information is intended to provide context for the - presented PCE policy framework. This section does not attempt to - present an exhaustive list of rationales or scenarios. + of policies in the TE path computation process, as well as + representative policies usage scenarios. This information is intended + to provide context for the presented PCE policy framework. This + section does not attempt to present an exhaustive list of rationales + or scenarios. 2.1. Motivation - The PCE architecture is introduced in [RFC4655]. It includes policy - as an integral part of the PCE architecture. This section presents - some of the rationale for this inclusion. + The PCE architecture as introduced in [RFC4655] includes policy as an + integral part of the PCE architecture. This section presents some of + the rationale for this inclusion. Network operators require a certain level of flexibility to shape the TE path computation process, so that the process can be aligned with their business and operational needs. Many aspects of the path computation may be governed by policies. For example, a PCC may use - policies configured by the operator to decide which optimizations, - constraints, diversities and their relaxation strategies to request - while computing path(s) for a particular service. Depending on SLAs, - TE and cost/performance ratio goals, path computation requests may be - built differently for different services. Service A, for instance, - may require two SRLG-disjoint paths for building end-to-end recovery - scheme, while for service B link-disjoint paths may be sufficient. - Service A may need paths with minimal end-to-end delay, while service - B may be looking for shortest (minimal-cost) paths. Different - constraint relaxation strategies may be applied while computing paths - for service A and for service B, and so forth. + policies configured by the operator to decide which optimization + criteria, constraints, diversities and their relaxation strategies to + request while computing path(s) for a particular service. Depending + on SLAs, TE and cost/performance ratio goals, path computation + requests may be issued differently for different services. A given + Service A, for instance, may require two SRLG-disjoint paths for + building end-to-end recovery scheme, while for a Service B link- + disjoint paths may be sufficient. Service A may need paths with + minimal end-to-end delay, while Service B may be looking for shortest + (minimal-cost) paths. Different constraint relaxation strategies may + be applied while computing paths for Service A and for Service B, and + so forth. So based on distinct service requirements distinct or + similar policies may be adopted when issuing/handling path + computation requests. - Likewise, a PCE may apply policies to decide which algorithm or - algorithms to use while performing path computations requested from a - particular PCC or for a particular domain, see [RFC4927]; whether to - seek the cooperation of other PCEs to satisfy a particular request or - to handle a request on its own (possibly responding with non explicit + Likewise, a PCE may apply policies to decide which algorithm(s) to + use while performing path computations requested from a particular + PCC or for a particular domain, see [RFC4927]; whether to seek the + cooperation of other PCEs to satisfy a particular request or to + handle a request on its own (possibly responding with non explicit paths); or how the request should be modified before being sent to other member(s) of a group of cooperating PCEs, etc. - Additional motivation for supporting policy within the PCE + Additional motivation for supporting policies within the PCE architecture can be described as follows. Historically, a path computation entity was an intrinsic part of an LSR's control plane and always co-located with the LSR's signaling and routing subsystems. This approach allowed for unlimited flexibility in providing various path computation enhancements, such as: adding new types of constraints, diversities and their relaxation strategies, adopting new objective functions and optimization criteria, etc. All that had to be done to support an enhancement was to upgrade the control plane software of a particular LSR (and no other LSRs or any other network elements). @@ -216,24 +224,23 @@ need to be standardized, all PCCs may need to be upgraded with new software, and new interoperability problems may need to be resolved, etc. Within the context of the PCE architecture, it is therefore highly desirable to find a way to introduce new path computation capabilities without requiring modifying either the discovery/communication protocols or the PCC software. One way to achieve this objective is to consider path selection constraints, their relaxations and objective functions, as path computation - request-specific policies. Furthermore, such policies may, on the one - hand, be configured and managed by an operator as any other policies - or, on the other hand, may be interpreted in real time by PCCs and - PCEs. + request-specific policies. Furthermore, such policies may be + configured and managed by a network operator as any other policies + and may be interpreted in real time by PCCs and PCEs. There are a number of advantages and useful by-products of such an approach: - New path computation capabilities may 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 to be updated. @@ -253,42 +260,42 @@ 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. 2.2. Representative Policy Scenarios - This section provides example scenarios of how policy may be applied - using the PCE policy framework within the PCE architecture context. - Actual networks may use one of the scenarios discussed, some - combination of the presented scenarios, or other scenarios (not + 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 policy within the PCE architecture. + applications of policies within the PCE architecture. 2.2.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 PCE computation process, which would return explicit + input to the path computation process, which would return explicit routes by expanding of all specified loose hops. ---------------------- | ----- | | | TED |<-+------------> | ----- | TED synchronization | | | mechanism (e.g., routing protocol) | | | | v | | ------ ----- | Inter-PCE Request/Response @@ -347,40 +354,41 @@ | Request/ | Response v Service ---------- Signaling ---------- Signaling ---------- Request| Head-End | Protocol | Adjacent | Protocol | Adjacent | ---->| Node |<---------->| Node |<---------->| Node | ---------- ---------- ---------- Figure 3. Multiple PCE Path Computation with Inter-PCE Communication - Policy-configured paths may also be used in multiple PCE environments - (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. + Policy-configured paths may also be used in environments with + 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. 2.2.2. Scenario: Provider Selection Policy - A potentially more interesting usage scenario is applying PC policies - in multi-domain multi-provider topologies. There are numerous - interesting policy applications in such topologies. A rudimentary - example is simple access control, that is, deciding which clients are - permitted to request inter-domain path computation. + 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 there are multiple transit domains available to provide a path from a source domain to a destination domain. Furthermore, each transit domain may have one or more options for reaching a particular domain. Each domain will need to select which of the multiple available paths will be used to satisfy a particular PCE request. @@ -434,33 +442,34 @@ 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. In this case, the PCC may apply user or service-specific policies to decide how the path selection process should be constrained, that is, - which constraints, diversities, optimizations and relaxations should - be applied in order for the service LSP(s) to have a likelihood to be - successfully established and provide necessary QoS and resilience - against network failures. When deciding on the set of constraints the - PCC uses as an input all information it knows about the user and - service, such as the contents of the received message, port ID over - 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. + which constraints, diversities, optimization criterion and constraint + relaxation strategies should be applied in order for the service + LSP(s) to have a likelihood to be successfully established and + provide necessary QoS and resilience against network failures. When + deciding on the set of constraints the PCC uses as an input all + information it knows about the user and service, such as the contents + of the received message, port ID over 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. 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 @@ -944,21 +953,21 @@ 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 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 requestor- + 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 @@ -1101,22 +1110,22 @@ (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 information. Policy can be - applied in two ways in this context: + 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 mandatory set of information (in particular the PCE presence and location). 2. 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 for distributing this information using either PCE discovery protocol(s) or PCC-PCE communication protocol(s). One important @@ -1131,22 +1140,22 @@ boundaries. In multi-domain networks multiple PCEs will communicate with each other and across administrative boundaries. In such cases, domain-specific polices 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 request and responses. 8. Path Computation Sequence of Events - This section presents representative scenarios; other scenarios are - also possible. + 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 @@ -1261,22 +1270,22 @@ dismissed and which were relaxed and in what way) - 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 An important aspect of the policy-enable path computation framework discussed above is the ability to introduce new constraints with minimal impact. In particular, only those components and mechanisms - that will use a new constraint need to change in order to support the - new constraint. Importantly, those components and mechanisms that + that will use a new constraint need to be updated in order to support + the new constraint. Importantly, those components and mechanisms that 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 @@ -1298,23 +1307,23 @@ 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 - of policy information maintained in PC Policy Repositories and policy - related transactions. The most notable issues, some of which are also - listed in [RFC4655], are: + issues related to policy information maintained in PC 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; - 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; @@ -1424,37 +1433,37 @@ Lou Berger LabN Consulting, LLC Phone: +1 301 468 9228 Email: lberger@labn.net Jerry Ash AT&T Email: gash5107@yahoo.com -15. Full Copyright Statement +Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. -16. Intellectual Property +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. @@ -1469,11 +1478,11 @@ 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: Thu Jul 5 19:48:55 EDT 2007 +Generated on: Fri Oct 26 16:05:21 EDT 2007