1. RNAP: A Resource Negotiation and Pricing Protocol
Xin Wang, Henning Schulzrinne
Columbia University
(This work was supported by Hughes Research Lab)
My name is (not necc. if you are introduced)
I will be talking about our work on RNAP, a Resource...
This is work done jointly by me and Prof. ....

2. What is RNAP?
Assumption: network provides a choice of delivery services to user
e.g. diff-serv, int-serv, best-effort, with different levels of QoS
with a pricing structure (may be usage-sensitive) for each.
RNAP: a protocol through which the user and network (or two network domains) negotiate network delivery services.
Network -> User: communicate availability of services; price quotations and accumulated charges
User -> Network: request/re-negotiate specific services for user flows.
Underlying Mechanism: combine network pricing with traffic engineering
I will first briefly talk about what RNAP is intended to do.
Let’s assume that ....
RNAP is a protocol through which ...
Using the protocol, the network tells the user about ...
In turn, the user requests.....

3. Outline Motivation Basic RNAP messaging Protocol details
Architectures
Scaling in Core Domains
Advance reservation
Pricing and charging
Experimental Results
Summary of Protocol Features
Future work
I will first present the motivation behind our work
I will briefly describe the basic messaging sequence in RNAP
I will then go into more detail about some important protocol fetaures
I will then briefly discuss some preliminary experimental results
Finally I will summarize my talk

4. Motivation
If multiple delivery service types are available, a flexible service selection and request mechanism is desirable.
BBE services need pricing and charging support.
Selecting and requesting a service at an agreed-upon price involves negotiation between user and network
Why do we need the RNAP protocol?
If the network has a number of delivery services available with different specifications and QoS levels, users/user applns need a means to select from the spectrum of services
To allow an environment with different types and levels of service to work, they have to be priced appropriately.
Obtaining information about available services, requesting a service to a spec. destination at an agreed upon price, etc. involves negotiation between user and network.

5. Motivation (Cont’d)
Dynamic resource negotiation capability and congestion sensitive pricing are desirable
Pricing signals congestion - allows safe and graceful QoS degradation OR increased spending to keep stable service
Allows better resource utilization- dynamic re-negotiation allows higher utilization as resources need not be requested/provisioned conservatively
Allows network resources to be obtained immediately - even during congestion (at high cost), e.g., urgent phone call
Network can quickly recover from unexpected events - such as network failure by re-negotiating with users
Some other things are desirable in this negotiation process. We would like the user and network to able to re-negotiate during an on-going session, and we would like the network to be able to adjust the price according to network conditions, and communicate this to the user.
network to recover gracefully from mis-behavior (congestion can happen even all user traffic stay in contract)
(throughput, jitter bounds) for dynamic (multimedia) traffic may change over time.

6. Typical Message Sequence
Query: User enquires about available services, prices
Query
Quotation
Quotation: Network specifies services supported, prices
Reserve
Reserve: User requests service(s) for flow(s) (Flow Id-Service-Price triplets)
Commit
Quotation
Commit: Network admits the service request at a specific price or denies it (Flow Id-Service-Status-Price)
Periodic re-negotiation
Reserve
Commit
Close: tears down negotiation session
Close
Release: release the resources
Release

7. Centralized Architecture (RNAP-C)
NRN
NRN
NRN
HRN
HRN S1 R1
Access Domain - A
Access Domain - B
We consider two alternative architectures for implementing RNAP in the network, a centralized architecture (RNAP-C) and a distributed architecture (RNAP-D)
In RNAP-C, user negotiates through a HRN, each network domain has a NRN.
When a user wants to to apply for resources from the network, it first sends a request to the NRN of its access domain.
This request is then propagated to next-domain NRN, and so on.
In general, each NRN is in charge of admission control, price quotation and charging for its domain.
Transit Domain
Internal Router
NRN
Network Resource Negotiator
Edge Router
Host Resource Negotiator
Data
HRN
Host
Intra domain messages
RNAP Messages

8. Architecture-Centralized
(RNAP-C)
Query
NRN
NRN
NRN
HRN
HRN S1 R1
AD - B
AD - A TD
Network Resource Negotiator
Internal Router
NRN
Edge Router
Host Resource Negotiator
HRN
Host
RNAP Messages

9. Architecture-Centralized
(RNAP-C)
Quotation
NRN
NRN
NRN
HRN
HRN S1 R1
AD - B
AD - A TD
Network Resource Negotiator
Internal Router
NRN
Edge Router
Host Resource Negotiator
HRN
Host
RNAP Messages

