Transcript 第六章 多媒體網路(Multimedia Networking)

第六章
多媒體網路(Multimedia Networking)
簡介

隨著網路的快速發展，我們在網路上使用多媒
體資料的機會越來越多，同時多媒體網路也漸
漸受到重視，所以就有許多因應多媒體網路的
協定產生了。
簡介

本章節的目的：




在多媒體網路中的服務所需要的條件
在現今best-effort的網路如何達到最佳的效果
瞭解現在有哪一些協定是使用在多媒體網路中的
例如：




RTSP
RTP
H.323
SIP

本章節所要介紹的是：


多媒體網路中的應用程式
streaming stored audio and video


interactive real-time apps




RTSP
Internet phone example
RTP
H.323 and SIP
beyond best effort



scheduling and policing
integrated services（Insserv）
differentiated services（Disserv）
網路中的多媒體

在網路中的多媒體有以下幾個特徵：



對於延遲（delay）較敏感
可以容忍資料遺失（loss tolerant）
資料具有連續性（continuous data）
網路中的多媒體（2）

多媒體應用程式的分類

串流儲存式（streaming stored）的audio和video


串流即時式（streaming live）的audio和video


先從網路下載多媒體檔案，再播放
直接透過網路播放多媒體檔案
即時交談式（real-time interactive）video

可依照我們的需求播放多媒體檔案
網路中的多媒體（3）

串流儲存式（streaming stored）的audio和
video



由使用者端去要求播放事先儲存在伺服器端的多媒
體檔案並透過網路傳送
使用者可控制多媒體檔案的播放
延遲：從使用者要求到播放開始的時間大約會有1
秒到10秒之間
網路中的多媒體（4）

單向即時（unidirectional real-time）模式



因為real-time所以直接由網路傳送播放
也因為是即時播放，所以使用者不能控制多媒體播
放，只能聽和看
例如：線上TV，線上廣播
網路中的多媒體（5）

交談式即時（Interactive real-time）模式





因為real-time所以直接由網路傳送播放
但是因為為交談式所以所傳送的資料並不像單向模
式那麼簡單，所以所造成的延遲會增加
Video：< 150 msec可接受範圍
Audio：< 150 msec為良好，<400可接受範圍
Jitter

在同一個多媒體串流中的封包的延遲變化程度
網路中的多媒體（6）


在我們現在所使用的Internet是使用best effort
傳送，所以對於傳送多媒體資料會有很大的影
響，例如：沒有辦法對於delay或是delay
variation提供保證
目前往處理封包大都是：



每一個封包的地位平等
FIFO
所以我們必須將所要處理的封包做分類
如何應用現在的網路傳送多媒體




使用UDP來傳送
在接收端使用暫存器和控制播放的速度已減少
jitter
將封包加上時間標籤以利播放
將不重要的封包丟掉
如何使現在的網路更適合傳送多媒體

我們必須改變網路所使用的協定可以讓我們所
使用的應用程式可以預先保留端對端的頻寬

所使用的協定必須要可以保留頻寬



例如：RSVP
必須改變router上scheduling policies來實現保留頻
寬
我們必須需要更複雜的軟體來實現在使用者和
router上面
Streaming Stored & Audio & Video

Streaming stored media




Audio和vedio檔案儲存在伺服器裡
由使用者發出要求存取
Audio和vedio檔案會在請求後10秒後送出
與伺服器端的交談行為是允許的

這裡指的是我們可以將多媒體檔案依照我們需求作動作
（暫停、倒轉、前進）
Streaming Stored & Audio & Video

Media player






移除jitter
解壓縮多媒體檔案
錯誤更正
圖形化介面讓我們更好控制多媒體播放
可以讓我們將播放程式嵌入到瀏覽器中
例如：Microsoft media player、Quick time、Real
time player…
網頁伺服器的多媒體串流（1）




瀏覽器透過HTTP要求
多媒體資料
伺服器透過HTTP回應
瀏覽器
瀏覽器會去呼叫media
player來播放多媒體資
料
缺點：

