Load-Balancing for Mesh Softwires
RFC 5640
Document | Type | RFC - Proposed Standard (August 2009; No errata) | |
---|---|---|---|
Authors | Clarence Filsfils , Prodosh Mohapatra , Carlos Pignataro | ||
Last updated | 2015-10-14 | ||
Replaces | draft-pmohapat-softwire-lb | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5640 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ralph Droms | ||
Send notices to | (None) |
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",Show full document text