Load-Balancing for Mesh Softwires, August 2009
- File formats:
- PROPOSED STANDARD
- Updated by:
- RFC 9012
- C. Filsfils
- softwire (int)
Cite this RFC: TXT | XML | BibTeX
Discuss this RFC: Send questions or comments to the mailing list firstname.lastname@example.org
Other actions: Submit Errata | Find IPR Disclosures from the IETF | View History of RFC 5640
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.