This document discusses several approaches for integrating IP and ATM networks to provide quality of service (QoS). It summarizes the Resource Reservation Protocol (RSVP), Scalable Reservation Protocol (SRP), and Simple Integrated Media Access (SIMA) approaches. It also outlines initial experiments on the DIANA platform to evaluate these approaches over ATM networks, including RSVP over ATM signaling, SRP control behavior, and the impact of dynamic SIMA marking. The conclusion is that RSVP over ATM peering has issues while SRP over ATM and SIMA/DiffServ seem more promising for further testing on DIANA in year 2 of the project.

1. DIANA: Scenarios for QoS based
integration of IP and ATM
EU IP/ATM cluster meeting, Lausanne
Switzerland Feb 11, 1999
John Loughney
Nokia Research Center

2. Motivation
ATM and IP evolution have some commonalties:
need for QoS ,
need for more capacity in the network,
need for efficient resource usage (multicasting, multiplexing,
dynamism etc..),
ATM is an established transport layer technology, but IP dominates in
application side & is a hot technology
in order to evaluate the options we should look into areas where ATM
and IP overlap, conflict and complete each other: QoS based
interworking between ATM and IP

3. Objectives of the project
To develop, integrate, validate and demonstrate resource reservation
and traffic control functionalities which seamlessly interoperate
between ATM and IP networks to achieve QoS.
At the boundary between the ATM and IP domains, DIANA will
translate between IP QoS and ATM QoS mechanisms. Alternative IP
QoS schemes are addressed (RSVP, SPR, SIMA/diff. serv.) and their
relationship to ATM QoS is studied.
The experimental prototyping in DIANA will allow the investigation,
testing and validation of different approaches for the convergence of
IP and ATM

4. Project Partners
Association Swisscom & Ascom Switzerland
University of Stuttgart Germany
Telenor Research & Development Norway
Finsiel Italy
Flextel Italy
Nokia Finland
Ascom Hasler AG Switzerland
Ecole Polytechnique Federale de Lausanne Switzerland
Swisscom Switzerland
Telscom AG Switzerland

5. QoS strategies for IP
Resource Reservation Protocol (RSVP)
per flow reservation
role: in access networks, for real time applications
Scalable Reservation Protocol (SRP)
adaptive, aggregated reservations
role: core and access, for adaptive applications
Differentiated Services/SIMA
aggregating, priority based
perfect match for core networks

6. Resource Reservation Protocol (RSVP)
designed for an Integrated Service Internet (Guaranteed & Controlled Load),
provides end-to-end QoS reservations for uni-directional flows,
operates on top of IP4 and IP6, out band "signaling"
supports multicasting,
receiver oriented, relies on periodical refreshments (soft state)
scalability problems with large numbers of flows
R1
Path
S1
Resv
R2
Multicast Packet Flow
Path message (multicast)
Resv message (unicast)

7. RSVP over ATM Framework
PRO
Aggregation of traffic
streams at the ingress to
ATM: + Scalability
Traffic descriptor & QoS
parameter based
resource reservation
end-to-end: Exact &
reliable guarantee
CON
Layered routing,
addressing & traffic
control
Different signaling
protocols

8. RSVP over ATM Implementation
CLIP address resolution: Proof of
concept
UNI signaling with dynamic re-
negotiation
However, focus is on traffic
control
Flow-to-VC aggregation
Dynamic, threshold based
VC bandwidth renegotiation
(cf. ACTS REFORM)

9. Interworking Scenarios
Overlay model (Scenario 1) Peer model (Scenario 2)
Integration unit Integration unit
Common transport layer Transport Layer A Transport Layer B
Technology X Technology Y Technology X Technology Y
• translation of user plane, find
• what is the common layer? common "application" layer: RTP
RTP, UDP (TCP), IP? ... Results into application specific
• Majority of applications use IP interworking
• Mapping of addressing, QoS •translation of control plane
parameters, control plane • translation of addressing, QoS
interworking parameters, ...

10. RSVP over ATM
Overlay model where common layer is IP and ATM as a link layer,
control plane mappings required, IETF RFCs

11. RSVP peering with ATM
Integration Unit
terminates both RSVP
and ATM signaling.
Two approaches for
setting up the ATM
section for originating
ATM host:
1) it is set up only after
RSVP section is done
2) sequentially
In some case loss of
data may occur, QoS
negotiation
problematic,
application level
interworking on user
plane.

