Orchestrally conducted Traffic ( OCT )
draft-hummel-te-oct-03
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Heinrich K. Hummel | ||
| Last updated | 2000-04-18 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
This draft proposes to engineer traffic such that we can speak of an Orchestrally Conducted Traffic (OCT): Any traffic stream (given by its source and destination nodes and by a priority class) may use several differently routed LSPs. Each, traffic stream ingress reports, periodically, the currently measured traffic load (in bitrate) to a common TE Conductor (TEC) who evaluates them as to forecast what traffic load change might occur in the immediate time ahead. Accordingly the TEC computes well synchronized likelihood values by which to take which route/LSP. These values will be such that any traffic stream will be served as good as possible, as often as possible, while equally ranked traffic streams are treated fair, higher ranked streams are prioritized and the network thruput is maximized. The TEC sends the likelihood values to the respective ingress node, who will distribute the received packets of the traffic stream to the pertaining LSPs accordingly.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)