Media player必須透過瀏
覽器和伺服器溝通
網頁伺服器的多媒體串流（2）




瀏覽器和伺服器一樣透過HTTP
溝通
瀏覽器只會收到meta file，並且
呼叫media player
Media player會透過TCP和伺服
器建立連線，並使用HTTP交換
訊息且開始播放檔案
缺點：
 雖然不需透過瀏覽器接收多媒
體資料，但是透過HTTP不能讓
我們使用快轉、倒轉、暫停等
功能
 也許我們可以試試使用UDP來
傳送
多媒體串流伺服器


透過網頁伺服器達成
多媒體需求的溝通
Media player再與多
媒體串流伺服器利用
UDP溝通，取代了
TCP的使用
即時串流協定（Real Time Streaming
Protocol: RTSP）

RFC：2326



用戶端與伺服器模式的應用層協定
提供使用者一些控制多媒體功能，例如：快轉、倒
轉、暫停等…
使用HTTP協定傳送多媒體資料，但是HTTP本身無
法儲存連續性的多媒體資料
即時串流協定（Real Time Streaming
Protocol: RTSP）（續）

RTSP的缺點




無法定義要如何對多媒體資料加封
無法限制多媒體資料透過什麼協定傳送
無法定義media player如何暫存資料
現實網路當中我們大多使用RTSP來當作傳送
控制訊號（control message）的協定
out of band control



RTSP的控制信息和多媒體資料使用不同的
port號，所以我們稱為out-of-band
多媒體資料的資料結構並不是定義在RTSP，
所以我們認為是in-band
如果RTSP的信息和傳送多媒體資料的port有
重複的話，我們稱為interleaved
RTSP的運作程序
Web
browser
HTTP GET
presentation desc.
Web
server
SETUP
PLAY
media
player
media stream
media
server
PAUSE
TEARDOWN
client
server
Meta file的範例
<title>Twister</title>
<session>
<group language=en lipsync>
<switch>
<track type=audio
e="PCMU/8000/1"
src = "rtsp://audio.example.com/twister/audio.en/lofi">
<track type=audio
e="DVI4/16000/2" pt="90 DVI4/8000/1"
src="rtsp://audio.example.com/twister/audio.en/hifi">
</switch>
<track type="video/jpeg"
src="rtsp://video.example.com/twister/video">
</group>
</session>
RTSP session



每一個RTSP都有一個session的識別號，每一
個識別號由伺服器選定
用戶端使用SETUP發出請求，然後伺服器會
回應一個識別號給用戶端
用戶端會一直使用這一個識別號直到這一個
session結束為止
RTSP交換訊息範例
C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0
Transport: rtp/udp; compression; port=3056; mode=PLAY
S: RTSP/1.0 200 1 OK
Session 4231
C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0
Session: 4231
Range: npt=0C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0
Session: 4231
Range: npt=37
C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0
Session: 4231
S: 200 3 OK
Real-time interactive applications

我們大多所使用的交談式應用有：


PC對PC的電話
PC對家用電話





Dialpad
Net2phone
視訊會議
Web cams
接著我們將詳細介紹PC對PC的網路電話
Internet phone over best-effort (1)


之前提過在現今網路會有packet delay、loss
和 jitter
Internet phone的例子





在通話時才會產生封包
Bit rate為64kbps
通話時每20 msec會產生160 bytes的chunk
Chunk＋header加封後利用UDP傳送
因為有可能資料流失，所以接收端必須有判斷的機
制
Internet phone (2)

Packet loss




端對端的延遲


端對端的延遲在400 msec以內我們可以接受
Delay jitter


使用UDP加封封包
Datagram可能會超出router queue
的TCP可以減少loss但是會增加delay
必須要在20 msec內
移除jitter的方法



sequence numbers
timestamps
delaying playout
Internet phone (3): fixed playout delay




