[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-yasukawa-pce-p2mp-req) 00 01 02 03 04 05 RFC 5862

Network Working Group                                        S. Yasukawa
Internet Draft                                                       NTT
Category: Informational                                        A. Farrel
Created: October 16, 2009                             Old Dog Consulting
Expires: April 16, 2010

       PCC-PCE Communication Requirements for Point to Multipoint
       Multiprotocol Label Switching Traffic Engineering (MPLS-TE)

                      draft-ietf-pce-p2mp-req-03.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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.

Abstract

   The Path Computation Element (PCE) provides path computation
   functions in support of traffic engineering in Multi-Protocol Label
   Switching (MPLS) and Generalized MPLS (GMPLS) networks.

   Extensions to the MPLS and GMPLS signaling and routing protocols have
   been made in support of point-to-multipoint (P2MP) Traffic Engineered
   (TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is
   already established, and since P2MP TE LSP routes are sometimes
   complex to compute, it is likely that PCE will be used for P2MP LSPs.

   Generic requirements for a communication protocol between Path
   Computation Clients (PCCs) and PCEs are presented in "Path
   Computation Element (PCE) Communication Protocol Generic
   Requirements". This document complements the generic requirements and
   presents a detailed set of PCC-PCE communication protocol
   requirements for point-to-multipoint MPLS/GMPLS traffic engineering.



S. Yasukawa and A. Farrel                                       [Page 1]

draft-ietf-pce-p2mp-req-03.txt                              October 2009


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].
   Although this document is not a protocol specification, this
   convention is adopted for clarity of description of requirements.

1. Introduction

   The Path Computation Element (PCE) defined in [RFC4655] is an entity
   that is capable of computing a network path or route based on a
   network graph, and applying computational constraints. The intention
   is that the PCE is used to compute the path of Traffic Engineered
   Label Switched Paths (TE LSPs) within Multiprotocol Label Switching
   (MPLS) and Generalized MPLS (GMPLS) networks.

   Requirements for point-to-multipoint (P2MP) MPLS TE LSPs are
   documented in [RFC4461] and signaling protocol extensions for
   setting up P2MP MPLS TE LSPs are defined in [RFC4875]. P2MP MPLS TE
   networks are considered in support of various features including
   layer 3 multicast VPNs [RFC4834].

   Path computation for P2MP TE LSPs presents a significant challenge,
   and network optimization of multiple P2MP TE LSPs requires
   considerable computational resources. PCE offers a way to offload
   such path computations from Label Switching Routers (LSRs).

   The applicability of the PCE-based path computation architecture to
   P2MP MPLS TE is described in a companion document [PCE-P2MP-APP]. No
   further attempt is made to justify the use of PCE for P2MP MPLS TE
   within this document.

   This document presents a set of PCC-PCE communication protocol
   (PCECP) requirements for P2MP MPLS traffic engineering. It
   supplements the generic requirements documented in [RFC4657].

2. PCC-PCE Communication Requirements for P2MP MPLS Traffic Engineering

   This section sets out additional requirements not covered in
   [RFC4657] specific to P2MP MPLS TE.

2.1. PCC-PCE Communication

   The PCC-PCE communication protocol MUST allow requests and replies
   for the computation of paths for P2MP LSPs.

   This requires no additional messages, but requires the addition of


S. Yasukawa and A. Farrel                                       [Page 2]

draft-ietf-pce-p2mp-req-03.txt                              October 2009


   the parameters described in the following sections to the existing
   PCC-PCE communication protocol messages.

2.1.1. Indication of P2MP Path Computation Request

   R1:  Although the presence of certain parameters (such as a list of
        more than one destination) MAY be used by a protocol
        specification to allow an implementation to infer that a path
        computation request is for a P2MP LSP, an explicit parameter
        SHOULD be placed in a conspicuous place within a Path
        Computation Request message to allow a receiving PCE to easily
        identify that the request is for a P2MP path.