10. Architecture-Centralized
(RNAP-C)
Reserve
NRN
NRN
NRN
HRN
HRN S1 R1
AD - B
AD - A TD
Network Resource Negotiator
Internal Router
NRN
Edge Router
Host Resource Negotiator
HRN
Host
RNAP Messages

11. Architecture-Centralized
(RNAP-C)
Commit
NRN
NRN
NRN
HRN
HRN S1 R1
AD - B
AD - A TD
Network Resource Negotiator
Internal Router
NRN
Edge Router
Host Resource Negotiator
HRN
Host
RNAP Messages

12. End-to-End Messaging
Sender HRN sends Query to access NRN; forwarded all the way to last-hop NRN
Last-hop NRN builds and sends Quotation message upstream; forwarded from NRN to NRN - quoted prices incremented at each NRN.
Sender HRN sends Reserve message to access NRN; forwarded downstream to to last-hop NRN
Last-hop NRN builds and sends Commit message upstream; forwarded from NRN to NRN - committed prices, accumulated charges incremented, or service request denied, at each NRN.

13. Architecture - Distributed
(RNAP-D)
HRN
HRN R1
AD - B
AD - A
In the distributed architecture, there is no centralized control. Effectively, there is a negotiating agent at each network node, which processes and forwards negotiation messages user request is sent from end to end, and the Quote is sent from last hop route to the first hop and accumulate the statistics. TD
Internal Router
Edge Router
Host
RNAP Messages

14. Distributed Architecture (RNAP-D)
HRN
HRN S1 R1
Access Domain - A
Access Domain - B
We consider two alternative architectures for implementing RNAP in the network, a centralized architecture (RNAP-C) and a distributed architecture (RNAP-D)
In RNAP-C, user negotiates through a HRN, each network domain has a NRN.
When a user wants to to apply for resources from the network, it first sends a request to the NRN of its access domain.
This request is then propagated to next-domain NRN, and so on.
In general, each NRN is in charge of admission control, price quotation and charging for its domain.
Transit Domain
Internal Router
HRN
Host Resource Negotiator
Edge Router
RNAP Messages
Host
Data

15. Architecture - Distributed
(RNAP-D)
HRN
HRN R1
AD - B
AD - A TD
Internal Router
Edge Router
Host
RNAP Messages

16. Scaling in Core Domains
Direct Aggregation
At boundary of access and core networks, map flow-level resource requests with same destination network to a single aggregate-level request.
Inside core network, process aggregate RNAP messages only, tunnel flow-level RNAP messages.
At edge of destination network, terminate aggregate-level RNAP message, re-activate flow-level RNAP messages.
Aggregate RNAP sessions fewer in number, larger resource requests, longer negotiation interval -> less overhead.
If we assume that a RNAP session is set up for each flow, the core network has to process thousands (?) of RNAP messages.
To reduce RNAP processing in the core of the network and increase scalability, we consider an aggregation mechanism
[Modify to make more similar to slide text]
In order to allows for the flow information to be used at dest,
they are tunneled to the destination network.
Due to the nature of dynamics negotiation, the network resource
may need to be adjusted frequently. In this case, block ...

17. Example: Aggregation NRN NRN NRN HRN HRN HRN HRN 50 50 100 100 50 50
150
150
HRN
HRN
100
100
HRN
AD - B
Charge calculation
-- At aggregation point, total charge for an aggregate
session is mapped into per flow charges R2
AD - A
HRN

18. Scaling in Core Domains (Cont’d)
Block Negotiation
Aggregate resources are added/given up in large blocks, to minimize negotiation overhead and reduce network dynamics
Bandwidth
time

19. Advance Reservation
Similar messaging sequence, reserve resources in advance for a specified future time
Price can be different from immediate reservation
Re-negotiation
“sell back” or “buy back”
Possible penalty or reward
Useful for resource negotiation between domains
One way in which RNAP can be used is to begin negotiation immediately prior to initiating a multimedia connection (for example, a telephone call or video-conference)
An alternative use is to reserve resources in adavance for a pre-scheduled multimedia session, particularly if is critical and/or resource-intensive.

20. Pricing and Charging How does the network arrive at a price?
How will RNAP collect and communicate pricing and charging information?
So far, we have considered how the protocol messaging works, and some practical considerations for implementation.
The other main focus of this work is how pricing and charging of services will work, and how the RNAP protocol can be used for pricing and charging.

