bupt-qosjava-arch-03.txt

Internet DRAFT - draft-bupt-qosjava-arch

draft-bupt-qosjava-arch

Last Version:	draft-bupt-qosjava-arch-03.txt	Tracker Entry
Date:	`21-Oct-2005`
Disposition:	expired
Previous Versions:	draft-bupt-qosjava-arch-03.txt (diff) - 05-Aug-2005
	draft-bupt-qosjava-arch-02.txt (diff) - 27-Jan-2005
	draft-bupt-qosjava-arch-01.txt (diff) - 21-Jan-2005
	draft-bupt-qosjava-arch-00.txt (diff) - 20-Jan-2005

Internet Draft xiaohui Huang
Expires: 18 March 2006 Yu Lin
Wendong Wang
Xirong Que
Shiduan Cheng
Li Jiao
Yidong Cui
bupt,china
18 October 2005

QoSjava: An Open and Scalable Architecture
Decoupling QoS Requirements from QoS Techniques

<draft-bupt-qosjava-arch-03.txt>

Status of This Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

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/1id-abstracts.html

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

Abstract

QoSJava, an architecture decoupling QoS reuirements from QoS
techniques is proposed in this draft. Referring to the idea of
Java, QoSJava can conceal the heterogeneity of different QoS
mechanisms as well as different vendors' devices. Users'
requirements are translated into a "middle language", i.e.
deployment task specification. And QoS mechanisms adapter plus
Device Driver constitute the "Virtual Machine" of QoSJava. Thus
network devices can be configured and QoS requirements can be
fulfilled automatically. Moreover, QoSJava is not only compatible
with current QoS mechanisms and devices, but open to new QoS
solutions and advanced facilities in the future.

Expires: March 18, 2006 bupt [Page 1]
Internet Draft October 18, 2005

TABLE OF CONTENTS

1. Introduction...................................................3
2. Motivation.....................................................4
2.1 Java.......................................................5
2.2 Motivation of QoSJava......................................5
2.3 Analogy between Java and QoSJava...........................6
3. QoSJava Architecture...........................................8
3.1 Architecture Overview......................................10
3.2 User Part..................................................10
3.2.1 User Interface ......................................10
3.2.2 User Requirement Translator..........................11
3.2.3 Resource Manager.....................................11
3.2.4 QoS Mechanisms Adapter...............................17
3.2.5 Device Driver........................................18
3.3 Administration Part........................................19
3.3.1 Administrator Interface..............................19
3.3.2 Measurement Data Analyzer............................20
3.3.3 Topology Management..................................20
4. Deployment of QoSJava..........................................20
5. Other Issues...................................................21
6. References.....................................................21
7. Acknowledgements...............................................22
8. Author's Address...............................................22
9. Full Copyright Statement.......................................23
10. Intellectual Property.........................................24

Expires: March 18, 2006 bupt [Page 2]
Internet Draft October 18, 2005

1. Introduction

Providing QoS in IP network is a hotspot in recent years. The goal
is driven by users' requirements to obtain a variety of services
from the network, such as Internet games, VOD, VoIP, video
conference, etc. Moreover, users desire that the network can satisfy
the quality of their services. When playing games, they hope not to
be dropped off the line. When watching movie, they expect a similar
effect to DVD. They hope that IP phone could sound as good as
telephone, attendee can be seen and heard in video conferencing, and
so on. In conclusion, users desire various services, but different
services have different requirements for the network.

IP QoS is also a concern of Service Provider (SP). SP wish to
provide value-added services in the network, such as network games,
VOD and those mentioned before, to attract more users to use the
network and to make more profits. It is necessary to provide QoS for
value-added services and to monitor users' traffic, or users may be
reluctant to pay. There are some preliminary price schemes in current
Internet, such as time-based and volume-based charging schemes. They
are too tousy when providing value-added services in Internet. Users
are unwilling to pay unless they do obtain a satisfying service. For
example, a SP provides VOD in the network. Users can select their
favorite movies and watch them online. In the IP network without any
QoS, the quality of the video will be unbearable when congestion
happens. It would be unreasonable of time-based charging scheme, for
users cannot even make out the figure in the screen. Volume-based
charging scheme is also ridiculous. Because in congestion, loss
packets will induce retransmission, users will generate more traffic
than usual cases. They would be raging to pay more whereas obtain no
service. Therefore, value-added service cannot survive without QoS.

IETF has proposed a series of RFC focused on IP QoS issue, including
IntServ[1], DiffServ[2] and MPLS[3]. IntServ[1] uses RSVP[4] as
signaling to reserve resource in the whole path before connection
setup. The connection can be admitted only if all the nodes and links
have sufficient resource. Because the core routers must save the soft
states of every micro-flow, IntServ has poor scalability. DiffServ[2]
architecture is proposed in RFC2475 to solve the problem. It
simplifies the core network by pushing the complication to the edge.
In DiffServ, the edge routers classify and mark the packets
according to QoS requirements of the traffic. The packets which have
similar QoS requirements are classified into the same aggregate and
are identified by DSCP field in IP header. MPLS[3] integrates Layer
2 information about network links (bandwidth, latency, utilization)

