8/98 1

A Two-Tier Model forInternet Resource Management

Lixia Zhang

UCLA

IETF RSVP WG

August 26, 1998

8/98 2

Once upon a time... Once upon a time network was a simple network, just a collection of

nodes Once upon a time a simple routing protocol served the simple network

8/98 3

Today’s Internet looks differently

8/98 4

Today’s global routing

No longer just using a single routing protocol Hierarchical routing architecture

needed for scaling needed for administrative control

concatenation of AS-to-AS forwarding provides end-to-end data delivery

routes are pre-computed (or pre-configured) routes adapt to topology/policy changes

8/98 5

Network resource management interconnection of multiple administrative domains a priori bilateral agreement between neighboring

domains

8/98 6

A picture for

Scalable Resource Management Two-tier resource management

inter-administrative domains intra-administrative domains

concatenation of bilateral agreement leads to end-to-end QoS delivery paths

Inter-domain: pre-negotiated neighboring relation amount of resources adjusted according to

demand/policy/topology changes

8/98 7

Resource manager for each domain:Bandwidth Broker (BB)

A logical entity residing in each administrative domain Managing internal demands & resources according to the

policy database (who can do what where and when) setting up & maintaining bilateral agreement with neighbor

domains

today’s BB: network administrators & operators would like to automate over time

“A Two-bit differentiated services architecture for the Internet”Nichols, Jacobson, Zhang

draft-nichols--diff-arch-00.txt, November 1997

8/98 8

An overall picture

“Keep complexity at edges, leave the core simple” peripheral domains may manage internal traffic and

resources in any way they wish border-crossing packets carrying right DS value and

treated in diff-serv way

ingress border routers policing (egress border routers shaping)

BBBB

BB

BB BB

diffservtreatment

8/98 9

Three major components

BBBB

BB

BB

diffservtreatment

BB to BB communication intra-domain resource management end-to-end QOS support

if/when needed maps to diffsrev PHB’s when crossing borders

8/98 10

Intra-transit domain implementation

Choices of implementation provisioning manual configuration, or SNMP use of protocols

for example: MPLS RSVP

8/98 11

“A Framework for End-to-End QoS Combining RSVP/Intserv andDifferentiated Services” draft-ietf-diffserv-rsvp-00.txt

“Tunnel” RSVP messages between leaf domains

Why “tunnel through”: do not want intermediate routers to see/act on end-to-end RSVP messages One way of doing it

drawback: assuming both ends using RSVP internally

RSVP PATH

diff-servcapable

8/98 12

Summary: One proposal for

diff-serv resource management two-level hierarchy

inter-domain management

• currently human

• automate over time; BB as one proposal intra-domain management: multiple choices

• provisioning, manual-configuration, SNMP, MPLS, RSVP

packet classification cross-domain traffic: classified by bits in TOS field leaf domain: one’s own choice