A˘g¨Uzerinden Video Transferinde `Farklandırılmıs Servisler`in

A˘g¨Uzerinden Video Transferinde `Farklandırılmıs Servisler`in

Ağ Üzerinden Video Transferinde ‘Farklandırılmış
Servisler’in Kullanımı
Eren Gürses,
ODTÜ, Elektrik-Elektronik Müh.
Nail Akar
Bilkent Üniv, Elektrik-Elektronik Müh.
Gözde Bozdağı Akar
ODTÜ, Elektrik-Elektronik Müh.
ÖZET
Günümüzdeki Internet yapısında gerçekzamanlı bilgiyi, uçtan-uca “çekirdek yönlendirici”lerin üzerinden gönderirken belli bir hizmet
niteliği(QoS) belirleyebilmek imkansızdır. Şu
anki yapıda kullanılması ve QoS üzerinde kesin
olmayan bazı garantilerden bahsedilebilmesini
sağlayabilmek amacıyla, Farklandırılmış Servisler’in (Differentiated Services) kullanılması
önerilmiştir.
Sıkıştırılmış video bilgisinin
içindeki çerçevelerin birbirlerine göre farklı
önem taşıması, bu tip VBR (Değişken Bit
Hızlı) trafiğin Internet üzerinden gönderilmesi
için DiffServ’in kullanılabilirliği fikrini ortaya
çıkarmıştır. Bu çalışmada, bütün paketlerin
aynı öneme sahip olmadığı trafikler için, bir önişaretlemenin son kullanıcı tarafından yapılması
ve kalan paketlerin gerektiği durumlarda “kenar
yönlendirici” tarafından önceliklerinin artırılması
mekanizması önerilmiştir. Bu sayede önemli
paketler Internet’te “çekirdek yönlendirici”lerden geçerken daha fazla, önemsiz paketler ise
çok daha az korunmuş olur.
1. GİRİŞ
“DiffServ”, şu anda kullanılan, hiçbir QoS
garantisi vermeyen (best effort) IP ağ’ları ve
internet pazarında kendine pek yer bulamamış
Tümleşik Hizmetlerin(IntServ) ortasında bir
yerde bulunmaktadır. Kaynak Ayırtma Pro-
tokolü (RSVP) kullanarak IntServ hizmeti
sağlamanın en büyük dezavantajı ölçeklenemez
oluşudur. Diffserv ise şu anki (best effort)
IP ağları ile aynı derecede ölçeklenebilmekte,
ve uygun yönetilmesi durumunda (best effort)IP’den farklı olarak QoS üzerinde bazı esnek garantilerden bahsedilebilmektedir. Bu
model ile sağlanan QoS, bağlantı başına değil,
ancak her LAN’dan çıkan kümelenmiş trafik
için, uçtan-uca tanımlı olabilmektedir.
Internet’te giderek artan çokluortam trafiği
ve bu trafiğin belli QoS sınırları istemesi, ve
sıkıştırılmış video bilgisinin yapısının “DiffServ”in mantığına uygun olması yüzünden
(bölüm 2), “Sıkıştırılmış Video” ve “DiffServ”in birlikte düşünülmesi dikkate değer bir
konudur. Sıkıştırılmış video’da intra ve inter
olarak adlandırılan çerçeveler vardır. Şu anda
yaygın olarak kullanılan DCT veya dalgacık
tabanlı bütün video sıkıştırıcılarda(MPEG-1,
MPEG-2, H263, H263+,..) intra/inter çerçeve
mantığı kullanılmaktadır. Intra çerçeveler, zaman(temporal) bilgisi kullanılmadan, durağan
resim gibi sıkıştırılan çerçevelerdir.
Inter
çerçevelerde ise “hareket vektör”leri bilgisi kullanılır ve bu vektörler bir önceki çerçeveye
göre tanımlanmışlardır. Bu yüzden bir önceki
inter/intra çerçeve kaybolmuşsa, gelen inter
çerçeve kod çözücü tarafından en son ulaşan
çerçeve referans alınarak açılır. Bu da yeni bir
intra çerçeve gelene kadar hatanın üst üste ek-
TABLO 1
lenerek artmasına neden olur. Intra çerçevelerin
kaybolması durumunda hatanın düzelme ihtimali olmamaktadır. Bu yüzden gönderilecek intra frame’lerin Internet’ten başarı ile iletilmesini
sağlayabilmek amacıyla “DiffServ” servis sınıflarından birisini seçip ve bunların içindeki
“yüksek öncelikli” kodlama puanını (code
point) kullanabiliriz [1], [2], [3].
Bütün paketlerin eşit öneme sahip olmadığı
trafiklerde (video gibi), bazı paketlerin yüksek,
bazılarının düşük “kodlama puanı” kullanarak
kodlanması kararını tamamen, paket içeriğinden
habersiz olan “kenar yönlendiricilerin” vermesi düşünülemez.
Bu yüzden belli bir
ön-işaretleme, trafiği yaratan ilgili uygulama
tarafından yapılmalıdır. Bu sayede Internet’teki
paket kayıplarından, gerçek-zamanlı bilginin
mümkün olduğunca az etkilenmesini son kullanıcılar sağlamış olmaktadır.
Son kullanıcılar’dan kaynaklanabilecek kötü
niyetli kullanımı denetlemek amacı ile “kenar
yönlendirici”lerde işaretleme, son kullanıcının
satın aldığı diffserv bant genişliği bilgisine
göre tekrar yapılmaktadır. [1], [2]’de anlatılan “DiffServ”den farklı olarak: Eğer sonkullanıcının “yüksek öncelikli” kodlama puanı
ile işaretlediği trafik, satın alınan oranın altında
ise, “kenar yönlendiricilere” bu trafiğin kodlama puanını arttırma mekanizması getirilmiştir
(bölüm 3).
RFC2597’ DE
Renk
yeşil
sarı
kırmızı
n
1
2
3
ÖNERILEN KODLAMA PUANLARI
AF 1n
001110
001100
001010
AF 2n
010110
010100
010010
AF 3n
011110
011100
011010
AF 4n
100110
100100
100010
2. DIFFSERV YAPISI
DiffServ’in kullanılabilmesi için gerekli olan
servis sınıfı ve kodlama puanı bilgileri, IPv6’da
“DS-Alanı”, veya IPv4’te TOS(Type of Service) byte’ı kullanılarak gönderilebilir [1].
“DS-Alanı”ın nasıl kullanıldığı Şekil 2’de
gösterilmiştir.
Önerilen kodlama puanları Tablo 1’de verilmiştir.
EF (Expedited Forwarding=Hızlı
İleti) sınıfı hizmetler bu çalışmanın konusunun
dışında kaldığı için anlatılmamıştır. 4 farklı
tipi olan AF (Assured Forwarding=Güvenli
İleti) sınıfı iletilerden birisi seçilerek, örneğin
AF1, simülasyonlarda kullanılmıştır. Farklı
servis sınıfına ait paketler yönlendiricilerde
ayrı sıralara girmektedir. Buna karşılık aynı
sınıfa ait farklı öncelikli paketler aynı sırada
yer alırlar, fakat kaybolma olasılıkları farklıdır.
Her servis sınıfında(AF1, AF2, AF3 veya
AF4) 3 renk kodu vardır, yeşil, sarı, kırmızı.
“yeşil” en yüksek, “kırmızı” da en düşük
öncelikli paket’lerin kodudur. Bunlar sırası
ile AFn1, AFn2, AFn3’e karşılık gelmektedir
(n=1,2,3,4)(Tablo 1).
0
1
2
3
4
5
6
7
INTERNET
DSCP
Servis Sinifi
Kodlama Puani
Denetleyici
Kenar Yonlendirici
Kaynak Yonlendirici
kullanilmiyor
DiffServ Kodlama Puani(DSCP)
RFC2474
Şekil 2. IPv6’te DS-Alanı
Cekirdek Yonlendirici
Son Kullanici
Şekil 1. Basit bir “DiffServ” yapısı
“Denetleyici”ler (Şekil 3) diffserv’in en
önemli parçasıdır.
Kenar yönlendiricilerin
üzerinde çalışırlar ve daha aşağı seviyedeki
yönlendiricilerden gelen trafiğin, parası ödenmiş
trafik oranının üzerine çıkıp çıkmaması durmuna göre paket işaretlemesi yaparlar. “Sınıflandırıcı”, servis sınıflarına ve trafiğin geldiği
kaynak yönlendiriciye göre sınıflama yapar.
“Ölçücü”, sınıflandırılmış paketlerin hızını
(oranını) ölçer ve “İşaretleyici”, Ölçücü ve
Sınıflandırıcı’dan gelen bilgilere göre paketlere
kodlama puanı verir.
Simülasyonlarımızda
denetleyici, olarak trTCM(two rate Three
Color Marker=iki hızlı üç renk işaretleyici)[4]
kullanılmıştır.
trTCM’de derinlikleri farklı
iki jeton kutusu(token bucket) algoritması
işlemektedir. Kutulardan ufak olanı, , tolere
edilecek “doruk oranı” belirler. Bunu belirlemek için PBS( kutusunun derinliği) ve PIR
( kutusunun doldurulma hızı) parametrelerini
kullanır. kutusu ise ortalama olarak nekadar
AF11 bit hızına izin verileceğini belirler. Bunun
için yine CBS (derinlik), ve CIR (doldurma hızı)
parametreleri kullanılır.
TABLO 2
“ RENGE
if (codePt == Kırmızı) if (
) if (
) codePt = Yeşil
else codePt = Sarı
else
codePt = Kırmızı
else if (codePt == Sarı) if (
) if (
) codePt = Yeşil
! "
#
else codePt = Sarı
isaretlenmis
paketler
paketler
else
codePt = Kırmızı
else if (codePt == Yeşil) if (
$ )
codePt = Kırmızı
else if (%
&$ ) Olcucu(meter)
Siniflandirici
DUYARLI ” DENETLEYICININ KODLAMA
PUANINI ARTIRMA ALGORITMASI
Isaretleyici
"&
Şekil 3. Denetleyici’nin yapısı
3. UYGULANAN DENETLEYİCİ
ALGORİTMASI
Video bilgisinin iletilmesinde, son kullanıcılara ön-işaretleme hakkı verilmiş olması, video paketlerinin “kenar yönlendirici”lerin üstünde çalışan “denetleyici”lerin
“renge duyarlı” (color aware) çalışmasını gerektirmektedir. Denetleyici olarak trTCM [4]
kullanılmıştır.
trTCM’in standardında yer
alan “renge duyarlı” denetleyici için kodlama
puanını artırma mekanizması önerilmemiştir.
Böyle bir mekanizma eklenmesi sayesinde,
son kullanıcının paketlerine önem sırasına göre
sınıflandırma yaptıktan sonra, “kenar yönlendirici” gelen trafiğin, kendisine bildirilen ve parası
codePt = Sarı
else codePt = Yeşil
"&
ödenen trafik oranının (CIR, CBS, PIR, PBS)
altında kalması durumunda paketlerin “kodlama
puanını” arttırabilmektedir (Tablo 2).
Böylelikle hem “yüksek öncelikli” olan paketlere
bir koruma sağlanmış ve parası ödenmiş bant
genişliği kullanılmış olur. Burada ')(+*,'.-/1032
ve 45(6* 47-8/1032 seçilmesi sayesinde yüksek
kod puanlı paketlerin kodlama puanı aynı
TABLO 3
kalırken, bazı düşük kodlama puanlı paketlerin
puanı yükseltilebilmektedir. ')(9* :3;=< ; 4>(9*
:3;?< seçilmesi durumunda, son kullanıcı’nın
işaretlediği paketlerin kod puanı arttırılmaz.
4. SINAMA ORTAMININ DETAYLARI
Sayısal ve görsel sonuçların elde edilebilmesi
için, ns-2.1b6 [5] simülatör’ü ve üzerine
yazılmış diffserv modülü [6] kullanıldı. Simülatör’ün kodunda bazı değişiklikler yaparak,
H263+ kodlayıcı/çözücüsü [9], [10] ile birlikte çalışabilmesi sağlandı. Böylece kaybolan paketlerin neden olduğu görsel etkiyi
gözlemlemenin mümkün olduğu bir sınama ortamı hazırlanmış oldu. Bu sınama ortamı 3
parçadan oluşmaktadır(Şekil 6).
4.1 Kodlayıcı & Trafik Yaratıcı
Sistemin ilk ayağı olan bu parçada University
of British Columbia’nın H263+ kodalyıcısı kullanılmaktadır. Ham video olarak QCIF(176 @
144) formatı kullanılmıştır.
Trafik yaratıcı (şekil 6’da UDP paketleyicisi),
video bit katarını, ağ üzerinden gönderilmek
üzere UDP paketlerine çeviren bölümdür. 22
bit’lik PSC(Picture Start Code=Resim Başlama
Kodu)’ye bakarak çerçevelerin intra veya inter oluşuna göre yüksek veya daha düşük
öncelik “kodlama puanı” verir. Paketler arası
geçen zaman, paket boyu ve pakete verilen “kodlama puanı” bilgilerini ns-2 “giriş
trafiği iz dosyasına” (input traffic trace file)
yazar(örneğin “foreman.ns”). Her paket için
toplam AB@CA#2D*,E3F byte veri yazılmaktadır.
Simülatörde gerçek video bilgisi ağ paketlerinde gitmemektedir, simülasyonun yapılabilmesi için sadece paketin uzunluğu ve iki
paket arasında geçen zaman bilgisi yeterlidir. Bu yüzden kod çözücü tarafına kaybolmadan ulaşan paketlerde sıkıştırılmış video
bilgisi yoktur, sadece paket’in ağ’daki yolculuğuna ait bilgiler taşınmaktadır. Bu yüzden
kaynak tarafındaki sıkıştırılmış video bilgisine
doğrudan erişmek gerekmektedir.
NS -2’ YE AIT “ ÇIKIŞ IZ DOSYASI ” NDAN ALINTI
SATIRLAR
r
+
r
+
-
0.925333
0.925333
0.925333
0.925385
0.925385
0.925667
4
0
0
3
4
4
7
2
2
4
7
7
cbr
cbr
cbr
udp
udp
udp
1000
1000
1000
324
324
324
————————————-
0
0
0
0
0
0
0.0
0.0
0.0
1.0
1.0
1.0
7.0
7.0
7.0
7.1
7.1
7.1
338
347
347
11
11
11
349
359
359
352
352
352
4.2 Simülatör
Bu aşamada değiştirilmiş ns-2 simülatör’ü
bir önceki adımda çıkarılan “giriş trafiği iz
dosyası”nı Şekil 1’deki “kaynak2”ye ait trafik
olarak kullanarak, “kaynak1” ve “kaynak3”e de
CBR bir trafik atayarak simülasyonu yapmaktadır.
Simülatör’ün çıkarttığı “çıkış iz dosyasında”
paketlerin yönlendiriciler arası seyahatleri ile
ilgili zamanlama bilgisi (yönlendiricilere varmaları, sıraya sokulmaları, sıralarının gelme zamanı), orijinal kaynak/varış yönlendiricileri bilgisi ve bağlantı bazında özebir(unique) paket
numaraları gibi bilgiler, bu dosya içinde yer almaktadır (Tablo 3). Tablo 3’da yer alan paket
bilgileri ile ilgili açıklamalar aşağıda verilmiştir.
$n her satırdaki n’inci alana karşılık gelmektedir.
G ($1) (r,+,-) paket’in alındığı(receive), sıraya
konduğu(+), veya sırasının geldiği(-) bilgisi
G ($2) 1.de belirtilen olayın gerçekleşme zamanı
G ($3)($4) 1.de belirtilen olayın gerçekleştiği
kaynak ve varış yönlendirici numaraları
G ($5) kullanılan agent’ın adı
G ($6) paketin boyu
G ($8) IPv6 için akış no’su
G ($9) paketin esas kaynak yönlendirici no’su .
ilgili bağlantı kapısı
G ($10) paketin esas varış yönlendirici no’su .
ilgili bağlantı kapısı
G ($11) bağlantı bazında, özebir paket numarası
G ($12) bütün simülasyon için özebir paket numarası
Bu dosya üzerinde çalışan bir “trafik gözleyici”,
Şekil 1’ deki “kaynak2”den “hedef1”e giden
bütün trafiği gözler, ve buraya ulaşan paketleri
kaydeder (örneğin temp.p1)
Simülasyonda kullanılan kenar ve çekirdek
yönlendiricilerde RED(Random Early Detection) Sıraları [7] kullanılmıştır. Sadece bir
servis sınıfına ait paketler için simülasyonlar
yapılmıştır. Dolayısıyla fiziksel olarak sadece
bir tane RED Sırası ve bunun içinde sanal 3
tane RED Sırası (kırmızı, sarı ve yeşil için)
düşünülmüştür
4.3 Zamanlayıcı & Kod Çözücü
TABLO 4
K AYNAKLAR TARAFINDAN
ÜRETILEN TRAFIK
type
rate
CIR CBS PIR PBS
(kbps) (kbps) (byte) (kbps) (byte)
JLK
200
0
0
0
0
JNM J OK K CBR
VBR 86.826(avg) 56 8000 100 4000
TABLO 5
86.826 KBPS VBR VIDEO KAYNA ĞI IÇIN
SIM ÜLASYON SONUÇLARI . CIR=56 KBPS , PIR=100
KBPS , CBS=8000 BYTE , PBS=4000 BYTE
kaynak2
kenar yön.
hedef1
Sim. kod
Burada çalışan multi-threaded bir uygulama
puan (bps) (byte)
(byte)
(bps) (byte)
sayesinde gerçek zamanda bir yandan “trafik
AF11
0
0
112166
54198 108396
0
0
36111
5250.5 10507
1 AF12
gözleyicinin” çıkardığı dosyadaki paketler ile
AF13 86826.5 173653 22895
500
1000
orijinal sıkıştırılmış video dosyası arasında
AF11 85586 171172 118332
55981 111962
0
0
50192
11184
2 AF12
karşılaştırma yapar, ve bir yandan da “video
AF13 1440.5 2481
2648
0
0
yastığına”da birikmiş H263+ videosunun koAF11 45842 91684 113448
54825 109653
0
0
45317
4903
9806
3 AF12
dunu çözüp, gösterir(Şekil 6). Karşılaştırma
AF13 40984.5 81969
12407
389.5
779
AF11 86236 172472 118322 55306.5 110613
sırasında, ancak ağ üzerinden başarı ile geçmiş
0
0
49423
3791.5 7583
4 AF12
video bilgisinin, kod çözücünün erişebileceği
AF13 590.5
1181
3427
389.5
779
“video yastığına” girmesini izin verilmektedir.
Bu sayede de ağ üzerindeki kayıplardan dolayı
oluşan performans azalması, görsel olarak [13].
Simülasyonlarda aynı video katarı, a) ölgözlemlenebilmektedir.
çeklenmemiş b) kısmen ölçeklenmiş olarak
5. SONUÇLAR
iki farklı modda işaretlenip gönderilmektedir.
Bölüm 4’te anlatılan sınama ortamı kul- ‘ölçeklenmemiş’ video’da intra/inter çerçeve
lanılarak yapılan bütün simülasyonlarda Şe- ayrımı yapılmadan sadece CIR oranı göz önüne
kil 7’deki ağ yapısı kullanılmıştır.
Bu alınarak son kullanıcı tarafından AF11 veya
Fakat ’kısmen
şekildeki trafik kaynaklarının özellikleri de AF13 işaretlemesi yapılır.
ölçekleme’
modunda,
CIR=56
kbps sınırları
Tablo 4’de verilmiştir. Tablo 4’deki VBR kaynaklar 25 çerçeve/sn. oranıyla kodlanmış, 16 içinde kalmak koşuluyla, bütün intra çerçeveler
saniyelik (400 çerçeveden oluşan) sıkıştırılmış AF11 ve inter çerçeveler AF13 ile işaretlenH.263+ video katarına karşılık gelmektedir. mektedir. Bu method ile sıkışık bir diffTablo
4’deki trafik kaynaklarından sadece serv ağ’ında AF13 ile işaretlenen çerçevelerin
H3I
’den gönderilen video, alıcı tarafından bölüm çoğu hedeflerine ulaşamayacaklar, fakat AF11
4.3’te anlatılan ‘Kod Çözücü’ye sokulmaktadır. işaretlenen intralar ulaştığı için görüntü her
Diğer video’lar sadece VBR karakterinde bir ulaşan intra çerçeve ile düzelecektir. Bu da
arka plan trafiği yaratmak için kullanılmıştır. ulaşan çerçeve sayısına göre izlenen video’nun
Sıkıştırılmış video’larda herhangi ‘katmanlı’ zaman içinde ölçeklenmiş (temporally scaled)
(layered) bir yapı kullanılmamıştır ve video olmasını sağlayacaktır. ‘kısmen ölçeklenmiş’
kaynaklarımız ölçeklenemektedir (scalability) videoda olduğundan daha fazla çerçeve kaybına
(bkz Annex O, N [12]).
Ölçeklenebilir dayanıklı sıkıştırma ve ışaretleme çalışmaları
H.263+ performansının detaylı olarak ince- [13]’da verilmiştir.
lendiği çalışmalar şu anda devam etmektedir
Simülasyon 1 ve 2’de ‘ölçeklenmemiş’ video
35
missing
received
average
30
25
PSNR(db)
P
20
15
10
5
0
0
50
100
150
200
frame no (25 fps)
250
300
350
400
(a) Simulation 1
35
missing
received
average
30
25
PSNR(db)
P
20
15
10
5
0
0
50
100
150
200
frame no (25 fps)
250
300
350
400
(b) Simulation 2
35
missing
received
average
30
25
PSNR(db)
P
20
15
10
5
0
0
50
100
150
200
frame no (25 fps)
250
300
350
400
(c) Simulation 3
35
missing
received
average
30
25
PSNR(db)
P
20
15
10
5
0
0
50
100
150
200
frame no (25 fps)
250
300
350
400
(d) Simulation 4
Şekil 4. Simülasyonlar için PSNR grafikleri
kullanılmıştır. Tablo 5’de gönderilen, işaretlenen
ve ulaşan video oranı/toplam veri bilgileri
görülmektedir.
Simülasyon1’de son kullanıcı bütün çerçeveleri, herhangi bir ‘katman’ (layer) tanımı olmadığı için AF13 ile
kodlamıştır. ‘Kenar Yönlendirici’ gelen katarı
CIR=56 kbps olacak şekilde bazı paketleri Tablo 2’deki algoritmaya göre AF11’e
yükseltmiştir. Simülasyon2’de ise son kullanıcı, satin aldığı CIR=56 kbps’in üzerinde
(86.8265 kbps) AF11 paket işaretlemiştir. Bu
durumda ‘kenar yönlendirici’ bazı paketleri,
yine Tablo 2’deki algoritmaya göre, CIR 56
kbps olacak şekilde tekrar işaretler. Simülasyon
1 ve 2’de, video katarlarında herhangi bir katman tanımı ve Diffserv ile korunan bir katman
olmadığı için performans farkı olmamaktadır
Şekil 4(a)-(b). Yani satın aldığı orana uyan ve
uymayan kullanıcı aynı etkiyi yaşamaktadır.
Simülasyon 3 ve 4’de ‘kısmen ölçeklenmiş’
video kullanılmıştır. Simülasyon 3’te 45.842
kbps’in içine intra çerçevelerin oluşturduğu katman ve rastgele seçilen bazı inter çerçeveler
konmuştur.
Kenar yönlendirici CIR 56
kbps olacak şekilde AF11 işaretlenen paketlerin sayısını Tablo 2’deki algoritmaya göre
artırmıştır (113448 byte
56.7 kbps). Son
kullanıcı anlaşmasının koşullarına uyduğu için
belirlediği paketler(intra’lar), sıkışık bir ağ’da
bile, çok büyük bir oranla hedef’e ulaşabilmiştir.
Fakat Simülasyon4’te anlaşma kurallarına uymayan kullanıcı, ödediği oranın (CIR=56
kbps) üzerinde (86.235 kbps) AF11 trafiği
göndermiştir. Bu durumda önemli paketler
(intra’lar) bile ‘kenar yönlendirici’ tarafından
AF13’e düşürülmektedir. Bu da, bu tip kullanıcıların diğerlerinden daha kötü bir QoS almalarını sağlamaktadıri Şekil 4(c)-(d).
Sonuçları görsel olarak değerlendirmek için
Şekil 5’deki birbirine karşılık gelen çerçeveler
karşılaştırılabilir.
En iyi sonuçlar ‘kısmen
ölçeklenebilir’ katmanlı video’da, anlaşma kurallarına uyulması durumunda elde edilmiştir.
Daha gelişmiş ve kayıplara daha dayanıklı,
Ölçeklenebilir video kodlayıcılarının yaratılan
sınama ortamında kullanılması gelecek çalışma-
lara bırakılmıştır.
[8]
[9]
[10]
[11]
(a) 253
(b) 264
(c) 278
[12]
[13]
(d) 253
(e) 264
(f) 279
(g) 253
(h) 264
(i) 275
(j) 253
(k) 264
(l) 277
Şekil 5. a,b,c Simülasyon 1’in, d,e,f Simülasyon 2’nin,
g,h,i Simülasyon 3’ün, ve j,k,l Simülasyon 4’ün
sonuçlarıdır.
REFERANSLAR
[1]
[2]
[3]
[4]
[5]
[6]
[7]
RFC2474, “Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers”
RFC2475, “An Architecture for Differentiated Services”
RFC2597, “Assured forwarding PHB Group”
RFC2698, “A Two Rate Three Color Marker”
Network Simulator ns-2 “http://www.isi.edu/nsnam/ns/”
Diffserv
Model
for
the
NS2
“http://www7.nortel.com:8080/CTL/”
S. FLoyd, V.Jacobson, “Random Early Detection Gateways for Congestion Avoidance”, IEEE/ACM Transactions on Networking, Volume 1, Number 4, August 1993,
pp. 397-413.
D. Clark, W. Fang, “Explicit Allocation of Best Effort
Packet Delivery Service” IEEE/ACM Transactions on Networking, Volume 6, Number 4, August 1998, pp. 362-373
tmn H.263+ encoder, University of British Columbia,
“http://www.ee.ubc.edu.ca”
K. Fall, K. Varadhan, “The ns Manual (formerly ns Notes and Documentation)” from
http://www.isi.edu/nsnam/ns/ns-documentation.html
tmndec-3.2.1 H.263+ decoder, The Telenor Research
TMN Software
ITU-T Recommendation H.263+, ”Video Coding for Low
Bit Rate Communication”, 1998
E. Gürses, N. Akar, G. B. Akar, ”Performance of
H.263+ Scalable Video over a Diffserv Network”,
IEEE/ICC’2002(submitted)
mfX?inXpoWV XpYlZ [\Z]_QqRlTerORlspjW[\j
QSRUTWV X?YUZ [\Z]_^a` X?b Z cedfX?` X?g Z [\Z
Alicinin Ekrani
H263+
Video Kodlayici
sikistirilmis video
UDP paketleyici
Video Yastigi
(16384 bytes)
kod cozucu
Harddisk
2048 bytes
tmndec-3.2.1
stream.263
zamanlayici
Harddisk
Paket Senkronizasyon Mod
giris trafigi
iz dosyasi
Zaman Senkronizasyon Mod
Harddisk
foreman.ns
trafik gozleyici
dosyasi
h Z ikjWV X?g Rl`
temp.p1
diffserv destekleyen
ns-2 simulatoru
Şekil 6. Sınama ortamının birimleri ve birbiri ile ilişkileri
k1 (CBR)
k3
V
k2
V
k4
V
k5
V
k6
V
kenar yonlendirici
kenar yonlendirici
2
1 Mb
5ms
3
0.5Mb
5ms
cekirdek yonlendirici
1Mb
5ms
7
hedef1
4
1Mb
5ms
k7 V
8
k8 V
hedef2
k9 V
k10 V
k11 V
Şekil 7. Simülasyonlarda kullanılan ağ topolojisi