這裡是使用固定的delay time q，而每一個
trunk會被mark上一個time stamp
所以再接收端會在time=t+q時播放如果超出這
歌時間就會丟棄這個資料
所以在這裡不需要sequence number
q在這裡是一個trade off


較大的q，較少的封包被丟棄
較小的q，有較好的交談性
Internet phone (4): fixed playout delay


First playout schedule: begins at p
Second playout schedule: begins at p’
packets
loss
packets
generated
packets
received
playout schedule
p-r
playout schedule
p' - r
time
r
p
p'
Recovery from packet loss (1)


Loss：是因為資料遺失或是超過播放的時間限
制
forward error correction (FEC)





每n個chunk為一個group，並加入一個額外的XOR
chunk
所以總共會送出n+1個trunk，並會增加頻寬的1/n
可以從n+1 chunks中更正一個chunk
接收所有chunks的延遲必須要固定
Trade off

n增加，頻寬、loss rate和播放延遲亦會增加
Recovery from packet loss (2)

2nd FEC scheme

下一個封包會夾帶一個跟前一個一樣但quality較差的封包，
萬一前一個封包掉了，後一個可以補回來
Recovery from packet loss (3)

Interleaving

將一個封包在細分成數個小單位，然後前後交叉傳送以降
低loss的機會
Real-Time Protocol (RTP)



RFC：1889
和前面的RTSP所不同的是RTP為了封包攜帶
audio和video有定義封包的結構
RTP封包提供了





封包攜帶的資料格式識別
封包序號編號
時間標記
RTP通常在終端系統使用
RTP使用UDP來加封封包
RTP runs on top of UDP



RTP和UDP共同組成了傳送層
應用成的程式透過RTP和UDP溝通
因為RTP是為了額外提供：





埠號，IP位址
錯誤更正
資料格式識別
封包序號編號
時間標記
RTP and QoS


RTP並沒有提供適時的資料傳送和任何麼品質
服務保證
RTP對於封包的加封只會在終端系統看的出來


因為如此在傳統的routing機制中沒有辦法對於RTP
所傳送的封包最任何特別的服務
所以為了提供應用程式有品質服務保證，在網
路之中必須使用類似RSVP這樣可以預先保留
頻寬的機制來提供所需要的品質保證
RTP Header

Payload Type (7 bits)：提供了128種可能的encoding
的方法







Payload type 0: PCM mu-law, 64 Kbps
Payload type 3, GSM, 13 Kbps
Payload type 7, LPC, 2.4 Kbps
Payload type 26, Motion JPEG
Payload type 31. H.261
Payload type 33, MPEG2 video
Sequence Number (16 bits)：用來偵測封包的遺失
LOSS
RTP Header


Timestamp field (32 bytes)：用來反映出第一個資料
封包的採樣和用來移除jitter
Synchronization Source identifier (SSRC)： 32 bits，
當作是一個資料源頭的識別號，這一個識別好是亂數
決定的
Real-Time Control Protocol (RTCP)
和RTP會同時發生作用
每一個RTP的session會用RTCP溝通，讓應
用程式獲得有用的資訊
並且會統計有多少個封包被傳送、多少封包
遺失、jitter變化
有了這一些資訊應用程式可以用來調整效能





例如：loss rate增大時…
RTCP - Continued



每一個RTP session都會有一
個multicast address，而所有
屬於這一個session的RTP和
RTCP都會使用這一個address
RTP和RTCP的封包是由不同
的埠號來區分
RTCP會有三種report packets



Receiver report packets
Sender report packets
Source description packets
RTCP--report packets

Receiver report packets


Sender report packets


紀錄封包遺失的片段、遺失的sequence number、
平均的inter-arrival jitter
RTP串流的SSRC、現在的時間、現在所傳送的封
包個數和現在所傳送的byte數
Source description packets

傳送者的e-mail、傳送者的名字、RTP串流所相關
的SSRC，這一個封包提供了SSRC和使用者（機
器）之間的對應
串流的同步