12. RSVP & DiffServ Interworking Over ATM
Int-serv Diff-serv Int-serv
Sending Receiving
Stub network ER1 Transit network ER2 Stub network
host host
Data stream: best effort
RSVP Path
RSVP Resv
RSVP Resv
DACS
RSVP Resv
Data stream: QoS Diff. Serv over ATM
Note: diff-serv bits can be set at ER1:
Data stream Data stream with diff-serv bits Data stream with diff-serv bits

13. Dynamic Bandwidth Management

14. RSVP over ATM Issues
Management of QoS data, VCs and VC for control
messaging (RSVP-messaging)
ITU SG11 looking into possibility to embed RSVP
messaging into Generic Identifier IE in ATM signaling
change of QoS: ATM allows change of PCR and SCR, not
service category, establishment of new VC
release of VC
set up of a VC is a costly operation; implies flow to VC
aggregation among RSVP sessions
multicast support

15. Scalable Reservation Protocol (SRP)
Inband signaling for "Controlled Load" services
routers aggregate the flows on output ports
sources request resources; routers estimate reserved bandwidth to
decide on admission and propagate requests; receivers send feedback
to source
sources adjust traffic based on the feedback from receivers
failed reservation requests are degraded (to best effort)
Sender Data & reservations Receiver
Feedback
Router

16. SRP Reservation Mechanism
DESIGN GOALS
Scalability: No SRP
router manages per-flow
state
Absolute reservation
Soft state: Flow of data
packets marked as
reserved or request
maintain or upgrade the
reservation
No traffic descriptor and
QoS parameter based
(explicit) signaling
IP layer solution

17. SRP Implementation Framework
PRO
Realizes absolute
reservation with a
scaleable architecture
Can be embedded in IP
DiffServ architecture
Relatively simple traffic
control in routers
CON
No explicit QoS
parameters
Builds upon the LINUX
DiffServ architecture Feedback control
that DIANA (EPFL) has Sensitive to route
co-developed changes
Policing more complex

18. SRP over ATM
BW
= ATM reservation
based on estimates
Time
ATM signaling latency

19. SRP Performance Example
Observed performance
0,6 SRP builds up reservation
2 SRP sources gradually (starting from BE)
0,5 (long ON and OFF periods)
Transient phases
0,4
SRP provides stable
Reserved Rate
0,3
reservation
Further work
0,2
Completion of the LINUX
0,1 framework: IP over ATM,
DiffServ & SRP queuing
0,0
0e+0 5e+4 1e+5 2e+5 2e+5 discipline
Time Policing

20. SRP over ATM Issues
Due to the inband nature of the SRP, overlay model is the
most natural
SRP builds up reservations gradually, while ATM expects
the connection parameters to be known at connection set
up.
A request packet that is destined to an ATM VC without
enough capacity can cause:
a new connection set up
re-negotiation of an existing connection
These are costly operations, anticipation of future
connections needed

21. Simple Integrated Media Access
WHY DIFFERENTIATED SERVICES? HOW DOES SIMA IMPLEMENT
DIFFERENTIATED SERVICES?
Integrated Services provide absolute Customer profile expressed in
& reliable QoS terms of a nominal bit rate
BUT per-flow state has to be Real-time or non real-time
established and managed: Not service selection for a flow
scaleable Drop priority of a flow
DS achieve scalability by classifying dynamically depends on
and marking packets at the ingress current bit rate to NBR ratio
to a DS network 8 drop preference and 2 delay
Profile based access priority (rt/nrt) levels
DS can provide relative QoS using Defines access & core router
simple, scaleable mechanisms functionality

22. SIMA / DiffServ
CE = Customer Equipment
A = Access Node
C C C = Core Node
CE A SIMA network A CE
C
C
• Access node (A):
• knows NBR and measures actual bit rate of flow (MBR)
• determines and sets the drop preference of each packet (from 0 to 6)
• Core network node (C):
• discards packets based only on the drop preference of the packet and buffer occupancy levels
• places the accepted packet either in the real-time or nrt buffer
• does not need to know anything about the NBR or the traffic process of separate connections
• no capacity reservation (CAC or RSVP)

23. SIMA Drop Preference Levels
Actual Bit Drop
Preference If the network is dimensioned properly:
Rate
Reserved for non-SIMA services
DP =7
with resource reservation
NBR/4 DP=6 Excellent quality
High quality, packet losses only during
NBR/2 DP =5
exceptional traffic peaks
Good quality: Small packet loss even
NBR DP =4
during busy hours
Moderate quality: usually small packet
2 NBR DP =3
loss ratio except for busy hours
Satisfactory quality: from time to
4 NBR DP =2
time very high packet loss ratio
Suitable for best effort during
8 NBR DP =1
busy hours
Unusable during busy hours:
16 NBR DP =0
suitable for BE during idle hours

