Internet Draft Lou Berger (Movaz Networks) Category: Informational Igor Bryskin (Movaz Networks) Expiration Date: April 2006 Dimitri Papadimitriou (Alcatel) October 2005 PCE Policy Architecture draft-berger-pce-policy-architecture-00.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 other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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 Abstract The PCE architecture [PCE-ARCH] introduces the concept of path computation related policy at a high level. This document provides additional details on policy as applied to the PCE architecture. Berger, et. al. & [Page 1] Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005 Contents 1 Introduction .............................................. 3 1.1 PCE Components ............................................ 3 1.2 Areas for Standardization ................................. 9 2 PCE Policy Architecture ................................... 10 2.1 Types of Policies ......................................... 10 2.1.1 User and Request Specific Policies ........................ 10 2.1.2 Client and Server Specific Policies ....................... 10 2.1.3 Local and Domain Specific Policies ........................ 11 2.2 Policy Application ........................................ 11 2.3 Policy Communication Support .............................. 13 2.4 PCE Discovery Policy Considerations ....................... 13 2.5 Policy Management ......................................... 14 3 Representative Policy Scenario ............................ 14 3.1 Scenario: Policy Configured Paths ......................... 15 3.2 Scenario: Provider Selection Policy ....................... 16 3.3 Scenario: Policy Based Constraints ........................ 17 4 Security Considerations ................................... 18 5 IANA Considerations ....................................... 19 6 References ................................................ 19 6.1 Normative References ...................................... 19 6.2 Informative References .................................... 19 7 Authors' Addresses ........................................ 20 8 Full Copyright Statement .................................. 20 9 Intellectual Property ..................................... 20 Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005 1. Introduction The PCE architecture is introduced in [PCE-ARCH]. This document describes the impact policy on the PCE architecture. Other documents, for example [PCE-POL-COMMS], will provide implications on more detailed aspects of PCE implementation. Policy impacts multiple aspects of the PCE architecture. The first is internal impact; the second is impact on PCE related communication. It is envisioned that policy will be largely applied as a local mater within each PCE. That said, it is necessary to define the policy models that the PCE architecture can support. Some example policies include rejection of a request based on requesting PCC or identified constraints, selection of a path based on the computation target, or the selection of a path based on the time of day. The definition of supported policy models will drive PCE solutions and will enable proper and complete evaluation of specific PCE solutions. PCE supported policy models are discussed later in this document. While the implementation and enforcement of policy is largely a local matter, the policies that may be applied impact the communication protocols used to support PCE. This includes PCC-PCE, PCE-PCE and PCE discovery communication. The primary impact is to the information carried by the protocols. To a lesser degree, policy support requirements may also drive the required protocol transactions. As the more detailed requirements for each PCE communication protocol is defined, it is important for these documents to articulate supported (and unsupported) policy models and the related requirements. Also, any defined solution must be evaluated on its ability to support these policy models and requirements. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.1. PCE Components From a component perspective, PCE policy is supported via a Policy Database. The Policy database provides non-TE information and is used by a PCE when responding to a requested path computation. Additionally, policy may also be used to govern what requests are made to the PCE from a PCC. [PCE-ARCH] shows the PCE architecture applied to four different node configurations. Figures 1 through Figure 4 shows these configurations updated to reflect PCE Policy. Berger, et. al. & [Page 3] Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005 In each configuration, policy is consulted before a response is provided by a PCE. A PCE may have local policy information that impacts the one or more paths selected to satisfy a particular PCE request. A local policy may be applied based on any information provided from a PCC. The policy may have any number of results including, for example, rejecting the request, identifying one or more paths that provide different quality of service, or providing one or more paths that have different costs, different end-to-end delays or other different characteristics. Additionally, changes in PCE policy may lead to a change to a previously provided path. Another, important policy decision is the one related to the TED selection. Indeed, the selection of the TED repository for the path computation itself can be subject to policing. This means that this document extends the PCE architecture by allowing the access point to the PCE to be disjoint from the access point to the TED that will be used for path computation purposes. This extension will likely impact inter-PCE communication, and selection of a "next PCE" when multiple PCEs are involved during the path computation. Path computation related policy must also be sensitive to where it is being applied. For example, a different set of policies may be applied for an intra-area or single-layer PCE request, than would be provided for an inter-area or multi-layer PCE request. In each configuration, all policy decisions are made independently at each PCE based on information passed from the previous PCE. Alternatively, in the multiple PCE path computation with inter-PCE communication configuration, see Figure 4, there is likely to be explicit communication of policy information between PCEs. The type of information conveyed to support policy will have significant implications on what policies may be applied at each PCE. Note that while the policy component is shown as co-resident, the policy database may be implemented using some form of distributed database. Such distributed approaches have no impact on the PCE policy architecture and are therefore out of scope of this document. Berger, et. al. & [Page 4] Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005 ------------------------------ | --------- | Routing ---------- | | | | Protocol | | | | TED |<-+----------+-> | | | | | | | | --------- | | | | | | | | | | Input | | | | v | | | | --------- --------- | | | | | Policy | | | | | Adjacent | | | Database|<-->| PCE | | | Node | | | | | | | | | | --------- --------- | | | | ^ | | | | |Request | | | | |Response| | | | v | | | | --------- | | | Service | | | | Signaling| | Request | |Signaling| | Protocol | | ------+---------------->| Engine |<-+----------+-> | | | | | | | | --------- | ---------- ------------------------------ Figure 1. Composite PCE Node Berger, et. al. & [Page 5] Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005 ---------------------- | ----- | | | TED |<-+------------> | ----- | TED synchronization | | | mechanism (e.g.,, routing protocol) | | | | v | | ------ ----- | | |Policy|<-->| PCE | | | ------ ----- | ---------------------- ^ | Request/ | Response v Service ---------- Signaling ---------- Request| Head-End | Protocol | Adjacent | ---->| Node |<---------->| Node | ---------- ---------- Figure 2. External PCE Node ------------------ ------------------- | | | | | 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 3. Multiple PCE Path Computation Berger, et. al. & [Page 6] Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005 ------------------ ------------------ | | 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 4. Multiple PCE Path Computation with Inter-PCE Communication The PCE architecture allows for there to be multiple PCEs for a number of reasons, including for redundancy or for distributed path computation purposes. Independent of purpose, in the configurations where multiple PCEs exist, the Policy Databases should be consistent across the PCEs in order for a PCE request to be satisfied as intended. The means by which such consistency is established is viewed as a configuration issue. The policy configuration interface is not specified or restricted by the PCE Policy Architecture. The interface may be purely a local matter, or may be supported via a standardized interface or policy distribution mechanism (e.g., MIB or LDAP.) Policy may also play a part in the selection of a PCE by a PCC when multiple PCEs exists, see Figures 3 and 4. Policy may also influence a request made by a PCC to a PCE. Figure 5, shows the PCC components used to support the application of such policy. Note Figure 5 also allows for multiple PCEs. Berger, et. al. & [Page 7] Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005 ---------------------- | ----- | | | 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 5: Policy Enabled PCC As stated in [PCE-ARCH], the PCC is not necessarily an LSR. Policy also is applied in such configurations. The example shown in [PCE- ARCH] is of an NMS. Figure 6 shows this example updated to support policy. Berger, et. al. & [Page 8] Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005 ---------------------- | ----- | Service | | TED |<------------+------------> Request | ----- | TED synchronization | | | | mechanism (e.g., v | | | routing protocol) ------------- Request/ | v | | | Response| ----- ------ | | NMS |<--------+->| PCE |<-->|Policy| | | | | ----- ------ | ------------- ---------------------- Service | Request | v ---------- Signaling ---------- | Head-End | Protocol | Adjacent | | Node |<---------->| Node | ---------- ---------- Figure 6. Management-based PCE Usage 1.2. Areas for Standardization The following areas require standardization within the PCE policy architecture: - Communication between PCCs and PCEs, and between cooperating PCEs, including the definition of policy related information communication. - Communication of policy related information dissemination e.g. as part of the PCE discovery or some other communication process. - Definition of metrics to evaluate policy support of path computation models. The focal point of this effort is to evaluate potential solutions to the Policy aspects of the PCE architecture. - MIB modules related to policy support. - Configuration related support for policy databases. Berger, et. al. & [Page 9] Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005 2. PCE Policy Architecture This section provides definitions and other aspects related to the support of policy by the PCE architecture. 2.1. Types of Policies For the purposes of PCE, we breakdown policy into multiple categories: user specific, request specific, client specific, server specific and domain specific. 2.1.1. User and Request Specific Policies User specific policies are policies that use as conditions user or service specified information. Examples of such information includes the contents of objects of a signaling or provisioning message, port ID over which the message was received, VPN ID, reference point type, or even the identity of the user initiating the request. User specific policies could be applied while building a path computation request. For example, Service A may require two SRLG disjoint paths for building end-to-end recovery scheme, while for service B link- disjoint paths may be sufficient. Alternatively, service A may need paths with minimal end-to-end delay, while service B may be looking for shortest (minimal-cost) paths. A final example is that different constraint relaxation strategies could be applied while computing paths for service A and for service B. Request specific policies are policies that use as conditions information found in a path computation request. Examples of request specific policies include constraints, diversities, constraint and diversity relaxation strategies, and optimization functions. Request-specific policies directly affect the path selection process because they specify which links, nodes, path segments and/or paths that are not acceptable or, on the contrary, may be desirable to appear in the resulting paths. 2.1.2. Client and Server Specific Policies Client specific policies are policies that use as a condition the requesting Path Computation Client (PCC) or, in the inter-PCE requesting case, a requesting Path Computation Engine (PCE). A PCE may take specific action depending on the identity of the requester. Some examples are the PCE may choose to drop or relax certain specified constraints or impose additional ones, select an algorithm or heuristic for the path computation, decide whether cooperation of Berger, et. al. & [Page 10] Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005 other PCEs are needed and whether explicit resulting paths should be generated or loose ones are sufficient. Server specific policies are policies that are associated with a particular Path Computation Engine and applied at a PCC or at a PCE initiating a inter-PCE request. A PCC or PCE may take specific action depending on the identity of the identity of the PCE to which it may make a request. One examples of this is that a requester may select a PCE based on its capabilities. Another example is that a requester may include different information in a path computation request based on the capabilities of a specific PCE. Capabilities in this context mean the ability of a PCE to provide specific functions, such as support for certain path computation constraints or optimization functions, method of PCE related communication authentication, or billing. 2.1.3. Local and Domain Specific Policies Local specific policies are policies that use as a condition the ID the PCC acting on behalf one (or more) LSRs. These policies uses conditions that are specific to the PCC to which they apply. In a network including multiple PCCs these conditions can be applied independently of the policies applying to the other PCC policies. Domain specific policies are policies that use as a condition the ID of a path computation domain the requesting PCC belongs to and/or IDs of domains the resulting paths go through. These policies have the same affect on the path computation process as client specific policies with the difference that they could be associated with/applied for a group of clients rather than individual clients. One example of domain-specific policy is a policy restricting which information a PCE should publish within a given domain. In such a case, PCEs in some domains may advertise just its presence while others may advertise details regarding its capabilities, client authentication process, billing, and computation resource availability. 2.2. Policy Application 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 being applied at both or even at either. The use of policy in a network, on PCCs and on PCEs, is specific network design choice. Some networks may choose to apply policy only at PCCs, some may choose to only apply policies at PCEs, and others will may choose to apply policies at Berger, et. al. & [Page 11] Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005 both. Regardless of how policy is applied, as previously mentioned, it must be applied in a consistent fashion in order to achieve the results intended. Section 1.1 shows some possible example configurations of where policy can be applied within the PCE architecture. Figures 1 through 6 show policy being applied at a PCE. Figure 5 shows policy being applied at both a PCC and a PCE. Along with supporting a flexibility in where policy may be applied, the PCE policy architecture is also flexible in terms of where specific types of policies may be applied. Also the PCE policy architecture allows for the application of only a subset of policy types. Section 2.1 defines multiple types of policies. Each of these may be applied at either a PCC or a PCE. Clearly when policy is only applied at PCCs or at PCEs, all policy types used in a network must be applied at those locations. In the case when 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 could gather in the path computation request, most likely in the form of policy information. The PCE is expected to understand this policy information and apply appropriate policies while defining the actual parameters of the path computation to be performed. Note that in this case, the PCC cannot use local or server policy information to select a PCE. When applying policy at both PCCs and PCEs, it is necessary to select which types of policies are applied at each. In such configurations, it is likely that the application of policy types will be distributed across PCCs and PCEs rather than applying all types at both. Particularly for those policy types that apply to the role being performed by the component. For example, user specific, server specific and request specific policies may be applied at PCCs, domain specific policies may be applied at PCEs and client specific policies may be applied at both. Client specific policies may also be relative to the location where the policy is applied, i.e., at the PCC the client is the service requester, while at the PCE the client is the requesting PCC or 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, 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", non-policy capable, constraints explicitly defined by the PCC-PCE communication protocol. Berger, et. al. & [Page 12] Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005 2.3. Policy Communication Support The described PCE policy architecture allows for a fair bit of flexibility in where and in what types of policy is applied. This is critical from the architecture perspective, but it does imply added complexity on the part of the PCE related communication protocols. The first added complexity is that the PCE communication protocols must carry sufficient information to support the types of policies that may be applied. For example, in the case where policy is only applied at a PCE, a PCC-PCE request must carry sufficient information for the PCE to apply request or even user specific policies. This does imply that a PCC must have sufficient understanding of what policy types may be applied at a PCE. Such information may be obtained via such approaches as configuration, static coding, or even via a PCE discovery mechanism. The PCC must also have sufficient understanding to properly encode the required information for each type of policy. The second added complexity is that the PCE communication protocols must also be able to carry information that may result from a policy decision. For example, user 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 policy component. This complexity is particularly important as it may be used to introduce new path computation related constraints without modification of the core PCC and PCE. This communication will likely simply require the PCE communication protocol(s) to support opaque policy related information elements. The final added complexity is that the 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 (opaque) information that must be provided to a PCC's policy component. 2.4. PCE Discovery Policy Considerations Dynamic PCE discovery allows PCCs/PCEs to automatically discover a set of PCEs, including information required for PCE selection, and to dynamically detect new PCEs or any modification of PCE's information. 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 location). Berger, et. al. & [Page 13] Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005 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 the discovery protocol or the specific PCC- PCE communication protocol. Here the most important policy decision is determined by the nature of the information to be discovered in particular when this information is not strictly speaking a "discovery" information, but a PCE state information exchange the policy should allow for making use of the appropriate protocol to exchange that information with the client PCC/PCE Another level where policing applies is at the administrative boundaries. This class of polices applies in particular when multiple PCEs would have to communicate one each other and cross an administrative boundary. In this context, several specific polices would be applied to 1) filter the information exchanged with peering PCEs during the discovery process (to the bare minimum in most cases if at all allowed by the security policy) and 2) strictly limit the exchange of information during path computation request/responses. 2.5. Policy Management The management of policy information used at PCCs and PCEs is largely out of scope of the PCE architecture. The architecture assumes that such information is installed using typical policy management techniques and are available for use by policy components co-resident with PCCs and PCEs. The policy management techniques may be statically configured, managed via an information or policy management protocol, e.g., LDAPv3 [RFC3377], or even dynamically established. 3. Representative Policy Scenario This section provides some example of policy may be applied using the PCE policy architecture. The intent of this section is to provide several diverse examples of how policy may be applied within the PCE architecture. Actual networks may use 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. [Authors' note: it is expected that this section will generate a number of divergent views of how PCE policy may be applied within the architecture. We view this as beneficial and that it is imperative for the PCE policy architecture to be sufficiently flexible to accommodate all views, and that each perspective be suitably Berger, et. al. & [Page 14] Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005 represented in this section.] 3.1. Scenario: Policy Configured Paths A very simple usage scenario for PCE policy would be to use PCE to centrally administer configured path. Configured paths are composed of strict and loose explicit hops, EROs see [RFC3209], and are used by one or more LSPs. Typically such paths are configured at the LSP ingress. With PCE policy, an alternate approach is possible. Using PCE policy, user specific policies can be created that will provide a configured path for a specific user request. The user request could be identified based on service parameters such as end- points, requested service/QoS, or even a token that identifies the end-user. The configured path would then be used as input to PCE computation process. The PCE process would return any explicit routes and expand all possible loose hops. This described policy could be applied at either PCC or PCE, see Figure 5. In the PCC case, the configured path would be expanded at the PCC and then passed to the PCE along with the PCE request, probably in the form of constraints. When applied at the PCE, the configured path would be internally expanded and used. Both cases require some method to configure and manage policies. In the PCC case, the real benefit would come when there is an automated policy distribution mechanism. Policy configured paths can also be used in multiple PCE environments, see Figures 3 and 4. For example, consider the case where there is limited visibility and multiple PCEs are used to resolve each region of visibility. In this example, it may not be possible, or desirable to configure the whole explicit path on the first PCE. What could be done, is to configure the explicit path for each area of visibility with each responsible PCE. Each PCE would then map an incoming request to the matching configured path. For this example to work, it would likely be necessary to include the exit point from, or the entry point into, each area of visibility. Clearly, policy database consistent is also critical in this example. Berger, et. al. & [Page 15] Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005 3.2. Scenario: Provider Selection Policy A more interesting usage scenario is applying policy to multi-domain, multi-provider, networks. There a number of interesting applications of policy in such networks. A rudimentary example is simple access control, i.e., which users, clients or PCEs are permitted to request inter-domain path computation. A more interesting example is applying policy to select which domain, or provider, is used to support a particular PCE request. Consider a topology that has multiple transit networks, see Figure 7. In this case, there are multiple transit networks available to provide a path from a source domain to a destination (or target) domain. Furthermore, each transit network may have one or more options for reaching the target domain. Each domain may need to select which of the multiple available paths can be used to satisfy a particular PCE request. Clear reachability is a base criteria for path selection, but policy may be a more interesting and important criteria. For example transit network A may be more expensive and provide lower delay or loss than transit network C. Likewise, a transit network may wish to treat PCE requests from its own customers differently than requests from another provider. In both cases, computation based on traffic engineering databases will result in multiple transit networks that provide reachability, but policy can be used to dictate which PCE requests get the better service. +----------------+ |Transit Domain A| +----------------+ +----------------+ |Transit Domain D| +------+ +----------------+ +----------------+ +------+ |Source| |Transit Domain B| +----------------+ |Target| |Domain| +----------------+ |Transit Domain E| |Domain| +------+ +----------------+ +----------------+ +------+ |Transit Domain C| +----------------+ +----------------+ |Transit Domain F| +----------------+ Figure 7: Multi-domain network with multiple transit options There are multiple options for differentiating which PCE requests use a particular transit domain and get better service. For example, the source domain may use user and client specific policies, to determine the level of service to provide and use domain specific policies to choose which transit domains are acceptable. A transit domain may use a combination of client specific policies to determine if a request is from a direct customer or another provider, and then use Berger, et. al. & [Page 16] Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005 domain specific policies to identify how the request should be processed. While this description presumes multiple PCEs, while envisioned to be less common, it is also possible to apply provider selection policy in single PCE environments. In this case, the single PCE will apply all policies, (e.g., user, client and domain specific policies) to determine the appropriate constraints for a particular PCE request. While less likely, the described policy could be also applied at a PCC. In the PCC case, the provider related policy would be expanded at the PCC and then passed to the PCE along with the PCE request, probably in the form of constraints. Independent of the number of PCEs, or the application of policy at PCCs, there must be some method to configure and manage policies consistently. It is also worth noting that this basic approach can also be used within a domain to provide different paths and services based on users, PCC, VPN ID, or even application. 3.3. Scenario: Policy Based Constraints Another usage scenario is to use policy to provide additional constraints for PCE request. Consider an LSR with a policy capable PCC, as shown in Figure 5, which receives a signaling message via signaling, including over a NNI or UNI reference point, or receives configuration request over a management interface to establish a service. The path(s) for LSP(s) that are needed to support the service are not explicitly specified in the message/request; 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, including 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 is 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 describe how the request Berger, et. al. & [Page 17] Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005 must considered in the path computation process. The PCC may also apply server specific policies for each of known, i.e., discovered or configured, PCE in order to select which PCE to use. 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 so that it has a higher likelihood of being satisfied in an efficient way. An example of modification as a result of a server specific policy is to remove a constraint not supported by the PCE. Once the policy processing is complete one the PCC, and the PCE request resulting from the original service request is updated by the policy processing, the request is sent to the PCE. The PCE that receives the request validates and otherwise processes the request applying the policies found in the request as well as any policies that are applied 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 request(s) 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 them back to the requesting PCC. The response may represent 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 of constraints were honored, which were dismissed and which were relaxed and in what way. PCC processes the response and instructs the LSR to encode the received path(s) into the outgoing signaling message(s). 4. Security Considerations This document adds a policy dimension to the considerations mentioned in [PCE-ARCH]. In particular it is now necessary to consider the security of policy information and policy related transactions. The most notable of these are: - Interception of policy related information in PCE requests and responses. Berger, et. al. & [Page 18] Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005 - Impersonation of user and client identities. - Falsification of policy information or PCE capabilities. - Denial of service attacks on policy related communication mechanisms. As with [PCE-ARCH], it is expected that PCE solutions will address these issues in detail. 5. IANA Considerations This document makes no requests to IANA. 6. References 6.1. Normative References [PCE-ARCH] Farrel, A., Vasseur, JP., Ash, J., "Path Computation Element (PCE) Architecture", July 2005. 6.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119. [RFC3209] Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3377] Hodges, J., Morgan, R., "Lightweight Directory Access Protocol (v3): Technical Specification", September 2002. [PCE-POL-COMMS] Bryskin, I., Papadimitriou, D., Berger, L., "Policy-Enabled Path Computation Communication Requirements", October 2005. Berger, et. al. & [Page 19] Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005 7. Authors' Addresses Lou Berger Movaz Networks, Inc Phone: +1 703-847-1801 Email: lberger@movaz.com Igor Bryskin Movaz Networks, Inc Phone: +1 703-847-4208 Email: ibryskin@movaz.com Dimitri Papadimitriou Alcatel Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240 8491 Email: dimitri.papadimitriou@alcatel.be 8. Full Copyright Statement Copyright (C) The Internet Society (2005). 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 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. 9. 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. Copies of IPR disclosures made to the IETF Secretariat and any Berger, et. al. & [Page 20] Internet Draft draft-berger-pce-policy-architecture-00.txt October 2005 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. 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. Berger, et. al. & [Page 21] Generated on: Mon Oct 17 00:29:11 EDT 2005