Internet DRAFT - draft-avantika-pce-multi-src-dest

draft-avantika-pce-multi-src-dest







PCE Working Group                                               U. Palle
Internet-Draft                                               Avantika. S
Intended status: Experimental                                   D. Dhody
Expires: August 18, 2014                             Huawei Technologies
                                                       February 14, 2014


    PCEP Extensions for Supporting Multiple Sources and Destinations
                  draft-avantika-pce-multi-src-dest-01

Abstract

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

   This document provides extensions for the Path Computation Element
   Protocol (PCEP) to support multiple sources and destinations in a
   single path request.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on August 18, 2014.

Copyright Notice

   Copyright (c) 2014 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Palle, et al.            Expires August 18, 2014                [Page 1]

Internet-Draft             PCE-MULTI-SRC-DEST              February 2014


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  PCEP Requirements . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Extension to PCEP . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  The New MP2MP END-POINTS Object . . . . . . . . . . . . .   6
   6.  Other Considerations  . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Identification of Source-Destination Pair in PCRep
           Message . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.2.  Request-ID  . . . . . . . . . . . . . . . . . . . . . . .   9
     6.3.  Backward Compatibility  . . . . . . . . . . . . . . . . .   9
     6.4.  Overloading the PCE . . . . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  Manageability Considerations  . . . . . . . . . . . . . . . .   9
     8.1.  Control of Function and Policy  . . . . . . . . . . . . .   9
     8.2.  Information and Data Models . . . . . . . . . . . . . . .  10
     8.3.  Liveness Detection and Monitoring . . . . . . . . . . . .  10
     8.4.  Verify Correct Operations . . . . . . . . . . . . . . . .  10
     8.5.  Requirements On Other Protocols . . . . . . . . . . . . .  10
     8.6.  Impact On Network Operations  . . . . . . . . . . . . . .  10
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  New END-POINTS Object Types . . . . . . . . . . . . . . .  10
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  10
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     11.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Appendix A.  Evaluation of Message Size Reduction . . . . . . . .  12

1.  Introduction

   [RFC5440] specifies the Path Computation Element Communication
   Protocol (PCEP) for communications between a Path Computation Client
   (PCC) and a Path Computation Element (PCE), or between two PCEs, in
   compliance with [RFC4657].

   As per [RFC5440], a single Path Computation Request (PCReq) message
   may carry more than one path computation request.  Each request is
   uniquely identified by a request-id number.  In some scenarios (refer
   Section 3), there is a need to send multiple requests with the same



Palle, et al.            Expires August 18, 2014                [Page 2]

Internet-Draft             PCE-MULTI-SRC-DEST              February 2014


   constraints and attributes to the PCE.  Currently these requests are
   either sent in a separate PCReq messages or clubbed together in one
   (or more) PCReq messages.  In either case, the constraints and
   attributes need to be encoded separately for each request even though
   they are exactly identical.

   Also note that, the PCE may choose to respond to each of the request
   independently in a separate Path Computation Reply (PCRep) messages
   or choose to bundle them in one (or more) PCRep messages.  In some
   scenarios (refer Section 3) one should wait for responses for all
   request before proceeding further.

   A mechanism to request path computation between multiple sources and
   destinations in a single path computation request would be helpful.

   Note that the scope of this work is point-to-point (P2P) path
   computation and is unrelated to MP2MP LSP ([RFC6388]).

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Terminology

   The following terminology is used in this document.

   LSR:  Label Switch Router.

   MPLS:  Multiprotocol Label Switching.

   NMS:  Network Management System.

   P2P:  Point-to-Point.

   PCC:  Path Computation Client.  Any client application requesting a
      path computation to be performed by a Path Computation Element.

   PCE:  Path Computation Element.  An entity (component, application,
      or network node) that is capable of computing a network path or
      route based on a network graph and applying computational
      constraints.

   PCEP:  Path Computation Element Communication Protocol.






Palle, et al.            Expires August 18, 2014                [Page 3]

Internet-Draft             PCE-MULTI-SRC-DEST              February 2014