21. Price and Charge Formulation
Router or NRN maintains state information
Flow Id, negotiated price, charge for last negotiation interval, accumulated charge
e2e price and charge collation
negotiation message passing through router/NRN uses state information to increment price/charge fields
Quotation message: carry estimated price for each quoted service
Commit message: carry accumulated charge for preceding negotiation interval, committed price for next interval
To begin with, let us assume that the pricing rules and strategies, and the accounting/monitoring mechanisms exist, to compute the price for a service locally at a node (or domain, in RNAP-C case), based on traffic going through that node (or domain).

22. Price and Charge Formulation in a RNAP-C Domain
Alternatives:
NRN does admission control and price computation
forms price based on topology, routing and configuration policies, network load
Ingress router does admission control and price computation
may determine internal router loads through egress-to-ingress Probe messages
Boundary and internal routers collect local prices/charges through intra-domain signaling protocol (YESSIR/RSVP).
In the previous slide, we assumed that the NRN of a domain can compute prices and charges for that domain. How will it do this?

23. Example: Price Formulation in RNAP-C
Table 2
Table 1
Resource Table
Domain Routing Table
ER1 R1 R1
ER2
Dest
NextHop
NextHop
(C, BW, Q, P)
(C, BW, Q, P)
1, 3, 30, 2
ER2 R1
ER2
ER1 R1
1, 2, 20, 1
Step1: determine a path (Table1)
NRN
C: service class
BW: average bandwidth (Mb)
Q: average queue length
P: price ($/Mb)
Step2: accumulate price along
the path (Table 2)
NRN needs two set of information: topology and routing information
resource information.for doing this, it needs to keep two table. R1
ER2
Step 3: send total price
( $3/Mb )
ER1 R2 R3 TD

24. Shared and Multicast Charging
Senders and receivers can share the total cost
Indicate willingness to pay by setting Charge Fraction field in Query/Reserve message
Request is rejected if sum of Charge Fraction fields is <1.
Given that the network is able to compute and communicate the charge for a service through RNAP, different scenarios are possible regarding who is to be charged ....

25. Pricing Strategy
Reservation_charge = holding_charge usage_charge congestion_charge
holding charge: charge for reservation
usage charge: charge for resource consumption
also dependent on service type, elasticity
congestion charge: charge for resource competition
resource overbooking
buffer overflow
Long-term high price
Resource re-provisioning (?)
We now very briefly consider on what basis a local price for a service at a node or in a domain may be set.
vendor potential revenue loss
allows for keeping connection during idle, encourage resource saving

26. Testbed Setup FreeBSD with routed, CBQ, RNAP Ra Rb 10 Mb
Embedded RNAP in RSVP Policy Data for prototype
RNAP
RSVP
Quotation
Path
Reserve
Resv
Commit
ResvErr

27. Evolution of Network Price and Total Resource Reservation
Total bandwidth: 4Mb/s t1: total reservation 2Mb/s t4: total reservation 2Mb/s Targeted bandwidth: t2: total reservation 3Mb/s t5: stabilized
70% (2.8 Mb) t3: stabilized
2800
Total bandwidth reservation
Price t1 t2 t3 t4 t5

28. Throughput of Sessions Sharing Bandwidth
Fairness sharing of bandwidth for applications with the same requirement and price sensitivity S1 S2 S3

29. Summary of Protocol Features
A protocol that enables service negotiation
multiple services, pricing, charging
Supports centralized and distributed network architectures.
Provides dynamic negotiation capability
Periodic re-negotiation capability
Flexible negotiation period
User can disable/enable negotiation at any time

30. Summary of Protocol Features (Cont’d)
Pricing and charging capability
Price and charge formulation, collation, communication to user
Charging mode: sender, receiver, or both
Flexibility of service selection
Multiple services: int-serv, diff-serv, best-effort
Different granularities of reservation: flow, aggregate level
Multi-party negotiation: senders, receivers, both
Stand alone, or embedded inside other protocols

31. Summary of Protocol Features (Cont’d)
Scalability
independent of hop count; aggregation in the core
Price predictability
Price is fixed for the service during a negotiation period
Reliability
Soft state for synchronous messages, liveness tracking
Retransmission of asynchronous messages
Server backup and information retrieval
To allow RNAP to be scalable,
Soft state nature makes the transmission reliable.
To protect against failure, back up server may be needed

32. Future Work Complete implementation
Large system performance evaluation