2.1.2. Indication of P2MP Objective Functions

   R2:  [RFC4657] includes the requirement to be able to specify the
        objective functions to be applied by a PCE during path
        computation.

        This document makes no change to that requirement, but it should
        be noted that new and different objective functions will be used
        for P2MP computation. Definitions for core objective functions
        can be found in [RFC5541] together with usage procedures. New
        objective functions for use with P2MP path computations will
        need to be defined and allocated codepoints in a separate
        document.

2.1.3. Non-Support of P2MP Path Computation

   R3:  PCEs are not required to support P2MP path computation.
        Therefore, it MUST be possible for a PCE to reject a P2MP Path
        Computation Request message with a reason code that indicates no
        support for P2MP path computation.

2.1.4. Non-Support by Back-Level PCE Implementations

   It is possible that initial PCE implementations will be developed
   without support for P2MP path computation and without the ability to
   recognize the explicit parameter described in section 2.1.1. Such
   legacy implementations will not be able to make use of the new
   reason code described in Section 2.1.3.

   R4:  Therefore, at least one parameter required for inclusion in a
        P2MP Path Computation Request message MUST be defined in such a
        way as to cause automatic rejection as unprocessable or
        unrecognized by a back-level PCE implementation without
        requiring any changes to that PCE. It is RECOMMENDED that the
        parameter that causes this result is the parameter described in


S. Yasukawa and A. Farrel                                       [Page 3]

draft-ietf-pce-p2mp-req-03.txt                              October 2009


        Section 2.1.1.

2.1.5. Specification of Destinations

   R5:  Since P2MP LSPs have more than one destination, it MUST be
        possible for a single Path Computation Request to list multiple
        destinations.

2.1.6. Indication of P2MP Paths

   R6:  The Path Computation Response MUST be able to carry the path of
        a P2MP LSP.

   P2MP paths can be expressed as a compacted series of routes as
   described in [RFC4875]. The Path Computation Response MUST be able to
   carry the P2MP path as either a compacted path (but not necessarily
   using the identical encoding as described in [RFC4875]), or as a non-
   compacted path comprising a series of source-to-leaf point-to-point
   (P2P) paths (known as S2L sub-paths).

   R7:  By default, the path returned by the PCE SHOULD use the
        compacted format.

        The request from the PCC MAY allow the PCC to express a
        preference for receiving a compacted or non-compacted P2MP path
        in the response.

2.1.7. Multi-Message Requests and Responses

   R8:  A single P2MP LSP may have very many destinations, and the
        computed path (tree) may be very extensive. In these cases it is
        possible that the entire Path Computation Request or Response
        cannot fit within one PCE message. Therefore, it MUST be
        possible for a single request or response to be conveyed by a
        sequence of PCE messages.

   Note that there is a requirement in [RFC4657] for reliable and
   in-order message delivery, so it is assumed that components of the
   sequence will be delivered in order and without missing components.

2.1.8. Non-Specification of Per-Destination Constraints and Parameters

   [RFC4875] requires that all branches of a single P2MP LSP have the
   same characteristics, and achieves this by not allowing the signaling
   parameters to be varied for different branches of the same P2MP LSP.

   R9:  It MUST NOT be possible to set different constraints, traffic
        parameters, or quality of service requirements for different


S. Yasukawa and A. Farrel                                       [Page 4]

draft-ietf-pce-p2mp-req-03.txt                              October 2009


        destinations of a P2MP LSP within a single computation request.

2.1.9. Path Modification and Path Diversity

   R10: No changes are made to the requirement to support path
        modification and path diversity as described in [RFC4657]. Note,
        however, that a consequence of this requirement is that it MUST
        be possible to supply an existing path on a Path Computation
        Request. This requirement is unchanged from [RFC4657], but it is
        a new requirement that such paths MUST be able to be P2MP paths.
        The PCC MUST be able to supply these paths as compacted paths or
        as a non-compacted paths (see Section 2.1.6) according to the
        preference of the PCC.

