SNU INC Lab 2015-09-06 Integrated Services RSVP Differentiated Services 전산과학과 정보통신 연구실 최 선 웅 9 월 23 일

23年 4月 19日 SNU INC LabSNU INC Lab

Integrated ServicesRSVP

Differentiated Services

전산과학과 정보통신 연구실최 선 웅9 월 23 일


History IP-based Internet

provide a simple best-effort delivery service to all applications

New real-time, multimedia, and multicasting applications are not well supported, in IP-based Internet. construct a second networking infrastructure for real-time tra

ffic replace the existing IP-based configuration with ATM


Integrated Services Architecture(ISA) Strong need to support a variety of traffic with a

variety of QoS requirements, within the TCP/IP architecture

Fundamental requirement add new functionality to routers and a means for requesting

QoS-based service from Internet

IETF is developing a suite of standards under the general umbrella of the Integrated Services Architecture(ISA)


Integrated Services(intserv) Integrated Services

The transport of audio, video, real-time, and classical data traffic within a single network infrastructure

Purpose of this working group Define the enhanced Internet service model Defining the application service, router scheduling and

(general) subnet interfaces Developing router validation requirements which can ensure

that the proper service is provided

RFC’s Specification of the Controlled-Load Network Element

Service (RFC 2211) Specification of Guaranteed Quality of Service (RFC 2212)


Internet Traffic Elastic Traffic

can adjust to change in delay and throughput across Internet and still meet the needs of its applications

non-real-time application FTP, SMTP, TELNET, SNMP, HTTP

Inelastic Traffic does not easily adapt to changes in delay and throughput

across Internet real-time application


Inelastic traffic Inelastic traffic

Tolerant / Intolerant depending on whether they can tolerate occasional loss

Adaptive / Non-adaptive depending on their adaptability Delay-adaptive / Rate-adaptive

Requirement for inelastic traffic need of means to give preferential treatment to applications

with more demanding requirements elastic traffic must still be supported


ISA Service Class Guaranteed(RFC 2212)

provide assured capacity level, or data rate specified upper bound on the queuing delay no queuing losses

Controlled load(RFC 2211) approximation no specified upper bound on the queuing delay, but ensure

that a very high percentage of the packets do not experience delays that greatly exceed the minimum transit delay

almost no queuing loss

Best effort


Flow Flow

distinguishable stream of related IP packets that results from a single user activity and requires the same QoS

Flow vs. TCP connection A flow is unidirectional There can be more than one recipient of a flow(multicast)


Internet Traffic Control Conventional Traffic Control

Routing algorithm Most routing protocols in use in Internet allow routes to be

selected to minimize delay Packet discard

When overflows, discard packets Typically, the most recent packet is discarded

These tools have worked reasonably well


Requirements ISA Approach

Flowspec Admission Control Routing algorithm

may be based on a variety of QoS parameters, not just minimum delay

Queuing discipline Discard policy Resource reservation

Reservation Protocol(RSVP)


IS Router Components Classifier

Incoming packet must be mapped into some class Choice of a class is based on fields in the packet header

Packet scheduler Manage queues for each output port Determine the order of packet transmission and discard Based on a packet’s class, the contents of the traffic control

database, and current and past activity on this outgoing port Determine whether the packet traffic in given flow exceeds

the required capacity and if so, decide how to treat the excess packets policing


IS Router Components(Cont’d) Admission Control

Implement the decision algorithm Enforce administrative policy Accounting and administrative reporting

Reservation Setup Protocol Create and maintain flow-specific state Carry flowspec to admission control


IS Host/Router Components

Application

RSVPProcess

PolicyControl

ClassifierPacket

Scheduler

AdmissionControl

RoutingProcess

RSVPProcess

PolicyControl

ClassifierPacket

Scheduler

AdmissionControl

HOST ROUTER

RSVP

DATA


Resource Reservation: RSVP Design goals

Heterogeneous receivers Dynamic multicast group membership Enable receivers to select one source from among multiple

sources transmitting to a multicast group Deal gracefully with changes in routes, automatically

reestablishing tree the resource reservation along the new paths

Minimize protocol overhead Be independent of routing protocol

RFC’s Resource ReSerVation Protocol (RSVP) -- Version 1

Functional Specification(RFC 2205)


RSVP Characteristics Characteristics

Unicast and multicast Soft state Receiver-initiated reservation Simplex Different reservation styles Transparent operation through non-RSVP routers Support for IPv4 and IPv6


Receiver-initiated Reservation In ATM, the source of a data flow requests resources

In unicast, this approach is reasonable Inadequate for multicasting

Why? Some members of a multicasting group may not require

delivery from a particular source over some period of time Some members of a group may only be able to a portion of

the source transmissions

Sender provide the routers with the traffic characteristics of the transmission

