Network Working Group Igor Bryskin Internet Draft Movaz Networks Category: Informational Dimitri Papadimitriou Expires: March 2006 Alcatel Lou Berger Movaz Networks October 2005 Policy-Enabled Path Computation Communication Requirements draft-bryskin-pce-policy-enabled-path-comp-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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract Traditionally, path computation entity used to be an intrinsic part of an LSR's control plane always co-located with the LSRs signaling I. Bryskin et al. Expires March 2006 Page 1 draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005 and routing subsystems. With introduction of non co-located PCE capability things in this respect became more complicated. In order to take advantage of the PCEs new capabilities, it is highly desirable to introduce new path computation capabilities that require modifying neither the discovery/communication protocols nor PCC software. This document details the requirements to be addressed while designing and developing mechanisms and protocols enabling policy- based control over path computation request/decision. Conventions used in this document 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 RFC 2119 [RFC2119]. 1. Terminology and Acronyms CSPF: Constraint-based Shortest Path First. LSP: Label Switched Path. LSR: Label Switching Router. PCC: Path Computation Client PCE: Path Computation Element: TE LSP: Traffic Engineering MPLS Label Switched Path. CIM: Core Information Model PCIM: Policy Core Information Model PCCIM: Path Computation Core Information Model QPIM: QoS Policy Information Model PBM: Policy-based Management PEP: Policy Enforcement Points PDP: Policy Decision Points COPS: Common Open Policy Service COPS-PR: COPS Usage for Policy Provisioning 2. Motivation Traditionally, path computation entity used to be an intrinsic part of an LSR's control plane always co-located with the LSRs signaling and routing subsystems. Such architectural approach allowed for unlimited flexibility in providing various path computation enhancements û adding new types of constraints, diversities and their relaxation strategies, adopting new objection functions and optimization criterions, etc. All what had to be done was to upgrade the control plane software of only this particular LSR (and no other LSRs or any other network elements). With introduction of non co-located PCE capability things in this respect became more complicated: with the TLV-style PCE discovery I. Bryskin et al. Expires March 2006 Page 2 draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005 and PCC-PCE communication protocols that are currently discussed within PCE WG, it won't be enough for a PCE to upgrade its own software. In order to take advantage of the PCEs new capabilities, new TLVs for both protocols need to be standardized, all PCCs need to be upgraded with new software, new interoperability problems need to be resolved, etc. It would be highly desirable to find a way of introducing new path computation capabilities that requires modifying neither the discovery/communication protocols nor PCC software. 3. Overview Policy-based Management (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, aiming at controlling a network as a whole. Two IETF Working Groups have in the past considered policy networking: The Resource Allocation Protocol 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 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. One way to achieve this objective is to consider constraints, their relaxations and objection functions as path computation request specific policies that on one hand could be configured and managed by an operator, and on the other hand could be interpreted in real time by both PCCs and PCEs. 4. Rationale There is a number of advantages and useful by-products of such approach: I. Bryskin et al. Expires March 2006 Page 3 draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005 - New path computation capabilities could be introduced with changing neither PCE-PCC communication and discovery protocols nor PCC software. Only software of a PCE supporting new capabilities needs to be updated - Existing constraints, objection functions and their relaxations could be aggregated and otherwise associated together, thus, producing new more complex ones that do not require change of code even on PCEs supporting them - Different elements such as conditions, actions, variables, etc. could be re-used by multiple constraints/diversities/optimizations - Both PCCs and PCEs need to handle other (that is, not request specific) policies (see below). Such policies could be placed within the same policy repositories, could be managed by the same policy management tools and could be interpreted using the same mechanisms as request-specific policies. The last bullet requires some more explanations. A PCE should be capable to apply client- and/or domain-specific policies, and, in some cases, service-specific policies, to decide on which algorithms to use while performing path computations requested from a particular PCC or for a particular domain; whether to seek for cooperation of other PCEs to satisfy a particular request or handle it on its own (possibly responding with non ûexplicit paths), etc. Likewise, a PCC should be capable to handle service-specific policies 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 price-performance goals path computation requests could 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 could be applied while computing paths for service A and for service B, and so forth. Another, simpler example is that Service A may use one PCE while Service B uses another. Finally, additional policies need to be supported by a PCE. Consider, for example, the case when a group of PCEs cooperate together in satisfying a particular path computation request. A PCE needs to decide how the request should be modified (perhaps, using identity of the original PCC and/or domain specific information) before being sent to other PCE(s) in the group. Note that in the context of this document "service-specific" means "user service ûspecific", that is, specific to a user service for which path computation needs to be performed and LSPs set up. This should not be confused with "request specific", that is, specific to I. Bryskin et al. Expires March 2006 Page 4 draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005 a particular path computation request. Service-specific policies are applied by policy-capable PCCs or conveyed to and applied by PCEs in case the latter deal with policy incapable PCCs. The described (non-request specific) policies need to be supported by PCCs and PCEs independently from the style of PCC-PCE communication protocols. Thus, introducing a new (request specific) type of policies describing constraints and other elements of a path computation request seems to be a natural and relatively inexpensive addition to the policy enabled path computation architecture. 5. Goals and Requirements The following requirements need to be addressed while designing and developing mechanisms and protocols enabling policy-based control over path computation request/decision. - Policies vs Mechanisms: this document only outlines the communication elements and mechanisms needed to allow a wide variety of possible policies to be applied for path computation control but it does not include any discussion of any specific policy behavior or does not require use of specific policies - GMPLS path computation-specific: the mechanisms must be designed to meet the policy-based control requirements specific to the problem of path computation using RSVP-TE as the signaling protocol on MPLS LSR, GMPLS LSR, but not limited to this as the mechanisms should work just as well for other types of PCCs such as NMS, network planner, etc. - Support for many policies: the mechanisms designed must include support for many policies and policy configurations. In general, the determination and configuration of viable policies are the responsibility of the service provider. - Provision for Monitoring and Accounting Information: The mechanisms must include support for monitoring policy state, and provide access information. In particular, mechanisms must be included to provide usage and access information that may be used for accounting purposes. - Fault tolerance and recovery: The mechanisms designed on the basis of this framework must include provisions for fault tolerance and recovery from failure cases such as failure of PCC/PCE PDPs, disruption in communication that separate a PCC/PCE PDP from its associated PCC/PCE PEPs. - Support for policy-ignorant nodes: Support for the mechanisms described in this document should not be mandatory for every node in I. Bryskin et al. Expires March 2006 Page 5 draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005 a network. Policy based path computation control could be enforced at a subset of nodes, for example the boundary nodes within an administrative domain. These capable nodes would function as trusted nodes from the point of view of the policy-ignorant nodes in that administrative domain. Alternatively, policy may be applied solely on PCEs with all PCCs being policy-ignorant nodes. - Scalability: One of the important requirements for the mechanisms designed for policy control is scalability. The mechanisms must scale at least to the same extent that RSVP-TE signaling scales in terms of accommodating multiple LSPs and network nodes in the path of an LSP. There are several sensitive areas in terms of scalability policy based path computation control. First, not every policy aware node in an infrastructure should be expected to contact a remote PDP. This would cause potentially long delays in verifying requests. Then, the policy control architecture must scale at least as well as RSVP-TE based on factors such as the size of RSVP-TE messages, the time required for the network to service an RSVP-TE request, local processing time required per node, and local memory consumed per node. These scaling considerations are of particular importance during re-routing of a set of LSPs. - Security and denial of service considerations: The policy control architecture must be secure as far as the following aspects are concerned. First, the mechanisms proposed must minimize theft and denial of service threats. Second, it must be ensured that the entities (such as PEPs and PDPs) involved in policy control can verify each other's identity and establish necessary trust before communicating. 6. Path Computation Core Information Model (PCCIM) The Policy Core Information Model (PCIM) introduced in RFC3060 and expanded in RFC 3460 presents the object-oriented information model for representing general policy information. This model defines two hierarchies of object classes: - structural classes representing policy information and control of policies - association classes that indicate how instances of the structural classes are related to each other. These classes could be mapped to various concrete implementations, for example, to a directory that uses LDAPv3 as its access protocol. Figure 1 shows an abstract from the class inheritance hierarchy for PCIM. ManagedElement (abstract) I. Bryskin et al. Expires March 2006 Page 6 draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005 | +--Policy (abstract) | | | +---PolicySet (abstract) | | | | | +---PolicyGroup | | | | | +---PolicyRule | | | +---PolicyCondition (abstract) | | | | | +---PolicyTimePeriodCondition | | | | | +---VendorPolicyCondition | | | | | +---SimplePolicyCondition | | | | | +---CompoundPolicyCondition | | | | | +---CompoundFilterCondition | | | +---PolicyAction (abstract) | | | | | +---VendorPolicyAction | | | | | +---SimplePolicyAction | | | | | +---CompoundPolicyAction | | | +---PolicyVariable (abstract) | | | | | +---PolicyExplicitVariable | | | | | +---PolicyImplicitVariable | | | | | +---(subtree of more specific classes) | | | +---PolicyValue (abstract) | | | +---(subtree of more specific classes) | Figure 1: PCIM Class Inheritance The policy classes and associations defined in PCIM are sufficiently generic to allow them to represent policies related to anything. Policy models for application-specific areas such as the Path Computation Service may extend the PCIM in several ways. The I. Bryskin et al. Expires March 2006 Page 7 draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005 preferred way is to use the PolicyGroup, PolicyRule, and PolicyTimePeriodCondition classes directly as a foundation for representing and communicating policy information. Then, specific subclasses derived from PolicyCondition and PolicyAction can capture application-specific definitions of conditions and actions of policies. Two subclasses, VendorPolicyCondition and VendorPolicyAction, are also defined to provide a standard extension mechanism for vendor-specific extensions to the Policy Core Information Model. Thus, Path Computation Core Information model could be built with the PCConstraint, PCDiversity, PCConstraintRelaxation, PCDiversityRelaxation, PCObjectionFunction, etc. as examples of the PCCIM basic objects. 7. Policy Enabled Path Computation Framework 7.1 PCC-PCE Configurations Path Computation Policies are instantiated using the PCCIM objects created using the PCIM class library as a foundation. PC Policies are configured and managed within the PC Policy Repository by the PC Policy Management Tool. There could be configurations with: o) Single Policy Repository In this configuration there is a single policy repository shared between PCCs and PCEs. I. Bryskin et al. Expires March 2006 Page 8 draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005 ........................ . . . PC Policy Management . . . ........................ . . --------- Policy a ---------------------- Policy b --------- | PCC-PDP |<--------- | PC Policy Repository | -------->| PCE-PDP | --------- ---------------------- --------- ^ ^ | e.g., COPS e.g., COPS | v v --------- --------- | PCC-PEP |<------------------------------------------->| PCE-PEP | --------- PCC-PCE Communication Protocol --------- Figure 2: Single PCC/PCE Policy Repository o) Multiple Policy Repositories The repositories in this case could be fully or partially synchronized by some discovery/ synchronization management protocol or could be completely independent. Note when PC Policy Repository A = B the result is the single policy repository. -------------- -------------- | PC Policy | | PC Policy | ---| Repository A | | Repository B |--- | -------------- -------------- | | | | Policy a Policy b | | | v v --------- --------- | PCC-PDP | | PCE-PDP | --------- --------- ^ ^ | e.g., COPS e.g., COPS | v v --------- --------- | PCC-PEP |<------------------------------------------->| PCE-PEP | --------- PCC-PCE Communication Protocol --------- Figure 3: Multiple PCE/PCC Policy Repositories I. Bryskin et al. Expires March 2006 Page 9 draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005 A PCC is logically split into two parts: PCC-PDP (Policy Decision Point) and PCC-PEP (Policy Enforcement Point). 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 could 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]. Likewise, a PCE is logically split 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 actual Path Computation Service (that is, runs path computation algorithms). PCE-PEP and PCE-PDP could be physically co-located or separated. In the later case they communicate using such protocols as COPS and/or COPS-PR. PCC-PDP/PCE-PDP could be co-located with or separated from the associated PC 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 PEP requests. 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 requests-specific policies found in the requests as well as client- and domain-specific policies supplied by the PCE-PDP. Note that a PCC request may include service specific information, for which the PCE-PEP must apply service specific policies in order to define actual path computation parameters. Figure 4 shows an example where PCCs are policy ignorant and the PCE/PCC request would always include service specific information. Another example would use the components shown in ether Figure 2 or 3, but the policy applied at the PCC would be limited to selecting a PCE. In this case the path computation request should contain service specific information, so that the chosen PCE could identify actual path computation parameters (applying local service specific policies). I. Bryskin et al. Expires March 2006 Page 10 draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005 ........................ . . . PC Policy Management . . . ........................ . . ---------------------- Policy --------- | PC Policy Repository | -------->| PCE-PDP | ---------------------- --------- ^ e.g., COPS | v --------- --------- | PCC |<------------------------------------------->| PCE-PEP | --------- PCC-PCE Communication Protocol --------- Figure 4: PCE Policy Repository with Policy Ignorant PCC On the other hand, it is also possible for policy to only be applied at the PCC. In this case the applied policy would be embodied in any requests to the PCE, e.g., in the form of constraints. This configuration is shown in Figure 5. ........................ . . . PC Policy Management . . . ........................ . . --------- Policy ---------------------- | PCC-PDP |<--------- | PC Policy Repository | --------- ---------------------- ^ | e.g., COPS v --------- --------- | PCC-PEP |<------------------------------------------->| PCE | --------- PCC-PCE Communication Protocol --------- Figure 5: PCC Policy Repository with Policy Ignorant PCE 7.2 Cooperating PCE Configurations The previous section shows the relationship between PCCs and PCEs. I. Bryskin et al. Expires March 2006 Page 11 draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005 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 Policy Repository will not be desirable, for example when the PCEs are managed by different entities. Although, to identify a usable path it remains necessary for there to be consistent policies across domains. 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 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. This configuration is also applicable for administrative domains with single PCE. ........................ . . . PC Policy Management . . . ........................ . . --------- Policy a ---------------------- Policy b --------- | PCE-PDP |<--------- | PC Policy Repository | -------->| PCE-PDP | --------- ---------------------- --------- ^ ^ | e.g., COPS e.g., COPS | v v --------- --------- | PCE-PEP |<------------------------------------------->| PCE-PEP | --------- PCE-PCE Communication Protocol --------- Figure 6: Single PCC Policy Repository o) Multiple Policy Repositories The repositories in this case could be fully or partially synchronized by some discovery/synchronization management protocol or could be completely independent. In the multi-domain case, it is expected that these repositories would be distinct, but provide consistent policies. I. Bryskin et al. Expires March 2006 Page 12 draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005 -------------- -------------- | PC Policy | | PC Policy | ---| Repository A | | Repository B |--- | -------------- -------------- | | | | Policy a Policy b | | | v v --------- --------- | PCE-PDP | | PCE-PDP | --------- --------- ^ ^ | e.g., COPS e.g., COPS | v v --------- --------- | PCE-PEP |<------------------------------------------->| PCE-PEP | --------- PCC-PCE Communication Protocol --------- Figure 7: Multiple PCC Policy Repositories 7.3 Inter-Component Communication PCC-PEP and PCE-PEP, and PCE-PEPs communicate via a PCC-PCE (request-response) Communication Protocol. This document makes no assumptions as to what protocol is used to support this protocol. This document does assume that the semantics of a Path computation requests are very abstract and general, and supports both PCE-PCC and PCE-PCE communication]. The Path computation request includes: . One or several source addresses; . One or several destination addresses; . Computation type (P2P, P2MP, MP2P, etc.); . Number of required paths; . Zero or more policy descriptors in the following format: , , , ,..., , , ,..., ... , , ,..., The Path computation response would include the list of computed path using the same format The PCC-PCE Communication Protocol should not understand nor makes any assumptions about the semantics of policies specified in the path computation requests. I. Bryskin et al. Expires March 2006 Page 13 draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005 Note: This document explicitly allows for the PCC-PDP to decide that all necessary constraints, objection functions, etc. pertinent for the computation of paths for the service in question are to be determined by the PCE performing the computation. In this case the PCC-PDP will use a set of policies describing the above mentioned service specific information. These policies could be placed within the path computation request and delivered to the PCE via 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 PCE-PDP). 8. Sequence of events happening during path computation This section presents representative scenarios; other scenarios are also possible. 8.1 Policy-enabled PCC, Policy-enabled PCE Let us consider what happens after a service has been provisioned to originate from a GMPLS LSR (or the LSR has received a Setup (RSVP Path) message from an upstream LSR), and the LSR decides to use a non co-located Path Computation Entity. - A PCC-PEP co-located with the LSR applies the service specific policies to select a PCE for the service path computation as well as to build the path computation request (that is, to select a list of policies, their variables and parameters expressing constraints, diversities, objection functions and relaxation strategies appropriate for the service path computation). The policies could 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 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/provisioning 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. - 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, could be either statically I. Bryskin et al. Expires March 2006 Page 14 draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005 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 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 path computation d) The address of the next-in-chain PCE; e) The path computation request to be sent to the next-in- chain PCE The PCE-PEP instructs a co-located path computation engine to perform the local path computation(s) and, if necessary, sends the path computation request to the next-in-chain PCE using the PCC-PCE Communication Protocol. Then it waits for the responses from the local path computation engine and the remote PCE, combines the resulting paths and sends them back to the PCC-PEP using the PCC-PCE Communication Protocol. The response contains policies describing the resulting paths as well as some additional information (for example, which of constraints were honored, which were 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) 8.2 Policy-ignorant PCC, Policy-enabled PCE This case parallels the previous example, but the service level policy must be applied at the PCE as the PCC is policy ignorant. Again, we consider what happens after a service has been provisioned to originate from a GMPLS LSR (or the LSR has received a Setup (RSVP Path) message from an upstream LSR), and the LSR decides to use a non co-located Path Computation Entity. - The PCC constructs a PCE request using information found in the signaling/provisioning 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. - PCE-PEP validates and otherwise processes the request applying the policies found in the request as well as client and domain specific polices. The PCE-PEP applies the service specific policies to select a PCE for the service path computation as well I. Bryskin et al. Expires March 2006 Page 15 draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005 as to build the path computation request (that is, to select a list of policies, their variables and parameters expressing constraints, diversities, objection functions and relaxation strategies appropriate for the service path computation). The policies, again, could 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 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 path computation d) The address of the next-in-chain PCE; e) The path computation request to be sent to the next-in- chain PCE The PCE-PEP instructs a co-located path computation engine to perform the local path computation(s) and, if necessary, sends the path computation request to the next-in-chain PCE using the PCC-PCE Communication Protocol. Then it waits for the responses from the local path computation engine and the remote PCE, combines the resulting paths and sends them back to the PCC-PEP using the PCC-PCE Communication Protocol. The response contains policies describing the resulting paths as well as some additional information (for example, which of constraints were honored, which were 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. Introducing a new constraint supported by a PCE Let us assume that a PCE has been upgraded with software supporting, optical physical impairment constraint such as Polarization Mode Dispersion (PMD) that previously has not been supported in the domain. In this case one or more new policies will be installed in the PC Policy Repository (associated with the PCE) defining the constraint (rules that determine application criteria, set of variables and valid parameters, etc.) and its relaxation strategy(ies). The new policies will be also propagated into other PC Policy Repositories within the domain via discovery/ synchronization protocols or via local configuration. PCE 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 policies into path computation requests for I. Bryskin et al. Expires March 2006 Page 16 draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005 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 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, it is solved already and in a much scalable way than using IGP-TE. 10. Acknowledgements We would like to thank Bela Berde for fruitful discussions on PBM and Policy-driven path computation. 11. IANA Considerations None. 12. Reference 12.1 Normative Reference [RFC2205] Braden, R., et al., "Resource ReSerVation Protocol (RSVP) - Version 1, Functional Specification", RFC 2205, September 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. [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 Information Model Version1 Specification, RFC 3060, February 2001. [RFC3209] Awduche, D., et al., "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3471] Berger, L., et al., Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, RFC 3471, January 2003. I. Bryskin et al. Expires March 2006 Page 17 draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005 [RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3644] Y. Snir, et al., Policy Quality of Service (QoS) Information Model, RFC 3644, November 2003. [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. 12.2 Informative Reference 13. Author's Addresses Igor Bryskin Movaz Networks, Inc Phone: +1 703-847-4208 Email: ibryskin@movaz.com Dimitri Papadimitriou (Alcatel) Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 Email: dimitri.papadimitriou@alcatel.be Lou Berger Movaz Networks, Inc Phone: +1 703-847-1801 Email: lberger@movaz.com I. Bryskin et al. Expires March 2006 Page 18 draft-bryskin-pce-policy-enabled-path-comp-00.txt October 2005 Intellectual Property Statement 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 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. I. Bryskin et al. Expires March 2006 Page 19