Skip to main content

PCEP Extensions for Signaling Multipath Information
draft-koldychev-pce-multipath-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Mike Koldychev , Siva Sivabalan , Tarek Saad , Vishnu Pavan Beeram , Hooman Bidgoli , Bhupendra Yadav
Last updated 2019-10-31
Replaced by draft-ietf-pce-multipath
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-koldychev-pce-multipath-00
Network Working Group                                       M. Koldychev
Internet-Draft                                              S. Sivabalan
Intended status: Informational                       Cisco Systems, Inc.
Expires: May 2, 2020                                             T. Saad
                                                               V. Beeram
                                                  Juniper Networks, Inc.
                                                              H. Bidgoli
                                                                   Nokia
                                                                B. Yadav
                                                                   Ciena
                                                        October 30, 2019

          PCEP Extensions for Signaling Multipath Information
                    draft-koldychev-pce-multipath-00

Abstract

   This document introduces a mechanism to communicate multipath
   information in PCEP as a set of Explicit Route Objects (EROs).  A
   special object is defined to carry per ERO attributes.  This
   mechanism is applicable to SR-TE and RSVP-TE.

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 May 2, 2020.

Copyright Notice

   Copyright (c) 2019 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

Koldychev, et al.          Expires May 2, 2020                  [Page 1]
Internet-Draft        PCEP Extensions for Multipath         October 2019

   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Terms and Abbreviations . . . . . . . . . . . . . . . . .   3
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Signaling Multiple Segment-Lists of an SR Candidate-Path    4
     3.2.  Splitting of Requested Bandwidth  . . . . . . . . . . . .   4
     3.3.  Providing Backup ERO for Protection . . . . . . . . . . .   4
   4.  Protocol Extensions . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Multipath Capability TLV  . . . . . . . . . . . . . . . .   4
     4.2.  ERO Attributes Object . . . . . . . . . . . . . . . . . .   5
     4.3.  Multipath Weight TLV  . . . . . . . . . . . . . . . . . .   6
     4.4.  Multipath Backup TLV  . . . . . . . . . . . . . . . . . .   6
   5.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Path Computation Element (PCE) Communication Protocol (PCEP)
   [RFC5440] enables the communication between a Path Computation Client
   (PCC) and a Path Control Element (PCE), or between two PCEs based on
   the PCE architecture [RFC4655].

   PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set
   of extensions to PCEP to enable active control of Multiprotocol Label
   Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS)
   tunnels.  [RFC8281] describes the setup and teardown of PCE-initiated

   LSPs under the active stateful PCE model, without the need for local
   configuration on the PCC, thus allowing for dynamic centralized
   control of a network.

   PCEP Extensions for Segment Routing [I-D.ietf-pce-segment-routing]
   specifies extensions to the Path Computation Element Protocol (PCEP)

Koldychev, et al.          Expires May 2, 2020                  [Page 2]
Internet-Draft        PCEP Extensions for Multipath         October 2019

   that allow a stateful PCE to compute and initiate Traffic Engineering
   (TE) paths, as well as a PCC to request a path subject to certain
   constraint(s) and optimization criteria in SR networks.

   Segment Routing Policy for Traffic Engineering
   [I-D.ietf-spring-segment-routing-policy] details the concepts of SR
   Policy and approaches to steering traffic into an SR Policy.  In
   particular, it describes the SR candidate-path as a collection of one
   or more Segment-Lists.  The current PCEP standards only allow for
   signaling of one Segment-List per Candidate-Path.  PCEP extension to
   support Segment Routing Policy Candidate Paths
   [I-D.barth-pce-segment-routing-policy-cp] specifically avoids
   defining how to signal multipath information, and states that this
   will be defined in another document (this one).

2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

2.1.  Terms and Abbreviations

   The following terms are used in this document:

   Endpoint:

      The IPv4 or IPv6 endpoint address of the SR policy in question, as
      described in [I-D.ietf-spring-segment-routing-policy].

   PCEP Tunnel:

      The object identified by the PLSP-ID, as per
      [I-D.koldychev-pce-operational].

   Tunnel Instance:

      The object identified by the LSP-Identifiers TLV, as per
      [I-D.koldychev-pce-operational].

3.  Motivation

   This extension is motivated by the use-cases described below.

Koldychev, et al.          Expires May 2, 2020                  [Page 3]
Internet-Draft        PCEP Extensions for Multipath         October 2019

3.1.  Signaling Multiple Segment-Lists of an SR Candidate-Path

   The Candidate-Path of an SR Policy corresponds to a PCEP Tunnel, see
   [I-D.barth-pce-segment-routing-policy-cp].  Each Candidate-Path can
   contain multiple Segment-Lists and each Segment-List is encoded by
   one SR-ERO object.  However, each Tunnel Instance can contain only a
   single ERO object, which prevents us from encoding multiple Segment-
   Lists within the same SR Candidate-Path.

   With the help of the protocol extensions defined in this document,
   this limitation is overcome.