Expires: March 18, 2006 bupt [Page 3]
Internet Draft October 18, 2005

into IP Layer within a particular autonomous system in order to
simplify and improve IP-packet exchange. When packets enter a
MPLS-based network, Label Edge Routers (LERs) stick a label to them,
which contains information about their QoS requirements. Once this
classification is completed and mapped, different packets are
assigned to corresponding Labeled Switch Paths (LSPs), where Label
Switch Routers (LSRs) place outgoing labels on the packets.

However, these QoS mechanisms function independently. In other words,
they won't take effect unless the same QoS mechanism is adopted in
the whole network. Unfortunately, different Network Providers (NP)
will use different QoS mechanisms according to their network devices
and budgets. Coordination of various QoS mechanisms should be
considered for the purpose of end to end QoS provisioning. IETF has
done some work on it. RFC2998 [5] proposed a framework combining
IntServ and DiffServ, which uses IntServ at network edge for
micro-flow admission control and DiffServ in the core network for
aggregate flow forwarding. Besides that, there are other solutions
for end to end QoS provisioning, such as Bandwidth Broker[6]
proposed by Internet 2, CANDENUS[7], TEQUILA [8] and AQUILA [9]
projects of Europe Commission, MONET's QoS Middleware[10], and so on.

However, none of these research works have been put into use or
deployed in large scale. There may be several reasons: The solutions
are too complicated and have high operational cost. They cannot
preserve current investments. They are not compatible with other QoS
mechanisms. They depend too much on a certain type of network device.

A feasible end to end QoS solution, QoSJava, is proposed in this
draft. The draft is a complement and extension of IETF's work on IP
QoS. The goal of QoSJava is to conceal the heterogeneity of
different QoS mechanisms and network devices of different vendors.
QoSJava provides a unified resource view for the upper layer,
implements automatic management of different kinds of network
devices, and can adapt to new QoS mechanisms and new network devices.

The rest of the draft is organized as follows: the motivation of
QoSJava is discussed in section 2. In section 3, the detail
framework and components of QoSJava are described. We give the
deployment of QoSJava in section 4. Other issues such as security
and performance are considered in section 5.

2. Motivation

The idea of QoSJava is borrowed from Java language. For users to
catch the essence of QoSJava, let's look back at the history of this
amazing language before we discuss the motivation.

Expires: March 18, 2006 bupt [Page 4]
Internet Draft October 18, 2005

2.1 Java

The original intention of Java is to build a system which can run on
a large, distributed and heterogeneous network to enable the
communication and coordination of electronic devices. After compiled,
Java language generates a virtual machine which executes on an
interpreter. There is an interpreter corresponding to a specific
operating system. Thus Java is a platform independent language. When
WWW developed swiftly in 1994, Java set foot in Internet. HotJava, a
browser independent of hardware and software platforms was designed.
Java applet and some other products came into being in succession.
The distribution of Java in Internet shocks the world.

This new simple object-oriented language enables software developer
to design applications which can be distributed in Internet by using
World Wide Web or any front-end software developed by ISV
(Independent Software Vendor). Moreover, due to Java is a virtual
machine, the Java-based software can run everywhere, no matter what
hardware and operating system are. Java applications can be executed
without modification or recompiled on any platforms, including
intelligent cell phones, Lap tops, Windows3.1, Win95, NT,OS/2 or Unix
stations and servers, it can even run on AS/400 or IBMS/390 of MVS.

2.2 Motivation of QoSJava

Providing end to end QoS face a similar problem as Java when
initially designed. Current network contains multiple users,
multiple SPs, multiple NPs and multiple device vendors. Each
character has its own requirements. Both users and SPs wish that QoS
can be provided in such an environment. But what's the situation of
the grounding network? Unfortunately, the network infrastructures
belong to different NPs. They purchased network devices from
different vendors according to their budgets. These devices use
different command sets. Besides that, different domains of the
network adopt different QoS mechanisms based on the capability of
devices in it. Core routers or high series of routers can support
MPLS, but some low series routers can just support DiffServ or
IntServ. Thus NPs adopt different mechanisms to guarantee QoS.

Someone may argue that unify the whole network would settle the
problem totally. But practically, there is competition between
different device vendors. They develop in different ways and have
different technical strategies. Most importantly, upgrading the
whole network is as difficult as replacing TCP/IP protocol, or may
cost even more. It would be impossible to upgrade all devices every
time a more advance network device is distributed. The whole network
use a single QoS mechanism is also infeasible. Current QoS solutions
are not perfect, and when a new solution appears, all devices need
to be reconfigured, which require high operational cost.

Expires: March 18, 2006 bupt [Page 5]
Internet Draft October 18, 2005