2.1.10. Reoptimization of P2MP TE LSPs

   R11: Reoptimization MUST be supported for P2MP TE LSPs as described
        for P2P LSPs in [RFC4657]. To support this, the existing path
        MUST be supplied as described in Section 2.1.9.

        Because P2MP LSPs are more complex it is often the case that
        small optimization improvements can be made after changes in
        network resource availability. But re-signaling any LSP
        introduces risks to the stability of the service provided to the
        customer and the stability of the network even when techniques
        like make-before-break [RFC3209] are used. Therefore, a P2MP
        Path Computation Request SHOULD contain a parameter that allows
        the PCC to express a cost-benefit reoptimization threshold for
        the whole LSP as well as per destination. The setting of this
        parameter is subject to local policy at the PCC and SHOULD be
        subject to policy at the PCE [RFC5394].

        Path reoptimization responses SHOULD indicate which of the
        routes (as supplied according to Section 2.1.6) have been
        modified from the paths supplied on the request.

2.1.11. Addition and Removal of Destinations from Existing Paths

   A variation of path modification described in Section 2.1.9 is that
   destinations may be added to, or removed from, existing P2MP TE LSPs.

   In the case of the addition of one or more destinations, it is
   necessary to compute a path for a new branch of the P2MP LSP. It may
   be desirable to recompute the whole P2MP tree, to add the new branch
   as a simple spur from the existing tree, or to recompute part of the
   P2MP tree.




S. Yasukawa and A. Farrel                                       [Page 5]

draft-ietf-pce-p2mp-req-03.txt                              October 2009


   R12: To support this function for leaf additions it MUST be possible
        to make the following indications on a path computation request:

        - The path of an existing P2MP LSP (as described in Section
          2.1.9).

        - Which destinations are new additions to the tree.

        - Which destinations of the existing tree must not have their
          paths modified.

        It MAY also be possible to indicate on a path computation
        request a cost-benefit reoptimization threshold such that the
        addition of new leaves will not cause reoptimization of the
        existing P2MP tree unless a certain improvement is made over
        simply grafting the new leaves to the existing tree. (Compare
        with Section 2.1.10.)

        In the case of the deletion of one or more destinations, it is
        not necessary to compute a new path for the P2MP TE LSP, but
        such a computation may yield optimizations over a simple pruning
        of the tree. The recomputation function in this case is
        essentially the same as that described in Section 2.1.10, but
        note that it MAY be possible to supply the full previous path of
        the entire P2MP TE LSP (that is, before the deletion of the
        destinations) on the Path Computation Request.

        For both addition and deletion of destinations, the Path
        Computation Response SHOULD indicate which of the routes (as
        supplied according to Section 2.1.6) have been modified from the
        paths supplied on the request as described in Section 2.1.10.

        Note that the selection of all of these options is subject to
        local policy at the PCC, and SHOULD be subject to policy at the
        PCE [RFC5394].

2.1.12. Specification of Applicable Branch Nodes

   For administrative or security reasons, or for other policy reasons,
   it may be desirable to limit the set of nodes within the network that
   may be used as branch points for a given LSP. That is, to provide to
   the path computation a limiting set of nodes that can be used as
   branches for a P2MP path computation, or to provide a list of nodes
   that must not be used as branch points.

   R13: The PCC MUST be able to specify on a Path Computation Request a
        list of nodes that constitutes a limiting superset of the branch
        nodes for a P2MP path computation.


S. Yasukawa and A. Farrel                                       [Page 6]

draft-ietf-pce-p2mp-req-03.txt                              October 2009


        A PCC MUST be able to specify on a Path Computation Request a
        list of nodes that must not be used as branch nodes for a P2MP
        path computation.

