DIANA: Scenarios for QoS based DIANA: Scenarios for QoS based integration of IP and ATMintegration of IP and ATM

EU IP/ATM cluster meeting, Lausanne Switzerland Feb 11, 1999

John Loughney

Nokia Research Center

MotivationMotivation

ATM and IP evolution have some commonalties: ATM and IP evolution have some commonalties:

need for QoS ,need for QoS ,

need for more capacity in the network,need for more capacity in the network,

need for efficient resource usage (multicasting, multiplexing, need for efficient resource usage (multicasting, multiplexing, dynamism etc..),dynamism etc..),

ATM is an established transport layer technology, but IP dominatATM is an established transport layer technology, but IP dominates in es in application side & is a hot technologyapplication side & is a hot technology

in order to evaluate the options we should look into areas wherein order to evaluate the options we should look into areas where ATM ATM and IP overlap, conflict and complete each other: and IP overlap, conflict and complete each other: QoS based QoS based interworking between ATM and IPinterworking between ATM and IP

Objectives of the projectObjectives of the projectTo develop, integrate, validate and demonstrate resource reservaTo develop, integrate, validate and demonstrate resource reservation tion and traffic control functionalities which seamlessly interoperatand traffic control functionalities which seamlessly interoperate e between ATM and IP networks to achieve QoS. between ATM and IP networks to achieve QoS.

At the boundary between the ATM and IP domains, DIANA will At the boundary between the ATM and IP domains, DIANA will translate between IP QoS and ATM QoS mechanisms. Alternative IP translate between IP QoS and ATM QoS mechanisms. Alternative IP QoS schemes are addressed (RSVP, SPR, SIMA/diff. serv.) and theiQoS schemes are addressed (RSVP, SPR, SIMA/diff. serv.) and their r relationship to ATM QoS is studied. relationship to ATM QoS is studied.

The experimental prototyping in DIANA will allow the investigatiThe experimental prototyping in DIANA will allow the investigation, on, testing and validation of different approaches for the convergentesting and validation of different approaches for the convergence of ce of IP and ATMIP and ATM

Project PartnersProject Partners

Association Swisscom & Ascom Association Swisscom & Ascom SwitzerlandSwitzerlandUniversity of Stuttgart University of Stuttgart GermanyGermanyTelenor Research & DevelopmentTelenor Research & Development NorwayNorwayFinsiel Finsiel ItalyItalyFlextelFlextel ItalyItalyNokia Nokia FinlandFinlandAscom Hasler AGAscom Hasler AG SwitzerlandSwitzerlandEcole Polytechnique Federale de LausanneEcole Polytechnique Federale de Lausanne SwitzerlandSwitzerlandSwisscomSwisscom SwitzerlandSwitzerlandTelscom AGTelscom AG SwitzerlandSwitzerland

QoS strategies for IPQoS strategies for IP

Resource Reservation Protocol (RSVP)Resource Reservation Protocol (RSVP)per flow reservation per flow reservation

role: in access networks, for real time applicationsrole: in access networks, for real time applications

Scalable Reservation Protocol (SRP)Scalable Reservation Protocol (SRP)adaptive, aggregated reservationsadaptive, aggregated reservations

role: core and access, for adaptive applicationsrole: core and access, for adaptive applications

Differentiated Services/SIMADifferentiated Services/SIMAaggregating, priority basedaggregating, priority based

perfect match for core networksperfect match for core networks

Resource Reservation Protocol (RSVP)Resource Reservation Protocol (RSVP)designed for an Integrated Service Internet designed for an Integrated Service Internet (Guaranteed & Controlled Load)(Guaranteed & Controlled Load),,

provides endprovides end--toto--end QoS reservations for uniend QoS reservations for uni--directional flows,directional flows,

operates on top of IP4 and IP6, out band "signaling"operates on top of IP4 and IP6, out band "signaling"

supports multicasting, supports multicasting,

receiver oriented, relies on periodical refreshments (soft statereceiver oriented, relies on periodical refreshments (soft state))

