Internet-Draft PCE-MULTI-SRC-DEST February 2014
Palle, et al. Expires 1 September 2014 [Page]
Workgroup:
PCE Working Group
Internet-Draft:
draft-avantika-pce-multi-src-dest-01
Published:
Intended Status:
Experimental
Expires:
Authors:
U. Palle
Huawei Technologies
Avantika. S
Huawei Technologies
D. Dhody
Huawei Technologies

PCEP Extensions for Supporting Multiple Sources and Destinations

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 5 August 2014.

▲

Table of Contents

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

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.

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) -

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:

     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:

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

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

11.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC4657]
Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, , <https://www.rfc-editor.org/info/rfc4657>.

11.2. Informative References

[RFC4655]
Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, , <https://www.rfc-editor.org/info/rfc4655>.
[RFC5440]
Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, , <https://www.rfc-editor.org/info/rfc5440>.
[RFC5623]
Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, , <https://www.rfc-editor.org/info/rfc5623>.
[RFC6006]
Zhao, Q., Ed., King, D., Ed., 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, DOI 10.17487/RFC6006, , <https://www.rfc-editor.org/info/rfc6006>.
[RFC6388]
Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, DOI 10.17487/RFC6388, , <https://www.rfc-editor.org/info/rfc6388>.
[RFC6805]
King, D., Ed. and A. Farrel, Ed., "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 10.17487/RFC6805, , <https://www.rfc-editor.org/info/rfc6805>.

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

Udayasree Palle
Huawei Technologies
Leela Palace
Bangalore 560008
Karnataka
India
Avantika
Huawei Technologies
Leela Palace
Bangalore 560008
Karnataka
India
Dhruv Dhody
Huawei Technologies
Leela Palace
Bangalore 560008
Karnataka
India