Search RFCs

RFC Editor

File formats:

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 listsoftwires@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 BGPEncapsulation Subsequent Address Family Identifier (SAFI) informationexchange) often carry a number of identifiable, distinct flows. Itcan, in some circumstances, be desirable to distribute these flowsover the equal cost multiple paths (ECMPs) that exist in the packetswitched network. Currently, the payload of a packet entering theSoftwire can only be interpreted by the ingress and egress routers.Thus, the load-balancing decision of a core router is only based onthe encapsulating header, presenting much less entropy than availablein the payload or the encapsulated header since the Softwireencapsulation acts in a tunneling fashion. This document describes amethod for achieving comparable load-balancing efficiency in anetwork carrying Softwire mesh service over Layer Two TunnelingProtocol - Version 3 (L2TPv3) over IP or Generic RoutingEncapsulation (GRE) encapsulation to what would be achieved withoutsuch encapsulation. [STANDARDS-TRACK]

For the definition ofStatus,seeRFC 2026.

For the definition ofStream, seeRFC 8729.