RTCP可以用來同步在同一個RTP session裡
的多媒體串流



例如：視訊會議裡包含影像和聲音
在RTP封包裡的時間標記是依附video或audio
的取樣率決定的，而不是real-time的
接收端會使用sender report packet的資訊來做
同步
RTCP Bandwidth Scaling

RTCP約佔整個session的頻寬的5%



例如：傳送的速率為2Mbps，則RTCP約為
100kbps
如果每一個接收端都傳送RTCP給所有其他的接收
端，這樣RTCP的traffic會很大
RTCP佔的100kbps會在分為接收端75kbps（75%）
和傳送端的25kbps（25%）
H.323


H.323亦是為了在網路上傳送多媒體資料所產生的一
個協定，較有名的應用程式為：Microsoft Net
meeting
接著我們將簡單介紹H.323這一個協定







Overview
H.323 terminal
H. 323 encoding
Gatekeeper
Gateway
Audio codecs
Video codecs
Overview (1)



目標：可以達到即時的通訊
由ITU所建議使用
應用的範圍



單獨的機器（例如：網路電話）
在PC上的應用
點對點或是多點的視訊會議
Overview (2)

在H.323裡面定義了






端點的機器如何撥接一個呼叫（call）
端點的機器如何交換共同的audio/video解碼
Audio和video如何加封來透過網路傳送
Audio和video如何同步
端點的機器如何和他的gatekeeper溝通
網路電話和一般PSTN/ISDN的電話如何溝通
Overview (3)





Telephone calls
Video calls
Conferences
Whiteboards
所有的機器必須支援
H.323
In te rn e t
"E th e rn e t" p h o n e
M S N e tm e e tin g
N e tS p e a k W e b P h o n e
Overview (4)
G a te k e e p e r
In te rn e t
PSTN
G a te w a y
H.323
SS7, Inband
H.323的端點機器必須支援

G.711


RTP


在端點機器之間用來傳送控制訊號的“Out-of-band” 控制協定
Q.931


將多媒體加封的協定
H.245


ITU 所制訂的語音壓縮標準
用來建立撥接的signaling協定
RAS (Registration/Admission/Status) 通道協定 –

用來和gatekeeper溝通的協定
H.323 Terminal
H.323的編碼（encoding）

Audio



H.323的終端機器必須支援G.711，用來傳送壓縮的
與語音，voice rate = 56/64 kbps
Optional：G.722, G.728, G.729
Video




對於H.323的終端機器是optional
終端機器必須支援QCIF H.261 (176x144 像素)
H.261 option：CIF, 4CIF, 16CIF
H.261是用來和使用多重64kbps的頻道溝通
Generating audio packet stream in H.323
Audio
Source
Encoding:
e.g., G.711
or G.723.1
RTP packet
encapsulation
UDP
socket
Internet or
Gatekeeper
H.245 Control Channel




一個H.323串流可能會包含多個不同種類的多
媒體資料
每一個H.323 session都會有一個H.245的控制
頻道
H.245控制頻道是一個reliable（TCP）的控制
頻道
主要任務


開啟或關閉一個多媒體頻道
相容性的交換

在開始傳送資料前，會先交換編碼的演算法
Information flows
C a ll C o n tro l
Channel
C a ll S ig n a lin g
Channel
M e d ia C o n tro l
Channel
H .3 2 3
T e rm in a l
H .3 2 3
T e rm in a l
R AS Ch a n n e l
H .3 2 3
G a te k e e p e r
M e d ia C h a n n e l
1
M e d ia C h a n n e l
2
T CP
UDP

在這裡gatekeeper是
optional，提供




位址轉換成IP位址
頻寬的管理
因為billing的方便，
H.323的calls可能會由
gatekeeper管理
RAS是用來terminalgatekeeper之間溝通
的協定
H.323 terminals
Gatekeeper（1）
Internet
Router
RAS
Gatekeeper
LAN = “Zone”
Gatekeeper（2）



