RNAP: A Resource Negotiation and Pricing Protocol

Xin Wang, Henning Schulzrinne

Columbia University

xwang@ctr.columbia.edu, schulzrinne@cs.columbia.edu

(This work was supported by Hughes Research Lab)

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

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

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

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

Typical Message Sequence

Query

Quotation

Reserve

Commit

Quotation

Reserve

Commit

Close

Release

Query: User enquires about available services, pricesQuotation: Network specifies services supported, pricesReserve: User requests service(s) for flow(s) (Flow Id-Service-Price triplets)

Commit: Network admits the service request at a specific price or denies it (Flow Id-Service-Status-Price)

Per

iodi

c re

-neg

otia

tion

Close: tears down negotiation session

Release: release the resources

Centralized Architecture (RNAP-C)

NRN

S1

R1

NRN NRNHRN

HRN

Access Domain - BAccess Domain - A

Transit Domain

Internal Router

Edge Router

Host RNAP Messages

NRN

HRN

Network Resource Negotiator

Host Resource Negotiator

Intra domain messages

Data

Architecture-Centralized

NRN

S1 R1

Internal Router

Edge Router

Host RNAP Messages

NRN

NRN

NRN

HRN

HRN HRN

Network Resource Negotiator

Host Resource Negotiator

AD - B

AD - A

TD

(RNAP-C)Query

Architecture-Centralized

NRN

S1 R1

Internal Router

Edge Router

Host RNAP Messages

NRN

NRN

NRN

HRN

HRN HRN

Network Resource Negotiator

Host Resource Negotiator

AD - B

AD - A

TD

(RNAP-C)Quotation

Architecture-Centralized

NRN

S1 R1

Internal Router

Edge Router

Host RNAP Messages

NRN

NRN

NRN

HRN

HRN HRN

Network Resource Negotiator

Host Resource Negotiator

AD - B

AD - A

TD

(RNAP-C)Reserve

Architecture-Centralized

NRN

S1 R1

Internal Router

Edge Router

Host RNAP Messages

NRN

NRN

NRN

HRN

HRN HRN

Network Resource Negotiator

Host Resource Negotiator

AD - B

AD - A

TD

(RNAP-C)Commit

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.

Architecture - Distributed

R1

Internal Router

Edge Router

Host RNAP Messages

HRN HRN

AD - B

AD - A

TD

(RNAP-D)

S1

R1

HRNHRN

Access Domain - B

Access Domain - A

Transit Domain

Internal Router

Edge Router

Host

RNAP Messages

HRN Host Resource Negotiator

Data

Distributed Architecture (RNAP-D)

Architecture - Distributed

R1

Internal Router

Edge Router

Host RNAP Messages

HRN HRN

AD - B

AD - A

TD

(RNAP-D)

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.

NRN

HRNR2

NRN NRN

HRN

HRN HRN

AD - B

AD - A

50

100

50

100

150

50

100

15050

100

Example: Aggregation

• Block Negotiation– Aggregate resources are added/given up in large

blocks, to minimize negotiation overhead and reduce network dynamics

Scaling in Core Domains (Cont’d)

time

Ban

dwid

th

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

Pricing and Charging

• How does the network arrive at a price?• How will RNAP collect and communicate pricing

and charging information?

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

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).

Example: Price Formulation in RNAP-C

NRN

TD

Dest NextHop ER1 R1

NextHop

ER2 R1 ER2

R1 ER2

R1

1, 3, 30, 2

Domain Routing Table Resource Table

ER1 ER2R1

R2 R3

ER11, 2, 20, 1

(C, BW, Q, P)(C, BW, Q, P)

Step1: determine a path (Table1)

Step2: accumulate price along the path (Table 2)

Table 1 Table 2

Step 3: send total price ( $3/Mb )

C: service classBW: average bandwidth (Mb)Q: average queue length P: price ($/Mb)

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.

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 (?)

Testbed Setup

S1

S2

S3

R1

R2

R3

FreeBSD with routed, CBQ, RNAP

10 Mb

Embedded RNAP in RSVP Policy Data for prototype

Ra Rb

Quotation Path

Reserve Resv

Commit ResvErr

RNAP RSVP

Total bandwidth reservation

Price

t1 t2 t4 t5t3

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

Evolution of Network Price and Total Resource Reservation

Fairness sharing of bandwidth for applications with the same requirement and price sensitivity

S1

S2

S3

Throughput of Sessions Sharing Bandwidth

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

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

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

Future Work

• Complete implementation• Large system performance evaluation