Network Service Models

1
Network Service Models

• Based on
• Dr. Jon Crowcrofts
• www.cs.ucl.ac.uk/staff/jon/mmbook/book/node35.html
  
• CECS401- Multimedia Systems
• Prof. Dr. Xinhua Zhang
• University of Missouri-Columbia
• Presented by Othoniel Rodriguez-Jimenez
• Arturo Guillen

2
Network Service ModelsOutline

• Arturo Guillen
• Introduction
• Sharing and Caring
• Service Scheduling and Queues
• Evolution of the Internet Service Model
• Otho Rodriguez
• RSVP
• Service Classes and Assurance
• Detailed Analysis of the Integrated Services
• Host Functions
• Resource ReSerVation Protocol (RSVP)
• QoS Routing
• Futures
• Arturo Guillen
• IP and ATM
• Conclusions

3
Network Service Models Introduction

• Definition Service Model refers both to the
  interface and to the performance that the network
  gives us.
• In this talk we are going to take a look at
• - Components of user and network that must
  interact to provide a network service.
• - The way internet provides these components and
  how they can fit together to make the service
  model that a user requires.
• - Network service models for supporting
  multimedia.
• - Mechanisms to provide varying levels of
  assurance about performance in terms of delay,
  throughput, loss and standard protocols.

4
Network Service ModelsIntroduction - User and
Network Service Interface
5
Network Service Models Sharing and Caring I

• Situation of the Internet
• - At the beginning the Internet was intended to
  support multiple types of service.
• - Nowadays the Best effort service model is
  the most used in the Internet. In this type of
  model, each request to send is honored by the
  network as best as it can.
• - The most problematic characteristic of the
  Best effort service model is the lack of contract
  between the network and the user.
• - The way users access the Internet made this
  model the most useful service model so far.
  Essentially any computer may attempt to
  communicate with any other computer at any moment.

6
Network Service Models Sharing and Caring II

• Traditional telecommunication networks
• - The actual situation of the Internet is in
  direct contrast with the traditional
  telecommunication networks. For example, in
  telephony system, the network can be provisioned
  for the expected of calls at any time.
• - call blocking congestion or overload. Here
  the degradation of service is to the users who
  get none, rather than to users who have
  established access to the network.
• - leased line strong resource commitment
  between the network and the user.

7
Network Service Models Sharing and Caring III

• Internet vs Traditional telecomm. Networks

8
Network Service Models Sharing and Caring IV

• How do we specify a contract between the user
  and the network?
• - In networks we have different types of traffic
  from different applications. We can specify a
  contract with the network in terms of a set of
  performance parameters.
• Table of service contract
  models

9
Network Service ModelSharing and Caring V -
User Expectation and Service Models

• - The service model that a network provides has a
  profound effect on user expectations.
• - Its very important to consider users
  expectations, when considering QoS requirements.
• - Modern phone network vs mobile phone.
• - In todays Internet users have a lack of
  expectation of quality. Users accept low quality
  of audio and video communication.

10
Network Service ModelService Schedules and
Queues

• - Performance of a comm. path is made up of
  contributions from many places
• - technology used
• - throughput of each link.
• - error rate (due to noise).
• - delay for the path
• - propagation time.
• - Store/forward time. lt-- Here is were we can
  improve performance
• - To change Best effort service used in the
  Internet we need to
• - recognize the user traffic.
• - give different treatment in the queues to that
  traffic.
• - There are different proposed queuing systems
• - for example Fair Queuing round robin
  scheduler for each source-destination.
• - A given device can implement several different
  queuing mechanisms and sort packets into the
  appropriate queue based on some notion of packet
  classification.

11
Network Service Models Evolution of the Internet
Service Model

• - The best effort Internet has provided the
  worst service possible for multimedia
• - packets are forwarded by routers solely on the
  basis that there is any known route, irrespective
  of the traffic along the route.
• - Routers overloaded discard packets (typically
  at the tail of the queue).
• - Other types of digital networks have been
  built. The most notably (for wide public access)
  it is based on the Integrated Services Digital
  Network architecture
• - gives constant rate from source to sink,
  irrespective of whether you have something ready
  to send at any moment or not.