H.323的設備必須要跟他那個區域的
gatekeeper做註冊的動作
如果gatekeeper存在的話，每一個終端設備要
撥接一個call的前要先經過gatekeeper同意
如果獲得同意，終端設備會傳送e-mail給
gatekeeper，裡面包含了要轉換成IP位址的資
訊
Gateway
PSTN
H.323 terminals
Gateway
Router
Internet
RAS
Gatekeeper
LAN = “Zone”


IP區域和PSTN（or ISDN）的橋樑
終端設備使用H.245和Q.931和gateway溝通
Audio codecs
C odec
B a n d w id th
[k b it/s ]
MOS
C o m p le x ity
[M IP S ]
P a c k e tiz a tio n
(fra m e s iz e )
[m s ]
G .7 1 1
64
4 .5
-
-
G .7 2 1 (A D P C M )
32
4 .4
6 .5
-
GSM
13
3 .8
4
20
G .7 2 9
8
4 .1
15
10
G .7 2 3
6 .4 /5 .3
4 .0
20
30
5
MOS (Mean Opinion Score)
T o ll q u a lity
4
re c o g n iz e s p e a k e r
3
in te llig ib le
2
in te llig ib ility p ro b .
1
M O S (M e a n O p in io n S c o re )
Video codecs

H.261 (p x 64 kbit/s)



ISDN上傳送Video
Resolutions : QCIF, CIF
H.263 (< 64 kbit/s)


低速率的溝通
Resolutions: SQCIF,
QCIF, CIF,4CIF, 16CIF
SQCIF
QCIF
CIF
4CIF
16CIF
(128 x 96)
(176 x 144)
(352 x 288)
(704 x 576)
(1408 x 1152)
QoS in IP networks



現在的網路並沒有提供
QoS的機制，所以IETF
有些團體就在制訂一些
可以提供QoS機制的
protocol
目前正在制訂的有
RSVP，Differentiated
Services和Integrated
Services
例子：
QoS的原理（1）

Principle 1


在router轉送封包時分成不同的類別的封包
制訂新的分配不同類別的封包政策
QoS的原理（2）

Principle 2


每一個不同的類別會受到不同的保護，以避免被其他的類別
影響
因為如此，所以我們需要policy management來確保每一個
頻寬的需求，通常我們都在終端執行
QoS的原理（3）

Principle 3

當我們達到類別互相不干擾後，我們必須讓我們的頻寬使用
效率達到最好
QoS的原理（4）

Principle 4

基於link的容量限制下，我們需要Call Admission Control來
管理一個call我們是不是要接受，如果容量滿了，我們必須
block new call
QoS的原理—總整理




Packet classification
Isolation：scheduling and policing
High resource utilization
Call admission control
QoS Approaches
Scheduling And Policing Mechanisms


Scheduling（排程）：依照policies選擇下一個被傳送
的封包
Policy

FIFO：最簡單的機制，先進入暫存區的封包先傳送
Policing Mechanisms（2）



Priority Queuing：不同的priority有不同的暫存區，我們可以依照
來源IP、目的地IP、TCP埠號…等來區分priority
傳送封包時永遠從最高優先權的先傳直到最高優先權的暫存區空
了
可分為可中斷（preemptive）和不可中斷（non-preemptive）兩種
Policing Mechanisms（3）

Round Robin：用掃瞄的方式來傳送資料，每一次都
從最高優先權的暫存區開始，一直掃到最低的，再由
最高的開始
Policing Mechanisms（4）

Weighted Fair Queuing：為更一般化的Round Robin，
基本上一樣是會由最高掃到最低的，但是會依照暫存
區理的資料不同而停留的時間不同
Policing Mechanisms

三種標準



Average Rate
Peak Rate
Burst Size
Policing Mechanisms（2）

Token Bucket是我們最常用來控制input的burst size
和average rate
Policing Mechanisms（3）