2.1.13. Capabilities Exchange

   PCE capabilities exchange forms part of PCE discovery [RFC4674], but
   may also be included in the PCECP message exchanges [RFC4657].

   R14: The ability to perform P2MP path computation and the objective
        functions supported by a PCE SHOULD be advertised as part of PCE
        discovery. In the event that the PCE ability to perform P2MP
        computation is not advertised as part of PCE discovery, the
        PCECP MUST allow a PCC to discover which PCEs with which it
        communicates support P2MP path computation and which objective
        functions specific to P2MP path computation are supported by
        each PCE.

   The list of objective functions is assumed to be coordinated with
   those that can be requested as described in Section 2.1.2.

   These requirements do not represent a change to [RFC4657] except to
   add more capabilities and objective functions.

2.1.14. Path-Tree Diversity

   Section 2.1.9 sets out the requirement to be able to request multiple
   diverse paths. Additionally, with P2MP trees it may be that only
   parts of the tree can be, or need to be diverse.

   R15: The PCC SHOULD be able to request a PCE to compute a secondary
        P2MP path tree with partial path diversity for specific leaves
        or a specific S2L sub-path.

3. Manageability Considerations

3.1. Control of Function and Policy

   PCE implementations MAY provide a configuration switch to allow
   support of P2MP MPLS TE computations to be enabled or disabled. When
   the level of support is changed, this SHOULD be re-advertised as
   described in Section 2.1.13.

   Support for, and advertisement of support for, P2MP MPLS TE path
   computation MAY be subject to policy and a PCE MAY hide its P2MP
   capabilities from certain PCCs by not advertising them through the
   discovery protocol, and not reporting them to the specific PCCs in
   any PCECP capabilities exchange. Further, a PCE MAY be directed by


S. Yasukawa and A. Farrel                                       [Page 7]

draft-ietf-pce-p2mp-req-03.txt                              October 2009


   policy to refuse a P2MP path computation for any reason including,
   but not limited to, the identity of the PCC that makes the request.

3.2. Information and Data Models

   PCECP protocol extensions to support P2MP MPLS TE SHOULD be
   accompanied by MIB objects for the control and monitoring of the
   protocol and the PCE that performs the computations. The MIB objects
   MAY be provided in the same MIB module as used for general PCECP
   control and monitoring or MAY be provided in a new MIB module.

   The MIB objects SHOULD provide the ability to control and monitor all
   aspects of PCECP relevant to P2MP MPLS TE path computation.

3.3. Liveness Detection and Monitoring

   No changes are necessary to the liveness detection and monitoring
   requirements as already embodied in [RFC4657]. It should be noted,
   however, that in general P2MP computations are likely to take longer
   than P2P computations. The liveness detection and monitoring features
   of the PCECP SHOULD take this into account.

3.4. Verifying Correct Operation

   There are no additional requirements beyond those expressed in
   [RFC4657] for verifying the correct operation of the PCECP. Note that
   verification of the correct operation of the PCE and its algorithms
   is out of scope for the protocol requirements, but a PCC MAY send the
   same request to more than one PCE and compare the results.

3.5. Requirements on Other Protocols and Functional Components

   A PCE operates on a topology graph that may be built using
   information distributed by TE extensions to the routing protocol
   operating within the network. In order that the PCE can select a
   suitable path for the signaling protocol to use to install the P2MP
   LSP, the topology graph must include information about the P2MP
   signaling and branching capabilities of each LSR in the network.

   Whatever means is used to collect the information to build the
   topology graph, the graph MUST include the requisite information. If
   the TE extensions to the routing protocol are used, these SHOULD be
   as described in [RFC5073].

3.6. Impact on Network Operation

   The use of a PCE to compute P2MP paths is not expected to have
   significant impact on network operations. But it should be noted that


S. Yasukawa and A. Farrel                                       [Page 8]

draft-ietf-pce-p2mp-req-03.txt                              October 2009


   the introduction of P2MP support to a PCE that already provides P2P
   path computation might change the loading of the PCE significantly
   and that might have an impact on the network behavior especially
   during recovery periods immediately after a network failure.