3.  Motivation

   Following key scenarios are identified where a mechanism to request
   path computation between multiple sources and destinations in a
   single path computation request would be helpful.

   Hierarchical PCE:  [RFC6805] describes the procedure for inter-domain
      path computation using Hierarchical PCE.  In case of end to end
      path computation by Parent PCE, it needs to issue multiple path
      computation requests to child PCEs.  In case of transit domain(s),
      the Parent PCE issues requests from each entry boundary node to
      each exit boundary node to the child PCE(s).  Similarly for
      ingress domain, the Parent PCE issues requests from source to each
      exit boundary node, where as for egress domain, the Parent PCE
      issues requests from each entry boundary node to the destination.
      All requests to a particular child PCE, need to be encoded
      separately even though they are exactly identical (they have the
      same constraints and attributes).  Also the Parent PCE needs to
      wait for responses for all requests before proceeding further.

   Inter-Layer PCE:  [RFC5623] describes inter-layer path computation
      framework.  In case of cooperating PCEs per layer, where each PCE
      has topology visibility restricted to its own layer and
      collaborate to compute an end-to-end path across layers.  The
      higher layer PCE may need to issue multiple requests to lower
      layer PCE requesting paths from each entry boundary node to each
      exit boundary node.  All these requests need to be encoded
      separately even though they are exactly identical (they have the
      same constraints and attributes).  Also the higher layer PCE needs
      to wait for responses for all requests before proceeding further.

   Management-Based PCE:  [RFC4655] describes a case where PCC is not
      necessarily an LSR, but for example, maybe a NMS or a planning
      tool etc.  Such a PCC may issue multiple requests to PCE with
      identical constraints and attributes to select among the several
      source-destination pairs.

   Using Multiple P2P Path Computations for MP2MP TE LSP:  In case
      where, for establishing a MP2MP TE LSP tunnel, multiple P2P path
      computation requests are sent to the PCE, one for each source-
      destination pair with identical constraints and attributes.

   In these scenarios, a mechanism to request path computation between
   multiple sources and destinations in a single path computation
   request would be helpful.






Palle, et al.            Expires August 18, 2014                [Page 4]

Internet-Draft             PCE-MULTI-SRC-DEST              February 2014


3.1.  Example

   Consider the topology example mentioned in Section 4.6 of [RFC6805] -

    -----------------------------------------------------------------
   |   Domain 5                                                      |
   |                              -----                              |
   |                             |PCE 5|                             |
   |                              -----                              |
   |                                                                 |
   |    ----------------     ----------------     ----------------   |
   |   | Domain 1       |   | Domain 2       |   | Domain 3       |  |
   |   |                |   |                |   |                |  |
   |   |        -----   |   |        -----   |   |        -----   |  |
   |   |       |PCE 1|  |   |       |PCE 2|  |   |       |PCE 3|  |  |
   |   |        -----   |   |        -----   |   |        -----   |  |
   |   |                |   |                |   |                |  |
   |   |            ----|   |----        ----|   |----            |  |
   |   |           |BN11+---+BN21|      |BN23+---+BN31|           |  |
   |   |   -        ----|   |----        ----|   |----        -   |  |
   |   |  |S|           |   |                |   |           |D|  |  |
   |   |   -        ----|   |----        ----|   |----        -   |  |
   |   |           |BN12+---+BN22|      |BN24+---+BN32|           |  |
   |   |            ----|   |----        ----|   |----            |  |
   |   |                |   |                |   |                |  |
   |   |         ----   |   |                |   |   ----         |  |
   |   |        |BN13|  |   |                |   |  |BN33|        |  |
   |    -----------+----     ----------------     ----+-----------   |
   |                \                                /               |
   |                 \      ----------------        /                |
   |                  \    |                |      /                 |
   |                   \   |----        ----|     /                  |
   |                    ----+BN41|      |BN42+----                   |
   |                       |----        ----|                        |
   |                       |                |                        |
   |                       |        -----   |                        |
   |                       |       |PCE 4|  |                        |
   |                       |        -----   |                        |
   |                       |                |                        |
   |                       | Domain 4       |                        |
   |                        ----------------                         |
   |                                                                 |
    -----------------------------------------------------------------

                       Figure 1: An example topology

   The following 11 individual requests are generated by parent PCE (PCE
   5) -



Palle, et al.            Expires August 18, 2014                [Page 5]

Internet-Draft             PCE-MULTI-SRC-DEST              February 2014


   Domain 1:  S-BN11; S-BN12; S-BN13;

   Domain 2:  BN21-BN23; BN21-BN24; BN22-BN23; BN22-BN24;

   Domain 3:  BN31-D; BN32-D; BN33-D;

   Domain 4:  BN41-BN42;

   The above requests for each domain, need to be encoded separately
   even though they are exactly identical.  A mechanism to request them
   together in a single path computation request would be helpful, in
   which case total 4 requests would be generated by parent PCE.

