Internet Draft TE Working Group Heinrich Hummel Internet Draft Siemens AG Expiration Date: March 2000 October 1999 Orchestrally conducted Traffic ( OCT ) draft-hummel-te-oct-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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), shall be served as best as possible (i.e. by using best-routed LSPs as often as possible) - which means eventually less optimally routed LSPs or even not at all, according to the current traffic load and the currently expected increase/decrease of the entire traffic. Fairness and appropriate/deliberate discrimination as well as optimal thruput will be achieved. The OCT concept assumes an information exchange between the source nodes of all traffic streams and a common TE conductor (TEC). This OCT concept is alternative to concepts where each traffic stream is its own conductor, i.e. decides all by itself without mutual synchronization which routes/LSPs to take. Hummel Oct 1999 [Page 1] Orchestrally conducted Traffic (OCT) Exp. March 2000 1. Introduction 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), shall be served as best as possible (i.e. by using best-routed LSPs as often as possible) - which means eventually less optimally routed LSPs or even not at all, according to the current traffic load and the currently expected increase/decrease of the entire traffic. Fairness and appropriate/deliberate discrimination as well as optimal thruput will be achieved. The OCT concept assumes an information exchange between the source nodes of all traffic streams and a common TE conductor (TEC). This OCT concept is alternative to concepts where each traffic stream is its own conductor, i.e. decides all by itself without mutual synchronization which routes/LSPs to take. 2. Observations and considerations Traffic engineering means monitoring, controlling and, yes, conducting all the traffic within a particular network domain. Let us partition the whole traffic into traffic streams, each of which is given by an information-triplet {source node, destination node, priority class}. At a particular moment in time zero, one or more LSPs may exist serving a particular traffic stream. Furthermore we should differentiate between two types of traffic streams: a) voice/video-traffic stream, served by on-demand established LSP, whereby each LSP needs a well- defined amount of bandwidth b) Best-Effort/Diffserv data-traffic streams, served by several pre-established LSPs, using different routes,without bandwidth reservation (or at most using UBR with MCR). TE-task with regard to voice/video: Which route shall be taken when an LSP is to be established for a new connection request? TE-task with regard to Data traffic: Which of several, differently routed LSPs shall be used for sending the next packets? Hereby OCT-objectives are: - Balance the routes/LSPs to be taken such that traffic congestion Hummel Oct 1999 [Page 2] Orchestrally conducted Traffic (OCT) Exp. March 2000 is avoided as much as possible. - Dissolve smoothly a situation which is or which is almost a congestion, i.e. do not create another congestion at another location instead. - Generate long-term information regarding permanent over/under- utilization of network resources. - Be fair to the equal-ranked rest of the traffic, discriminate the lower-ranked rest of the traffic, endure discrimination imposed by higher-ranked traffic. A bad example (many conductors): Consider a highway with two lanes. All cars drive on the right lane. Because the overall speed gets too slow, each driver decides all by itself to change the lane. Result: There is no improvement when all cars drive on the left lane. A good example (one conductor): When you get close to Munich on the German Autobahn from Berlin to Munich you will see electronic speed limit signs at the points A (near Pfaffenhofen about 40 km north from Munich), B (near Allershausen about 30 km north from Munich) and C (near Eching about 20 km north from Munich). At each point the passing cars are -electronically- counted and reported to a traffic engineering computer. The computer evaluates these numbers and, from time to time,commands each traffic sign to display an updated speed limit, e.g. like: no limit, 120 km/h, 100 km/h, 80 km/h, 60 km/h. Hereby, the displayed speed limits at the points A, B, and C are well SYNCHRONIZED. (Regrettably this system does not tell the car drivers which alternative country roads to drive. Indeed, that would even be a better example of the problem which the TE-WG is going to tackle.) An important aspect: Changes are made moderately. What would happen if the traffic sign at location A switched from "no limit" down to "60 km/h"? Of course, that would relieve a congestion closest to Munich dramatically. However, it would also induce a traffic congestion right away at point A itself. The message is: In order to dissolve a congestion, do not shift a traffic stream entirely from route R1 to route R2. It may just relocate the point of congestion. Instead, reroute the traffic stream GRADUALLY and of course in synchronization with all others. Hummel Oct 1999 [Page 3] Orchestrally conducted Traffic (OCT) Exp. March 2000 Gradually reshifting means:From now on let only a smaller part of the expected traffic take the (old) congesting route. It also implies: Do not reroute existing voice/video connections ! Let me approach to the OCT concept from another corner: Imagine, a voice/video-connection needs to be established for a request which is part of a particular traffic stream and let 5 different routes be available, which all are optimal/acceptable from the requestor's prospective. However which route is the right one to choose, from the overall network thruput prospective ? By which likelihood should route R1 be chosen? By which likelihood route R5? Furthermore, the traffic load may be such heavy that the network resources cannot cope with it. Therefore, one additional option must be: By which likelihood should the request be turned down? These questions bring us right to the heart of the matter: Each (source) node must, from time to time, report to a central traffic engineering conductor (TEC) what is the current traffic load situation from its own prospective, i.e. with respect to all traffic streams originated by this node. With respect to all current voice/video traffic streams: What are their LSPs and their routes while consuming how much bandwidth? With respect to all current data traffic streams: What are their LSPs and their routes and their current transmission rates? The TEC will recognize the differences with the previous reports, i.e. recognize the increase or decrease of the traffic and also the currently available spare bandwidth. It will be able to extrapolate to the near future. Based on the collected information for all traffic streams the TEC will compute for each of them by which likelihood should be taken, in case of voice/video traffic stream: which particular route for the next call; in case of data traffic stream: which existing LSP for the next bulk of packets. This may include "by which likelihood the requested service should be rejected". The TEC shall compute these likelihood figures such that the traffic load is well balanced on all network components. It should then send the computed likelihood figures to the appropriate source nodes. Hummel Oct 1999 [Page 4] Orchestrally conducted Traffic (OCT) Exp. March 2000 Then, whenever a node receives a request to establish a particular voice/video connestion for a particular traffic stream, respectively to transmit another bulk of data packets, it may toss a dice in order to get a random number between 0 and 1. The random number will be within an intervall, e.g. I0, I1, I2,...,I5 . If the random number is within I1, then route R1 (resp. existing LSP 1) shall be chosen, if it is within intervall I5 then route R5 (resp. existing LSP 5) shall be chosen. If the random number is within I0 then the request shall be rejected. Note that these intervalls represent a statistical stage function whereby the width of each intervall indicates the likelihood to take the respective route/LSP. The result for a particular data traffic stream may look like this: At gold medallion class level: take best routed LSP 1 by 100 % likelihood. At silver medallion level: take LSP 1 by 60 %, LSP 2 and LSP3 each by 20 % likelihood. At bronze medallion level: take LSP 4 by 70 % and reject the transmission request by 30 % likelihood. How should the TEC compute for each traffic stream the respective routes and likelihood parameters? There will be certainly several different methods and models ( creating a lot of intellectual fun) as to compute these likelihood values. Some maximes: 1) One maxime for computing these likelihood values may be: "Give me by the highest possible likelihood the relatively best route, while taking into consideration that all other traffic of the same class level is entitled for the same egoistic demand." I.e. create fair shares between requestors on same class level. 2) Distribute the remaining resources going from the most-prior class down to the least-prior class. 3) Avoid damaging many a little bit. Rather damage a few brutally. (or vice versa ?) There are yet 2 extrem situations in the network: 1) In spite of best traffic engineering the network might not be able to cope with the traffic load. The TEC should recognize, after a longer period of time, which links need to be stocked up by how much bandwidth, etc. 2) Some links may turn out to be always under-utilized by a certain amount of bandwidth. They may be reduced or may be made available for e.g. an additional VPN, etc. Hummel Oct 1999 [Page 5] Orchestrally conducted Traffic (OCT) Exp. March 2000 Indeed, there may be a lot of different policies/maximes. There may even be different definitions of fairness: E.g. it may still be fair to discriminate a particular traffic stream which has several options for the sake of another traffic stream which depends on just one route option. Like in an orchestra which is able to play different tunes and symphonies, a TEC may pursue different methods and models and may therefore produce different results, i.e. differently sized likelihood values. However there must be and there is indeed a common base: In a music orchestra the common base are the music notes, in this OCT concept the common base are likelihood values as such. Sending likelihood values to the individual (source) nodes: The TEC may send to each individual source node of traffic streams the respectively computed likelihood values by means of separate messages. Alternative: In [3] the TREE ROUTE TLV is specified, i.e. a means to send out a message along a tree structured route while bringing individual target information to individual nodes in the tree. Let's assume that the tree is a spanning tree, i.e spanning the entire network domain with the TEC being its root. By using the TREE ROUTE TLV the TEC may send a message that conveys to each node of the network its individual likelihood and route data with respect to all traffic streams that are originated at that node. 3. Proposal It is proposed to work out the OCT concept, i.e. a framework document describing the model, the details of the required communication, possible strategies/policies/methods/algorithms for the TEC resulting in likelihood information to be handed out to the nodes of the network. 4. Intellectual Property Considerations Siemens AG may seek patent or other intellectual property protection for some or all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Siemens AG, Siemens AG intend to disclose those patents and license them under openly specified and non-discriminatory terms. Hummel Oct 1999 [Page 6] Orchestrally conducted Traffic (OCT) Exp. March 2000 5. References [1] "Traffic Engineering Concept", draft-awduche-mpls-traffic-eng- 00.txt, Awduche [2] "Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)," 1/1998, draft-li-paste-00.txt, Li, Rekhter [3] "Explicit Tree Routing", draft-hummel-mpls-tree-route-01.txt, Hummel, Loke 6. Authors' Addresses Heinrich Hummel Siemens AG Hofmannstrasse 51 81379 Munich, Germany Tel: +49 89 722 32057 Email: heinrich.hummel@icn.siemens.de Hummel Oct 1999 [Page 7]