In addition, QoS provisioning would inevitably interfere with the
configuration of network devices. In current environment, network
administrators are responsible for configuring and setting network
devices. For example, change the routing table to steer packets to
free resource when congestion, establish LSP in MPLS domain for a
certain traffic aggregate, and etc., in such circumstances, network
administrator has to login on several routers and change their
configuration separately. In an operating network providing
value-add services, manual configuration and setting of network
devices cannot meet the real-time and accuracy requirements.
Automation is needed.

As aforementioned, current network is a diverse environment. The
difficulty of end to end QoS provisioning lies in the fact that the
end to end path traverses multiple QoS mechanisms and distinct
devices. In order to propose a practical solution, heterogeneity of
QoS mechanisms and devices should be hided, and expansibility with
technical progress is needed. In addition, Automatic modification
and configuration platform for different devices should be provided
for network administrator, hence they don't have to reconfigure all
the network devices one by one in the case of failure or technology
transition. It is most significant to ensure that the QoS solution
is as simple as possible and the operational cost is as low as
possible. QoSJava is proposed in this draft to settle all these
problems and fulfill the end to end QoS provisioning requirements.

2.3 Analogy between Java and QoSJava

QoSJava is analogous to Java, it first translates user's QoS
requirement to a "middle language", i.e. deployment task
specification. Then the QoS Mechanisms Adapter will translate the
deployment task specification into a script written by a series of
QoS configuration instructions. Then the script is fed into the
Device Drive, which interprets each instruction in the script into
several commands corresponding to the network device. The commands
will finally execute on the devices and the configuration is
actually completed. QoS Mechanisms Adapter plus Device Driver
accomplish the similar function of Java Virtual Machine. Java adapts
to different hardware and software platform, while QoSJava adapts to
various QoS mechanisms and devices. Thus QoSJava can migrate to the
network with any QoS mechanisms and devices of different vendors,
and as a result end to end QoS is provided.

The similarity between Java and QoSJava is illustrated in Figure 1
and listed in Table 1.

Expires: March 18, 2006 bupt [Page 6]
Internet Draft October 18, 2005

Java QoSJava
|
+-----------------------------+ | +-----------------------------+
| Description of Programmer's | | | Description of User's |
| requirements | | | QoS Requirements |
+-----------------------------+ | +-----------------------------+
| | |
---------------+------------------|-------------------+-----------------
^ | | | ^
| v | v |
| +-----------------------+ | +-----------------------+ |
| | Java Language of | | | Java Language of | |
| | Programming | | | Programming | |
| +-----------------------+ | +-----------------------+ |
v | | | v
---------------+------------------|-------------------+-----------------
^ | | | ^
| v | v |
| +-----------------------+ | +-----------------------+ |
| | Java Virtual | | | QoSJava | |
| | Machine | | | Middle-ware | |
| +-----------------------+ | +-----------------------+ |
v | | | v
---------------+------------------|-------------------+-----------------
| | |
|-------+-------+------| | |-------+-------+------|
| | | | | | | | |
v v v v | v v v v
+------+-------+------+------+ | +------+-------+------+------+
|Linux |Windows|Unix |OS/2 | | |Linux |Windows|Unix |OS/2 |
| | | | | | | | | | |
+------+-------+------+------+ | +------+-------+------+------+
Figure 1: Similarity between Java and QoSJava

QoSJava can conceal the heterogeneity of different QoS mechanisms
and devices. Network devices from different vendors such as Cisco,
Juniper and HUAWEI can be managed automatically. Moreover, QoSJava
is compatible with new solutions and advance facilities. QoS is
provided by software implementation thus current network needs
little modification. Therefore the network can evolve smoothly and
legacy investments are preserved. QoSJava is an open and stable QoS
management architecture. It is independent of the development of
network technology, QoS mechanisms and application implementation.
Consequently, it can adapt to service requirements in the future.

Expires: March 18, 2006 bupt [Page 7]
Internet Draft October 18, 2005

3. QoSJava Architecture

This section gives a detail description of QoSJava framework and
its components.

Expires: March 18, 2006 bupt [Page 8]
Internet Draft October 18, 2005