Bucket 可以擁有b個
tokens：token 會以r
token/sec產生，直到整
個bucket塞滿tokens.
在時間 t 後，所傳送的
封包會小於等於(r t+ b)
Token bucket和WFQ結
合可以提供delay的
upper bound
Call Admission




Session必須先定義他所需要的QoS需求，並
且指出所要透過網路傳送的資料特徵
R-spec：定義被要求的QoS
T-spec：定義所傳送資料的特徵
所以我們需要一個signaling協定來攜帶這一些
訊息讓router之到來幫我們保留所需要的資源，
RSVP是現在所常用的一個保留資源的
signaling協定
Call Admission（2）

Call Admission：router必須基於這一些call的T-spec、
R-spec和現在所擁有的資源來決定要不要接受這一個
call
Integrated Services




RFC1633
這是為了在網路上提供QoS所發整展的一套機制
針對每一個應用程式的session做QoS
基於資源保留，所以router必須維護一個狀態訊息（virtual
circuit state），並且需要記錄已經被保留資源和新的call所需要
的資源
Integrated Services : Classes





Controlled Load：這是一個提供接近於一個可接受的QoS的class，
應用於提供下載的router上
RFC2211
Providing the client data flow with quality of service closely
approximation the QoS that same flow would receive from an
unloaded network element
Using capacity (admission) control to assure that this service is
received even when the network element is overloaded.
Applications:
 Adaptive real-time applications
 These applications perform quite well when the network is
unloaded, but rapidly degrade in performance as the
network becomes more loaded
 Controlled-load service simply prioritizes the packets in the flow,
ensuring that they do not wait too long in router queues as they
cross the network.
Integrated Services : Classes（2）




Guaranteed QoS：這是提供強健的QoS保證的class，
用於對於delay較敏感的hard-real time應用程式
RFC2212
Providing firm bounds on the queueing
delays that a packet will experience in a
router.
Applications:


Hard real-time applications
Audio and video playback applications that are
intolerant of late-arriving packets
Introduction of RSVP




Resource ReSerVation Protocol.
Allows applications running in hosts to
reserve resources in the Internet for their
data flows.
Used by the routers to forward bandwidth
reservation requests.
RSVP software must be present in the
receivers, sender, and routers.
RSVP in Hosts and Routers
HOST
Application
RSVP
process
ROUTER
RSVP
messages
Policy
Control
Routing
Protocol
process
RSVP
process
RSVP
messages
Policy
Control
Data
Classifier
Packet
Scheduler
Admission
Control
Packet
Scheduler
Classifier
Data
Admission
Control
Data
Packet
Scheduler
Data
Introduction of RSVP （2）

Two principle characteristics of RSVP




It provides reservations for bandwidth in multicast
trees(unicast is handled as a special case).
It is receiver-oriented.
RSVP reserves resources for only one
direction data streams.
RSVP is not a routing protocol


It does not determine the links in which the
reservations are to be made.
An RSVP daemon consults the local routing
databases to obtain routes.
Introduction of RSVP （3）


RSVP depends on an underlying routing
protocol(unicast or multicast) to determine
the routes for the flows
RSVP is sometimes referred to as a signaling
protocol that allows hosts to establish and
tear-down reservations for data flows
RSVP: multicast- and receiver-oriented
RSVP Operation Example
Session
(Ipa,PID,Port)
Path message
Resv message
IGMP(1)
IGMP message
Receiver B
Data
Packet
Session
(Ipa,PID,Port) (4)
Resv (3)
IGMP (1)
path (2)
Sender
Resv(3) Receiver A
Merge
point
Session
(Ipa,PID,Port)
A Few Simple Example
Differentiated Services（DS）




因為在Integrated Services上會有一些問題，所以
又另外在衍生的另一個提供QoS的機制
Scalability：因為在Integrated Services需要維護
記載一些state，所以當在高速的網路中時事很難
去維護這麼多traffic flow所造成的state
Flexible Service Models：Intserv 只有提供兩種
classes，我們需要更有彈性的區分
Simpler signaling：因為RSVP過於繁雜，所以我
們需要一個較簡單signaling協定
Differentiated Services（2）