scalability problems with large numbers of flowsscalability problems with large numbers of flows

S1

R1

R2

Path

Resv

Multicast Packet FlowPath message (multicast)Resv message (unicast)

PROPROAggregation of traffic Aggregation of traffic streams at the ingress to streams at the ingress to ATM: + ScalabilityATM: + Scalability

Traffic descriptor & QoS Traffic descriptor & QoS parameter based parameter based resource reservation resource reservation endend--toto--end: Exact & end: Exact & reliable guaranteereliable guarantee

RSVP over ATM FrameworkRSVP over ATM Framework

CONCONLayered routing, Layered routing, addressing & traffic addressing & traffic controlcontrol

Different signaling Different signaling protocolsprotocols

RSVP over ATM ImplementationRSVP over ATM Implementation

CLIP address resolution: Proof of CLIP address resolution: Proof of conceptconcept

UNI signaling with dynamic reUNI signaling with dynamic re--negotiationnegotiation

However, focus is on traffic However, focus is on traffic controlcontrol

FlowFlow--toto--VC aggregationVC aggregation

Dynamic, threshold based Dynamic, threshold based VC bandwidth renegotiation VC bandwidth renegotiation (cf. ACTS REFORM) (cf. ACTS REFORM)

Interworking ScenariosInterworking Scenarios

Overlay model (Scenario 1)Overlay model (Scenario 1) Peer model (Scenario 2)Peer model (Scenario 2)

Common transport layer

Integration unit

Technology X Technology Y

• what is the common layer? RTP, UDP (TCP), IP?

• Majority of applications use IP

• Mapping of addressing, QoS parameters, control plane interworking

Technology X Technology Y

Transport Layer A

• translation of user plane, find common "application" layer: RTP ... Results into application specificinterworking

•translation of control plane

• translation of addressing, QoS parameters, ...

Integration unit Transport Layer B

RSVP over ATMRSVP over ATM

Overlay model where common layer is IP and ATM as a link layer, Overlay model where common layer is IP and ATM as a link layer, control plane mappings required, IETF RFCscontrol plane mappings required, IETF RFCs

RSVP peering with ATMRSVP peering with ATMIntegration 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) sequentiallyIn some case loss of data may occur, QoS negotiation problematic,application level interworking on user plane.

RSVP & DiffServ Interworking Over ATMRSVP & DiffServ Interworking Over ATM

Diff. Serv over ATM

Sending host

Receiving hostStub network Stub networkTransit networkER1 ER2

Int-serv Int-servDiff-serv

Data stream: best effortRSVP Path

RSVP ResvRSVP Resv

DACSRSVP Resv

Data stream: QoS

Note: diff-serv bits can be set at ER1:

Data stream Data stream with diff-serv bits Data stream with diff-serv bits

Dynamic Bandwidth ManagementDynamic Bandwidth Management

RSVP over ATM IssuesRSVP over ATM Issues

Management of QoS data, VCs and VC for control Management of QoS data, VCs and VC for control messaging (RSVPmessaging (RSVP--messaging)messaging)

ITU SG11 looking into possibility to embed RSVP ITU SG11 looking into possibility to embed RSVP messaging into Generic Identifier IE in ATM signaling messaging into Generic Identifier IE in ATM signaling

change of QoS: ATM allows change of PCR and SCR, not change of QoS: ATM allows change of PCR and SCR, not service category, establishment of new VCservice category, establishment of new VC

release of VCrelease of VC

set up of a VC is a costly operation; implies flow to VC set up of a VC is a costly operation; implies flow to VC aggregation among RSVP sessionsaggregation among RSVP sessions

multicast supportmulticast support

Scalable Reservation Protocol (SRP)Scalable Reservation Protocol (SRP)Inband signaling for "Controlled Load" servicesInband signaling for "Controlled Load" services

routers aggregate the flows on output portsrouters aggregate the flows on output ports

sources request resources; routers estimate reserved bandwidth tsources request resources; routers estimate reserved bandwidth to o decide on admission and propagate requests; receivers send feedbdecide on admission and propagate requests; receivers send feedback ack to sourceto source

