The Internet Global Summit - Global Distributed Intelligence for Everyone
The 10th Annual Internet Society Conference
High-Speed Networks QoS Management: Where to Put the Complexity?
High-speed networks must provide QoS to enable the development of important new applications, such as Tele-medicine, Video-on-Demand and Remote Learning, for example. QoS guaranties have to be observed "on the fly", since critical applications trust on the services networks provide. QoS guaranties can only be achieved with a specialized QoS Management applied to the networks.
Today's high-speed networks are based in a large number of technologies, and new applications "know" some of them. Video-on-Demand, for example, could use standard IPv4 packages, Differentiated Services based on IPv4 packages, new Ipv6 approaches or even direct ATM layer cells. Since applications can be implemented in a large number of different network technologies, it's important to define how to manage QoS in such technologies.
For each network technology there must be an appropriate QoS management. IPv4 requires link usage statistics to proactively detect congestion. RSVP are used to help in such tasks. ATM based networks requires switch monitoring of VC's. If IPv4 runs over ATM networks, do we must manage only IP, ATM or both of them? Where to put the management complexities? ATM requires end-to-end QoS management while IP requires end-to-end and subnet management. How we must manage the management?
This paper describes techniques to be applied when several network technologies are used at the same time, probably in a redundant way. Such techniques provides QoS management based in a layered model of interoperability. The techniques are most based in IPv4, IPv6, Frame-relay and ATM, but can be applied on any other network transport technology.
High-speed networks are being applied in several and heterogeneous environments. Today, there's no de facto high-speed network standard. Since countless technologies combination can be used, it's important to define some guidelines to QoS management. Such complexities are the main reason we thing this paper it's important for people involved with high-speed networks today.
The paper concludes stating that QoS management are high dependent on the network itself, the technologies used, and in the applications requirements.
Lisandro Zambenedetti Granvile (email@example.com) UFRGS Brazil
Liane Margarida Rockenbach Tarouco (firstname.lastname@example.org) UFRGSBrazil
Provide QoS in network today is a necessity. New applications can only run properly if some aspects of the network are guaranteed. Unfortunately, TCP/IP based networks were not created with QoS in mind. It doesn't happen, for instance, with ATM networks, where QoS features were always part of the ATM architecture.
Multimedia and critical mission applications are not suited to run in best effort environment, such as the Internet. Since no guaranties are provided by the network, critical application always have to face the possibility of congestion. One possibility to solve the problem is to migrate applications to networks where QoS are present. For example, TCP/IP based applications should be adapted to run in ATM networks. Another solution is to provide QoS in no QoS able networks. In this case, networked applications remain intact, but the network itself must be changed.
Users see networks because applications present views and abstractions of network serviced to the users. Thus, for users, networked applications are the network. Changing applications, to the users, is to change de network view. Changing network without changing applications means no change in the network view. Based on this, we believe that the QoS problem are more adequately solved providing QoS in legated networks, and remaining applications unchanged.
Since almost all networked applications are implemented over TCP/IP stack, in a global view, we must try to provide QoS in TCP/IP based networks. Several works have been done in this area. Differentiated services implements soft QoS, for applications with some degree of needs. RSVP implements hard QoS, for applications with more strict needs of QoS.
Providing QoS introduces in networks new resources. Such resources must be managed by network administrators. No management means no QoS. No QoS means best effort: something applications can not handle anymore. This paper describes our approach to QoS management for high speed networks TCP/IP based. We believe IP (v4 or v6) with DiffServices, RSVP and SNMPv3 will be the standard management platform. Other technologies, such ATM, would exist of course, but to provide lower level services.
In this section we analyze resources needed to provide QoS on TCP/IP based networks. After, we propose an architecture to manage such resources.
To provide soft QoS
Soft QoS are need by applications with certain network restrictions. In this environment, there is no network resource reservation prior to communications. Applications start sending packets, and this packets are treated by routers in different ways. Packets with same treatment compete each other, but different packet sets have different treatments.
IETF proposes the Differentiated Serviced architecture  to provide soft QoS. The complete architecture define several elements. In our approach we believe only two element must be manage to properly guarantes QoS: end-systems and routers. End systems requires QoS management to guarantie bad behaved applications don't use network resource they are not supposed to use. Routers management must be provided to program the treatment of packets.
To provide hard QoS
Hard QoS are need by applications with strict network restrictions. Most of this applications are time sensitive. Tele-medicine, for instance. We must guarantee that the images doctor see are the strict representations of what is happening to the patient on the remote hospital. To provide QoS network resources must be previously reserved before data packets transmission.
From the applications point of view, this prior resource reservation can be done in two different ways: by the application itself; or by some monitoring system, that know when the application will need resources and proceeds with network resources reservation. Reservation requires na signaling protocol to be used. IETF have some workgroups related to signaling protocols. RSVP (Resource ReServation Protocol)  is today the most IETF signaling protocol in use. We assume in this paper RSVP as the protocol use to allocate network resources.
The same way happened with DiffServices, we define two resources to be managed in hard QoS provisioning: end-systems an routers. End-systems must be managed only in the case reservation are done by some monitoring system. This system have to be manage to guarantee the resources applications need are properly reserved prior to data transmission. Routers management are needed to control RSVP signaling process.
Low layer management
Low layers are used to transport data from source to destination. To travel through several gateways, IP protocol are used within routers and end-systems. Between two routers, links can be implemented in several ways: RS232 interface, Ethernet interface, ATM network and SONET, for example. Thus, IP can use several different protocols/services to travel from one router to the next. Inernet2 project , for instance, uses ATM network to provide data transfer. Abilene project , on the other hand, uses SONET connections. IP runs directly over SONET infrastructure. In any case, IP is the protocol seen by end-systems and routers, independently of the lower layer structure.
To guarantee QoS in the network, lower level services must operate adequately. Any problem with lower level protocols reflect QoS loose on higher level IP protocol. Thus, lower layer have to be properly configured to be possible to implement QoS. We also need to manage this lower layer characteristics. In this case, we point two principal management aspects: configuration management; and resource reservation mapping.
Configuration management are intended to provide proper lower layer resources configuration. To achieve this we use fault, configuration and performance management, defined by OSI  as 3 of 5 functional areas of management. Configuration management in this context depends on lower layer specific parameters. ATM networks have totally different management characteristics than RS232 interface, for example. There is no common lower layer management framework: for each technology a different management framework.
Resource reservation mapping are used to allow the reservation of lower layer resources when higher layer requests QoS guarantees. This mapping must be automatically done, in a way users don't realize lower layer operations. This abstract is needed to free users to thing about aspects of resources they are not supposed to. For instance, if a video-on-demand application requests bandwidth to deploy a movie, it does so using RSVP, but the application don't care if the lower layer uses ATM singling protocol or it gets a reserved RS232 Interface to increase the bandwidth. The abstraction is also needed because between source and destination, several different lower layers technologies can be used in any segment.
High-speed network and SNMP
Historically, SNMP has been the network management protocol used to manage TCP/IP based network. Since network products begun to support SNMP, the protocol usage increased. Nowadays it is the de facto protocol to manage either TCP/IP network or other type of network (ATM , for example). Several management applications have been developed using SNMP as base protocol. SNMP Management platforms are extensively used, counting with several automation and analysis tools. SNMP itself evolved. Today, SNMPv3 are the last version of the protocol.
The same way IP would be the basic network protocol, we believe SNMP would be the basic management protocol. But SNMP have some features that are not interesting in high-speed networks management. Since transport between hops are much more faster, the management protocol must be the same way.
It is not a problem of the protocol itself, but the management architecture SNMP always represented. If management station is placed too far from the resource to be managed, the transit time of SNMP messages can be too long. While a SNMP PDU is travelling from de management station to the managed resource, several performance problems can occur. QoS can be affects and the manager can't even see it. To solve this architectural problem we must use two concepts largely know in network management area, but not always found on the managed environments: management by delegation; and management by exception.
Management by delegation (MbD)  moves management functions to the data, than data to the function, as occurs in standard management. The idea behind delegation is to delegate management power to mid-level managers next to the resources to be managed. Ideally, the resources themselves would be the mid-level managers, and proceed with their own management. Management by Exception  are used to reduce network management traffic. Management messages are required to carry notifications of exceptions descriptions. To get exceptions, the monitoring entity (probably a mid-level manager) analyze the data retrieve and derivate scenarios. If the derivated ones are exceptions, one SNMP trap message is generated and sent to the manager.
Architecture to manage QoS in high-speed networks
To provide Hard and Soft QoS we define an architecture the uses SNMP (v2 or v3) as management protocol. The following figure illustrated our approach.
Each element has a specific role in the management.
It is responsible for delegation management functions to the mid-level manager. The main manager itself can directly access end-systems or routers, but in this case no delegation is allowed. The main manager is not responsible for monitoring e polling. Its mains goal is to receive SNMP traps from mid-level managers describing special conditions. To delegate functions, main manger uses SNMP. Some methods are possible, but today the most suitable is the script MIB model.
On receiving management functions, mid-level managers must start monitoring the associated resource to detect exceptions. Each managed resource (end-system or router) has only one mid-level manager associated, although one mid-level manager can monitor several resources at the same time. Mid-level managers and resources can be implemented separately or in the same equipment. In the last case performance is improved, but expenses too.
To allow monitoring by mid-level managers, end-systems must implement MIBs that export QoS related objects. In Hard QoS the MIB is simplified because resources are allocated previously, so few aspects must be monitored. With Soft QoS the MIB is complex: several aspects must be monitored since there's no prior reservation.
With hard or soft QoS routers must be manage to guarantee services are operating adequately. MIBs should inform manager about trafic and configuration. Several aspects must be observed, for instance, how packets of type X must be treated within router with DiffServices?
Marking and reservation
Two important aspects of QoS provisioning are related to the marking and reservation tasks. Marking are performed in each packet of a flow to classify such flow among the other possible flow. Reservation, as said before, is the process of allocation network resources prior to data transmission.
Marking is important in soft QoS and reservation in hard QoS. This two tasks can be done by different entities. Depending on the entity used, the management differs. Marking can be done by applications or by a monitoring entity. Marking by applications requires that applications access socket API to properly set a value in the DS Field (Differentiated Service Filed). Some applications uses such field to identify special flows. For instance, OSPF routing protocol sets DS Field to identify routing packets as having high precedence. Unfortunately, today applications almost never sets DS Field. Packets always leave end-systems with default value. Since no marking is done, routers have no way to decide how to treat different flows with the same DS Field. So, if applications don't use DS Field, two possibility exist: change applications to do such marking; or using other entity to mark packets.
From the point of view of network management, having other entity marking packets is better than having applications. This is due to the fact that application developers would always prefer high priority packets in their applications. If every application have the higher priority, between applications would be no priority. It means DiffServices operating as best effort. If we leave the marking task for another entity, such entity can mark packets based on its internal programming. Application developers have no way to establish high-priority packets, because mark are not done within applications. Having the marking entity controlled by a SNMP enabled platform, it allows managers to decide which application would receive high-priority packets, and which would not.
From the point of view of applications management, having other entity marking packets is also better. Applications already developed don't need to be changed to get some priority. Applications not yet developed would not be concerned about accessing complicated socket APIs to set the DS Field value. So, we do believe marking must be done by an entity and not by applications.
Similar to the marking process, reservation can be done by applications or by another entity. Applications already developed have certain gain when another entity take care about the reservation task. Since the applications don't perceives the reservation, they don't need to be changed nor adapted. From the point of view of management, another entity is better because manager don't be concerned about applications peculiarities. He/she only access reservation entity parameter. From the point of view of operation, application reservation is better, because only the applications is able to correct know the resources it need to proceed with transmission.
From this observations we believe that reservations management is a mixed approach, based on entity reservation and application reservation. It is important to notice that applications and marking or reservation entities can exist together on the same system. For instance, na marking entity could be a daemon that monitor "ready-to-go" IP packets and mark them based on some internal program. It can be managed if a MIB is provided, in a way manager can change entity internal programming.The paper is expected to be 8-10 pages in length, about 4000 words. It is due on 25 January, 2000. Every paper must be submitted in HTML, the Hyper-Text Markup Language widely used on the World Wide Web. This will support a common presentation on CD-ROM and on the Web.
Architecture on practice
The architecture proposed before is being developed under the Metropoa project (Metropolitan High-Speed Network of Porto Alegre). The project uses an ATM network as backbone to connect several PCs. To provide the required elements to form the complete architecture, the following implementations are under development.
ATM management architecture.
To manage lower layer aspects, we need an infrastructure to monitor and configure ATM equipment of the Metropoa network. Several ATM equipment don't support standard MIBs (AToM and ILMI). Our approach is to access ATM network always using the same MIB. SNMP Proxies have been develop to allow this access in a standard way.
Windows and Linux Marker.
To mark IP packets in end-systems, we developed na marker entity that get "ready-to-go" IP packets and mark them based on internal programming. The marker exports a MIB, so manager can program the marker based on its assumptions about soft QoS on he/she network. 6.
This paper describes an architecture to manage QoS aspects in high-speed networks. Management by delegation e management by exception is used to achieve na adequate access to the high-speed network equipment and to decrease network management traffic. SNMP (v2 or v3) are the management protocol that implements exchanges between main manager, mid-level managers and end-systems and routers. End-systems and routers must export MIB objects to allow managers to monitor and configure QoS.
Two approaches exists: applications mark and reserve resources, or another entity do so. For management, other entity is better, since applications don't interfere in the management process.
 S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang and W. Weiss. An architecture for differentiated services. Internet Draft. August, 1998.
 C. Liu. Multimedia Over IP: RSVP, RTP, RTCP, RTSP. (may, 1999).
 Internet2 Homepage. URL: http://www.internet2.org. 1999.
 Allan Leinwand & Karen F. Conroy. Network Management: A Practical Perspective. 2nd edition. Addison Wesley, 1996.
 Harry J. R. Dutton & Petter Lenhard. Asynchronous Transfer Mode (ATM): Technical Overview. 2nd ed. Prentice Hall, 1995.
 SCHÖNWÄLDER, J. Network Management by Delegation - From Research Prototypes Towards Standards. JENC8, Proceedings. 1997. URL: http://www.ibr.cs.tu-bs.de/vs/papers/jenc8-97.ps.gz
 LABARRE, L. Management By Exception: OSI Event Generation, Reporting, and Logging. The MITRE Corporation, Burlington Road, 1991.