| |
| User Requirements |
v v
+---------------------------------------------------+ +---------------+
| User Ingerface | |Administrator |
| | |Interface |
+---------------------------------------------------+ +---------------+
| ^ |
v | |
+---------------------------------------------------+ | |
|QoS Requirement to Resource Requirement Translation| v |
+---------------------------------------------------+ +-----------+ |
| |Measurement| |
| |Data | |
| |Analyzer | |
v +-----------+ |
+---------------------------------------------------+ ^ | |
|+--------+ +----------+ +----------+ +---------+| | | |
||Planning| |Addmission| |Deployment| |Monitor || |+----------+ |
|| | |Control | | | |Task || ||Topology | |
|| | | | | | |Generator|| ||Management| |
|+--------+ +----------+ +----------+ +---------+| |+----------+ |
+---------------------------------------------------+ | | |
| | | |
v v v v
+---------------------------------------------------------------------+
| QoS Mechanisms Adapter |
| +--------+ +-------+ +-------+ +-------+ |
+--|DiffServ|---|IntServ|---|MPLS |---+ +---------------------+
|Adapter | |Adapter| ^ |Adapter| |
+--------+ +-------+ | +-------+ |
v v
+---------------------------------------------------------------------+
| Network Element Driver |
| +--------+ +-------+ +-------+ +-------+ |
| |Cisco | |Juniper| |Huawei | | | |
+--|Router |---|Router |---|Router |---+ +---------------------+
|Driver | |Driver | |Driver |
+--------+ +-------+ +-------+
^
|
|
v
+---------------------------------------------------------------------+
| IP network |
| +------------+ +--------------+ +--------------+ |
| |Cisco Router| |Juniper Router| |Huawei Rounter| |
| +------------+ +--------------+ +--------------+ |
+---------------------------------------------------------------------+
Figure 2: QoSJava Framework

Expires: March 18, 2006 bupt [Page 9]
Internet Draft October 18, 2005

3.1 Architecture Overview

Figure 2 sketches the architecture of the proposed framework of
QoSJava, which has two parts, user part and administrator part. User
part is in the left. It deals with the whole process from user
submitting his QoS requirements to network device being configured.
The right part is administrator part, which is for network
administrator to initialize the network, monitor network performance
and to execute high level configuration task. From the management
interface, administrator can obtain the information of whether
user's QoS requirement is fulfilled, observe whether user's traffic
exceeds the constraint specified, and browse all the measurement
data. As the "virtual machine", QoS Mechanism Adapter and Device
Driver traverse two parts. In the following sections, these two parts
are described separately in detail.

3.2 User Part

User part is in charge of fulfilling user's QoS requirement. It
consists of several components, from the top down, are User
Interface, User Requirement Translator, Resource Manager, QoS
Mechanisms Adapter and Network Element Driver.

3.2.1 User Interface

User Interface is the entrance for end users. As the front-end
application, it is responsible for receiving user's requirement,
delivering it to User Requirement Translator and returning the
admission result to the user. It also implements QoS requirement
negotiation protocol and can interact with end users. If user's
requirement is admitted, User Interface will construct a contract
and send it back to the user, or User Interface will initiate a
negotiation process and suggest user to relax the constraint.

The contract can be SLA, xml specification or any forms that
designate user's QoS requirements. The implementation of User
Interface is not restricted, so developer can choose any suitable
technology to realize it. In our prototype, we use SLA to express
user's requirements, and the User Interface is presented to users as
a web service.

Expires: March 18, 2006 bupt [Page 10]Internet Draft October 18, 2005

3.2.2 User Requirement Translator

End users have variety of QoS requirements, thus front-end
applications present differently to users. Some front-end
applications present a web page to users, and guide them to fill in
items in the web page. Some applications can only receive SOAP
message, thus users have to express their requirements in xml
documents. In the future, applications allowing users to express
requirements in natural language may come into being. Therefore, we
need to add a layer between User Interface and the execution logic,
which is User Requirement Translator(URT). URT needs to adapt to
variety expression of QoS requirements. For example, URT may collect
information from web page, provide XML Parser for XML Document, or
construct an intelligent translator for natural language expression.
For user is not an expert, they may just know what service they
want, such as VOD or VoIP. And they are also clear about the service
approximate quality that they want, such as gold, silver or bronze.
Thus we can design templates for a specific service, which have
parameters with values. Whatever way is used, the goal of URT is to
extract the technical parameters from QoS requirements:

q_e2e=(SrcIP,DesIP,BW,Class,Delay,LossRate,Jitter,StartTime,EndTime)

q_e2e is a tuple describing user's QoS requirement. The parameters
contained in the tuple can be extended as needed. At present, we
define the following items.
SrcIP: Source IP Address
DesIP: Destination IP Address
BW: Bandwidth required by the user
Class: Traffic class of the service
Delay: End to end delay
LossRate: End to end packet loss rate
Jitter: End to end jitter
StartTime: The time when the contract begin to take effect
EndTime: The time when the contract begin to expire

3.2.3 Resource Manager

Resource Manager (RM) is a logical view of the physical network.
It has a whole view of the network topology, the state and available
resource of each network device. At the first sight, RM is a kind of
network management software. Actually they have some distinction.
RM does not interact with network device by SNMP, instead it use the
instructions provided by our Device Driver. RM has more functions
than network management software. After collecting the information
of network devices (mainly routers), RM needs to do calculation
online or offline for resource planning and managing. It has a
resource database, which records the resource information of the
domain where QoSJava is located. According to the q_e2e tuple which
specifying user's QoS requirement, RM enforces admission control and
generates corresponding monitor task.

Expires: March 18, 2006 bupt [Page 11]
Internet Draft October 18, 2005

