The development and use of distributed multimedia applications are growing rapidly. These applications usually require a minimum Quality of Service (QoS) from the network, in terms of throughput, packet loss, delay, and jitter. Also, multimedia applications on the Internet commonly employ the UDP transport protocol, which lacks a congestion control mechanism. These applications can therefore starve TCP applications (which perform congestion control) of their fair share of bandwidth. Different approaches have been considered to address these problems:
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.
Basic RNAP messages include: Query, Quotation, Reserve, Commit, Preempt, Close and Release. We first consider how a customer reserves resources for a flow or group of flows end-to-end, to a particular destination address, assuming that the intervening domains implement RNAP-D.
When a customer flow traverses a domain implementing RNAP-C, with a controlling NRN, the flow of messages is identical to that considered earlier for RNAP-D, if each domain is considered to be equivalent to a single node, with the NRN corresponding to the LRN for that node. Accordingly, the NRN is responsible for collecting and communicating admission and pricing and charging information for the domain as a whole instead of for a single node. It is also possible that the flow traverses multiple domains some of which implement RNAP-C and others RNAP-D. In this case, the NRN of a RNAP-C domain would talk to the corresponding boundary LRN of an adjoining RNAP-D domain, and the messaging flow would be as before.
If end-to-end RNAP reservation is carried out for each customer flow, RNAP agents in the core network may potentially need to process RNAP messages for hundreds of thousands of flows, and maintain state information for each of them. In this section, we discuss how RNAP messages can be aggregated in the core of the network by allowing RNAP agents to handle reservations for flow-aggregates instead of individual flows.
All RNAP messages have a Id field identifying the corresponding data flow; it contains 3 sub-fields: Flow Id, Aggregation Flag, and Aggregate Flow Id. We consider the aggregation by an RNAP agent of RNAP messages belonging to a number of different senders on a sink tree, that is senders with the same destination network address. The aggregating agent aggregates RNAP messages for user flows which have the same destination network address (obtained from the Flow Id), and also use the same or similar services and have similar negotiation intervals. We consider aggregation for RNAP-D, and aggregation for RNAP-C separately.
The main RNAP messages, Query, Reserve, Quotation and Commit, all contain a common Price structure, used to convey pricing and charging information. The Price structure carried by RNAP messages consists of the following fields: New Price, Current Charge, Accumulated Charge, and HRN Data. There is a Price structure corresponding to each service being negotiated by a RNAP message. The New Price field contains the price quoted by the network provider to the negotiating HRN for the next negotiation period. The Current Charge field contains the amount charged by the network provider for the preceding negotiation period. The Accumulated Charge field contains the total amount charged by the network provider since the beginning of the negotiation session and is carried to protect against the loss of Commit messages. RNAP addresses the issue of arriving at the contracted price to be quoted for a flow receiving a particular service in a given negotiation period, and computing the charge for the service at the end of the period ( Price and Charge Formulation in RNAP-D, Price and Charge Formulation in RNAP-C).
Last Updated: 5/00