Load-Balancing for Mesh Softwires
RFC 5640
|
| Document |
Type |
|
RFC - Proposed Standard
(August 2009; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Replaces |
|
draft-pmohapat-softwire-lb
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
|
Reviews |
|
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 5640 (Proposed Standard)
|
|
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
Show full document text