• - inconvenient Its narrow band service.
• - Most recently, we have seen an evolution
  towards a more flexible support for multimedia
  service Multiservice IP and broadband ISDN (the
  last one provided by ATM).
• - At this point, the notion of Traffic Classes
  (each of which have a range of parameters QoS
  parameters) have being designed.

12
Network Service Models Evolution of the
Internet Service Model - Classification and
Admission I

• CLASSIFICATION
• - A class is supported by some queuing discipline
  being applied especially to a particular flow of
  traffic.
• - This is set up using a signaling protocol by
• - network manager.
• - programmed into a router.
• - request by user.
• - In the Internet the signaling protocol has to
  provide
• - traffic flow category.
• - the QoS parameters.
• - a way for a router to recognize the packets
  belonging to the flow.

13
Network Service Models Evolution of the
Internet Service Model - Classification and
Admission II

• - The classification is simply based on a set of
  packet fields that remain constant for a flow
• - UDP and TCP port .
• - IP level transport identifier.
• - source and destination IP host addresses.
• - To dynamically create this classification, and
  map it into routers queues, the Internet has
  devised RSVP, the Resource Reservation Protocol.
• ADMISSION
• - When a service request is made it can deny
  access to a flow. Right now a normal IP router
  cannot do this.

14
Network Service Models Evolution of the
Internet Service Model - Integrated Service Model

• Key features of Integrated Servs. Arch.
• Reserved Resources
• router must know resources committed for on-going
  sessions
• Call Setup (call admission)
• requires participation of all routers in path
• router determines available local resources
  required for the flow

15
Network Service Models Evolution of the
Internet Service Model - Integrated Service Model

• - Right now there are 5 classes of service

16
Network Service Models Evolution of the
Internet Service Model - Differentiated Services

• - Differentiated Services have emerged in the
  Internet as a Class of Service to provide better
  than Best effort quality, in contrast to
  Integrated Services which uses more stringent and
  complex QoS approach.
• - Essentially, through pricing and understanding
  of user requirements, it appears that we can
  control a repertoire of quality of service
  parameters for each application.
• - A class of service is selected (by subscription
  or by marking using class of service bits in each
  packet header) and the routers along the path
  have programmed the parameters for each class.
• - There is great enthusiasm for this approach
  nowadays.

17
Network Service Models

• Outline
• RSVP, an Overview
• Service Classes and Assurance
• Detailed Analysis of Integrated Services
  Internet (ISI)
• Host Functions to Support ISI
• Resource ReSerVation Protocol (RSVP), in Detail
• QoS Routing
• Futures

18
Network Service Models Resource ReSerVation
Protocol

• An Overview, will discuss in detail later
• RSVP Zhang-94
• Establishes resources reservations in the network
  routers for different flow classes
• Dual Function Protocol
• Installs knowledge on classes of flows
• This is known as the FilterSpec
• Details QoS needed by those flows
• This is known as the FlowSpec

19
Network Service Models Resource ReSerVation
Protocol

• RSVP motivation
• fill the needs of multimedia applications
  distributed using Multicast Procotocol
• Important Concepts of Multicast Prot.
• On each multicast address (MC-IP/port), several
  senders (identified by their IP/port) source
  packets and an unspecified and anonymous number
  of receivers subscribe

20
Network Service Models Resource ReSerVation
Protocol

• Filter Specs. are re-usable in two ways
• Senders and Receivers can independently specify
  flow characteristics
• Receivers can select sub-band rates or sub-set of
  senders most convenient to them
• Similar to people choosing among BW/Color,
  mono/stereo, NTSC/HDTV
• Wild-card filterSpec refers to groups of sources
• A user in a teleconference only needs 1 voice
  chan. that may originate at any of the
  participants
• More when we discuss traffic Merging Styles later

21
Network Service Models Resource ReSerVation
Protocol

• Flow Specs
• Used for Admission Control and Traffic Re-shaping
  
• For each class of service specify quantitative
  parameters
• mean rate, and burstiness,
• modeled through the token-bucket parameters
• Tokens are credits that accumulate at rate r, and
  are expended 11 with each byte of packet traffic
  admitted

