[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
addition of TLV to locator ID or locator ID set
Summary: support for an additional TLV is required in order to allow for
a destination (sink) to signal to a source which links should be utilized
to carry traffic inbound to the destination (sink).
=================================================================
In the current IPv4 multihoming scenario, where de-aggregation is the
mechanism for inter-AS traffic engineering, a destination (sink) can
manipulate the routing announcements to control how traffic is loaded
across all of the inbound links to the destination (sink).
In the shim6 implementation it is up to the source to determine the order
of the locator ID set and choose which locator ID to send the traffic
to. The source lacks routing information, and the routing table lacks
information about the de-aggregates.
In order to allow the destination (sink) to control how traffic is loaded
across all of the inbound links to the destination, the destination must
send some clues to advise the source on how the locator IDs should be
ordered.
The suggestion is to attach one or more Type Length Values (TLVs) to a
locator ID or set of locator IDs when two shim6 capable hosts exchange
the locator ID set. A TLV similar to IS-IS will be flexible enough to
allow the destination to specify any type of inbound link preferences.
The TLV will consist of a type which will specify the sort preference
type and a value.
Initial TLV scould include:
1. Link Order -- lower value link order is always used before higher link
order
2. Round-robin -- value specified would weight the round-robin. No value
would result in a non-weighted round-robin for all locator IDs in the set.
3. Lowest latency -- paths with lower measured latency will be preferred
over paths with higher latency. A value set will be added or subtracted
to the measured value for biasing
Additional TLVs should be easily added.
Take for example, a destination that has six uplinks (1,2,3,4,5,6). Each
link is with a different ISP, and each host has an IP address associated
with each upstream ISP. Assume the destination wants the following
inbound link loading charastics:
Use links 1 and 2 as primary.
Use links 3 and 4 as secondary only if both links 1 and 2 fail
Use links 5 and 6 as tertiary only if links 1, 2, 3, and 4 all fail
In this case the destination needs to send additional information along
with the locator IDs to indicate that the source should order the set of
locator IDs such that the IP addresses associated with links 1 and 2 be
used first. This wil be followed by the set of IP addresses associated
with links 3 and 4 as second. Finally the set of IP addresses associated
with links 5 and 6 should be used third.
(1, 2) -- TLV type = link order, Value = 0
(3, 4) -- TLV type = link order, Value = 1
(5, 6) -- TLV type = link order, Value = 2
From a traffic engineering perspective you may find that a simple
round-robin loading of all the links at a particular level may not
result in the desired utilization on inbound links. This may be
from differnt sized flows that are being round-robined or due to
different sized links.
Take the case where link 1 is an OC-3 and link 2 is a DS-3. In this
case you would want the OC-3 to carry three times more traffic than
the DS-3. In this case, the destination may want to alter the pre-
existing policy (from above) such that link 1 carries 75% of the traffic
and link 2 carries only 25% of the traffic. This can be accomplished
by weighting the round-robin.
(1) -- TLV type = round-robin, Value = 0.75
(2) -- TLV type = round-robin, Value = 0.25
(1, 2) -- TLV type = link order, Value = 0
(3, 4) -- TLV type = link order, Value = 1
(5, 6) -- TLV type = link order, Value = 2
If this general approach seems reasonable, then some text will need to
be added to the shim6 architecture document to make a place holder for
the TLV.
An additional draft will need to be written to define the default
locator ID selection process, and how the TLVs will be used to modify
locator ID selection. It should also include the format of the TLVs,
current TLV types, and thier acceptable values, consideration of the
maximum number of TLVs, and what to do when mutliple conflicting TLVs
and applied a locator ID or locator ID set.
Some TLVs may also rely on a forwarding component in order to sort the
locator IDs. I wanted somethin analogous to the current BGP "best" path.
Since end hosts lack routing state, there will need to be another mechinism
to determine shortest path leveraging the forwarding plane. One method is
to measure the latency in the forwarding path. This seems that this solution
should be closely aligned to forwarding path failure detection problem space.
Thnaks for your comments,
___Jason
==========================================================================
Jason Schiller (703)886.6648
Senior Internet Network Engineer fax:(703)886.0512
Americas' Network Engineering schiller@uu.net
UUNET, an MCI brand jason.schiller@mci.com