sources adjust traffic based on the feedback from receivers sources adjust traffic based on the feedback from receivers

failed reservation requests are degraded (to best effort)failed reservation requests are degraded (to best effort)

Feedback

Sender Data & reservations Receiver

Router

SRP Reservation MechanismSRP Reservation MechanismDESIGN GOALSDESIGN GOALS

Scalability: No SRP Scalability: No SRP router manages perrouter manages per--flow flow statestate

Absolute reservationAbsolute reservation

Soft state: Flow of data Soft state: Flow of data packets marked as packets marked as reserved or request reserved or request maintain or upgrade the maintain or upgrade the reservationreservation

No traffic descriptor and No traffic descriptor and QoS parameter based QoS parameter based (explicit) signaling(explicit) signaling

IP layer solutionIP layer solution

SRP Implementation FrameworkSRP Implementation FrameworkPROPRO

Realizes absolute Realizes absolute reservation with a reservation with a scaleable architecturescaleable architecture

Can be embedded in IP Can be embedded in IP DiffServ architectureDiffServ architecture

Relatively simple traffic Relatively simple traffic control in routerscontrol in routers

Builds upon the LINUX Builds upon the LINUX DiffServ architecture DiffServ architecture that DIANA (EPFL) has that DIANA (EPFL) has coco--developeddeveloped

CONCON

No explicit QoS No explicit QoS parametersparameters

Feedback controlFeedback control

Sensitive to route Sensitive to route changeschanges

Policing more complexPolicing more complex

SRP over ATMSRP over ATM

Time

BW

ATM signaling latency

= ATM reservationbased on estimates

SRP Performance ExampleSRP Performance ExampleObserved performanceObserved performance

SRP builds up reservation SRP builds up reservation gradually (starting from BE)gradually (starting from BE)

Transient phasesTransient phases

SRP provides stable SRP provides stable reservationreservation

Further workFurther work

Completion of the LINUX Completion of the LINUX framework: IP over ATM, framework: IP over ATM, DiffServ & SRP queuing DiffServ & SRP queuing disciplinediscipline

PolicingPolicingTime

0e+0 5e+4 1e+5 2e+5 2e+5

Res

erve

d R

ate

0,0

0,1

0,2

0,3

0,4

0,5

0,6

2 SRP sources(long ON and OFF periods)

SRP over ATM IssuesSRP over ATM IssuesDue to the inband nature of the SRP, overlay model is the Due to the inband nature of the SRP, overlay model is the most naturalmost natural

SRP builds up reservations gradually, while ATM expects SRP builds up reservations gradually, while ATM expects the connection parameters to be known at connection set the connection parameters to be known at connection set up. up.

A request packet that is destined to an ATM VC without A request packet that is destined to an ATM VC without enough capacity can cause:enough capacity can cause:

a new connection set up a new connection set up

rere--negotiation of an existing connectionnegotiation of an existing connection

These are costly operations, anticipation of future These are costly operations, anticipation of future connections neededconnections needed

SSimple imple IIntegrated ntegrated MMedia edia AAccessccessWHY DIFFERENTIATED SERVICES?WHY DIFFERENTIATED SERVICES?

Integrated Services provide absolute Integrated Services provide absolute & reliable QoS& reliable QoS

BUT perBUT per--flow state has to be flow state has to be established and managed: Not established and managed: Not scaleablescaleable

DS achieve scalability by classifying DS achieve scalability by classifying and marking packets at the ingress and marking packets at the ingress to a DS networkto a DS network

Profile based accessProfile based access

DS can provide relative QoS using DS can provide relative QoS using simple, scaleable mechanisms simple, scaleable mechanisms

HOW DOES SIMA IMPLEMENTHOW DOES SIMA IMPLEMENT

DIFFERENTIATED SERVICES?DIFFERENTIATED SERVICES?

Customer profile expressed in Customer profile expressed in terms of a nominal bit rateterms of a nominal bit rate

RealReal--time or non realtime or non real--time time service selection for a flowservice selection for a flow

