Aggregate traffic management

Dear NANOGers,

I have a very hands-on question:
Suppose I am a network operator for a decent-sized ISP, and I decide
that I want to "divide" aggregate traffic flowing through a router
toward some destination, in order to then send some of it through one
route and the remainder through another route. Thus, I desire to
enforce some traffic engineering decision.

How would I be able to accomplish this "division"? What technologies
(even if vendor-specific) would I use?

I can think of some methods like prefix-matching classification and
ECMP, but I am still not sure exactly how the latter works in practice
(at the router level) and how one may set them up to achieve such
load-sharing.

Thank you for your expertise and lore,

How would I be able to accomplish this "division"? What technologies
(even if vendor-specific) would I use?

I can think of some methods like prefix-matching classification and
ECMP, but I am still not sure exactly how the latter works in practice
(at the router level) and how one may set them up to achieve such
load-sharing.

To my knowledge it is somewhat vendor specific. I've used policy routes and
tag switching in dividing and altering traffic flows. I do know that with
some vendors, it is important to make sure you activate the optimizations
for things such as policy routing to save mass amounts of cpu time. I'm
still a neophyte when it comes to tag switching. Others might help better in
that.

Jack Bates
BrightNet Oklahoma

It can be done several ways, but the question is "how are you differentiating"?

This is an incomplete list of methods for differentiating, each of which is supported by one or more vendors or open-source solutions:

  - destination address
    - specific prefix matching
    - prefix length matching (.../23, /24, etc.)
    - destination AS #
    - destination AS path length
    - destination (fill in the blank for other BGP or IGP specific tricks)
  - source address (see "destination address" for list of possible match criteria)
  - protocol (UDP, TCP, ICMP)
  - port (source or destination)
  - ToS bits
  - URL for port 80 traffic
  - MAC address of source machine
  - amount of throughput to a particular source/destination path

There are even some methods that don't differentiate, but do random traffic distribution (for some highly imperfect value of "random", which I won't debate here.)

  - round-robin gateway specification
  - DNS round-robin (limited use, usually for servers producing traffic)

If you could be more specific on what your distinguishing method would be for choosing one path over the other, some specific examples could be distilled from this group, I'm sure. <sarcasm> Though, of course, we here in North America don't have to worry ourselves about these issues, and we route everything through our most congested peer. </sarcasm>

Is this simply to get a survey of all possible routing decision concepts, or are you looking for answers only at one layer of the OSI model? You do say "router" in your description, but I'm still uncertain if that is a limiting factor in your question.

JT

Stanislav,

  It depends what control mechanism you are using:

   o routes learned via an IGP - ECMP would work and if it's a single
     destination host, per-packet loadbalancing between the outgoing
     links is your only practical choice; rest of ECMP schemes work
     by distributing flows or routes amongst links

   o learned via BGP and the traffic consists of a variety of flows
     that all use the same reachability information (BGP route); you
     could de-aggregate the announcement locally if you have an idea
     how the per-flow volume maps into the route; BGP Multipath feature
     set exists in most router implementations, but the distribution
     methods are statistically different

  For the latter, several systems exist in the market place that try
  to automate TE for BGP-learned routes, one of which is ours. These
  system require a closed feedback loop for traffic volume per flow
  and link mappings; this needs to occur close to real time to be
  effective.
  
    - Serge

Thus spake Stanislav Rost (stanrost@lcs.mit.edu):