(1) Router Resource Abstraction

Router resource correlating to QoS can be abstracted into the
following tuple:

Res=(RouterID,DomainID,Class,RT,IfNum,If_1,If_2,...,If_IfNum)

If_1,If_2,...,If_IfNum are detail of the Interface, which has
the following definition:

If = (BW,Buffer,Priority,Bucket,NextHop)

RouterID: Identity of Router, may be one IP of the router
DomainID: Identity of the domain where the router is situated
Class: Traffic class of the service
RT: Routing Table
IfNum: Number of the Interfaces in the router
If1~IfIfNum: The detail of each router interface
BW: Bandwidth of the interface
Buffer: Buffer size of the interface
Priority: Schedule priority of the packets
Bucket: Size of the bucket used for traffic conditioning
NextHop: The router which the interface connects to

Router has some other resource which can characterize its
performance, but these parameters have little to do with QoS.

Res_other = (CPU,Mem,RTConverge)

CPU: CPU speed of the router
Mem: Memory size of the router
RTConverge: Routing Table converge time of the router

Router information can be easily acquired from network management
system. The abstraction of router resource can be extended, so long
as adding interface between it and the network management system
to get more information. In our framework, topology management can
also use the instructions provided by Device Driver to get router
information. These instructions encapsulate SNMP commands. When
planning the network resource, only QoS related router resource is
considered.

(2) Resource Planning (RP)

Network planning is done in a coarse granularity, which is not the
optimal resource assignment. In fact, there is no solution for
optimal resource utility in Internet due to its complexity traffic

Expires: March 18, 2006 bupt [Page 12]
Internet Draft October 18, 2005

pattern. Considering the different traffic characteristics of
different services,we found that by distributing the resource to
several traffic classes in a reasonable way, the resource utility
will increase. Bandwidth may be abundant in the future, but we are
still sure that improving resource utility would be the everlasting
target of network providers. In QoSJava, services are classified into
gold, silver and brown, similar to EF, AF and BE in DiffServ. In the
following section, we will prove that our scheme does improve the
bandwidth utility.

In the traditional IP network, traffic of different characteristics
is mixed up and transmitted in a best effort way. Services with burst
traffic such as Web and FTP degrades the quality of audio and video
service. The mixed traffic may also have burst characteristic. If the
simple solution, bandwidth over-provisioning, is adopted to provide
QoS, bandwidth of the peak rate should be reserved. Thus bandwidth
utility can reach no more than 30% or 40%.

In fact, different services have different QoS requirements for
network. Audio service needs a constant bandwidth to guarantee low
latency and low jitter. Video service has a relatively smooth traffic
pattern, thus it needs smooth throughput without abrupt changes.
Moreover, the media player in the end system has buffer. Thus Video
service's requirement for network is not as stringent as audio
service. As for other service such as file transmission, ftp and web
page browsing, they can endure longer latency and most users do not
insist on high quality for these services to avoid high charge. In a
word, bandwidth multiplexing degree of these services are different.

Base on the fact, we found that after distribute the bandwidth to
different traffic classes, apply different multiplexing policies on
different classes, and ensure that each of them should not exceed the
constraint, bandwidth utility will increase. Say, we distribute 10%
bandwidth to gold service, 50% to silver and the residual 40% to
bronze. For gold service class, over-provisioning is adopted, thus
its bandwidth utility is 90% approximately. For silver class, 100M
bandwidth can carry 150M traffic, considering video traffic's
characteristics, the bandwidth utility may be 70%. Bronze service
class carries best effort service. More flows can be fed into the
channel until it is saturated, thus its bandwidth utility approach
100%. From the equation below, we can see that the total bandwidth
utility may increase to about 70%~80%. Admission control should be
introduced to make sure that the traffic would not violate the
bandwidth constraint distributed.

Total_BW_Utility = 10% * 90% + 50% * 70% + 40% * 100% = 84%

Expires: March 18, 2006 bupt [Page 13]
Internet Draft October 18, 2005

Based on the analysis, Resource Planning assigned the network
resource to three traffic class. It constructs the resource topology
from the router resource information provided by network management
system, and decides on the resource assignment according to network
traffic distribution monitored by measurement facilities. The
computation is offline, thus computing complexity and efficiency are
not the main concern. The Resource Planning component will educe the
available resource matrixes of the domain for different traffic
classes, i.e. R_Gold, R_Silver, and R_Bronze. The available
resource matrix is a n*n matrix, in which n is the number of edge
routers in the domain.

Let's explain the semantic of the element in the matrix. Take
r_Gold(i,j)in matrix R_Gold as an example, it represents the
available resource for gold service between ER_i and ER_j , which is
defined by the following tuple.

r_Gold(i,j)=(srcER,DesER,BW,Class,Buffer,Priority,Bucket)