3.2.  Splitting of Requested Bandwidth

   A PCC may request a path with 100 Gbit of bandwidth, but all links in
   the network have only 50 Gbit capacity.  The PCE can return two
   paths, that can each carry 50 Gbit.  The PCC can then equally or
   unequally split the incoming 100 Gbit of traffic among the two 50
   Gbit paths.  Section 4.3 introduces a new TLV that carries the ERO
   path weight that allows distributing of incoming traffic on to the
   multiple ERO path(s).

3.3.  Providing Backup ERO for Protection

   It is desirable for the PCE to compute and signal to the PCC a backup
   ERO path that is used to protect a primary ERO path.  In this case,
   an indication specify a primary or backup.

   When multipath is used, a backup ERO path may protect one or more
   primary ERO path.  For this reason, a primary and backup path
   identifiers are needed to indicate which backup ERO path(s) protect
   which primary ERO path(s).  Section 4.4 introduces a new TLV that
   carries the required information.

4.  Protocol Extensions

4.1.  Multipath Capability TLV

   We define the MULTIPATH-CAP TLV that MAY be present in the OPEN
   object and/or the LSP object.  The purpose of this TLV is two-fold:

   1.  From PCC: it tells how many multipaths the PCC can install in
       forwarding.

   2.  From PCE: it tells that the PCE supports this standard and how
       many multipaths the PCE can compute.

Koldychev, et al.          Expires May 2, 2020                  [Page 4]
Internet-Draft        PCEP Extensions for Multipath         October 2019

   Only the first instance of this TLV can be processed, subsequent
   instances SHOULD be ignored.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Number of Multipaths      |            Reserved       |B|W|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1: MULTIPATH-CAP TLV format

   Type: TBD1 for "MULTIPATH-CAP" TLV.

   Length: 4.

   Number of Multipaths: the maximum number of multipaths that a PCE can
   return.  The value 0 indicates unlimited number.

   B-flag: whether MULTIPATH-BACKUP-TLV is supported.

   W-flag: whether MULTIPATH-WEIGHT-TLV is supported.

   Reserved: zero on transmit, ignore on receipt.

4.2.  ERO Attributes Object

   We define the ERO-ATTRIB object that is used to carry per-ERO
   information and to act as a separator between several ERO objects.
   The ERO-ATTRIB object always precedes the ERO that it applies to.  If
   multiple ERO objects are present, then each ERO object MUST be
   preceded by an ERO-ATTRIB object that describes it.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Flags                           | Oper|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                          Optional TLVs                        ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 2: ERO-ATTRIB object format

   Flags: to be extended in the future.

   Oper: operational state of the ERO, same values as the identically
   named field in the LSP object.

Koldychev, et al.          Expires May 2, 2020                  [Page 5]
Internet-Draft        PCEP Extensions for Multipath         October 2019

4.3.  Multipath Weight TLV

   We define the MULTIPATH-WEIGHT TLV that MAY be present in the
   ERO_ATTRIBUTES object.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Weight                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 3: MULTIPATH-WEIGHT TLV format

   Type: TBD2 for "MULTIPATH-WEIGHT" TLV.

   Length: 4.

   Weight: weight of this path within the multipath, if W-ECMP is
   desired.  The fraction of flows a specific ERO carries is derived
   from the ratio of its weight to the sum of all other multipath ERO
   weights.

4.4.  Multipath Backup TLV

   This document introduces a new MULTIPATH-BACKUP TLV that is optional
   and can be present in the ERO_ATTRIBUTES object.

   This TLV is used to indicate the presence of a backup ERO path that
   is used for protection in case of failure of the primary ERO path.
   The format of the MULTIPATH-BACKUP TLV is:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Flags                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         ERO Path ID.                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Backup ERO Path ID                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 4: MULTIPATH-BACKUP TLV format

Koldychev, et al.          Expires May 2, 2020                  [Page 6]
Internet-Draft        PCEP Extensions for Multipath         October 2019

   Type: TBD3 for "MULTIPATH-BACKUP" TLV

   Length: 8

   Flags:

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |P|B|F|      Reserved                                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      P: If set, indicates the ERO is for a primary path

      B: If set, indicates the ERO is for a backup path

      F: If set, indicates this primary ERO is also protected.  The
      backup ERO Path ID indicates the ERO of the backup path.

   ERO Path ID: an identifier that identifies a primary path in the set
   of ERO(s)

   Backup ERO Path ID: an identifier that identifies the backup path ERO
   in the set of ERO(s)