24. Packet scheduling and Buffering
DPa = f(Mrt, Mnrt) Mrt
rt
+
yes
DP ≥ DPa rt/nrt Mnrt
no
(discard) nrt
DP = preference of the incoming packet Mrt = occupancy level of real-time buffer
DPa = allowed drop preference level Mnrt = occupancy level of nrt buffer

25. SIMA Implementation Framework
SIMA in the DIANA IU
Access node functionality
Measure & classify data into
flows
Check against NBR
Calculate priority
Core node functionality
Drop & delay priority based
on DS bits and buffer
occupancy
Options
Dynamic NBR (RSVP &
DiffServ)
Exploiting ATM´s flexibility
as L2

26. SIMA Performance Example
Example exhibits weight (NBR)
0.6
proportional fairness
0.5
1 Node, 5 TCP like sources
Further research required to
Normalised Throughput
0.4
investigate
the impact of dynamic
0.3
priority assignment during
0.2
congestion epochs
the interaction with TCP´s
0.1
flow and congestion
0.0
control
0.0 0.1 0.2 0.3
the behavior in large scale
Nominal Bit Rate
networks

27. SIMA Over ATM Issues
SIMA is developed for IP, could be reworked for ATM (in
theory)
Uses ATM as a link between SIMA routers
Usual IP over ATM difficulties

28. Comparison of IP QoS strategies & ATM QoS
RSVP SRP DiffServ UNI4.0
Receiver requests reservation in Sender requests and maintains a Service Level Agreement, between Sender sets up a bi-directional VC
response to a PATH message, uni- reservation by marking packets user and the ISP.
directional
Default best-effort service Default best-effort service Default best-effort No connectivity if set-up fails
Heterogeneous QoS within a Multicast under study Multicast (still under study) Point-to-multipoint VCs with a
multicast session (Homogeneous QoS planned) homogeneous QoS
Dynamic QoS: RESV can alter the Dynamic QoS: Request is signalled No means for signalling defined, Static QoS, negotiated at set-up
reservation at any time implicitly and dynamically by static (Q.2963.x now specifies sender
marking packets controlled modification
procedures)
Multiple reservation filter styles to n.a. Behaviour Aggregate classifier, Point-to-multipoint
select different senders in a Multi Field classifier
multipoint-to-multipoint scenario
Soft state: Messages are resent Soft, aggregated state in routers n.a. Hard state: Connections have to be
periodically explicitly released
Guaranteed, controlled load and Service similar to controlled load Many services (e.g. relative CBR, rt/nrt-VBR, ABR, (GFR),
best-effort service guarantees and absolute) UBR

29. Summary
RSVP over ATM SRP SIMA
•Layered architecture •IP architecture •IP DiffServ
•Absolute bandwidth
•Traffic & QoS reservation without per- •Nominal bit rate
parameter based flow state •Relative priority
•Most complex traffic •Dynamic priority
control architecture •Control loop dependent on current bit
rate to NBR ratio

30. Trial Scenario
DISTRIBUTED INFRASTRUCTURE
More realistic traffic
scenario
RSVP over ATM
Signaling (re-negotiation)
becomes more expensive
SRP
Delay in control loop
Policing trial
SIMA
Interaction with TCP flow &
congestion control

31. Planned Performance Experiments
RSVP over ATM Application controlled
How does aggregation affect renegotiation
individual QoS? Exploits RSVP´s dynamic
Dynamic BW re-negotiation: re-negotiation capabilities
Trade-off between reservation RVBR service for traffic
efficiency and signaling load descriptor calculation
SRP Reference Applications
Dynamic behavior in transient VAT
phases ARMIDA VoD application
Policing (MPEG4): Adapts to
SIMA available network
Impact of dynamic marking resources
Interaction with TCP Synthetic sources

32. Design of the Integration Unit
HW based on Flextel´s Multi Purpose Switch/Router
open SW environment (Linux)
started with RSVP over ATM scenario

33. Design of the Integration Unit
HW based on Flextel´s Multi Purpose Switch/Router
open SW environment (Linux)
started with RSVP over ATM scenario

34. Conclusion
DIANA platform has the ability to verify a number of approaches
the project aims to provide answers to evolution considerations
test and evaluate the scenarios under consideration
year 1 started with RSVP over ATM scenario
RSVP-ATM peer model seems to be problematic: no real application
need, no immediate market need
year 2 starts:
proof of RSVP over ATM scenario
SRP over ATM promising new approach
SIMA/Diff. Serv. seems more relevant than peering RSVP with ATM