srcER: Identification of the Ingress edge router located in the
domain
DesER: Identification of the Egress edge router located in the
domain
BW: The total granted traffic entering the network from srcER and
departing from DesER
Class: Traffic class of the service
Buffer: Buffer size of the interface
Priority: Schedule priority of packets
Bucket: Size of the bucket used for traffic conditioning

(3) Admission Control (AC)

Admission Control component (AC) has several functions:

A. Decompose QoS requirement for domains in the end to end path
Because q_e2e may traverse multiple domains, which adopt different
QoS mechanisms, AC should decompose q_e2e into QoS requirements
q_i(i=1,2,...,m) for each domain. m is the total number of domains
in the end to end path, and q_i corresponds to domain i.

B. Translate user's QoS requirement q_i into resource requirement.
After decomposition, AC needs to translate each QoS requirement
q_i into resource requirement for domain i.
Function maps QoS requirement to resource requirement.

f: q_i -> r_out_i

In which
r_out_i=(srcER,DesER,BW,Class,Buffer,Priority,Bucket)

Expires: March 18, 2006 bupt [Page 14]
Internet Draft October 18, 2005

C. QoS requirement Admission
According to QoS requirement q_i, AC consult available resource
database for resource matrix, and admit user's requirement. If
resource is sufficient, admission is successful, or an admission
failure notification is returned with the failed reason to guide
the next step negotiation. The whole process of admission control
contains the following steps:

Class = Extract Service Class from r_out_i;
R = Find Corresponding Matrix to Class,it may be r_Gold(i,j),
r_Silver(i,j) or r_Bronze(i,j);
Result = CAC(r_out_i,R);
If Result = = Failed
{
Append (Reason, Result);
}

Successful and failed admission results are expressed here as xml
documents:

<CAC Result>Success</CAC Result>

<CAC Result>Failed</CAC Result>
<Reason>BW is too large</Reason>

D. Modify corresponding resource matrix after successful admission
If admission turns out to be successful, resource assigned should
be subtracted from the available resource database.

(4) Monitor Task Generator (MTG)

MTG is responsible for generating monitor task for user's QoS
requirement, in order to guarantee QoS provisioning. AC decomposes
user's QoS requirement for each domain in the end to end path, which
adopts different QoS mechanisms. Similarly, their monitoring methods
are also different. MTG should generate monitor task for each domain
according to its QoS mechanism. TaskGen is a function which maps
QoS requirement q_i to a monitor task. The monitor task generation
process is described below.

TaskGen: q_i -> T_i

T_i=(Address,Class,MonTime,Param)
Address=(SrcIP,SrcPort,DesIP,DesPort)
Class=Gold|Silver|Bronze
MonTime=(StartTime,EndTime,Interval)
Param=(Throughput,Delay,Jitter,LossRate)

Expires: March 18, 2006 bupt [Page 15]
Internet Draft October 18, 2005

Table 2: Parameters of Monitoring Task

The measurement technologies supported by routers can be used. For
example, Cisco routers provide active measurement SAA and passive
measurement Netflow. Both of them can be used in the monitor task.

Expires: March 18, 2006 bupt [Page 16]
Internet Draft October 18, 2005

(5) Deployment

After user's requirement is admitted and monitor task is generated,
Deployment component will create deployment task specification for
bottom layers. The deployment task specification is the "middle
language" of QoSJava. It contains the information of the resource
should be assigned for QoS provisioning and the monitor task should
be enforced for QoS guarantee. The specification can be an xml
document with consentaneous labels of the system. It can also be a
configuration file with API provided by bottom layers. No constraint
for the format of this specification. All depend on the developer.
In the QoSJava framework proposed in this draft, the lower layer,
i.e. QoS Mechanisms Adapter, provides a serials of API for
Deployment component. Deployment component can use these APIs to
Issue orders, demand on resource assignment and monitor task
enforcement.

3.2.4 QoS Mechanisms Adapter

Different QoS mechanisms have different resource management patterns
and different QoS provisioning methods. In IntServ, resource should
Be reserved in all the routers along the end to end path. And
DiffServ classifies traffic at the edge and specifies packets' PHB,
i.e. EF, AF and BE. As for MPLS, it establishes LSP and sticks
labels to the packets in the entrance router. In addition, they
Behave differently in traffic monitoring. QoS Mechanisms Adapter is
meant to conceal their heterogeneity and provides a unify interface
for Resource Manager.

QoS Mechanisms Adapter should perform at least two operations.
One is to interpret resource assignment task r_out_i, and the other
to interpret monitor task T_i. Based on the mechanisms adopted in the
domain, QMA translates the deployment task specification to a script
containing a series of instructions provided by Device Driver. The
adapting scheme is as follows:

r_out_i and T_i are specified in the Deployment Task Specification.

Expires: March 18, 2006 bupt [Page 17]
Internet Draft October 18, 2005