4.  PCEP Requirements

   Following key requirements are identified for PCEP to enable multiple
   sources and destinations in a single path computation request:

   1.  It MUST be possible for a single Path Computation Request to list
       multiple sources and destinations.

   2.  It MUST be possible for a single Path Computation Reply to be
       sent for multiple sources and destinations.

   3.  It MUST NOT be possible to set different constraints, traffic
       parameters, or quality-of-service requirements for different
       source and destination pair within a single computation request.

5.  Extension to PCEP

   This document extends the existing END-POINTS object [RFC5440] and
   [RFC6006] by defining two new END-POINTS object types.

5.1.  The New MP2MP END-POINTS Object

   The END-POINTS object is used in a PCReq message to specify the
   source IP address and the destination IP address of the path for
   which a path computation is requested.  This document extends the
   existing END-POINT object to support multiple sources and
   destinations in a single path request.

   Two new MP2MP END-POINTS objects for IPv4 and IPv6 are defined.

   The format of the MP2MP END-POINTS object body for IPv4 (Object-
   Type=5 (TBD)) is as follows:






Palle, et al.            Expires August 18, 2014                [Page 6]

Internet-Draft             PCE-MULTI-SRC-DEST              February 2014


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      No of Sources  (2 bytes) |  No of Destinations  (2 bytes)|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Source IPv4 address 1 (4 bytes)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                           ......                              ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Source IPv4 address m (4 bytes)               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Destination IPv4 address 1 (4 bytes)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                           ......                              ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              Destination IPv4 address n (4 bytes)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 2: The new MP2MP END-POINTS Object Body Format for IPv4

   The format of the MP2MP END-POINTS object body for IPv6 (Object-
   Type=6 (TBD)) is as follows:





























Palle, et al.            Expires August 18, 2014                [Page 7]

Internet-Draft             PCE-MULTI-SRC-DEST              February 2014


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      No of Sources  (2 bytes) |  No of Destinations  (2 bytes)|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                 Source IPv6 address 1 (16 bytes)              |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                           ......                              ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                 Source IPv6 address m (16 bytes)              |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |              Destination IPv6 address 1 (16 bytes)            |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                           ......                              ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |              Destination IPv6 address n (16 bytes)            |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 3: The new MP2MP END-POINTS Object Body Format for IPv6

   The MP2MP END-POINTS object body has a variable length.  These are
   multiples of 4 bytes for IPv4, and multiples of 16 bytes for IPv6,
   plus 4 bytes.

   On receiving MP2MP END-POINTS object, PCE computes m*n P2P paths,
   i.e, point to point path is computed between each combination of
   source and destination received in MP2MP END-POINTS object.

6.  Other Considerations

6.1.  Identification of Source-Destination Pair in PCRep Message

   Since the END-POINTS object is not carried in the PCRep message
   ([RFC5440]), the implementation supporting this extension SHOULD
   encode the source and the destination as the first and the last hop




Palle, et al.            Expires August 18, 2014                [Page 8]

Internet-Draft             PCE-MULTI-SRC-DEST              February 2014


   in the ERO.  This is done to easily identify that which ERO
   corresponds to which source-destination pair.

6.2.  Request-ID

   As per [RFC5440], each request is uniquely identified by a request-id
   number.

   Since a single request is used for multiple sources and destinations
   sharing the same request-id number, along with request and response,
   the request-id number in RP object used in other PCEP messages
   (PCNtf, PCErr ...) applies to all sources and destinations (in the
   single request).

6.3.  Backward Compatibility

   If PCE receives new END-POINTS type in path request and it
   understands the END-POINTS type, but the PCE is not capable of/
   support multiple sources and destinations in a single path request,
   the PCE MUST send a PCErr message with a PCEP-ERROR Object Error-Type
   = 4 (Not supported object) [RFC5440].  The path computation request
   MUST then be cancelled.

   If the PCE does not understand the new END-POINTS type, then the PCE
   MUST send a PCErr message with a PCEP-ERROR Object Error-Type = 3
   (Unknown object) [RFC5440].

6.4.  Overloading the PCE

   The new END-POINTS type could be used to issue multiple computations
   together hence overloading the PCE.  The PCE MUST allow for the use
   of policies to accept/reject such a request.

7.  Security Considerations

   This document defines new END-POINTS types which does not add any new
   security concerns beyond those discussed in [RFC5440].

8.  Manageability Considerations

8.1.  Control of Function and Policy

   TBD.








Palle, et al.            Expires August 18, 2014                [Page 9]

Internet-Draft             PCE-MULTI-SRC-DEST              February 2014


