Internet Draft xiaohui Huang Expires: 20 July 2005 Yu Lin Wendong Wang Xirong Que Shiduan Cheng Li Jiao Yidong Cui bupt,china 20 January 2005 QoSjava: An Open and Scalable Architecture Decoupling QoS Requirements from QoS Techniques Status of This Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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: July 20, 2005 bupt [Page 1] Internet Draft January 20, 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........................................19 3.3 Administration Part........................................19 3.3.1 Administrator Interface..............................19 3.3.2 Measurement Data Analyzer............................19 3.3.3 Topology Management..................................20 4. Deployment of QoSJava..........................................20 5. Other Issues...................................................20 6. References.....................................................21 7. Acknowledgements...............................................21 8. Author's Address...............................................22 9. Full Copyright Statement.......................................22 10. Intellectual Property.........................................23 Expires: July 20, 2005 bupt [Page 2] Internet Draft January 20, 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 with 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: July 20, 2005 bupt [Page 3] Internet Draft January 20, 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: July 20, 2005 bupt [Page 4] Internet Draft January 20, 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: July 20, 2005 bupt [Page 5] Internet Draft January 20, 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: July 20, 2005 bupt [Page 6] Internet Draft January 20, 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 | | ªR | | | | | | ªR | | | | +------+-------+------+------+ | +------+-------+------+------+ 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: July 20, 2005 bupt [Page 7] Internet Draft January 20, 2005 +-----------+--------------------------+---------------------------+ | | Java | QoS | +-----------+--------------------------+---------------------------+ | | Platform-independent |Providing an open, scalable| | | application development | and feasible end to end | | Challenge | in multi-vendor and |QoS provisioning solution | | | multi-operating system |in heterogeneous network | | | environment |environment including | | | |multiple user requirements,| | | | multiple vendor router | | | |platforms and multiple QoS | | | |mechanisms | +-----------+--------------------------+---------------------------+ | User |User requirement is |User requirement is | |Requirement|described in Java |described in SLA or | |Description|language(i.e. Source Code)|contracts signed by users | +-----------+--------------------------+---------------------------+ | |Java code is translated |User requirements are | | |into a í—middle languageí˜, |translated into resource | | |which is interpreted by |requirement for network, | | |Java virtual machine into |and finally into a í—middle | | |a series of machine |languageí˜, i.e. deployment | | |instructions of specific |task specification. Based | | Solution |computer and operating |on the QoS mechanism | | |system, thus Java has |adopted and the command set| | |platform-independent |of network device, Device | | |property |Driver interprets the | | | |deployment task | | | |specification into specific| | | |router commands and do | | | |configuration | +-----------+--------------------------+---------------------------+ Table 1: Comparison between Java and QoSJava 3. QoSJava Architecture This section gives a detail description of QoSJava framework and its components. Expires: July 20, 2005 bupt [Page 8] Internet Draft January 20, 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: July 20, 2005 bupt [Page 9] Internet Draft January 20, 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: July 20, 2005 bupt [Page 10] Internet Draft January 20, 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: July 20, 2005 bupt [Page 11] Internet Draft January 20, 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: July 20, 2005 bupt [Page 12] Internet Draft January 20, 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: July 20, 2005 bupt [Page 13] Internet Draft January 20, 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: July 20, 2005 bupt [Page 14] Internet Draft January 20, 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: Success or Failed BW is too large 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: July 20, 2005 bupt [Page 15] Internet Draft January 20, 2005 The semantic of all parameters are listed in table 2: +----------+--------------------------------------------------------+ | Item | Detail | +----------+--------------------------------------------------------+ |Address |The tuple represents monitoring location | +----------+--------------------------------------------------------+ |SrcIP |IP of Ingress router to be monitored | +----------+--------------------------------------------------------+ |SrcPort |Port of Ingress router to be monitored | +----------+--------------------------------------------------------+ |DesIP |IP of Egress router to be monitored | +----------+--------------------------------------------------------+ |DesPort |Port of Egress router to be monitored | +----------+--------------------------------------------------------+ |Class |Class of the service | +----------+--------------------------------------------------------+ |Gold |Gold service, similar as EF traffic class in DiffServ | +----------+--------------------------------------------------------+ |Silver |Silver service, similar as AF traffic class in DiffServ | +----------+--------------------------------------------------------+ |Bronze |Bronze service, similar as BE traffic class in DiffServ | +----------+--------------------------------------------------------+ |MonTime |The tuple represents monitorí¯s task schedule | +----------+--------------------------------------------------------+ |StartTime |Start time of the monitor task | +----------+--------------------------------------------------------+ |EndTime |End time of the monitor task | +----------+--------------------------------------------------------+ |Interval |Interval of collecting monitor data | +----------+--------------------------------------------------------+ |Param |The tuple represents monitor task detail | +----------+--------------------------------------------------------+ |Throughput|Throughput between Ingress router and Egress router | +----------+--------------------------------------------------------+ |Delay |Packet delay between Ingress router and Egress router | +----------+--------------------------------------------------------+ |Jitter |Packet jitter between Ingress router and Egress router | +----------+--------------------------------------------------------+ |LossRate |Packet loss rate between Ingress router and Egress | | |router | +----------+--------------------------------------------------------+ 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: July 20, 2005 bupt [Page 16] Internet Draft January 20, 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. + - Configuration of all routers along the path (IntServ) | QoSAdapter | - Configuration of edge routers (DiffServ) (r_out_i) = | | - Establish LSP between routers (MPLS) | + - To be extended (other QoS mechanisms) Expires: July 20, 2005 bupt [Page 17] Internet Draft January 20, 2005 + - Monitor all routers along the path (IntServ) | QoSAdapter | - Monitor Ingress router and Egress router (DiffServ) (T_i) = | | - Monitor entrance and exit of LSP (MPLS) | + - To be extended (other QoS mechanisms) 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. [DoServiceClassModify] @TELNETCONN <1> qos863 Enable qos863 Config terminal policy-map p-in-<2> class <3> police cir <4> bc <5> pir <12> be <6> conform-action set-dscp-transmit <7> exceed-action drop violate-action drop end @TELNETDISC Note: means the Nth formal parameter of the advanced task. Instructions described the advance task to be performed. Completing the task needs a series of commands executed in the router. For example, when the service class needs to be modified, first it should telnet to the router and establishes the connection. Then password should be transmitted to the router. After authentication, Administrator's priority should be upgrade using command "enable". 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. Expires: July 20, 2005 bupt [Page 18] Internet Draft January 20, 2005 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. Instruction: @TELNETCONN When the script with the instruction is executed by Device Driver, this instruction will be interpreted into a series of commands, completing the task of telnet the router whose ID is RouterIP. 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 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. Expires: July 20, 2005 bupt [Page 19] Internet Draft January 20, 2005 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. ........................................ . 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. Expires: July 20, 2005 bupt [Page 20] Internet Draft January 20, 2005 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 [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. Expires: July 20, 2005 bupt [Page 21] Internet Draft January 20, 2005 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 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 Expires: July 20, 2005 bupt [Page 22] Internet Draft January 20, 2005 9. Full Copyright Statement Copyright (C) The Internet Society (2004). 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. 10. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.