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:
           <policy name>,
           <policy variable1 name>, <param11>, <param12>,...,<param1N>
           <policy variable2 name>, <param21>, <param12>,...,<param2N>
           ...
           <policy variableM name>, <paramM1>, <paramM2>,...,<paramMN>
     
        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