Receiver specify the desired QoS


Soft State Reservation state is cached information in the router Periodically refreshed by end system If a state is not refreshed within a required time limit,

the router discards the state If a new route becomes preferred for a given flow, the

end systems provide the reservation to the new routers on the route


RSVP Admission Control RSVP process communicates with two local decision

modules admission control

determines the node has sufficient available resources to supply the requested QoS

policy control determines whether the user has administrative permission to

make the reservation


RSVP Admission Control(Cont’d) If either check fails,

RSVP returns an error notification to the application process that originated the request

If both check succeed, RSVP sets parameters in a packet classifier and packet

scheduler to obtain the desired QoS The packet classifier determines the QoS class for each packet The packet scheduler orders packet transmission to achieve

the promised QoS for each stream


RSVP Admission Policy(rap)

Network Node

PEP PDP

Policy Server

LDP

COPS


Scalability Scalability

Receiver-oriented reservation requests that merge as they progress up the multicast tree

While RSVP protocol is designed specifically for multicast applications, it may also make unicast reservations


Robustness RSVP is designed to utilize the robustness of current

Internet routing algorithms RSVP does not perform its own routing Use underlying routing protocols to determine where it

should carry reservation requests As routing changes paths to adapt to topology changes,

RSVP adapts its reservation to the new paths wherever reservations are in place

RSVP runs over IP, both IPv4 and IPv6


Data Flows Session

Destination IP address IP protocol id Destination port

Flow spec Service class RSpec TSpec

Filter spec Source address UDP/TCP source port


Relationship

Filterspec

FlowspecQoS

delivery

Best-effortdelivery

Packets thatpass filter

Otherpackets

Packets

PacketScheduler


RSVP Operation: Filtering An example of filtering

Fig. Filtering a substream


Reservation Styles Reservation attribute

shared/ distinct

Sender selection explicit/ wildcard

Reservation AttributeSender

SelectionDistinct Shared

ExplicitFixed-filter(FF) style

Shared-explicit(SE) style

Wildcard -Wildcard-filter

(WF) style


Reservation Style Notation Notation

Filterspec{Flowspec}

Wildcard Filter(WF) style WF(*{Q})

Shared Explicit style SE(S1, S2, … {Q})

Fixed Filter(FF) style FF(S1{Q1}, S2{Q2}, …)



Basic RSVP Message Two basic message type

Resv / Path

Path message Provide upstream routing information Each host that wishes to participate as a sender in a

multicast group issues a Path message Transmitted throughout the distribution tree to all multicast

destination

Resv message Originate at a receiver and propagate upstream, being

merged Must be repeated periodically to maintain the soft states


RSVP Mechanism Overview Procedure

a. A receiver joins a multicast group by sending an IGMP join message to a neighboring router

b. A potential sender issues a Path message to the multicast group address

c. A receiver receives a Path message identifying a sender

d. The receiver sends Resv messages, specifying the desired flow descriptors

e. The Resv message propagates through the internet and is delivered to the sender

f. The sender starts sending data packets

g. The receiver starts receiving data packets


Reservation ExampleR1

S1

S2

R2N1 N2

R3

Path(S1, S1) Path(N1, S1) Path(N2, S1)

Path(N2, S1)

Path(N2, S1)

Path(N1, S2)

Path(N2, S2)

Path(N2, S2)

Path(N2, S2)Path(N2, S2)

Filterspec Phop ReservedN1 S1 S1 0

N2 S1 N1 0

Filterspec Phop Reserved

S1 S1 0N1

S2 S2 0S1 N1 0

N2S2 N1 0


Reservation Example : WFR1

S1

S2

R2N1 N2

R3

Resv(WF(*{5B}))

Resv(WF(*{3B}))

Resv(WF(*{2B}))

Resv(WF(*{5B}))

Filterspec Phop Reserved

S1 S1 5BN1

S2 S2 5BS1 N1 5B

N2S2 N1 5B

