This document describes the Hrn part implementation of RNAP (Resource Negotiation and Pricing Protocol ). The HRN negotiates only with its access network to reserve resources. It obtains information and price quotations for available services from the network. It requests particular services, specifying the type of service (Guaranteed, Controlled Load, Differential Services, best effort, etc.), parameters to characterize the user traffic (e.g., peak rate, average rate and burst size) and QoS requirements (e.g., loss rate and delay). The HRN can request a different service for each flow from network through RNAP.
This project implements the Hrn user agent in RNAP Architecture. Hrn can configure the environment for various applications requiring a service and according to a configuration, Hrn controls user applications such as audio or video application using Mbus. Mbus[1] has been designed as a basis for interaction between software components with the aim of enabling construction of complex multimedia conferencing systems out of simple components and simplifying coordimation of several system models. RATv4.2.6[2] is used for an audio application and VIC(2.8ucl1.1.3)[2] for an video application.
The HRN is guaranteed to work on all OS platforms with appropriate software packages:
HRN consists of three components which are HRN Control Engine, Audio engine and video engine. In current version, as a Audio Engine, RAT is used and VIC is used for Video Engine. HRN uses Mbus for control engines and gets information such as session, source/destination IP address and port number, codec for audio engine and sending rate for video engine etc.
If resource reservation is done statically (before transmission), resource reservation and provisioning tend to be conservative due to the lack of quantitative knowledge of traffic statistics. Moreover, the resource allocation is based on initial availability of resources and does not take into account changes in availability during an ongoing transmission. Many multimedia applications are long-lived, exacerbating the problem. Users of rate-adaptive applications do not have any incentive to scale back their sending rate below their access bandwidth, since selfish users will generally obtain better quality than those that reduce their rate. Pricing network services based on the level of service, usage, and congestion provides a natural and equitable incentive for applications to adapt their sending rates according to network conditions. Increasing the price during congestion gives the application an incentive to back-off its sending rate and at the same time allows an application with more stringent bandwidth and QoS requirements to maintain a high quality by paying more. The central goal of our work is to develop a Resource Negotiation and Pricing (RNAP) protocol and architecture with the following main properties:
The customer and network negotiate and agree upon specifications such as the type of service user packets will receive, the constraints the user traffic must adhere to, and the price to be charged for the service. The protocol should be generic and flexible enough to support multiple delivery services and environments (including int-serv, diff-serv, and best effort services), service negotiation at different levels of granularity (flow- and aggregate-based), negotiation by both sender and receiver, and ``in-band'' and ``out-of-band'' resource reservation mechanisms.
It should allow the service provider to communicate service availability, estimated prices for available services and charges accruing to the user, and allow the user to request a specific service. It should also support dynamic service re-negotiation between the user and the network, allowing the network to adjust pricing in response to changes in network load, and allowing the user to respond to changes in application requirements. We refer to the proposed negotiation protocol as the Resource Negotiation And Pricing protocol (RNAP).
Based on the policy of each domain, different algorithms can be used for computation of a local or incremental price for a service at a given point in a network; We propose a number of alternative mechanisms to allow the network to compute a global price on the basis of these incremental prices, and to charge the user for the end-to-end service. The proposed protocol and architecture and pricing mechanism are intended to co-exist with current Internet QOS schemes (e.g. those proposed within the int-serv and diff-serv frameworks), and work in a scalable manner over a variety of network architectures . We present RNAP as a stand-alone protocol, but it is also possible to implement some components of RNAP as a layer on top of RSVP or other hop-by-hop reliable signaling protocols.
RNAP is intended for use by both adaptive and non-adaptive applications. Non-adaptive applications may choose services that offer a static price, or absorb any changes in price while maintaining their sending rate. Adaptive applications adapt their sending rate and/or choice of network services in response to changes in network service prices. RNAP provides a framework within which an application can adapt so as to obtain the best value from the network.
A customer (sender or receiver) wishes to reserve network resources for multiple flows, for example, flows corresponding to audio, video and white-board applications in a video-conference. The customer negotiates with the network through a Host Resource Negotiator (HRN). The HRN negotiates only with its access network to reserve resources, even if its flows traverse multiple domains. It obtains information and price quotations for available services from the network. It requests particular services, specifying the type of service (Guaranteed, Controlled Load (CL), Expedited Forwarding (EF), Assured Forwarding (AF), best effort, etc.), parameters to characterize the user traffic (e.g., peak rate, average rate and burst size) and QoS requirements (e.g., loss rate and delay). The HRN can request a different service for each flow from network through RNAP.
In addition to resource negotiation between the HRN and the network, the RNAP protocol is also intended for resource negotiation between two network domains. An access domain A may receive requests for a service in a certain direction passing through a neighboring transit domain B from one or more users, and use RNAP to reserve resources for the flow or flow-aggregate in domain B. For negotiations by the network service provider, we consider two alternative architectures, a centralized architecture, and a distributed architecture, described below.
The RNAP-C architecture is based on an underlying network divided into Autonomous Systems (AS). Each administrative domain negotiates through a Network Resource Negotiator (NRN). Protocol messages are sent between NRNs, or between HRNs and NRNs, and touch each AS once.
The NRN delivers price quotations for the different available service levels to customers, answers service requests from customers, and is also responsible for maintaining and communicating charges for a customer session.
The NRN may be an individual entity, or may be a complementary functional unit that works with other administrative entities. For example, the NRN can be part of (or function as) the Bandwidth Broker (BB) in the diff-serv model and the PDP in the COPSarchitecture. The NRN either has a well-known address, or is located via the service location protocol (SLP). The NRN address of a neighboring domain can be pre-configured or obtained through DNS SRV.
Resource reservation and admission decisions may be performed by the NRN or by other entities, such as the BB of the diff-serv model. If they are performed by other entities, the NRN communicates requests for services to them individually or in aggregate, and receives admission and pricing decisions from them. The implementation of resource reservation and admission control, and the associated communication with administrative entities, is closely related to specific Better than Best Effort (BBE) services, and is out side the scope of the RNAP protocol.
In this architecture, the RNAP protocol is implemented at each router, in the form of a Local Resource Negotiator (LRN). RNAP messages propagate hop-by-hop along the same path as customer data flows, from the first-hop LRN to the egress LRN, and in the reverse direction.
The RNAP message format is independent of the architecture. Therefore, the two architectures can co-exist; for instance, a domain administered by a NRN can exchange RNAP messages with a neighboring domain which employs the distributed architecture. Also, a HRN does not need to know about the RNAP architecture of its local domain, since it receives and sends the same negotiation messages in either case.
KyungTae Kim (kk521@columbia.edu)