方法：


在核心網路的router中只會有一些簡單的功能（相
較於邊端router）
不需要定義服務的類別
DiffServ Architecture
DiffServ Architecture（2）

DS domain:


DS region:


connect to other DS interior or boundary nodes within the same domain.
DS ingress nodes:


DS boundary nodes interconnect the DS domain to other DS or non-DS-capable
domains.
DS Interior nodes:


A DS region is a set of one or more continuous DS domains.
DS boundary nodes:


A DS domain is a set of DS nodes that are with the same service provisioning policy
and set of PHB groups implemented on each node.
responsible for ensuring the traffic entering the DS domain conforms to any TCA
between it and other domain.
DS egress nodes:

Perform traffic conditioning functions on traffic forwarded to a directly connected
peering domain, depending on the details of the TCA between the two domains.
Edge Functions



在一個有DS功能的主機或是router都有
Classification：端點的機器會依照分類的規則將封包
加上標記（mark）
Traffic Conditioning：端點機器有可能會延遲後再轉
送或是丟棄封包
Core Functions


Forwarding：根據“Per-Hop-Behavior”
（PHB）特定的封包類別來轉送封包
好處：router不需要維護或記載任何state
Classification and Conditioning


在現在的IP header（IPv4）裡的TOS欄位尚未被用
到，在IPv6定義為traffic class
在這裡DS就是利用TOS一個byte來做classification


Differentiated Service Code Point (DSCP)：6 bits
2 bits are currently unused
Classification and Conditioning（2）

Router會依照使用者所定義的user profile（rate和
burst size）來對traffic profile做控制
DiffServ Components




Classifier.
Traffic Conditioner.
Service Level Agreement (SLA).
Traffic Conditioning Agreement (TCA).
Classifier

Behavior Aggregate(BA) classifier:


BA classifier uses only the DiffServ codepoint(DSCP) in a packet’s IP
header to determine the logical output stream to which the packet should be
directed.
Multi-Field(MF) classifier:


MF classifier classifies packets based on one or more fields in the packet
header.
A common type of MF classifier is a 5-tuple classifier. (src addr, dest addr,
src port, dest port, IP protocol)
Traffic conditioner

Meter:


Metering is the function of monitoring the arrival times of packets on a traffic
stream and determining the level of conformance of each packet to a profile.
Types of meters:



Average rate meter.
Exponential weighted moving average meters.
Token bucket meters.
Traffic conditioner (cont.)

Marker:



Shaper:


Marker set the DSCP in a packet header.
Marker may act on unmarked packets or may remark previously marked
packets.
Shaper are used to shape traffic to a certain temporal profile.
Dropper:

Droppers simply discard packets with no parameters.
SLA

Service Level Agreement(SLA):



A service contract between a customer and a service provider that specifies
the forwarding service a customer should receive.
A SLA may also specify traffic profiles and actions to traffic streams which
are in- or out-of-profile.
Static SLA:


norm at the present time.
first instantiated at the agreed upon service start date and may periodically
be renegotiated.
SLA (cont.)

Dynamic SLA:



may change as the traffic load fluctuates.
dynamic SLAs change without human intervention and thus require an
automated agent and protocol.
Challenging problems for Dynamic SLA :



Network providers have to balance frequently changing loads on different
routers within the provider network.
Customer equipments will have to adapt to dynamic SLAs.
End user applications have to adapt their behavior during a session.
TCA

Traffic Conditioning Agreement(TCA) specifies detailed service
parameters for each service level:





Traffic profiles.
Metering rules.
Marking rules.
Discarding rules.
Shaping rules.
Traffic Profiles



A traffic profile specifies the temporal properties of a traffic
stream selected by a classifier.
In-profile packets may be allowed to enter the DS domain without
further conditioning.
Out-of-profile packets may be queued until they are inprofile(shaped), discarded(policed), marked with a new
codepoint(remarked), or forwarded unchanged while triggering
some accounting procedure.
Bandwidth Broker




