One document matched: draft-yasukawa-pce-p2mp-req-00.txt

Network Working Group                                    Seisho Yasukawa
Internet Draft                                                       NTT
Category: Informational                                    Adrian Farrel
Expires: August 2006                                  Old Dog Consulting
                                                           February 2006

      PCC-PCE Communication Requirements for Point to Multipoint
                           Traffic Engineering

                      draft-yasukawa-pce-p2mp-req-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.

Abstract

   The Path Computation Element (PCE) provides functions of path
   computation 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 traffic engineered point-to-multipoint (P2MP)
   label switched paths (LSPs). Since P2MP LSP routes are sometimes
   complex to compute, and given the use of PCE in MPLS networks it is
   likely that PCE will be used in P2MP MPLS networks.

   Generic requirements for a communication protocol between Path
   Computation Clients (PCCs) and PCEs are presented in "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
   traffic engineering.

Yasukawa                     Expires August 2006                [Page 1]

draft-yasukawa-pce-p2mp-req-00.txt                         February 2006

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. Introduction

   The Path Computation Element (PCE) defined in [PCE-ARCH] 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 [P2MP-REQ] and signaling protocol extensions are
   defined in [P2MP-RSVP]. P2MP MPLS TE networks are currently being
   planned by service provides in support of various features including
   layer 3 multicast VPNs.

   Path computation for P2MP LSPs presents a significant challenge and
   network optimization of multiple P2MP TE LSPs will require
   considerable computational resources. PCE offers a way to offload
   such path computations from LSRs.

   The applicability of the PCE-based path computation architecture to
   point-to-multipoint MPLS traffic engineering 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 [PCE-COM-REQ].

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

   This section sets out additional requirements not covered in
   [PCE-COM-REQ] specific to the problems of 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 implies the following
  additional constraints to be added to the PCC-PCE communication
  protocol.



Yasukawa                     Expires August 2006                [Page 2]

draft-yasukawa-pce-p2mp-req-00.txt                         February 2006

2.1.1. Indication of P2MP Path Computation Request

   Although the presence of certain parameters (such as a list of more
   than one destination) may be used 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. Non-Support of P2MP Path Computation

   Not all PCEs are 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.3. 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 flag described in section 2.1.1. Therefore at
   least one parameter required for P2MP path computation (possibly
   including the flag described in section 2.1.1) 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.

2.1.4. Specification of Destinations

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

2.1.5. Indication of P2MP Paths

   The Path Computation Response MUST be able to carry the path of a
   P2MP LSP. This SHOULD be expressed as a compacted series of routes as
   described in [P2MP-RSVP] although not necessarily using an identical
   encoding. This MAY be expressed as a non-compacted series of
   source-to-destination routes.

2.1.6. Multi-Message Requests and Responses

   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 messages.

   Note that there is a requirement in [PCE-COM-REQ] for reliable and
   in-order message delivery, so it is assumed that components of the

Yasukawa                     Expires August 2006                [Page 3]

draft-yasukawa-pce-p2mp-req-00.txt                         February 2006

   sequence will be delivered in order and without missing items.

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

   It MUST NOT be possible to set different constraints, traffic
   parameters, or quality of service requirements for different
   destination of a P2MP LSP within a single computation request.

2.1.8. Path Modification and Path Diversity

   No changes are made to the requirement to support path modification
   and path diversity as described in [PCE-COM-REQ]. 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 as well, but it is a new requirement that
   such paths MUST be able to be P2MP paths.

2.1.9. Capabilities Exchange

   PCE capabilities exchange forms part of PCE discovery [PCE-DISCO],
   but MAY also be included in the PCECP message exchanges.

   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.

3. Manageability Considerations

   Manageability of P2MP MPLS TE with PCE must address the following
   considerations.

   - Need for a MIB module for control and monitoring.
   - Need for built-in diagnostic tools.
   - Configuration implications for the protocol.

4. Security Considerations

   P2MP computation requests do not raise any additional security issues
   for the PCECP.

   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

Yasukawa                     Expires August 2006                [Page 4]

draft-yasukawa-pce-p2mp-req-00.txt                         February 2006

   requests.

5. IANA Considerations

   This document makes no requests for IANA action.

6. Acknowledgments

   TBD

7. References

7.1. Normative Reference

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

   [PCE-COM-REQ]  J. Ash, J.L Le Roux et al., "PCE Communication
                  Protocol Generic Requirements",
                  draft-ietf-pce-comm-protocol-gen-reqs (work in
                  progress).

7.2. Informative Reference

   [PCE-ARCH]     A. Farrel, JP. Vasseur and J. Ash, "Path Computation
                  Element (PCE) Architecture",
                  draft-ietf-pce-architecture (work in progress).

   [PCE-DISCO]    JL Le Roux et al., "Requirements for Path Computation
                  Element (PCE) Discovery",
                  draft-ietf-pce-discovery-reqs (work in progress).

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

   [P2MP-REQ]     Yasukawa, S. (Editor), "Signaling Requirements for
                  Point to Multipoint Traffic Engineered MPLS LSPs",
                  draft-ietf-mpls-p2mp-sig-requirement, (work in
                  progress).

   [P2MP-RSVP]    Aggarwal, R., Papadimitriou, D., and Yasukawa, S.,
                  "Extensions to RSVP-TE for Point to Multipoint TE
                  LSPs", draft-ietf-mpls-rsvp-te-p2mp, (work in
                  progress).





Yasukawa                     Expires August 2006                [Page 5]

draft-yasukawa-pce-p2mp-req-00.txt                         February 2006

8. Authors' Addresses

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

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

9. 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 (2006).  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.

Yasukawa                     Expires August 2006                [Page 6]