Skip to main content

The Use of MPLS Special Purpose Labels for the Computation of Load Balancing
draft-pignataro-mpls-reserved-labels-lb-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 "Expired".
Authors Carlos Pignataro , Loa Andersson , Kireeti Kompella
Last updated 2013-01-25
RFC stream (None)
Formats
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-pignataro-mpls-reserved-labels-lb-00
Network Working Group                                       C. Pignataro
Internet-Draft                                       Cisco Systems, Inc.
Updates:  4928, 6790 (if approved)                          L. Andersson
Intended status:  Standards Track                    Huawei Technologies
Expires:  July 29, 2013                                      K. Kompella
                                                        Juniper Networks
                                                        January 25, 2013

   The Use of MPLS Special Purpose Labels for the Computation of Load
                               Balancing
               draft-pignataro-mpls-reserved-labels-lb-00

Abstract

   In addition to being used for forwarding, an MPLS label stack may
   also be used as an entropy source to perform load balancing
   computation in various ways.  RFC 4928 and RFC 6790 describe this
   mechanism in great detail.  However, those two RFCs differ in the use
   of MPLS special purpose labels (previously referred to as "reserved
   labels") for computation of load balancing.  This document restricts
   the use of MPLS special purpose labels for computation of load
   balancing, clarifying the difference in specifications.

   This document updates RFC 4928 and RFC 6790.

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

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 July 29, 2013.

Pignataro, et al.         Expires July 29, 2013                 [Page 1]
Internet-Draft         MPLS Reserved Labels and LB          January 2013

Copyright Notice

   Copyright (c) 2013 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
   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  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  MPLS Reserved Labels and Load Balancing . . . . . . . . . . . . 3
     2.1.  Current Specifications  . . . . . . . . . . . . . . . . . . 3
     2.2.  Detail of Updates . . . . . . . . . . . . . . . . . . . . . 4
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   5.  Normative References  . . . . . . . . . . . . . . . . . . . . . 4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 4

Pignataro, et al.         Expires July 29, 2013                 [Page 2]
Internet-Draft         MPLS Reserved Labels and LB          January 2013

1.  Introduction

   In addition to being used for forwarding, an MPLS label stack may
   also be used as an entropy source to perform load balancing
   computation in various ways.  RFC 4928 and RFC 6790 describe this
   mechanism in great detail.  However, those two RFCs defer in the use
   of MPLS special purpose labels (previously referred to as "reserved
   labels") for computation of load balancing.  This document restricts
   the use of MPLS special purpose labels for computation of load
   balancing, clarifying the difference in specifications.

   This document updates RFC 4928 and RFC 6790.

2.  MPLS Reserved Labels and Load Balancing

2.1.  Current Specifications

   This section highlights current specifications relating to the usage
   of MPLS special purpose labels for purposes of load balancing
   computation.

   [RFC4928] states that special purpose labels ("reserved labels") may
   be used for load balancing, and describes current ECMP practice as
   follows:

      It must also be noted that LSRs that correctly identify a payload
      as not being IP most often will load-share traffic across multiple
      equal-cost paths based on the label stack.  Any reserved label, no
      matter where it is located in the stack, may be included in the
      computation for load balancing.  Modification of the label stack
      between packets of a single flow could result in re-ordering that
      flow.  That is, were an explicit null or a router-alert label to
      be added to a packet, that packet could take a different path
      through the network.

   [RFC6790], conversely, succintly states that special purpose labels
   ("reserved labels") MUST NOT be used for load balancing:

      If a transit LSR recognizes the ELI, it MAY choose to load balance
      solely on the following label (the EL); otherwise, it SHOULD use
      as much of the whole label stack as feasible as keys for the load-
      balancing function.  In any case, reserved labels MUST NOT be used
      as keys for the load-balancing function.

Pignataro, et al.         Expires July 29, 2013                 [Page 3]
Internet-Draft         MPLS Reserved Labels and LB          January 2013

2.2.  Detail of Updates

   There are several MPLS special purpose labels.  MPLS special purpose
   labels have special meaning both in the control plane and the data
   plane, including an indication for OAM.  OAM packets not taking the
   same path as data packets defeats their purpose.  Consequently, this
   document updates RFC 4928 and RFC 6790 by specifying that:

      MPLS special purpose labels MUST NOT be used as input into the
      load balancing computation.

3.  IANA Considerations

   This document makes no request of IANA.

   [Note to RFC Editor:  this section may be removed on publication as
   an RFC.]

4.  Security Considerations

   This document updates RFC 4928 and RFC 6790 by specifying that MPLS
   special purpose labels are not used as input into the load-balancing
   computations.  This update does not impose any new security
   considerations.

5.  Normative References

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

   [RFC4928]  Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
              Cost Multipath Treatment in MPLS Networks", BCP 128,
              RFC 4928, June 2007.

   [RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
              L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
              RFC 6790, November 2012.

Pignataro, et al.         Expires July 29, 2013                 [Page 4]
Internet-Draft         MPLS Reserved Labels and LB          January 2013

Authors' Addresses

   Carlos Pignataro
   Cisco Systems, Inc.

   Email:  cpignata@cisco.com

   Loa Andersson
   Huawei Technologies

   Email:  loa@mail01.huawei.com

   Kireeti Kompella
   Juniper Networks

   Email:  kireeti.kompella@gmail.com

Pignataro, et al.         Expires July 29, 2013                 [Page 5]