Resv(WF(*{5B})

Resv(WF(*{5B}))


Reservation Example : FFR1

R2N2

R3

Resv(FF(S1{4B}, S2{2B}))

Resv(FF(S1{B}, S2{3B}))

Resv(FF(S1{5B}))

Filterspec Phop ReservedS1 S1 5B

N1S2 S2 3BS1 N1 5B

N2S2 N1 3B

S1

S2

N1Resv(FF(S1{5B}, S2{3B}))Resv(FF(S1{5B}))

Resv(FF(S2{3B}))


Reservation Example : SER1

R2N2

R3

Resv(SE(S1, S2{2B}))

Resv(SE(S1, S2{3B}))

Resv(SE(S2{5B}))

Filterspec Phop ReservedS1 S1 5B

N1S2 S2 5BS1 N1 5B

N2S2 N1 5B

S1

S2

N1Resv(SE(S1, S2{5B}))Resv(SE(S1{5B}))

Resv(SE(S2{5B}))


Flow Specification Flowspec = Traffic Spec + QoS Spec

= TSpec + RSpec TSpec : Peak rate(p), bucket rate(r), bucket size(b),

max datagram size(M), min policed unit(m) All datagrams less than m are counted as m bytes Peak rate may be unknown or unspecified

RSpec : Rate(R) and delay slack(S) S = Extra acceptable delay over that obtainable with R Zero slack ==> Reserve exactly R.

RSpec specified only for guaranteed rate service.

Not for controlled load service.


Guaranteed Service Firm end-to-end delay bound

Error terms : C, D

)rRp(DR

CM

)rp(R

)Rp)(Mb(Q tot

totenddelayend

2

)rpR(DR

CMQ tot

totenddelayend

2


Path Message Phop

last node address

Sender Template Filter specification

Sender TSpec Optional ADSPEC

One Path With Advertising(OPWA) information


Processing Path Message Update the path state

If no path state exists, create it

Store Phop In order to route Resv message

Set cleanup timer Expiration of the cleanup timer triggers deletion of the path

state Soft-state


ADSPEC Optional object to advertise to receivers the

characteristics of the end-to-end communication path ADSPEC format

Message header Default General Parameters fragment

minimum path latency, Global break bit, Path bandwidth, Integrated Service Hop Count, PathMTU

Guaranteed Service fragment Ctot, Dtot, Csum, Dsum, Guaranteed Service Break bit, Guaranteed

Service General Parameters Header/Values Controlled-Load Service fragment

Controlled-Load Service Break Bit, Controlled-Load Service General Parameters Headers/Values


Reservation using OPWA Qdelreq : the required bound on end-to-end queuing

delay End-to-end delay required by the receiver’s application – the

minimum path latency

Initial check (R = p) Choose an equation

Find R


Slack Term S : slack term

End-to-end delay required by the application – End-to-end delay bound

Ctot i : the cumulative sum of the error terms, C for all the routers that are upstream of, and including, the current element i

)RRr(R

C

R

bS

R

C

R

bS inout

in

tot i

inin

out

tot i

outout



Problems of Intserv Resource reservations for flow-based traffic

High overheads of setting-up a reservation Difficult determination of required resources Overhead of authentication, authorization, and accounting

per flow Scalability problem


Differentiated Services(diffserv) Objective

Provide scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop

Simple and coarse methods of providing differentiated classes of service for Internet traffic

How-to-do Setting bits in the TOS octet at network edges and

administrative boundaries Using those bits to determine how packets are treated by

the routers inside the network Conditioning the marked packets at network boundaries in

accordance with the requirements of each service


Related Proposals Premium Service(V. Jacobson)

Scheduling priority Strict admission control Virtual leases line

Assured Service(D. Clark) Drop priority A better best-effort

User-Share Differentiation(Z. Wang) User

Who are granted some bandwidth Share

How much bandwidth is allocated to a user


Diffserv Working Group Feb 98

Working group formed

Goals Standardize the 'DS byte’ Assign specific per-hop behaviors to the DS byte Define the framework of the differentiated services

architecture Experiment with other per-hop behaviors that can be used to

produce additional services


Terminology Behavior aggregate

A collection of packets with the same code point crossing a boundary in a particular direction

DS byte IPv4 TOS octet or IPv6 Traffic Class octet

Per-hop Behavior(PHB) Forwarding treatment applied at a differentiated services-

enabled node to a behavior aggregate


DS byte

PHB: per-hop behavior CU: currently unused

PHB CU

10 2 3 4 5 6 7


Per-Hop Behaviors Differentiated services model

Router has a set of parameters that can be used to control how packets are scheduled onto an output interface

N separate queues with settable priorities, queue lengths, round-robin weights, drop algorithm, drop preference weights and thresholds, etc

Two per-hop behaviors Default(DE: 000000)

common, best-effort forwarding Expedited Forwarding(EF: 000010)

high priority behavior typically used for network control traffic such as routing updates


Traffic Classification and Conditioning Packet classification

Identify the subset of traffic which may receive a differentiated service within the DS domain

Traffic conditioning Metering, shaping, policing and remarking


Classifier and Conditioner

Classifier Marker

Meter

Shaper/Dropper

Packets

Conditioner


Traffic Management Traffic conditioner

Meter Measures traffic against profile Passes state information to other conditioning functions

Marker Sets codepoint(possibly based on metering)

Shaper/dropper Delays or drops packets


Summary Support QoS in the Internet

Intserv/RSVP Diffserv

Documents

SNU INC Lab 2015-09-06 Integrated Services RSVP Differentiated Services 전산과학과 정보통신 연구실 최 선 웅 9 월 23 일