5.  Operation

   When the PCC wants to indicate to the PCE that it wants to get
   multipaths instead of a single path, it can do one or both of the
   following:

   1.  Send the MULTIPATH-CAP TLV in the OPEN object during session
       establishment.  This applies to all PCEP Tunnels on the PCC,
       unless overridden by PCEP Tunnel specific information.

   2.  Send the MULTIPATH-CAP TLV in the LSP object for a particular
       PCEP Tunnel in the PCRpt message.  This applies to the specified
       PCEP Tunnel and overrides the information from the OPEN object.

   When PCE computes the path for a PCEP Tunnel, it MUST NOT return more
   multipaths than the corresponding value of "Number of Multipaths"
   from the MULTIPATH-CAP TLV.  If this TLV is absent (from both OPEN
   and LSP objects), then the "Number of Multipaths" is assumed to be 1.

   If the PCE supports this standard, then it MUST include the
   MULTIPATH-CAP TLV in the OPEN object.  This tells the PCC that it can
   report multiple ERO objects to this PCE.  If the PCE does not include
   the MULTIPATH-CAP TLV in the OPEN object, then the PCC MUST assume
   that the PCE does not support this standard and fall back to
   reporting only a single ERO.

Koldychev, et al.          Expires May 2, 2020                  [Page 7]
Internet-Draft        PCEP Extensions for Multipath         October 2019

6.  IANA Considerations

   IANA is requested to make the assignment of a new value for the
   existing "PCEP TLV Type Indicators" registry as follows:

   +------------+-----------------------------------+------------------+
   | TLV Type   | TLV Name                          | Reference        |
   | Value      |                                   |                  |
   +------------+-----------------------------------+------------------+
   | TBD1       | MULTIPATH-CAP                     | This document    |
   +------------+-----------------------------------+------------------+
   | TBD2       | MULTIPATH-WEIGHT                  | This document    |
   +------------+-----------------------------------+------------------+
   | TBD3       | MULTIPATH-BACKUP                  | This document    |
   +------------+-----------------------------------+------------------+

7.  Security Considerations

   None at this time.

8.  Acknowledgement

   Thanks to Dhruv Dhody for ideas and discussion.

9.  References

9.1.  Normative References

   [I-D.barth-pce-segment-routing-policy-cp]
              Koldychev, M., Sivabalan, S., Barth, C., and C. Li, "PCEP
              extension to support Segment Routing Policy Candidate
              Paths", draft-barth-pce-segment-routing-policy-cp-03 (work
              in progress), July 2019.

   [I-D.ietf-pce-segment-routing]
              Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
              and J. Hardwick, "PCEP Extensions for Segment Routing",
              draft-ietf-pce-segment-routing-16 (work in progress),
              March 2019.

   [I-D.ietf-spring-segment-routing-policy]
              Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
              bogdanov@google.com, b., and P. Mattes, "Segment Routing
              Policy Architecture", draft-ietf-spring-segment-routing-
              policy-03 (work in progress), May 2019.

Koldychev, et al.          Expires May 2, 2020                  [Page 8]
Internet-Draft        PCEP Extensions for Multipath         October 2019

   [I-D.koldychev-pce-operational]
              Koldychev, M., Sivabalan, S., Negi, M., Achaval, D., and
              H. Kotni, "PCEP Operational Clarification", draft-
              koldychev-pce-operational-00 (work in progress), July
              2019.

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

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009, <https://www.rfc-
              editor.org/info/rfc5440>.

   [RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for Stateful PCE", RFC 8231, DOI 10.17487/
              RFC8231, September 2017, <https://www.rfc-editor.org/info/
              rfc8231>.

   [RFC8281]  Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for PCE-Initiated LSP Setup in a Stateful PCE
              Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
              <https://www.rfc-editor.org/info/rfc8281>.

9.2.  Informative References

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/
              RFC4655, August 2006, <https://www.rfc-editor.org/info/
              rfc4655>.

Authors' Addresses

   Mike Koldychev
   Cisco Systems, Inc.

   Email: mkoldych@cisco.com

   Siva Sivabalan
   Cisco Systems, Inc.

   Email: msiva@cisco.com

Koldychev, et al.          Expires May 2, 2020                  [Page 9]
Internet-Draft        PCEP Extensions for Multipath         October 2019

   Tarek Saad
   Juniper Networks, Inc.

   Email: tsaad@juniper.net

   Vishnu Pavan Beeram
   Juniper Networks, Inc.

   Email: vbeeram@juniper.net

   Hooman Bidgoli
   Nokia

   Email: hooman.bidgoli@nokia.com

   Bhupendra Yadav
   Ciena

   Email: byadav@ciena.com

Koldychev, et al.          Expires May 2, 2020                 [Page 10]