RFC 5640

Load-Balancing for Mesh Softwires, August 2009

File formats:
icon for text file icon for PDF icon for HTML
Status:
PROPOSED STANDARD
Updated by:
RFC 9012
Authors:
C. Filsfils
P. Mohapatra
C. Pignataro
Stream:
IETF
Source:
softwire (int)

Cite this RFC: TXT  |  XML  |   BibTeX

DOI:  https://doi.org/10.17487/RFC5640

Discuss this RFC: Send questions or comments to the mailing list softwires@ietf.org

Other actions: Submit Errata  |  Find IPR Disclosures from the IETF  |  View History of RFC 5640


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. [STANDARDS-TRACK]


For the definition of Status, see RFC 2026.

For the definition of Stream, see RFC 8729.




Advanced Search