4. Security Considerations

   P2MP computation requests do not raise any additional security issues
   for the PCECP as there are no new messages and no new PCC-PCE
   relationships or transactions introduced.

   Note, however, that P2MP computation requests are more CPU-intensive
   and also use more link bandwidth. Therefore, if the PCECP was
   susceptible to denial of service attacks based on the injection of
   spurious Path Computation Requests, the support of P2MP path
   computation would exacerbate the effect.

   It would be possible to consider applying different authorization
   policies for P2MP Path Computation Requests compared to other
   requests.

5. IANA Considerations

   This document makes no requests for IANA action.

6. Acknowledgments

   Thanks to Dean Cheng, Young Lee, Quintin Zhao, Daniel King, and
   Fabien Verhaeghe for their comments and suggestions on this document.

7. References

7.1. Normative Reference

   [RFC2119]      Bradner, S., "Key words for use in RFCs to indicate
                  requirements levels", RFC 2119, March 1997.

   [RFC4657]      Ash, J., and Le Roux, J.L., "Path Computation Element
                  (PCE) Communication Protocol Generic Requirements",
                  RFC 4657, September 2006.

   [RFC5394]      Bryskin, I., Papadimitriou, D., Berger, L., and Ash,
                  J., "Policy-Enabled Path Computation Framework",
                  RFC 5394, December 2008.

   [PCE-P2MP-APP] S. Yasukawa et al., "Applicability of the Path
                  Computation Element to Point-to-Multipoint Traffic
                  Engineering", draft-ietf-pce-p2mp-app, work in


S. Yasukawa and A. Farrel                                       [Page 9]

draft-ietf-pce-p2mp-req-03.txt                              October 2009


                  progress.


7.2. Informative Reference

   [RFC3209]      Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
                  V., and G. Swallow, "RSVP-TE:  Extensions to RSVP for
                  LSP Tunnels", RFC 3209, December 2001.

   [RFC4461]      S. Yasukawa, Editor "Signaling Requirements for
                  Point-to-Multipoint Traffic Engineered MPLS LSPs",
                  RFC4461, April 2006.

   [RFC4655]      Farrel, A., Vasseur, J.P., and Ash, G., "A Path
                  Computation Element (PCE)-Based Architecture",
                  RFC 4655, August 2006.

   [RFC4674]      J.L. Le Roux, Editor, "Requirements for Path
                  Computation Element (PCE) Discovery", RFC 4674,
                  October 2006.

   [RFC4834]      Morin, T., "Requirements for Multicast in Layer 3
                  Provider-Provisioned Virtual Private Networks
                  (PPVPNs)", RFC 4834, April 2007.

   [RFC4875]      Aggarwal, R., Papadimitriou, D., and Yasukawa, S.,
                  "Extensions to Resource Reservation Protocol - Traffic
                  Engineering (RSVP-TE) for Point-to-Multipoint TE Label
                  Switched Paths (LSPs)", RFC 4875, May 2007.

   [RFC5073]      Vasseur, J.P, and Le Roux, J.L., Editors, "IGP Routing
                  Protocol Extensions for Discovery of Traffic
                  Engineering Node Capabilities", RFC 5073, December
                  2007.

   [RFC5541]      Le Roux, J.L., Vasseur, J.P., and Lee, Y., "Encoding
                  of Objective Functions in the Path Computation Element
                  Communication Protocol (PCEP)", RFC 5541, June 2009.

8. Authors' Addresses

   Seisho Yasukawa
   NTT Corporation
   9-11, Midori-Cho 3-Chome
   Musashino-Shi, Tokyo 180-8585,
   Japan
   Email: yasukawa.seisho@lab.ntt.co.jp



S. Yasukawa and A. Farrel                                      [Page 10]

draft-ietf-pce-p2mp-req-03.txt                              October 2009

   Adrian Farrel
   Old Dog Consulting
   Email: adrian@olddog.co.uk

9. Full Copyright Statement

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.





































S. Yasukawa and A. Farrel                                      [Page 11]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/