fixed token rate, r associated with mean rate
b (depth) associated to peak burst
x
L bytes
Yes
To traffic shaper
L lt x ?
No
Conforming
Non-conforming
22
Network Service ModelsService Classes and
Assurance

• Service Classes and Assurance
• Associated with all proposed service classes we
  find two functions
• Admission control (before admission)
• Can serv. be traffic supported with current
  resources
• Refusal control, or call reservation blocking
• Policing action (after admission)
• Does actual flow violates requirements or
  capacity?
• If yes, do we use queue tail packet dropping or
  Random Early Detection (RED) dropping , or others?

23
Network Service ModelsDetailed Analysis of
Integrated Services Internet

• IETF and Integrate Services Internet
• Services classes are defined with QoS commitments
  from routers traversed by flow.
• End applications request QoS on a per flow basis
• Requests specify level of resources, as well as
  Routers transmission scheduling behavior
• Packets in flow are to receive QoS committed
• Session identifies flow a generalized port spec

Session Destination MC-IP address and Port num,
Transport protocol, and List of Senders to
session with their IP and Port number
24
Network Service Models Detailed Analysis of
Integrated Services Internet

• Integrated Services Over Specific Lower Layers
  (ISSLL)
• Specify how router negotiates service guarantees
  from QoS-active lower layers
• Example ISSLL required to use ATM as LL
• Router receives applications flow traffic
  envelope, a.k.a. traffic arrival pattern, for
  example MTU parameter is data link layer media
  dependent.
• Otherwise, Router controls passive link layers
  directly

25
Network Service Models Detailed Analysis of
Integrated Services Internet

• Installed reservations on Routers along path will
  not change as long as
• no path changes, no router fails, and requested
  resources are not exceeded during flow lifetime.
• RSVP senders refresh timers allow restablishment
• Behaving data flows are protected from
  non-conforming flows which trigger policy
  enforcement activity in the Router
• IETF has considered many but formally specified
  two classes Guaranteed Svc., Controlled Load

26
Network Service Models Host Functions for
Integrated Service Internet

• Host Functions needed to Support ISI
• Controlled Load Service
• Guaranteed Service
• Policing and Conformance
• Integrated Services on Specific Link Technology

27
Network Service Models Host Functions for
Integrated Service Internet

• Controlled-Load Service
• Same Tspec (traffic) as for Guaranteed but
  without the peak-rate parameter.
• Service committed is equivalent to that of a
  lightly loaded network under Best-Effort, with
  little deterioration upon load increases
• Example For applics. that can tolerate some
  limited loss and delay
• like existing MBONE applic. with adaptive
  playout buffering,
• or some delay sensitive protocols like LAT,
  (assumes LAN-like environment latencies,
  i.e.Local Area Transport)

28
Network Service Models Host Functions for
Integrated Service Internet

• Guaranteed Service
• Assured bandwidth (b/w)
• Firm end-to-end delay
• No queuing loss
• Suitable for legacy applic. expecting delivery
  model similar to Telecom circuits
• Router allocates b/w R and buff.spc. B using
  fluid model of service

29
Network Service Models Host Functions for
Integrated Service Internet

• Guaranteed Service
• uses perfect Fluid Model
• token bucket at rate r, and depth d, link rate R
• delay due to burst b is bounded by b/R when R gt
  r
• router model dev. from ideal, error terms C D
• give delay bound of b/R C/R D where CD
  correspond to packet size and scheduling delays
• GS further bounds the flow peak rate p and the
  maximum packet size M for more precise bound on
  delay,
• these are summed to obtain the bound on the end
  to end path delay through all the routers.

30
Network Service Models Host Functions for
Integrated Service Internet

• Fluid Model equations (missing in Website)
• End to End Delay Bound ,?
• Eq.(1) for case p gt R gt r
• ? (b-M)(p-R) / (R(p-r)) (M Ctot)/R Dtot
• Eq.(2) for case R gt pgt r
• ? 0 (M
  Ctot)/R Dtot
• In (2) with Rgtp there is no peak rate shaping
  delay term because there is no need to use
  queuing to re-shape traffic
