RNAP: A Resource Negotiation and Pricing Protocol
RNAP: A Resource Negotiation and Pricing Protocol
- Introduction
- Architecture
- Messages
- Implementation
Introduction
Motivated by growth of Internet multimedia applications,
a number of researchers have investigated network delivery services that
provide ``better-than-best-effort'' (BBE) service to the user, in the sense
that they provide some QoS support or guarantees to applications.
Important examples of proposed network service models are
the integrated service model (int-serv) \cite{Guaranteed, Controlled-Load},
and the differentiated service model (diff-serv)
\cite {Two-bit, DIFF-SERV}.
As these services are implemented in the Internet, user applications will
be able to request and use the delivery service appropriate to their
requirements. We may regard the selection and use of a specific delivery
service as a negotiation process. 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 central goal of our work is
to develop a protocol through which this negotiation can take place.
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.
Architecture
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 \cite{Guaranteed}, controlled load \cite{Controlled-Load} (CL),
expedited forwarding \cite{EF}, assured forwarding \cite{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.
Centralized Architecture (RNAP-C)
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) (Fig. \ref{RNAP_C}).
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 \cite{Two-bit}
and the PDP in the COPS architecture \cite{COPS}.
The NRN either has a well-known address, or is located via the service
location protocol \cite{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.
Distributed Architecture (RNAP-D)
In this architecture, the RNAP protocol
is implemented at each router, in the form of a Local Resource Negotiator
(LRN) (Fig. \ref{RNAP_D}).
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.
We consider the messaging process in greater detail after introducing
specific RNAP messages in Section \ref{sec:Protocol_Messages_and_Message_Fields}.
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.
Messages
-
Query
The HRN uses {\em Query} messages to request a price quotation from
the NRN for one or more services, for a flow or group of flows belonging
to the customer.
The message consists of a set of {\em Flow Ids}, and one or more
service fields accompanying each {\em Flow Id}. The HRN specifies a set of
requirements (such as service time and QoS) with each service, by setting appropri
ate service sub-fields.
When the HRN sends a {\em Query} for the first time, the NRN also sets up state
information for a new {\em RNAP session}.
-
Quotation
Upon receiving a {\em Query} message, the NRN determines the price
for each service for which quotations were requested,
and returns a list of {\em Service} and {\em Price}
pairs inside a {\em Quotation} message.
When a {\em Query} message has null {\em Service} list, the
NRN returns quotations for all available services using
default values of unspecified service parameters;
it does not return quotations for services which have one
or more mandatory parameters to be specified by the customer.
In addition to asynchronously sending {\em Quotation} messages,
the NRN also sends out {\em Quotation} messages periodically.
A {\em Quotation} message sent periodically
contains price quotations for all
services requested by the customer.
-
Reserve
The HRN sends a {\em Reserve } message to apply for services with specified s
ervice
parameters for
a flow or group of flow.
A {\em Reserve} message
is sent at the beginning of a session to request services for the first time, and
thereafter,
periodically at {\em Negotiation Intervals}, and also asynchronously at any time.
In general, each {\em Reserve} message carries
one or more {\em Flow Id-Service-Price} triples. The function of the
{\em Price} structure in this context is explained in Section
\ref{pricing_structure}.
-
Commit
The {\em Commit} message is generated by the NRN in response to a
{\em Reserve} message, and consist of a set of
{\em Flow Id}, {\em Service},
{\em Status} and {\em Price} 4-tuples.
The reservation request indicates the desired and minimum acceptable
QoS (in {\em HRN Data} fields presented in Section \ref{sharing_mcast}).
The {\em Reserve} message keeps track of the currently allocated
resources, which fall within that range.
For each {\em Flow Id }, the NRN determines the admissibility
of the flow, and returns this information in the {\em Status} field, as
{\em Admit\_Complete}, {\em Admit\_Incomplete} or {\em Reject}.
The admission policy is specific to the service, and need not be administered
by the NRN. The {\em Status}
is {\em Admit\_Incomplete} 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 NRN returns the price for providing the service
in the {\em Price} field
(normally the same as the price quoted in the preceding {\it Quotation} message).
If the {\em Commit} is in response to a re-negotiation {\em Reserve} request in an
ongoing session,
the NRN also returns the amount charged for each service in the preceding
negotiation period, and the accumulated charge since the beginning of the
session.
-
Preempt
If a {\em Service} is set as preemptable, the NRN may send a {\em Preempt}
message to the HRN to unilaterally change the service parameters
or price, or even terminate the service, at any
time during a {\em Negotiation Interval}. This allows the provider to make room
for other more important flows urgently, without waiting for the end of a
{\em Negotiation Interval}. A preemptable service would be expected to cost
less than an equivalent non-preemptable service.
-
Close and Release
A {\em Close} message is sent from the HRN to the NRN to signal the
end of an RNAP session. The NRN sends a {\em Release} message in acknowledgment.
Last Updated:
Tue Feb 3 08:47:45 PST 1998