Drop priority of a flow Drop priority of a flow dynamically depends on dynamically depends on current bit rate to NBR ratiocurrent bit rate to NBR ratio

8 drop preference and 2 delay 8 drop preference and 2 delay priority (rt/nrt) levelspriority (rt/nrt) levels

Defines access & core router Defines access & core router functionalityfunctionality

SIMA / DiffServSIMA / DiffServ

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

CE = Customer EquipmentA = Access NodeC = Core Node

CE A

C

C

C

ASIMA network CE

C

SIMA Drop Preference LevelsSIMA Drop Preference Levels

Moderate quality: usually small packet loss ratio except for busy hours

Good quality: Small packet loss even during busy hours

High quality, packet losses only during exceptional traffic peaks

Excellent quality

Reserved for non-SIMA services with resource reservation

Satisfactory quality: from time to time very high packet loss ratio

Suitable for best effort during busy hours

Unusable during busy hours: suitable for BE during idle hours

DP =7

Drop Preference

DP=6

DP =5

DP =4

DP =3

DP =2

DP =1

DP =0

NBR/4

NBR/2

NBR

2 NBR

4 NBR

8 NBR

16 NBR

Actual Bit Rate

If the network is dimensioned properly:

Packet scheduling and BufferingPacket scheduling and Buffering

DP = preference of the incoming packetDPa = allowed drop preference level

Mrt = occupancy level of real-time bufferMnrt = occupancy level of nrt buffer

DPa = f(Mrt, Mnrt)

DP ≥ DPa rt/nrt

+

nrt

rtMrt

Mnrt

no (discard)

yes

SIMA Implementation FrameworkSIMA Implementation FrameworkSIMA in the DIANA IUSIMA in the DIANA IUAccess node functionalityAccess node functionality

Measure & classify data into Measure & classify data into flowsflows

Check against NBRCheck against NBR

Calculate priorityCalculate priority

Core node functionalityCore node functionality

Drop & delay priority based Drop & delay priority based on DS bits and buffer on DS bits and buffer occupancyoccupancy

OptionsOptions

Dynamic NBR (RSVP & Dynamic NBR (RSVP & DiffServ)DiffServ)

Exploiting ATMExploiting ATM´́s flexibility s flexibility as L2as L2

SIMA Performance ExampleSIMA Performance Example

Example exhibits weight (NBR) Example exhibits weight (NBR) proportional fairnessproportional fairness

Further research required to Further research required to investigateinvestigate

the impact of dynamic the impact of dynamic priority assignment during priority assignment during congestion epochscongestion epochs

the interaction with TCPthe interaction with TCP´́s s flow and congestion flow and congestion controlcontrol

the behavior in large scale the behavior in large scale networksnetworks

Nominal Bit Rate

0.0 0.1 0.2 0.3

Nor

mal

ised

Thr

ough

put

0.0

0.1

0.2

0.3

0.4

0.5

0.6

1 Node, 5 TCP like sources

SIMA is developed for IP, could be reworked for ATM (in SIMA is developed for IP, could be reworked for ATM (in theory)theory)

Uses ATM as a link between SIMA routersUses ATM as a link between SIMA routers

Usual IP over ATM difficultiesUsual IP over ATM difficulties

SIMA Over ATM IssuesSIMA Over ATM Issues

Comparison of IP QoS strategies & ATM QoSComparison of IP QoS strategies & ATM QoS

RSVP SRP DiffServ UNI4.0

Receiver requests reservation inresponse to a PATH message, uni-

directional

Sender requests and maintains areservation by marking packets

Service Level Agreement, betweenuser and the ISP.

Sender sets up a bi-directional VC

Default best-effort service Default best-effort service Default best-effort No connectivity if set-up fails

Heterogeneous QoS within amulticast session

Multicast under study(Homogeneous QoS planned)

Multicast (still under study) Point-to-multipoint VCs with ahomogeneous QoS

Dynamic QoS: RESV can alter thereservation at any time

Dynamic QoS: Request is signalledimplicitly and dynamically by

marking packets

