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.
Authors
Lisandro Zambenedetti Granvile (granvile@inf.ufrgs.br)
UFRGS
Brazil
Liane Margarida Rockenbach Tarouco (liane@penta.ufrgs.br)
UFRGS
Brazil
Introduction
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.
Paper Format
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 [1] 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) [2] 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 [3], for instance, uses
ATM network to provide data transfer. Abilene project [3], 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 [4] 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 [5], 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) [6] 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 [7] 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.
Main manager
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.
Mid-level managers
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.
End-systems
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.
Routers
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.
Conclusion
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.
Refereces
[1] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang and W. Weiss.
An architecture for differentiated services. Internet Draft. August,
1998.
[2] C. Liu. Multimedia Over IP: RSVP, RTP, RTCP, RTSP. (may, 1999).
[3] Internet2 Homepage. URL: http://www.internet2.org. 1999.
[4] Allan Leinwand & Karen F. Conroy. Network Management: A Practical
Perspective. 2nd edition. Addison Wesley, 1996.
[5] Harry J. R. Dutton & Petter Lenhard. Asynchronous Transfer Mode
(ATM): Technical Overview. 2nd ed. Prentice Hall, 1995.
[6] 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
[7] LABARRE, L. Management By Exception: OSI Event Generation, Reporting,
and Logging. The MITRE Corporation, Burlington Road, 1991.