act the policy and call admission control manager in each DS
domain.
keep track of current allocation of marked traffic.
interpret new requests to mark traffic according to policies and
current allocation.
parcel out marked traffic allocations and set up edge routers.
Bandwidth Broker Architecture
adjacent BB
adjacent BB
Inter-Domain
Interface
application
server
user/
host
network
operator
User/App
Interface
Data
Repository
edge
routers
Policy Manager
Interface
Network Management
Interface
Intra-Domain
Interface
Routing
Information
edge
routers
DS Code point
backward compatibility
Best-Effort traffic
TOS (RFC 791)
IP precedence (RFC 1349)
0
1
2
3
4
5
6
DSCP
Pool 1
IP precedence
Best-Effort
Default PHB
Expedited
Forwarding
PHB
7
0
CU
1
2
3
4
Precedence
5
6
TOS
7
0
X
X
X
X
X
0
1
1
1
0
0
0
111
Network control
1
1
0
0
0
0
110
Internetwork control
1
0
1
0
0
0
101
Critical
1
0
0
0
0
0
100
Flash override
0
1
1
0
0
0
011
Flash
0
1
0
0
0
0
010
Immediate
0
0
1
0
0
0
001
Priority
0
0
0
0
0
0
000
Routine
High Priority
Class Selector Codepoint
1
0
Low Drop
0
1
0
Medium Drop
0
1
High Drop
0
1
Assured
Forwarding
PHB
1
1
Low Priority
0
0
0
0
0
0
1
1
0
0
0
0
0
1
0
0
1
1
0
1
0
0
1
0
0
0
1
1
1
0
0
Class 1
Class 2
Class 3
Class 4
Low Drop
1
0
0
0
0
0
1
0
1
0
0
0
Medium Drop
1
0
0
0
1
0
1
0
1
0
1
0
High Drop
1
0
0
1
0
0
1
0
1
1
0
0
Per-Hop Behavior

Per-hop Behavior(PHB)



is a description of the externally observable forwarding behavior
of a DS node applied to a particular DS behavior aggregate.
PHBs may be specified in terms of their resource priority relative
to other PHBs, or their relative observable traffic characteristics.
PHBs are implemented in nodes by buffer management and
packet scheduling mechanisms.
Assured Forwarding PHB Group

Reference:


IETF RFC 2597.
Description:



AF PHB group is a means for a provider DS domain to offer
different levels of forwarding assurances for IP packets received
from a customer DS domain.
Four independent forwarding AF classes and with each AF class,
three levels of drop precedence are defined.
Packets of class x have smaller forwarding time(delay time) than
class y, if x>y.
Assured Forwarding PHB Group (cont.)

Description:




A packet with drop precedence p must be forwarded with higher
probability than a packet with drop precedence q, if p<q.
An IP packet that belongs to an AF class i and has drop
precedence j within is marked with the AFij.
A DS node must allocate a configurable, minimum amount of
forwarding resources to each implemented AF class.
An AF class may also be configurable to receive more
forwarding resources than minimum when excess resources are
available either from other AF classes or from other PHB groups.
Assured Forwarding PHB Group (cont.)

AF PHB recommend codepoint:
AF1
AF2
AF3
AF4
low
010000
011000
100000
101000
mid
010010
011010
100010
101010
high
010100
011100
100100
101100
Expedited Forwarding PHB

Reference:


IETF RFC 2598.
Description:



The EF PHB can be used to build a low loss, low latency, low
jitter, assured bandwidth, end-to-end service through DS
domains.
The departure rate of the aggregate’s packets from DS nodes
must equal or exceed a configurable rate.
The EF traffic receives this rate independent of the intensity of
any other traffic attempting to transit the node.
Expedited Forwarding PHB (cont.)



DSCP: Diffserv codepoint
CU: currently unused
EF PHB recommend codepoint:

101110