No means for signalling defined,static

Static QoS, negotiated at set-up(Q.2963.x now specifies sender

controlled modificationprocedures)

Multiple reservation filter styles toselect different senders in a

multipoint-to-multipoint scenario

n.a. Behaviour Aggregate classifier,Multi Field classifier

Point-to-multipoint

Soft state: Messages are resentperiodically

Soft, aggregated state in routers n.a. Hard state: Connections have to beexplicitly released

Guaranteed, controlled load andbest-effort service

Service similar to controlled load Many services (e.g. relativeguarantees and absolute)

CBR, rt/nrt-VBR, ABR, (GFR),UBR

SummarySummary

•Nominal bit rate•Relative priority

•Dynamic priority dependent on current bit

rate to NBR ratio

RSVP over ATM SRP SIMA

•Layered architecture •IP architecture •IP DiffServ

•Traffic & QoS parameter based

•Absolute bandwidth reservation without per-

flow state

•Most complex traffic control architecture •Control loop

Trial ScenarioTrial Scenario

More realistic traffic More realistic traffic scenarioscenario

RSVP over ATMRSVP over ATMSignaling (reSignaling (re--negotiation) negotiation) becomes more expensivebecomes more expensive

SRPSRPDelay in control loopDelay in control loopPolicing trialPolicing trial

SIMASIMAInteraction with TCP flow & Interaction with TCP flow & congestion controlcongestion control

DISTRIBUTED INFRASTRUCTUREDISTRIBUTED INFRASTRUCTURE

Planned Performance ExperimentsPlanned Performance ExperimentsRSVP over ATMRSVP over ATM

How does aggregation affect How does aggregation affect individual QoS?individual QoS?

Dynamic BW reDynamic BW re--negotiation: negotiation: TradeTrade--off between reservation off between reservation efficiency and signaling loadefficiency and signaling load

SRPSRP

Dynamic behavior in transient Dynamic behavior in transient phasesphases

PolicingPolicing

SIMASIMA

Impact of dynamic markingImpact of dynamic marking

Interaction with TCPInteraction with TCP

Application controlled Application controlled renegotiationrenegotiation

Exploits RSVPExploits RSVP´́s dynamic s dynamic rere--negotiation capabilitiesnegotiation capabilities

RVBR service for traffic RVBR service for traffic descriptor calculationdescriptor calculation

Reference ApplicationsReference Applications

VATVAT

ARMIDA VoD application ARMIDA VoD application (MPEG4): Adapts to (MPEG4): Adapts to available network available network resourcesresources

Synthetic sourcesSynthetic sources

Design of the Integration UnitDesign of the Integration UnitHW based on FlextelHW based on Flextel´́s Multi Purpose Switch/Routers Multi Purpose Switch/Router

open SW environment (Linux)open SW environment (Linux)

started with RSVP over ATM scenariostarted with RSVP over ATM scenario

Design of the Integration UnitDesign of the Integration Unit

HW based on FlextelHW based on Flextel´́s Multi Purpose Switch/Routers Multi Purpose Switch/Routeropen SW environment (Linux)open SW environment (Linux)

started with RSVP over ATM scenariostarted with RSVP over ATM scenario

ConclusionConclusion

DIANA platform has the ability to verify a number of approachesDIANA platform has the ability to verify a number of approaches

the project aims to provide answers to evolution considerationsthe project aims to provide answers to evolution considerations

test and evaluate the scenarios under considerationtest and evaluate the scenarios under consideration

year 1 started with RSVP over ATM scenarioyear 1 started with RSVP over ATM scenarioRSVPRSVP--ATM peer model seems to be problematic: no real application ATM peer model seems to be problematic: no real application need, no immediate market needneed, no immediate market need

year 2 starts:year 2 starts:proof of RSVP over ATM scenarioproof of RSVP over ATM scenario

SRP over ATM promising new approach SRP over ATM promising new approach

SIMA/Diff. Serv. seems more relevant than peering RSVP with ATM SIMA/Diff. Serv. seems more relevant than peering RSVP with ATM