In IntServ, QMA needs to translate the Deployment Task Specification
to the configuration of all the routers located in the domain along
The end to end path. In DiffServ, QMA translates the specification
to the configuration of Ingress router and Egress Router, which may
include traffic class (EF/AF/BE), queue priority, packet dropping
scheme, etc. As for MPLS, the specification is translated to
establishment and monitor of LSP, including label distribution.

Expressions aforementioned only describe the semantics of QMA's
result. In implementation, the result given by QMA would be an
execution script with instruction sequence. An instruction
encapsulates a series of commands for network devices and can
perform an advanced task. An example is given below. It describes a
scenario in which domain D_1 adopts IntServ. Thus in D_1, resource
reservation and monitoring task deployment should be done in all
routers along the end-to-end path.

[INTSERV_QOSCONFIG]
#ResvRes<Domain D_1, IP of Router 1, r_out_i tuple>
#DeployMonTask<Domain D_1, IP of Router1, T_i tuple>
¡
#ResvRes<Domain D_1, IP of Router N, r_out_i tuple>
#DeployMonTask<Domain D_1, IP of Router N, T_i tuple>

When a new QoS mechanism comes out, new adapting model can be added
to QoSJava by extending the execution script or adding some new
Execution scripts. Therefore QoSJava is compatible with new QoS
mechanism without violating the existing QoS mechanisms. Thus
variety of QoS mechanisms could be coexistent in the network to
provide end to end QoS.

3.2.5 Device Driver

While QoS Mechanisms Adapter conceals heterogeneity of QoS
mechanisms, Device Driver has the purpose of making the difference
of network devices transparent. DD provides instruction set for QMA,
and interprets each instruction to commands corresponding to devices
of the domain. DD realizes automatic configuration of network
devices, including system setting, initializing, QoS configuration
and easurement data collection.

Expires: March 18, 2006 bupt [Page 18]
Internet Draft October 18, 2005

An instruction example which is interpreted to commands of Cisco
Router (2600, 3600 and 7200 series) is given below.

#MODIFY_SERVICECLASS <19>
@TELNETCONN <1>
******
Enable
******
Config terminal
policy-map p-in-<19>
class <17>
police cir <10> bc <11> pir <12> be <13> conform-action set-
dscp-transmit <14> exceed-action drop
violate-action drop
@TELNETDISC

Note: <N> means the Nth formal parameter of the instruction.

