Load-Balancing for Mesh Softwires
RFC 5640

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

Network Working Group                                        C. Filsfils
Request for Comments: 5640                                  P. Mohapatra
Category: Standards Track                                   C. Pignataro
                                                           Cisco Systems
                                                             August 2009

                   Load-Balancing for Mesh Softwires

Abstract

   Payloads transported over a Softwire mesh service (as defined by BGP
   Encapsulation Subsequent Address Family Identifier (SAFI) information
   exchange) often carry a number of identifiable, distinct flows.  It
   can, in some circumstances, be desirable to distribute these flows
   over the equal cost multiple paths (ECMPs) that exist in the packet
   switched network.  Currently, the payload of a packet entering the
   Softwire can only be interpreted by the ingress and egress routers.
   Thus, the load-balancing decision of a core router is only based on
   the encapsulating header, presenting much less entropy than available
   in the payload or the encapsulated header since the Softwire
   encapsulation acts in a tunneling fashion.  This document describes a
   method for achieving comparable load-balancing efficiency in a
   network carrying Softwire mesh service over Layer Two Tunneling
   Protocol - Version 3 (L2TPv3) over IP or Generic Routing
   Encapsulation (GRE) encapsulation to what would be achieved without
   such encapsulation.

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Filsfils, et al.            Standards Track                     [Page 1]
RFC 5640           Load-Balancing for Mesh Softwires         August 2009

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 2
   2.  Load-Balancing Block sub-TLV  . . . . . . . . . . . . . . . . . 2
     2.1.  Applicability to Tunnel Types . . . . . . . . . . . . . . . 3
     2.2.  Encapsulation Considerations  . . . . . . . . . . . . . . . 4
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 4
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5

1.  Introduction

   Consider the case of a router R1 that encapsulates a packet P into a
   Softwire bound to router R3.  R2 is a router on the shortest path
   from R1 to R3.  R2's shortest path to R3 involves equal cost multiple
   paths (ECMPs).  The goal is for R2 to be able to choose which path to
   use on the basis of the full entropy of packet P.

   This is achieved by carrying in the encapsulation header a signature
   of the inner header, hence enhancing the entropy of the flows as seen
   by the core routers.  The signature is carried as part of one of the
   fields of the encapsulation header.  To aid with better description
   in the document, we define the generic term "load-balancing field" to
   mean such a value that is specific to an encapsulation type.  For
   example, for L2TPv3-over-IP [RFC3931] encapsulation, the load-
   balancing field is the Session Identifier (Session ID).  For GRE
   [RFC2784] encapsulation, the Key field [RFC2890], if present,
   represents the load-balancing field.  This mechanism assumes that
   core routers base their load-balancing decisions on a flow definition
   that includes the load-balancing field.  This is an obvious and
   generic functionality as, for example, for L2TPv3-over-IP tunnels,
   the Session ID is at the same well-known constant offset as the TCP/
   UDP ports in the encapsulating header.

   The Encapsulation SAFI [RFC5512] is extended such that a contiguous
   block of the load-balancing field is bound to the Softwire advertised
   by a BGP next-hop.  On a per-inner-flow basis, the ingress Provider
   Edge (PE) selects one value of the load-balancing field from the
   block to preserve per-flow ordering and, at the same time, to enhance
   the entropy across flows.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",