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.
The LHL determines local service availability and a local price for each service, and initiates a Quotation message containing QoS specifications and price for each service. When a Query message does not specify any service, the LRN returns quotations for all available services using default values of unspecified service parameters.
The Quotation message is sent upstream towards the HRN, and each intermediate LRN verifies local availability of each service, and increments the price by the local price that it computes. The FHL returns the Quotation message to HRN.
In addition to asynchronously sending Quotation messages, the LHL also sends out Quotation messages periodically, containing price quotations for all services requested by the customer.
In response to a Reserve message, the LHL initiates a Commit message stating the admissibility of the flow. The Reserve request may be admitted or denied, or admitted partially if network resources are scarce and the provider admits the service request with a lower QoS or sending rate than requested. If the flows are admitted, the Commit message also contains a local price for the contracted service, and for an on-going session, it also contains the accumulated local charge for a service. As the Commit message is forwarded upstream, the committed price and accumulated charge are incremented at each router.
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.
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).