1. 8/98 1 A Two-Tier Model for Internet Resource Management Lixia Zhang UCLA IETF RSVP WG August 26, 1998

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

3. 8/98 3 Today’s Internet looks differently

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

5. 8/98 5 Network resource management  interconnection of multiple administrative domains  a priori bilateral agreement between neighboring domains

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

7. 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. 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) BB diffserv treatment

9. 8/98 9 Three major components BB diffserv treatment  BB to BB communication  intra-domain resource management  end-to-end QOS support  if/when needed  maps to diffsrev PHB’s when crossing borders

10. 8/98 10 Intra-transit domain implementation Choices of implementation  provisioning  manual configuration, or SNMP  use of protocols for example:  MPLS  RSVP

11. 8/98 11 “A Framework for End-to-End QoS Combining RSVP/Intserv and Differentiated Services” d raft-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-serv capable

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