8.2.  Information and Data Models

   TBD.

8.3.  Liveness Detection and Monitoring

   TBD.

8.4.  Verify Correct Operations

   TBD.

8.5.  Requirements On Other Protocols

   TBD.

8.6.  Impact On Network Operations

   TBD.

9.  IANA Considerations

   IANA assigns values to PCEP parameters in registries defined in
   [RFC5440].  IANA is requested to make the following additional
   assignments.

9.1.  New END-POINTS Object Types

   Two new END-POINTS Object-Types are defined in this document.  IANA
   is requested to make the following Object-Type allocations from the
   "PCEP Objects" sub-registry:

       Object-Class Value    4
       Name                  END-POINTS
       Object-Type           5: MP2MP IPv4
                             6: MP2MP IPv6
                             7-15: Unassigned
       Reference             This.I-D

10.  Acknowledgments

   Thanks to Quintin Zhao for his suggestions.

11.  References







Palle, et al.            Expires August 18, 2014               [Page 10]

Internet-Draft             PCE-MULTI-SRC-DEST              February 2014


11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

11.2.  Informative References

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

   [RFC5440]  Vasseur, JP. and JL. Le Roux, "Path Computation Element
              (PCE) Communication Protocol (PCEP)", RFC 5440, March
              2009.

   [RFC5623]  Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
              "Framework for PCE-Based Inter-Layer MPLS and GMPLS
              Traffic Engineering", RFC 5623, September 2009.

   [RFC6006]  Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z.,
              and J. Meuric, "Extensions to the Path Computation Element
              Communication Protocol (PCEP) for Point-to-Multipoint
              Traffic Engineering Label Switched Paths", RFC 6006,
              September 2010.

   [RFC6388]  Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
              "Label Distribution Protocol Extensions for Point-to-
              Multipoint and Multipoint-to-Multipoint Label Switched
              Paths", RFC 6388, November 2011.

   [RFC6805]  King, D. and A. Farrel, "The Application of the Path
              Computation Element Architecture to the Determination of a
              Sequence of Domains in MPLS and GMPLS", RFC 6805, November
              2012.














Palle, et al.            Expires August 18, 2014               [Page 11]

Internet-Draft             PCE-MULTI-SRC-DEST              February 2014


Appendix A.  Evaluation of Message Size Reduction

   Consider the domain 2 in Figure 1, where 4 path requests need to be
   encoded (from 2 entry boundary nodes to 2 exit boundary nodes with
   the exact same constraints).

   Following figure illustrates the existing mechanism of carrying
   multiple requests in single PCReq message (as per [RFC5440]):

             +--------------+ +--------------+ +--------------+
             |RP            | |RP            | |RP            |
   +-------+ |END-POINTS(8) | |END-POINTS    | |END-POINTS    |
   |COMMON |+|BANDWIDTH     |+|BANDWIDTH     |+|BANDWIDTH     |
   |HEADER | |METRIC        | |METRIC        | |METRIC        |
   +-------+ |METRIC        | |METRIC        | |METRIC        |
             +--------------+ +--------------+ +--------------+
   4 Bytes     36 Bytes         36 Bytes         36 Bytes

             +--------------+
             |RP            |
             |END-POINTS(20)|
           + |BANDWIDTH     | = 148 Bytes
             |METRIC        |
             |METRIC        |
             +--------------+
               36 Bytes

   Combining multiple requests into a single request by using MP2MP END-
   POINTS object is illustrated below:

             +--------------+
             |RP            |
   +-------+ |END-POINTS(20)|
   |COMMON |+|BANDWIDTH     | = 54 Bytes
   |HEADER | |METRIC        |
   +-------+ |METRIC        |
             +--------------+
   4 Bytes     48 Bytes

   There is message size reduction of 64% in this example for just one
   domain.

Authors' Addresses








Palle, et al.            Expires August 18, 2014               [Page 12]

Internet-Draft             PCE-MULTI-SRC-DEST              February 2014


   Udayasree Palle
   Huawei Technologies
   Leela Palace
   Bangalore, Karnataka  560008
   INDIA

   EMail: udayasree.palle@huawei.com


   Avantika
   Huawei Technologies
   Leela Palace
   Bangalore, Karnataka  560008
   INDIA

   EMail: avantika.sushilkumar@huawei.com


   Dhruv Dhody
   Huawei Technologies
   Leela Palace
   Bangalore, Karnataka  560008
   INDIA

   EMail: dhruv.ietf@gmail.com


























Palle, et al.            Expires August 18, 2014               [Page 13]