When the script with this instruction (#MODIFY_SERVICECLASS) is
executed by Device Driver, the instruction will be interpreted into
a sequence of commands, completing the task of service class
modification. First the API of telnet package provided by operating
system is used to telnet to the router and establishes a connection
(@TELNETCONN). Then password (******) is transmitted to the router.
After authentication, administrator's priority would be upgraded
using command "enable" and password needs to be input again. Service
class is modified in succession. The command "police" sets the
parameters including committed information rate (cir), confirm burst
(bc), peak information rate (pir), exceed burst (be) and the dscp
value attached to packets whose rates are less than cir (set-dscp-
transmit). It also indicates that all packets whose rates are greater
than cir will be dropped. When the task is completed, it disconnects
from the router (@TELNETDISC). These commands will be executed in
batch, avoiding administrator's interference.

When we say network devices, we mainly refer to routers. We can use
SNMP or TELNET to access the router's operation system, and perform
configuration, control and data collection.

3.3 Administration Part

3.3.1 Administrator Interface

Administrator Interface is for system administrators to observe the
performance and status of network routers in the domain. Whether the
admitted QoS requirement is guaranteed and user's traffic is
violating the threshold are also observed. Besides that,
Administrator can issue orders with high level instructions and
implement automatically network devices configuration, such as

Expires: March 18, 2006 bupt [Page 19]
Internet Draft October 18, 2005

startup, stop and reconfiguration. They don't need to login into all
devices and do modification one by one, thus the operational cost
will decrease.

3.3.2 Measurement Data Analyzer

Monitoring user's QoS requirement and collecting QoS metrics is the
basis for billing. Measurement Data Analyzer (MDA) focuses on
analyzing the statistics colleted by network devices, draw a
conclusion of whether user's requirement is fulfilled and whether
user's traffic is conforming to the contract. MDA obtains
Information of monitoring tasks from Monitor Task Generator, and
Correlates monitoring tasks with the statistics. When the analysis
turns out that user's QoS is not fulfilled or user's traffic breaks
the threshold, alarm will be generated. MDA will also deduce the
reason for failure, reminding administrator to take corresponding
measures such as employing Traffic Engineering, changing Router
Table to bypass the bottleneck, and etc.

3.3.3 Topology Management

Topology Management (TM) performs like Network Management software.
Instead of using SNMP directly, TM uses instructions which
encapsulate SNMP commands provided by Device Driver. TM provides
network details for Planning and Admission Control components in
Resource Manager. The information includes domains, routers in the
domain, router IP and corresponding ID, routing table, domain which
the router belonging to, whether the router is an edge router or a
core router, etc. Planning and Admission Control components can use
these information to reconstruct the whole network topology and gain
the resource view.

4. Deployment of QoSJava

QoSJava is deployed for each domain in the network. It may be hosted
by server farm or just a computer with high computation ability. We
give a deployment example in figure.

Expires: March 18, 2006 bupt [Page 20]
Internet Draft October 18, 2005

........................................
. Business Logic Server Group .
........................................
. +------+ +------+ +-------+ +------+ .
. | SLA | | RM | |Monitor| | DD | .
. |Server| |Server| |Server | |Server| .
. +------+ +------+ +-------+ +------+ .
. | | | | .
.....|........|.........|........|...... +--------+
| | | | |Browser |
===============================================----|Terminal|
| | | | | |
........|............|........ +------+ +------+ +--------+
. | | . | | | |
. +-----------+ +----------+ . | Web | |Policy|
. |Performance| |Accounting| . |Server| |Server|
. |DB Server | |DB Server | . | | | |
. +-----------+ +----------+ . +------+ +------+
..............................
. DB Server Group .
..............................

figure 3: QoSJava Deployment

5. Other Issues

When put into large scale use, performance and security issues should
be considered carefully. We thought of adding an Access Server for
dealing with the concurrent users' requests. We will study these
issues in our future work.

6. REFERENCES

[1] Braden, R., Clark, D. and Shenker, S., "Integrated Services in
the Internet Architecture: an Overview", Internet RFC 1633,
June 1994
[2] D. Grossman, "New Terminology and Clarifications for Diffserv",
RFC 3260, April 2002
[3] E. Rosen, A. Viswanathan and R. Callon, "Multiprotocol Label
Switching Architecture", RFC3031, January 2001
[4] R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin,
"Resource ReSerVation Protocol (RSVP) --Version 1 Functional
Specification", RFC 2205, Sept. 1997
[5] Y. Bernet, P. Ford, R. Yavatkar, F. Baker, and etc. "A Framework
for Integrated Services Operation over Diffserv Networks",
RFC2998, November 2000

Expires: March 18, 2006 bupt [Page 21]
Internet Draft October 18, 2005

[6] P Nanda, A Simmonds: 'Providing end-to-end guaranteed quality of
service over the Internet: a survey on bandwidth broker
architecture for differentiated services network', CIT 2001 4th
International Conference on IT, Berhampur, India, 20 - 23
December 2001, pp. 211 - 216.
[7] CADENUS Project Consortium, Deliverable D1.2, End-user services
in the Premium IP: Models, Architectures and Provisioning
Scenarios, http://www.cadenus.org, November 2001
[8] TEQUILA Project Consortium, Deliverable D1.1, Functional
Architecture Definition and Top Level Design,
http://www.ist-tequila.org, September 2000
[9] AQUILA Project Consortium, Deliverable D1201, System
Architecture and Specification for the first trial,
http://www.ist-aquila.org, June 2000
[10] QoS Middleware Research, Monet Research Group,
http://cairo.cs.uiuc.edu/middleware/, January 2004

7. Acknowledgements

Thanks to JunFeng Xiao, Huirong Tian Shuanghong Wang, Chengguan Wang,
YuanYin Chen, Yinghua Cui, YiQiang Ding and all members in QoSA
project for their work for this draft.

8. Author's Address

Questions about this draft can be directed to:

Xiaohui Huang
State Key Laboratory of Networking and Switching,
Beijing University of Posts and Telecommunications
Beijing, P.R.China, 100876
E-mail: hxiaohui@bupt.edu.cn

Yu Lin
State Key Laboratory of Networking and Switching,
Beijing University of Posts and Telecommunications
Beijing, P.R.China, 100876
E-mail: linyu@bupt.edu.cn

Wendong Wang
State Key Laboratory of Networking and Switching,
Beijing University of Posts and Telecommunications
Beijing, P.R.China, 100876
E-mail: wdwang@bupt.edu.cn

Expires: March 18, 2006 bupt [Page 22]
Internet Draft October 18, 2005

Xirong Que
State Key Laboratory of Networking and Switching,
Beijing University of Posts and Telecommunications
Beijing, P.R.China, 100876
E-mail: rongqx@bupt.edu.cn

Shiduan Cheng
State Key Laboratory of Networking and Switching,
Beijing University of Posts and Telecommunications
Beijing, P.R.China, 100876
E-mail: chsd@bupt.edu.cn

Li Jiao
State Key Laboratory of Networking and Switching,
Beijing University of Posts and Telecommunications
Beijing, P.R.China, 100876
E-mail: jiaoli@bupt.edu.cn

Yidong Cui
State Key Laboratory of Networking and Switching,
Beijing University of Posts and Telecommunications
Beijing, P.R.China, 100876
E-mail: nathan@x263.net

9. Full Copyright Statement

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Expires: March 18, 2006 bupt [Page 23]
Internet Draft October 18, 2005

10. Intellectual Property

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/1id-abstracts.html

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html"