• Reference (McDysan, David QoS Traffic
  Management in IP ATM Networks, 2000,
  McGraw-Hill, ISBN 0-07-134959-6, available at EBW
  Engineering Library

31
Network Service Models Host Functions for
Integrated Service Internet

• Guaranteed Service
• FlowSpec made up of
• Tspec parameters (traffic)
• p peak rate of flow (bytes/sec)
• b bucket depth (bytes)
• r token bucket rate (bytes/sec)
• m minimum policed unit (bytes)
• M maximum datagram size (bytes)
• Rspec parameters (reservation)
• R bandwidth, i.e. service rate (bytes/ sec)
• S slack Term (ms), when end-to-end delay lt
  applic req.
• Besides Rspec R Tspec router needs terms Csum
  and Dsum since last reshape point, uses these to
  calculate queuing buffer size B

32
Network Service Models Host Functions for
Integrated Service Internet

• Guaranteed Service
• Traffic policed at network Access points
• Traffic reshaping required at points where
• possible to exceed the Tspec even though all
  senders associated to data flow conform to their
  individual Tspecs.
• at branch points in distribution tree
• at merge points in the distribution tree for
  sources sharing the same reservation
• this reshaping incurs in additional queuing delay

33
Network Service Models Host Functions for
Integrated Service Internet

• Policing and Conformance
• Routers must check flows for conformance to
  Tspecs
• Prevent non-conforming flows from negatively
  impacting QoS of conforming or best effort pkt
• Alternatives for handling non-conformance
• handle as Best Effort traffic
• assign lower effort than Best Effort
• degrade individual packets or all packets in flow
• Pricing policies might force lesser service to
  non-conforming traffic

34
Network Service Models Host Functions for
Integrated Service Internet

• Integrated Srvcs with Specific Link Layer
• Routers must implement ISSLL
• Queue servicing disciplines like Weighted Fair
  Queuing, hierarchical round-robin are a baseline
  requirement to support Guaranteed Service, while
  simple priority queuing may suffice for
  Controlled Load.
• Need a mechanism for controlling the link
  interconnect technology
• IP across ATM switches maps RSVP QoS requests
  into AMT Q.2931 requests.

35
Network Service Models Resource Reservation
Protocol

• Resource ReSerVation Protocol (RSVP)
• Enables senders, receivers and routers of
  communication sessions to communicate
• to setup the necessary router state to support
  the services required by a session.
• Novel signaling protocol in three ways
• multicast, receiver-driven request model
• uses soft-state
• low cost in implementation in end-sys. and
  routers
• RSVP operations apply to packets of a session

36
Network Service Models Resource Reservation
Protocol

• A signaling, not a routing protocol
• uses any pre-existing route set up by underlying
  routing protocol, i.e. Multicast distribution
  tree
• Path message originates from traffic sender
• installs reverse-routing information for routers
  in path
• inform receivers of characteristics of path to
  sender
• Reservation message originates from traffic recvr
• carry reservation requests to routers along
  distribution tree from receivers toward senders
  (upstream)
• receivers must periodically issue refresh
  reservation message to their reservation upstream
  router
• Router issues periodic refresh Reservation msg to
  upstream router, while reservation is active

37
Network Service Models Resource Reservation
Protocol
UPSTREAM
DOWNSTREAM
Resv ResvTear PathErr Path PathTear ResvConf Resv
Err
RC1
S1
RC2
R1
R2
R3
RC3
R4
38
Network Service Models Resource Reservation
Protocol
Router Interface
Soft State FlowSpec FilterSpec refresh timers
clean-up timers
refresh PathMsg (periodic local origin)
Refresh PathMsg (from upstream)
RsvMsg
merged RsvMsg
FlowSpec FilterSpec
PathTearMsg
PathTearMsg
Refresh Rsv/Path msgs originate locally while
Reservation/Path exists. Local Rsv state
refreshed by downstream refresh Reservation
msgs Local Path state is refreshed by upstream
refresh Path messages Refresh messgs locally
originated every refresh time-out
interval Received Reservation/Path messages reset
respective clean-up timer
39
Network Service Models Resource Reservation
Protocol

• Reservation styles and Merging
• FilterSpec and FlowSpec are obtained by
• merging resource requests from arriving Resv
  messages
• Reservation style
• Determines the way Reservation Specification
  merging is performed when reservation message
  arrives
• Three reservation styles
• Fixed Filter (FF)
• Wildcard Filter (WF)
• Shared Explicit(SE)

40
Network Service Models Resource Reservation
Protocol
RSVP Reservation Options
Reservation
Distinct
Shared
Choice of Sender
Explicit
Shared-Explicit (SE) Style
Fixed-Filter (FF) Style
Wildcard
Wildcard Filter (WF) Style
Not Defined
Merging can only occur with Resv of the same
Style and for the same Session (Source
Multimedia Comm. Protocols and Applic,
Kuo,Effelsberg,Garcia-Luna)
41
Network Service Models Resource Reservation
Protocol
forwards
S ? session sources B ? b/w units
Fixed Filter (FF) Reservation Example
42
Network Service Models Resource Reservation
Protocol
Wildcard Filter Reservation Example WF
reservation scope must apply to outgoing intrf to
agregate
43
Network Service Models Resource Reservation
Protocol
Shared Explicit Reservation Example
44
Network Service Models Resource Reservation
Protocol

• Path Messages information
• Phop(previous hop) addr. of last RSVP-capable
  node to forward this message, updated by routers
• Sender Template FilterSpec sender IP/port
• Sender Tspec sender source traffic
  characteristics
• Optional Adspec (OPWA) updated at routers along
  path, and informs receivers of level of resources
  required to obtain a given end-to-end QoS

45
Network Service Models Resource Reservation
Protocol

• Processing and Propag. of Path Mssgs.
• Update, or create Path state within router
• Path state stored includes Sender Tspec, the
  address Phop of previous upstream router, and
  optional Adspec
• Sender Tspec provides ceiling to guard against
  overspecified Reservation requests
• Reset cleanup-timer, used for soft-state time-out
• Router updates and forwards Path message
• periodically sends path message to refresh path
  state
• Reception of a PathTear messg removes path and
  reservation state , usually at session-end

46
Network Service Models Resource Reservation
Protocol

• Adspec
• Optional service descriptor in Path mssgs
• Advertises to recvrs characteristics end-end path
• Consists of
• Message header
• Default General Parameters part
• At least one of
• Guaranteed Service part
• Controlled-Load Service part

47
Network Service Models Resource Reservation
Protocol

• Adspec Default General Part contains
• Minimum Path Latency end-to-end link latency,
  needs adding queuing delay to obtain real end-end
  delay
• Path Bandwidth minimum link b/w along path
• Global Break bit flags RSVP not supported by
  some router
• Integrated Svcs Hop Count incremented by
  RSVP/IS router
• Path MTU Max Trans. Unit, is minimum of links
  MTU.

48
Network Service Models Resource Reservation
Protocol

• Adspec Guaranteed Service Part
• Ctot and Dtot - end to end composed values for C
  and D
• C is rate dependent queuing delay
• D is rate independent queuing delay
• Csum and Dsum - composed value for C and D since
  last re-shaping point, used/modified by flow
  reshaping processes
• Guaranteed Service Break bit - flags no support
  for G.Svc.
• Guaranteed Service General Parameters
  Headers/Values - will override corresponding
  Default parameters with respect to Guaranteed
  Service.

49
Network Service Models Resource Reservation
Protocol

• Adspec Controlled Load Part
• Controlled-Load Service Break bit - set by any
  RSVP/IP router that does not support Controlled
  -Load
• Controlled-Load Service Parameters Headers/Values
  - Override specific General Parameters as far as
  receiver wishing to make a Controlled-Load
  reservation is concerned.
• Omission of either Controlled Load Part or
  Guaranteed Service part means that such QoS is
  not available. Can be used to force receivers to
  choose the same service.

50
Network Service Models Resource Reservation
Protocol

• Reservations using One Pass with Advertising
  (OPWA)
• Sender must include Adspec on its Path message,
  otherwise it is called One Pass (OP)
• RSVP goal is to minimize the number of handshakes
  either for One Pass or OPWA

51
Network Service Models Resource Reservation
Protocol

• OPWA (cont..)
• Sample Case, with Controlled-Load omitted
• Receiver can extract from Path Message
• Sendr Tspec r, b, p, m,
• Sendr Adspec Min Path Latency, Ctot, Dtot, path
  MTU and B/W
• MaxQueuingDelayTolerated is calculated as
  QdelReq
• QdelReq (Application end-end delay) - (Min
  Path Latency)
• Then estimate Resv Rspec R parameter by checking
  equ. (2)
• if Qdelreq lt ( (M Ctot)/R Dtot ) , assuming
  Rp
• increase R up to min value that meets
  Qdelreq, use equ (2)
• else
• decrease R down to max value that meets
  Qdelreq, use equ(1)
• if obtained value of R exceeds Path B/W it must
  be reduced to that value

52
Network Service Models Resource Reservation
Protocol

• Sample Case, with Controlled-Load omitted
  (cont)
• Recvr can create Resv Rspec comprising of
• Calculated value of reservation rate R
• Slack Term set either to
• zero,
• or when R equal to its min value of r
• Slack r - (R for ? equal Qdelreq)
• Indication of reservation style FF,SE, WF
• Filterspec, similar to Sendr Template in Path
  messg.
• Flowspec, comprising Rspec and a Tspec where M
  equal PathMtu
• ResvConf object, with Recvr address, to be
  returned to receiver indicating high
  probability that end to end reservation is
  installed
• (Note receiver and sender above are from Flow
  point of view, their role is inverted during
  Reservation message transmission)

53
Network Service Models Resource Reservation
Protocol

• Sample Case, with Controlled-Load omitted
  (cont)
• The Resv messg containing Rspec is sent to
  upstream Router using the Phop previous hop
  address.
• The Flowspec within Rspec is passed to Router
  traffic control module
• If reservation is denied ResvErr message is sent
  downstream
• If reservation is accepted Filterspec and
  Flowspec are installed
• This reservation could be merged to additional
  reservations and sent to the next router upstream.

54
Network Service Models Resource Reservation
Protocol

• Slack Term
• Included within Rspec of Resv messg.
• Amount by which receiver end-to-end application
  delay is below the end-to-end delay bound
  assuming routers reserve b/w R
• Helps end-to-end reservation be successful by
  allowing routers to take advantage of the slack
  to reserve less bandwidth, differential must not
  be larger than slack.

55
Network Service Models Resource Reservation
Protocol

• Slack Term (cont..)
• Figure 2.7 R12.5Mb/s, S10. Reservation request
  denied

56
Network Service Models Resource Reservation
Protocol

• Slack Term (cont..)
• Figure 2.8 R13Mb/s, S1gt0, R22Mb/s, S2ltS1.
  Reservation accepted , slack used to accommodate
  the difference

57
Network Service Models Resource Reservation
Protocol

• QoS Routing
• Any other way to change performance of flow,
  besides changing Router schedule?
• Sln Select a different path, QoS routing
• Problems
• alternate path routing is very complex
• alternate paths used by other users
• Research topic

58
Network Service Models Resource Reservation
Protocol

• Futures
• Internet has evolved from
• Best Effort, FIFO, Dest. Routed, Unicast system
• To
• Multi-service, QoS Routed, multicast-capable
  system
• RSVP with OPWA
• allow application to determine end to end QoS in
  advance

59
Network Service Models Resource Reservation
Protocol

• Futures (cont..)
• In the future more research needs to be done in
• Research areas per Jon Crowcroft (circa 1998)
• Accounting and Billing integrated into the model
• Aggregation of non-specifically related
  reservations
• Authentication of users of RSVP for billing
  purposes
• Usage accounting model must incorporate mirror
  servers
• Scheme to permit settlements across service
  providers
• Experience in using a mutiservice networks is
  needed

60
Network Service ModelsIP and ATM

• - Two basic tasks of intermediate node in packet
  switched networks
• - forwards packets, maintaining as economically
  as possible and appropriate timing relationship
  between packets (to meet the service contract).
• - deliver packets along the appropriate route to
  destination.
• - The Internet TCP/IP has defined a simple
  service model
• - It does not offer any definition of the timing
  model (the routers have a single FIFO queue)
• - The path selection mechanism is very rich. It
  has a rapid response to changes in traffic
  patterns.

61
Network Service ModelsIP and ATM II

• - Recently, to add further services, the Internet
  standards have been enhanced to provide signaling
  protocol. The new family of service models are
  base on the theory in Parekhs work
• - His work shows how a Weighted Fair Queueing
  System can provide bounded delays, once the
  traffic is constrained by a leaky bucket and an
  admission test is carried out.
• - This is known as a flow specification.
  Subsequent packets are matched to the admitted
  flow.
• - In contrast to Parekhs work, two other hybrid
  approaches to build a fast Internet have been
  proposed
• 1.- Frame Relay or ATM switch fabric
• - It will be provided by telecommunication
  carriers. It is made up of traditional virtual
  circuit based on packet switching.
• 2.- Hybrid switch/router nodes
• - Is more integrated approach. It tries to
  capitalize on the benefits of virtual circuits
  and the flexibility advantages of dynamic IP
  routing.

62
Network Service ModelsIP and ATM - Mapping
Classes and QoS

• - The integrated service model has an initial
  deployment scenario of routers connected together
  by point to point links. In this situation only
  the routers need to know how to do the packet
  scheduling for service classes.
• - However, there are part of the Internet using
  other interconnection technologies between
  routers
• - routers interconnected via LAN
• - routers interconnected by so-called Non
  Broadcast Multiple Access (NBMA) like frame
  relay or ATM.
• - The integrated services of some of the IP level
  services onto services provided at the lower
  layer
• - in some cases the data link layer cannot
  guarantee the services (case of Ethernet) and
  need kind of a bandwidth manager.
• - In the case of NBMA networks (particularly
  ATM) a much richer variety is available at the
  lower layer.

63
Network Service Models IP and ATM - Topology
Control

• - One of the main reasons for the success of IP
  is the flexibility for addressing and routing.
  But it also has some problems
• - stability of routing is getting worse.
• - exhaustion of global IPv4 address space.
• - These problems are being solved by the
  introduction of IPv6, but it seems that it also
  introduces new problems
• - the performance for route lookup.
• - The work of Degermark and others, shows that it
  is feasible to construct a new data structure
  that
• - permits fast routing lookup.
• - reduces the size of the routing tables.
• - This permits us to consider using IP addresses
  for deciding what to do with a packet as well as
  where to send it. This gives high degrees of
  flexibility. One can change
• - QoS in the middle of the flow.
• - the route of the packet.

64
Network Service Models IP and ATM - QoS Control

• - QoS control requires
• - some number of alternate queues.
• - some form of admission and policing.
• - Assuming that admission and policing can be
  done on small number of flows when ingress into
  the network, we can aggregate flows as they
  approach the core of the network.
• - The only problem left is the performance of
  queue insertion.

65
Network Service ModelsIP and ATM - Queue
Insertion/Lookup Performance

• - Queue insertion for WFQ is typically a sort
  algorithm basically it is swapping packets in
  the queue.
• - Hui Zhangs work shows that for CBR (guarantee
  Service in Integrated Service Internet), a
  different algorithm called Worst Case Fair Weight
  Fair Queueing achieves better delay jitter bounds
  and can have O(1) insertion time.

66
Network Service ModelsIP and ATM - Conclusions

• - It appears that a purist IP architecture for
  all switching nodes in the Internet is both
  feasible, and for management reasons (and
  therefore cost), attractive.
• - The work done on QoS and scalable ATM switch
  design, seems to be unnecessary for general
  Internet, but useful at modest speed links, where
  the reduced latency for voice/video may be cut
  through cell size.

67
Network Service ModelsConclusions

• - We have looked at network service models and
  discovered that it is a complex area. There are a
  lot of debate on how to provide what is perceived
  as the need for guarantees for multimedia
  networked applications.
• - A network offers services which provide
  probabilities of meeting some performance
  requirements. The performance of a service may be
  applied to
• - individual offerings (i.e. to pair of groups
  of users).
• - to a set of typical users.
• - The contract concerning performance may be
  made
• - sometime in advance through subscription.
• - immediately before (or remade during) each
  session.
• - This area is extremely active in terms of
  research, standard development and technology
  deployment.
• - The very important aspect of this area is the
  effect of pricing.
• - Also is important to realize that the best
  technical solutions are often swept away by
  marketing.