Differentiated Services, in short Diffserv, has been the first candidate to satisfy the requirements of scalable Quality of Services (QoS) over the global Internet by the means of clear distinction between the forwarding path behavior and the control plane management. Bandwidth Broker (BB), which is a server of control plane first presented by Francis et al. in [Two-Tier], configures the forwarding path behavior in routers. Since Diffserv specifies only externally observable forwarding path behavior, each vender can implement the different mechanisms. In order to make BB manage the different forwarding paths uniquely, we propose the design of the router equipped with Virtual Configuration Manager (VCM) where configuration requests from BB, written by a higher-level description, translate into specific parameters of its own forwarding path. Thanks to VCM, the control plane management can handle all routers uniquely without aware of their implementations.
In order to support end-user applications that require QoS to the Internet, such as a viewer application for Internet broadcasts, the Internet community has attempted to put a QoS function on the global Internet for more than a decade. Integrated Services was the first solution to handle each packet differently; each intermediate router, between a sender node and a destination node, has to associate the incoming packets with the flow to which they belong by looking at some parts of the IP header: the source address, the destination address, the port address and the protocol ID. Integrated Services can treat each flow in a different way, although this flow classification mechanism clearly has less scalability because of the flow table with dense granularity.
Differentiated Services (Diffserv), which has as its primary goal "allowing different levels of service to be provided for traffic streams on a common network infrastructure," [RFC2475], was convinced by the Internet Engineering Task Force (IETF) community to overcome the shortcoming of Integrated Services discrimination. Diffserv makes the forwarding path behavior scalable and flexible by means of binding packets to limited levels of class. On the other hand, the challenge to the control plane has just started. In this paper, we present a simple control plane architecture that enables unique handling of all routers with different implementations.
The rest of the paper is structured as follows: in the following part, the brief outline of Diffserv and the Two-Tier resource management are presented. Our proposed architecture is described in section 2. We show the implementation of the architecture and conclude with some items for future work.
Forwarding Path serves for the "special" treat to each packet by queue service discipline and/or queue management discipline. An edge router associates each incoming packet with the service level indicated by the DS codepoint (DSCP) in DS Field, the former TOS field. For instance, a packet whose DS field contains "101110" should be treated as its departure rate must equal or exceed a configurable rate following the fashion of Expedited Forwarding (EF) Per Hop Behavior [RFC2598]. IETF also defines another PHB, called Assured Forwarding PHB (AF) [RFC2597] with multiple thresholds to discard packets. Because of this flow aggregation mechanism, Diffserv has succeeded in making forwarding path behavior simple and scalable. As shown in Figure 1, a Diffserv router is composed of five logical components in addition to the traditional router components:
Each above component is configured through the Management Plane described in the following section.
The control plane, or Management Plane, includes the configuration of Forwarding Path in edge routers with respect to which packets should have special treatment and what kind of rules are to be applied to the use of resources. Diffserv WG in the IETF community has been focused on Forwarding Path and the design of Management Plane remains as a great challenge.
A framework that insists to separate Management Plane to inter-domain and intra-domain, following the current routing architecture, is proposed by Francis et.al. in [Two-Tier]. In this architecture, SLA [Note 1] negotiations between domains and resource allocations to Forwarding Path are managed by Bandwidth Broker (BB) as the representative of a domain, as shown in Figure 2. [Note 1: In the latest Internet-draft for the Diffserv [Term], a Service Level Specification (SLS), which refers to the particular information relative to the BB and the network devices in order to support an SLA in that network, was newly defined. In order to avoid complication, we simply use SLA for the meaning of both SLA and SLS.]:
Since Diffserv specifies only externally observable behaviors in the Forwarding Path, equipment vendors can use different mechanisms to implement these behaviors. This mechanism also might be in differentiation strategy and the vendor would veil the detailed specification. The vendor might use a priority queue, a weighted round robin scheduler or its original implementation for Expedited Forwarding (EF), for example. If BBs were to directly control each router they would have to be aware of the details of each router's implementation. This level of detail complicates the design of a BB, especially in large heterogeneous domains where a number of different router designs coexist.
Similar problems were faced in the World Wide Web architecture to make executable applications on a server run on heterogeneous clients running on various types of OS. JAVA architecture, where an OS independent code named Applet is running on an OS-free virtual machine, has satisfied this requirement.
Following this notion, we propose the design of an edge router equipped with Virtual Configuration Manager (VCM), where a higher-level description named Virtual Configuration Description (VCD) generated in BB is translated into the specific parameters of Forwarding Path. Therefore, since VCM succeeds to veil the details of Forwarding Path implementation, BB can concentrate on the management of SLA without being aware of different implementations of routers. To clarify this mechanism, we present the architecture of VCM in the following section.
In order to clarify and satisfy the requested functions of VCM, it is divided into three modules with respect to the queries from BB: Resource module, Local rule module and Outsourcing module, as shown in Figure 3.
This module processes the VCD categorized queue service disciplines and/or queue management disciplines.
The biggest challenge of this design is defining the granularity of the VCD. If it has dense granularity, BB might be aware of the implementation of each edge router. However, the coarse granularity might cause the inaccurate queue management. In terms of simplicity, we decide to set its criteria to the proposed PHBs, EF and AF, because both SLA and Forwarding Path will be designed taking them into consideration. So peak bandwidth and burst tolerance parameters for EF, or peak bandwidth and two levels burst tolerance parameters for AF, are included. Therefore, this module is in charge of interpreting the VCD to the specific parameters of Forwarding Path with the monitoring of Forwarding Path.
This module is in charge of reflecting the local rule with SLA on each edge router. If there are no rules, the VCD is directly applied to Forwarding Path.
An example of the entity which requires local rule is metering, since each router might have the different metering mechanism, the installation parameters should be a combination of queries from BB and the rules. On the other hand, DSCP may be directly mapped to the classifier and the marker.
This module processes the VCD requiring the joint work with the entities outside of the Management Plane.
One of the candidates of VCD processed by this module is for the reservation to intra-domain resources. For instance, if a domain services explicit routing, all the router's IP addresses on the way from the ingress router to the egress router might be suggested by BB which includes Route Server function. Or in case of servicing Multi-Protocol Label Switching (MPLS), this module simply hands over the IP address of the egress router to Label Distributed Protocol (LDP).
As described above, by classifying the functionality of VCM into three modules, we can finally get the sketch of the design.
The example described below assumes edge routers equipped with CBQ [CBQ] and RED [RED] for shaping and dropping, and a token bucket for policing. Also, BB is expected to the SLA negotiation in static fashion.
As the first step, triggered by creation, update or deletion of SLA for an EF traffic by an administrator, BB generates the peak bandwidth and the burst tolerance parameters from SLA, which are assumed 30Mbps and 100 milliseconds here, in order to describe VCD. For the resource reservation of intra-domain, the egress router of the EF traffic is designated by the destination address specified in SLA through the routing tables constituted of all edge router's routing tables acquired from internal BGP (IBGP). BB also assigns EF DSCP, 101110, and settles the charging rule to the traffic.
After the creation of the VCD, the BB transmits it to both of the egress router and the ingress router that faces the upstream domain.
In the case of the egress router, after receiving the request, it should configure the shaper: CBQ, which provides a hierarchy of arbitrary defined traffic classes to share the bandwidth on a link in controlled fashion. The resource module in VCM interprets the peak bandwidth and the burst tolerance parameters to its specific parameters. If the EF class in CBQ still affords more than 30Mbps with 100 milliseconds for burst tolerance, the VCM simply updates the class reflecting the parameters. If the class is full but it is possible to take resources from the best effort class, the VCM updates both classes to accommodate the requests, so that the managing of the queue condition is a major role of VCM. Also RED, which is constituted of maximum queue length, weight for the discarding, max and min drop probability for the dropper, is configured as the same fashion as CBQ. Subsequently, the Local rule module installs the DSCP, 101110, and the charging rule into the classifier and the meter. The Outsourcing module in the egress router does not commit the reservation to the intra-domain resources since this is triggered by the ingress router. Under the successful configuration, the egress router returns an ACK message to the BB and waits a signal from the manager of intra-domain resources in order to associate the above configuration with.
After receiving the ACK message from the egress router, the BB sends the same request to the ingress router. Then the Resource module in the router applies 30Mbps as the peak bandwidth and 100 milliseconds as the burst tolerance to the token bucket rate and depth for the policer and the Local rule module installs the queries to the meter, the classifier and maker as the same as the egress router. Finally, the manager for the reservation of intra-domain resources is activated; RSVP [RSVP] might be used for this reservation. After the acquirement of the intra-domain resources, the router sends the successful result back to the BB by an ACK message.
The BB finally notifies the completion of the mission to the administrator after receiving the ACK messages from both the egress and the ingress router.
In case of the failure of this mission, notified by a NACK message from the egress or the ingress, the BB informs the administrator of it.
Having implemented a prototype edge router and BB following this model, we present the brief architecture which uses Common Open Policy Service (COPS) Protocol [COPS] for the message exchange between BB and the edge routers.
COPS, designed by the IETF community, provides policy control over QoS signaling in a simple fashion. COPS is based on a client-server model: Policy Decision Point (PDP) as the server of policy management and Policy Enforcement Points (PEPs) as the clients of PDP. So in our architecture, the PDP function is included in BB and edge routers contain the PEP function. COPS consists mainly of three messages as shown in Figure 4: Request (REQ) message for query the request from PEP to PDP, Decision (DEC) message for sending the appropriate parameters in response to the REQ message from PDP to PEP, and Report (RPT) message to notify the result of the installation to PDP. Thanks to the transmission of these messages on a TCP connection, COPS reaches reliability.
The operations of COPS are classified into Outsourcing Operations and Configuration Operations. In the outsourcing scenario, receiving an event that requires a new policy decision, PEP sends a REQ message to the remote PDP which makes a decision and sends a DEC message back to the PEP. The PEP is responsible for deleting the installed request once the request is no longer applicable. The PEP can update a previously installed request state by reissuing a REQ message. The remote PDP is then expected to make new decisions and send a decision message back to the PEP. In the configuration scenario, as in the outsourcing scenario, the PEP will make a configuration request to the PDP. The PDP will then send potentially several decisions of configuration data to the PEP. The PEP is expected to install and use the configuration locally. A particular named configuration can be updated by simply sending additional decision messages for the same configuration.
The block diagram of our prototype router is shown in Figure 5:
We also have sketched the block diagram of BB as shown in Figure 6. Since the COPS common module and the specific message object module have the same functions as the router's, we describe the others here:
As described above, we can achieve the unique Forwarding Path management on the heterogeneous network where each router has different implementation of Forwarding Path. The JAVA based implementation of VCM module can successfully lead to portability to run it on various routers.
We have presented the basic design of the Management Plane where BB can manage edge routers in a unique way without being aware of their implementation. In the two-tier architecture, a resource manager for the inter-domain resource negotiation, the Bandwidth Broker, has the responsibility to reflect SLA into edge routers equipped with Forwarding Path for treating the packets in Diffserv fashion. To handle the different Forwarding Path implementation, our proposed VCM works as an interpreter implemented in an edge router to translate queries of the configuration of Forwarding Path to the specific parameters for the router. This configuration is written by a higher-level description, named Virtual Configuration Description, designed to handle all routers uniquely. By dividing it into three modules -- Resource module, Local rule module and Outsourcing module -- we have succeeded in the design of VCM. Also in order to achieve adaptability, VCM is decided to implement by JAVA.
Our current research area is not only to specify the details of the architecture for a Diffserv capable router, but also to design the signaling protocol for the dynamic negotiation of SLA between BBs. Therefore, future work is as follows:
[CBQ] S.Floyd, V.Jacobson, "Link-sharing Resource
Management Models for Packet Networks." IEEE/ACM Transactions on Networking,
Vol.3 No.4, August 1995.
[COPS] J.Boyle, R.Cohen, D.Durham, S. Herzog, R.Rajan,
A.Sastry, "The COPS (Common Open Policy Service) Protocol." Internet-Draft,
[RED] S.Floyd, V.Jacobson. "Randmon Early Detection
Gateways for Congestion Avoidance." IEEE/ACM Transactions on Networking, August
[RFC2475] S.Blake, D.Black, M.Carlson, E.Davies,
Z.Wang and W.Weiss. "An Architecture for Differentiated Services." RFC 2475, December 1998.
[RFC2597] J.Heinane, F.Baker, W.Weiss, J.Wroclawski,
"Assured Forwarding PHB Group." RFC 2597, June
[RFC2598] V.Jacobson, K.Nichols, K.Poduri. "An
Expedited Forwarding PHB." RFC 2598, June
[Term] D.Grossman. "New Terminology for Diffserv."
Internet-Draft, November 1999.
[Two-Tier] F.Reichmeyer, L.Ong, A.Terzis, L.Zhang,
R.Yavatkar. "A Two-Tier Resource Management Model for Differentiated Services
Networks." Work in progress, Internet-Draft, November 1998.
[RSVP] R.Braden, L.Zhang, S.Berson, S.Herzog, S.Jamin.
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification."
RFC 2205, September 1997.