Technical Summary
Load balancing, or multi-pathing, is an attempt to balance traffic
across a network by allowing the traffic to use multiple paths. Load
balancing has several benefits: it eases capacity planning; it can
help absorb traffic surges by spreading them across multiple paths;
it allows better resilience by offering alternate paths in the event
of a link or node failure.
As providers scale their networks, they use several techniques to
achieve greater bandwidth between nodes. Two widely used techniques
are: Link Aggregation Group (LAG) and Equal-Cost Multi-Path (ECMP).
For MPLS networks, most of the same tecniques apply.
However, finding useful keys in a packet for the purpose of load
balancing can be more of a challenge. In many cases, MPLS
encapsulation may require fairly deep inspection of packets to find
these keys at transit LSRs.
One way to eliminate the need for this deep inspection is to have the
ingress LSR of an MPLS Label Switched Path extract the appropriate
keys from a given packet, input them to its load balancing function,
and place the result in an additional label, termed the 'entropy
label', as part of the MPLS label stack it pushes onto that packet.
This docuement assumes that a method are used by the ingress nodes,
e.g. use certain fields, termed 'keys', within a packet's header
as input to a load balancing function (typically a hash function) that
selects the path for all packets in a given flow.
For MPLS networks this document specifies how an entropy and entropy
label indicator is introduced into the label stack. In MPLS networks
the packet's MPLS entire label stack can then be used by transit LSRs
to perform load balancing, as the entropy label introduces the right
level of "entropy" into the label stack.
Working Group Summary
This document has a strong support in the working group
and has been well reviewed. We have had good discussions both
on the mailing list and at the meetings in Paris.
The working last call high-lighted an issues, that was decided
to not have an effect on this draft, but the working group chairs
has initiated a separate discussion that were started at the
Vancouver meeting. This is has to do with how an LSRs should
behave if it can't inspect the entire label stack and how the use
of entropy labels will cooperate with MPLS OAM..
Document Quality
We know of one implementation, that yet has to be completed;
and several vendors have indicated that they intend to implement
this specification.
Personnel
Loa Andersson is the document shepherd.
Adrian Farrel is/ the responsible AD.
RFC Editor Note
Section 1.2
OLD
On the other hand, an ingress LSR (e.g., a PE router) has detailed
knowledge of an packet's contents, typically through a priori
configuration of the encapsulation(s) that are expected at a given
PE-CE interface, (e.g., IPv4, IPv6, VPLS, etc.). They also have more
flexible forwarding hardware. PE routers need this information and
these capabilities to:
NEW
On the other hand, an ingress LSR (e.g., a PE router) has detailed
knowledge of a packet's contents, typically through a priori
configuration of the encapsulations that are expected at a given
PE-CE interface, (e.g., IPv4, IPv6, VPLS, etc.). They may also have
more flexible forwarding hardware, depending on implementation
details. PE routers need this information and these capabilities to:
END
---
Section 3
s/[IANA MPLS Label Values]/[RFC3032]/
---
Section 4.1
s/If an ingress X/If an ingress LSR X/
---
Section 5.4
s/companion document./future document./
---
Section 8
OLD
This section describes the use of entropy labels in various
scenarios.
NEW
This section describes the use of entropy labels in various
scenarios. The material in this section is illustrative and offers
guidance to implementations, but does not form a normative part of
this specification.
END
---
Section 9
OLD
Given that there is no end-user control over the values used for
entropy labels, there is little risk of Entropy Label forgery which
could cause uneven load-balancing in the network.
NEW
Given that there is no end-user control over the values used for
entropy labels, there is little risk of Entropy Label forgery which
could cause uneven load-balancing in the network.
Note that if the EL value is calculated only based on packet headers,
then a relatively efficient wiretapping interface could be added
depending on the function used to generate the EL value. An
implementation may protect against this by adding some other input to
the generation of the EL values that would make it harder to build a
table of EL values to tap given knowledge of the keys from the
packet. For example the ingress LSR could generate a random input to
the EL generation process. In practice, many ECMP hashing algorithms
contain a random factor in any case so as to avoid polarization
issues.
END
IANA Note
This is a "strong request" for specific allocations to facilitate early implementations.
IANA should consider itself free to select other values if necessary, but if there is
free choice, it would be appreciated if the values indicated below were allocated.
In Section 10.1 the allocation of an MPLS Reserved Label is requested.
Please allocate label 7 as the Entropy Label Indicator (ELI)
In Section 10.2 the allocation of an LDP TLV Type is requested.
Please allocate type 0x0206 for the Entropy Label Capability TLV