IPv6 BAŞLIĞINDA BULUNAN AKIŞ ETİKETİ ALANININ KULLANIM YAKLAŞIMLARI

IPv6 BAŞLIĞINDA BULUNAN AKIŞ ETİKETİ ALANININ KULLANIM YAKLAŞIMLARI Sadettin DEMİR İbrahim ÖZÇELİK Özet İnternet mimarisinin ilk oluşmaya başladığı yıllarda ilk ve önemli amaç, verilerin paket anahtarlamalı ağlar üzerinde iletilmesiydi. Günümüzde internet teknolojisinin gelişmesiyle VOIP, IPTV ve video konferans gibi gerçek zamanlı uygulamalar arttıkça bu mimari yetersiz gelmeye başlamış ve QoS desteği için çeşitli yöntemler geliştirilmiştir. IPv6 ise başlığında bulundurmuş olduğu Akış Etiketi (Flow Label) alanı ile yeni bir yaklaşım getirmiştir. IPv6 için yetkili kurum olan IETF, bu alanın kullanımıyla ilgili kesin kurallar tanımlamamıştır. Bu alanın kullanımı ile ilgili sadece yaklaşımlar mevcuttur. Bu çalışma IPv6 başlığında bulunan Akış Etiketi alanının QoS desteği için kullanım yaklaşımlarını açıklamak amacıyla yapılmıştır. Anahtar Kelimeler Akış Etiketi, IPv6, Servis Kalitesi Abstract When the architecture of the Internet began to emerge in the first and important objective was the transmission of the data on the packet switched networks. Today, after the development of Internet technology, VoIP, real-time applications such as IPTV and video-conferencing increases, it started to become poor and QoS architecture to support a variety of methods have been developed. IPv6 which has the Flow Label header has brought a new approach to the field. IETF which is the authorized body of the IPv6 has not been described strict rules regarding the use of this field. This field is only available in the user approaches. This study is to explain the use of QoS approaches in the header of the IPv6 Flow Label field. Key Words Flow Label, IPv6, Quality of Service I. GİRİŞ İnternet mimarisi paket anahtarlamalı ağlar üzerinde best effort tabir edilen, ilk gelen ilk servis alır mantığı ile oluşturulmuştur ve paketlerin önceliklendirilmesi söz konusu değildir. Bu ağların tasarımında gecikme (delay), geçikme süresi (latency), bandgenişliği (bandwidth) ve seğirme (jitter) gibi faktörlerin önceliği bulunmamaktadır[1]. O yıllardaki uygulamalarda öncelik, verinin hangi koşulda olursa olsun iletilmesiydi. İnternet S. Demir. Süleyman Demirel Üniversitesi Enformatik Bölümü Ertokuş Bey Derslikleri Doğu Kampüs, 32260 Isparta, Telefon: 0246 2113500 e-posta: sadettin@sdu.edu.tr. İ. Özçelik, Sakarya Üniversitesi Mühendislik Fakültesi Bilgisayar Mühendisliği Bölümü Esentepe Kampüsü 54187 Adapazarı / Sakarya Telefon: 0264 2955891 e-posta: ozcelik@sakarya.edu.tr. teknolojileri ve uygulamalarının gelişmesiyle, kullanıcı verinin hangi koşulda olursa olsun iletilmesiydi. İnternet teknolojileri ve uygulamalarının gelişmesiyle, kullanıcı ihtiyaçları da değişmiştir. Günümüz teknolojisine bakıldığında, internet üzerindeki en dikkat çekici gelişmelerden biri gerçek zamanlı uygulamalar üzerinde olmuştur ve bu uygulamalar internet mimarisinin doğasında bulunmayan zaman parametrelerinin öne çıkmasına neden olmuştur. Böylece servis kalitesi (Quality of Service) terimi anlam kazanmaya başlamıştır. Servisler, verilerinin belirli zaman aralıklarında alıcıya ulaşmasını istemektedirler ve mevcut teknolojiler bu istekleri karşılamakta her geçen gün yetersiz kalmaktadırlar. Bundan dolayı ihtiyaçlar doğrultusunda, yani servislerin talep ettikleri önceliklendirme ve servis kalitesi konusunda yeni teknolojiler geliştirilmeye başlanmıştır. Bu teknolojilerden biri de IPv6 teknolojisidir. IPv6 teknolojisi, IPv4 adres uzayının yetersizliğini ortadan kaldıran bir teknoloji gibi görünse de, getirmiş olduğu yenilikler sadece bununla sınırlı değildir. Ölçeklenebilir ve güvenli bir protokol olması, adres ataması işlemlerini otomatikleştirdiği için cihazların Plug and Play yani tak-çalıştır mantığıyla internete bağlanmasına imkan vermesi, her bir paketin bir yönlendiriciyi geçtiği her anda yapılan IPv4 başlık bilgisi hata kontrolünün (checksum) kaldırılması ve daha esnek başlık yapısı gibi nedenlerden dolayı her geçen gün IPv4 teknolojisinin yerini almaya başlamıştır [2]. Bundan dolayıdır ki Sonraki Nesil Ağlar (Next Generation Networks-NGN) IPv6 tabanlıdır[3]. Servis kalitesi açısından değerlendirildiğinde ise IPv4 başlık yapısında bulunan Servis Tipi (Type of Service) alanı işlevsellik açısından korunarak IPv6 başlık yapısında Trafik Sınıfı (Traffic Class) olarak yerini almıştır. Bunun yanında gecikme parametreleri gibi birçok parametreyi daha da geliştiren Akış Etiketi (flow label) alanı IPv6 başlık yapısında ilk defa kullanılmaya başlanmıştır[4]. 20 bit uzunluğunda olan bu alanın içeriği için taslak yaklaşımlar mevcut olsa da henüz tam olarak tanımlanmamıştır. Bu çalışmanın 2. bölümünde IPv6 gibi ağ katmanı çözümleri açıklanacak, 3. bölümde ise IPv6 başlığında bulunan Akış Etiketi alanının kullanımıyla ilgili olarak sunulan taslaklar incelenecektir. II. MEVCUT TEKNOLOJİLER VE MİMARİLER Gerçek zamanlı uygulamaların ihtiyaç duydukları servis kalitesinin sağlanması için IP, Frame Relay, ATM, MPLS ve Ethernet gibi çeşitli protokoller ağ sistemlerine entegre edilmiştir[6]. Bunun yanında IntServ ve DiffServ gibi mimariler de geliştirilerek kullanılmıştır[7]. Frame Relay teknolojisi tıkanıklık kontrol mekanizmaları sağlamak için Forward Error Congestion 63

ULUSAL IPv6 KONFERANSI 2011 Notification (FECN), Backward Error Congestion Notification (BECN) ve Discard Eligible (DE) bitlerini kullanırken[8][10], ATM ise QoS desteği için zengin özelliklere sahiptir. ATM servis mimarisi, alanı trafiği sınıflandırırken, sonraki 4 bit ise sınıflandırılmış trafiği karakterize eden QoS parametreleri için ayrılmış olmasına rağmen bu bitlerin tamamını aynı anda kullanamaz. Burada en önemli sorun bu parametreleri ifade eden bitlerin sadece bir tanesi set edilebilmektedir. Dolayısıyla IPv4 başlığında bulunan QoS parametreleri sağlıklı bir şekilde çalışmamaktadır veya sağlıklı sonuçlar doğurmamaktadır. Bundan dolayı bu konudaki eksikliği gidermek adına IntServ ve DiffServ gibi mimariler geliştirilmiştir. 000 (0) Routine 001 (1) - Priority 010 (2) Immediate 011 (3) - Flash 100 (4) Flash Override 101 (5) - Critical 110 (6) Internetwork 111 (7) - Network Control Control Şekil 2. IPv4 ToS alanı ve Presedence değerlerinin anlamları[9] Şekil 1. IPv4 ve IPv6 başlık yapıları [5] bağlantı kurulumu sırasında talep edilebilecek altı farklı hizmet sınıflandırması tanımlar[11]. Ethernet teknolojisinde ise 802.1Q standardı çerçeve içerisine 3 bitlik Öncelik (Priority) alanı ekleyerek QoS desteği sağlamaya çalışır. MPLS teknolojisinde ise paket başlıkları ağa giriş noktasında etiketlenir. Böylece ağ içerisinde yer alan yönlendiricilerin paket başlıklarını işlemesi yerine işlem maliyeti açısından daha etkin olan etiket anahtarlama süreçleri devreye girer ki bu da basit, hızlı ve ölçeklenebilir bir ağ anlamına gelmektedir[8]. Bu da servis kalitesinin iyileştirilmesi olarak kullanıcıya dönmektedir. Bu çözümler OSI modelinin 2. katmanında veya 2. ile 3. katman arasında çalışan donanım tabanlı yaklaşımlardır. Bundan sonra açıklanacak olan teknolojiler ise IPv6 gibi 3. katman yaklaşımlarıdır ve fonksiyonellik olarak benzerlik gösteren teknolojilerdir. A. IPv4 Protokolü IPv4 protokol özellikleri RFC791 belgesinde tanımlanmıştır. Aslında IPv4 protokolü trafik akışını protokol, kaynak ve hedef portu, kaynak ve hedef adresi gibi verilere dayanarak sınıflayabilmektedir. Bunun yanında başlıkta bulunan ToS alanındaki IP öncelik (IP Precedence) bitlerini kullanarak da trafiği sınıflayabilmektedir[8]. IPv4 başlığında bulunan Servis Tipi (Type of Service) alanı Servis Sınıflarının (Class of Service-CoS) ayırt edilmesini sağlar. Böylece ağ üzerinde akmakta olan veri trafiğini sınıflara ayırarak, farklı sınıflara ait servislerin kendilerine özgü servis kalitesinin sunulmasında bir yöntem oluşturmuş olur. IPv4 başlık yapısında 3 bit ile ifade edilen Precedence B. IntServ IntServ, internet üzerindeki gerçek zamanlı ve gerçek zamanlı olmayan IP servislerinin desteklenmesi ve bunların ihtiyaçları olan QoS ihtiyaçlarının sağlanması amacıyla IETF Integrated Services Working Group tarafından önerilmiştir. IntServ mimarisi, geleneksel internet mimarisi üzerinde çalışmakta olan gerçek zamanlı ve gerçek zamanlı olmayan uygulamaların artan ihtiyaçlarını karşılamak için bir ilave yöntem önermektedir. IntServ mimarisi temelde iki olmak üzere toplamda üç servis sınıfı tanımlar. Bunlar; garanti edilen servisler, kontrollü yük servisleri ve best effort servislerdir. IntServ modelinde uygulama gereksinimleri, veriler ortama aktarılmadan önce kontrol edilir. Uygulama kendi karakteristiğini ağa bildirir ve bant genişliği, gecikme vb. gereksinimlerini karşılayacak derecede kaynak ayarlanmasını ister. Kenar yönlendiriciler ağ üzerinde bu gereksinimlerin karşılanacağı onayını almadan verileri ortama aktarmaz. Onay aldıktan sonra uygulama profilinde tanımlanmış ihtiyaçlar doğrultusunda verileri ortama aktarır. C. DiffServ DiffServ mimarisi, internet trafiğinin gerekli QoS desteğini sağlamak için IP paketlerine her bir kullanıcı davranışını (per-hop behavior -PHB) ifade eden işaretleme kullanır [10]. Bu modelde ağa giren trafik sınıflandırılır ve ağın davranışıyla birleştirilerek işaretlenir. Bu tanımlama Differentiated-Services Codepoint (DS codepoint) ile 64

ifade edilir. Her bir DS codepoint ile ilişkilendirilen PHB ye göre paketler iletilir. DiffServ mimarisine IPv4 desteği başlık içerisindeki TOS alanında bulunan DS bitleriyle sağlanır. Bu alanda bulunan toplam sekiz bitin iki tanesi kullanılmadığı için kalan altı bit ile internet trafiği 64 farklı sınıfa ayrılabilir. IPv6 da bu destek başlık içerisinde bulunan TC alanıyla sağlanır ve kullanım yapısı TOS ile aynıdır. Şekil 3 de de gösterildiği gibi DSCP alanı 6 bitlik alanı bir bütün olarak kullanmaktadır. Bu alanın ilk 3 biti trafiği sınıflamak için kullanılırken diğer 3 bit ise sınıflandırılmış trafiğin ihtiyaç duyduğu QoS parametrelerini ifade etmektedir. Böylece IPv4 de bulunan eksiklik giderilmiştir. Servis kalitesini belirten bitlerin tamamı aynı anda ve beraberce set edilebilmektedir. getirilmemiş taslak olarak kabul edilmiştir. Bundan sonraki bölümlerde bu taslak önerilerde bulunan Akış Etiketi kullanım yaklaşımları incelenecektir. A. Conta Yaklaşımı [15] Bu taslak IPv6 Akış Etiketi tanımlamasına bir öneri sunmaktadır ve RFC2460 içerisinde belirtilmiş olan tanımlamanın değiştirilmesini önermektedir. Buna göre gerektiğinde özgün değer yol üzerindeki ilgili düğümler tarafından yenilenebilir veya devamlılığı sağlanır. Bu durum kaynak alıcıya özel bir bilgi iletmek istediğinde kesinlikle gereklidir. Bu taslağa göre eğer Akış Etiketi komşu yönlendiriciler arasındaki özel durum bilgilerini taşırsa böyle bir yetenekte olması gereklidir. Bu durumun dezavantajı ise Akış Etiketlerinin değişken olmayan yapısına karşı kompleks bir öneri olmasıdır. Taslağa göre önerilen format Şekil 4 deki gibidir. Şekil 3. IPv4 ve IPv6 başlıklarında DS bitleri [12] III. IPv6 AKIŞ ETİKETİ (FLOW LABEL) IPv6 başlık yapısı daha önceki sürümde bulunmayan ve ilk defa tanımlanan 20 bitlik Akış Etiketi (Flow Label) olarak adlandırılan bir alan içerir. Akış Etiketi alanı kullanarak yapılan trafik tanımlaması yönlendiricilere, bir akışa ait paketleri tanıma ve özel olarak işleme olanağı tanır. Bu da IPv6 tarafından gerekli olan servis kalitesinin desteklenmesi anlamına gelmektedir[13]. IPv6 başlık yapısı içerisinde trafiği etiketleyebileceğimiz iki alan bulunmaktadır. Bunlardan biri Trafik Sınıfı (Trafic Class) diğeri ise Akış Etiketi (Flow Label) alanıdır. Trafik Sınıfı alanı IPv4 başlığı içerisindeki ToS alanıyla eşdeğer olarak tanımlanmıştır. Bu alan kullanılarak trafik belirli sınıflar içerisine dahil edilebilir. Şu anda uygulanmakta olan yapıda 3 bit trafiği sınıflandırmak için kullanılmaktadır ki bu yapı ile akış 8 farklı sınıftan birine dahil edilebilir. Bunun yanındaki diğer bitler ise QoS için gerekli parametrelerin detayını sunamamakta, Şekil 2 de gösterildiği gibi sadece olup olmadıklarına dair bir bilgi içermektedir. Ancak Akış Etiketi alanı toplam 20 bitten oluşmaktadır. Bu bitlerin bir kısmı trafiği sınıflandırmak için kullanılsa bile kalan bitler QoS parametrelerini daha detaylı olarak verebilir. Bu parametrelerin sadece var olup olmadıklarını değil eğer mevcutsa tam birimlerini sunabilirler. Hatta Trafik Sınıfı alanında akış sınıflandırıldıktan sonra Akış Etiketi alanının tamamı QoS parametrelerini ifade etmek için kullanılabilir. IPv6 başlığı içerisinde bulunan 20 bitlik Akış Etiketi alanı için kesin bir tanımlama yapılmamıştır[14]. Şimdiye kadar birkaç öneri yapılmıştır ancak IETF IPv6 grubu tarafından incelenen bu öneriler standart haline Şekil 4. Conta tarafından önerilen Akış Etiketi formatı[15] Bu özel format, RFC2460 tarafından belirtilmiş olan Akış Etiketi değerinin seçimindeki rastgele sayı metodunu desteklemektedir. Bunun yanında pakete uygulanacak DiffServ desteği de sağlanmış olur. Bu taslakta IPv6 Akış Etiketi için önerilen DiffServ tanımı tartışılmaya açılmıştır. Şekil 5. Conta tarafından önerilen Akış Etiketi alanı DiffServ tanımlaması[15] Bu öneride, Per Hop Behavior Identification Code (PHB-ID) tanımlaması için 16 bit kullanılmaktadır. Bu ID seçimi sayı tabanlı bir yaklaşımdır ve RFC3140 tarafından tanımlanmıştır. Sonuç olarak bu taslaktaki yaklaşıma göre Akış Etiketi alanı kullanılarak IPv6 tarafından DiffServ desteği sağlanabilir. Şekil 5 de Res olarak gösterilen bitler gelecekte kullanılmak üzere ayrılmış bitlerdir. Conta Server Port Format Short Format Yaklaşımı[15] Conta tarafından yapılan öneride alternatif format önerileri de yapılmış ve bunlar tartışılmaya açılmıştır. Önerilen bu yöntemde ise Akış Etiketi alanında host-to-host protokol tipi ve host-to-host başlık bilgileri taşınabilir. Bunun için 65

ULUSAL IPv6 KONFERANSI 2011 önerilen format Şekil 6 da verilmiştir. Şekil 6. Conta tarafından önerilen Server Port Format Short Format yapısı [15] Bu yapıda gösterilmiş olan Server Port Number alanı istemci/sunucu uygulamalarında uygulamanın türünün belirlenmesini sağlayan ve sunucu tarafından atanan port numarasıdır. Bu değer kullanılarak uygulamanın ihtiyacı olan QoS karakteristikleri belirlenebilir. H-to-H protocol alanı ise TCP, UDP veya gerektiğinde başka protokollerde olabilmekte ve host-to-host protokol belirteci olarak kullanılmaktadır. Ancak dikkat edilirse burada port numarası olarak 12 bit ayrılmıştır ve bu durumda ulaşılabilecek en büyük sayı 4096 dır ve bu sayı tüm portları ifade edememektedir. Conta Server Port Format Long Format Yaklaşımı[15] Conta tarafından yapılan bir başka öneri ise Long Format önerisidir. Bu öneride Akış Etiketi alanı içindeki ilk 16 bit istemci/sunucu uygulamalarında sunucu tarafından atanan TCP veya UDP port numarasıdır. Sonraki 3 bit, gelecek uygulamalar için ayrılmış ve son bit 0 olması durumunda TCP, 1 olması durumunda UDP portunu işaret etmektedir. Böylece Short Formatta doğan handikap ortadan kaldırılmıştır. Şekil 8. Conta tarafından önerilen Header Lenght Format yapısı [15] B. Banarjee Yaklaşımı [16] Bu taslak daha önce yapılmış çeşitli önermeler doğrultusunda Akış Etiketi alanında tanımlanmış değerlerin kullanabilirliğini değerlendirmektedir. Taslak ayrıca IPv6 QoS desteği için DiffServ gibi IntServ yaklaşımı da içeren hibrit bir yapı sunmaktadır. Bundan dolayı MultiServ adı verilen deneysel bir QoS şeması tanımlamaktadır. Bu hibrit taslakta, Akış Etiketi alanının ilk 3 biti yaklaşım tipi belirlemek için kullanılır. Kalan 17 bit ise belirlenen yaklaşım içinde diğer parçaların tanımlanması için kullanılır. Akış Etiketi alanında kalan 17 bit ise kullanıcı veya uygulama tarafından talep edilen QoS ihtiyaçlarını tanımlamak için kullanılır. Yaklaşım tipi belirlendikten sonra son 17 bitin kullanımı aşağıdaki bölümlerde açıklanmaya çalışılmıştır. Tablo1. banarjee önerı sı ne göre yaklaşım tı plerı [16] Şekil 7. Conta tarafından önerilen Server Port Format Long Format yapısı [15] Conta Header Length Format Yaklaşımı[15] Conta tarafından önerilen son yaklaşımdır. Bu yapıda Akış Etiketi içerisindeki ilk 16 bit IPv6 başlık uzunluğunu tanımlamak için kullanılmıştır. Burada başlık uzunluğu olarak yapılan tanımdan, ana başlık uzunluğu ve hostto-host veya taşıma katmanı işlemlerinden doğan uzantı başlıları toplamı kastedilmiştir. Bu öneride IPv6 başlık uzunluğu olarak belirtilen değer, kaynak ve hedef portlarını, kaynak ve hedef adreslerini host-to-host protokol tanımlamalarını belirttiği için bu değerler kullanılarak DiffServ sınıflayıcıya bilgi sağlayabilir. Ancak bu yöntemde IPv6 başlığı içerisinde Toplam Başlık Uzunluğu gibi bir alan olmadığı için ilave hesaplamalar gerektirmektedir ve bu da bir dezavantaj olarak karşımıza çıkmaktadır. 66 Default Değer Yaklaşımı[16] Bu yaklaşım uygulama veya son kullanıcının ağdan herhangi bir QoS isteği olmadığı zaman uygulanan yaklaşımdır. Akış Etiket alanının değeri 0 olarak ayarlanır ve işlem sırasında herhangi bir talep dikkate alınmaz. Rastgele Sayı Yaklaşımı[16] Bu yaklaşımda ise, pseudo-random olarak üretilen bir sayının kullanımı tanımlanır. Bu üretilen değer trafik akışını etiketlemek için kullanılan değerdir ve aynı zamanda Akış Etiketi alanı içerisindeki 20 bitin sayısal değeridir. Akış Etiketi alanı için bu rastgele üretilen sayının sayısal değeri 1 ile 1FFFF arasında herhangi bir sayı olabilir. Şekil 9. Banarjee tarafından önerilen Rastgele Sayı Yaklaşımı yapısı [16]

Eğer bu yaklaşım IntServ modeli destekliyorsa ancak o zaman üretilmiş olan bu rastgele sayının bir anlamı olacaktır. Öngörülemez bir değer değişimi olarak karşımıza çıkan bu sayılar deterministik yapıdaki ağlar için anlam ifade etmeyecektir. Ancak IntServ modeli yaklaşımda bulunan bilimsel çalışmalarda kendine yer bulmuştur[17]. Hop-by-Hop Genişletilmiş Başlık Yaklaşımı[16] Bu yaklaşım, QoS gereksinimlerini belirlemek için hopby-hop genişletilmiş başlık yapısının kullanımını tanımlar. Şekil 10. Banarjee tarafından önerilen Hop-by-Hop Genişletilmiş Başlık Yaklaşımı yapısı [16] Bu yaklaşımda, QoS ihtiyaçlarının belirlenmesinde kullanılmak üzere değerler içeren modifiye edilmiş hopby-hop genişletilmiş bir başlık yapısı önerilmektedir. Aynı zamanda bu yaklaşımda Akış Etiketi alanı yok sayılır. Bu yaklaşım uygulama ihtiyaçlarını belirlemede kullanılabilir yani uygulama ihtiyaçlarını direk olarak karşılamaz. Bundan dolayı önerilen başka bir yaklaşım yoksa kullanılabilir. DiffServ PHB-ID Yaklaşımı[16] Bu yaklaşım Akış Etiket alanından elde edilen değerin DiffServ PHB-ID olarak kullanımını tanımlamaktadır. Bu yaklaşımda QoS ihtiyaçlarının tanımlanması gelen Akış Etiketi değerinin DiffServ sınıflayıcı tarafından eşleştirilmesi için destek sağlar. Akış Etiketi değeri 16 bitlik PHB-ID değeri olacaktır. Son bit gelecek kullanımlar için rezerve edilmiştir. Şekil 12. Banarjee tarafından önerilen Port ve Protokol Numarası Yaklaşımı yapısı [16] Bandgenişliği, Geçikme ve Tampon İhtiyaçları Yaklaşımı[16] Bu yaklaşım bandgenişliği, gecikme, seğirme, paket kaybı ve tampon bellek ihtiyacı gibi önemli QoS parametrelerini listeler. Bu yaklaşımda seğirme ve paket kaybı değerleri uygulamalar için en az seviyede olması arzu edildiğinden Akış Etiketi alanı içerisinde tanımlı olması gerekmemektedir. Bu değerler aynı zamanda hopby-hop genişletilmiş başlık yaklaşımında da kullanılabilir. Akış Etiketi alanı değeri olarak tanımlanarak kullanılan 3 parametre aşağıdaki gibidir. Bandgenişliği (kbps katları olarak ifade edilecek) Gecikme (nanosaniye olarak ifade edilecek) Tampon gereksinimleri (byte olarak ifade edilecek) Bu taslak yaklaşımına göre Akış Etiketi alanının kullanılan 17 bitinin sonuncusu Soft Real Time ile Hard Real Time uygulamaları ayırt etmek için kullanılır. Şekil 13. Banarjee tarafından önerilen Soft Real Time Uygulamalar Yaklaşımı yapısı [16] Soft Real Time uygulamalarda QoS gereksinimlerinin tamamının karşılanmaması durumunda yine de uygulamanın yönetilebilir olmasından dolayı bu yaklaşım uygundur. Şekil 11. Banarjee tarafından önerilen DiffServ PHB-ID Yaklaşımı yapısı [16] Port Numarası ve Protokol Yaklaşımı[16] Bu yaklaşım Akış Etiketi alanı içindeki değerin port ve protokol numarası olarak kullanımını tanımlar. Bu yaklaşımda kullanılan 16 bit istemci/sunucu uygulamalarda sunucu tarafından port numarasını tanımlarken kalan son bit kullanılan protokolün TCP veya UDP olduğunu belirtir. Bu yaklaşım sadece TCP veya UDP protokolleri üzerinde operasyonlarını tanımlar. Başka bir protokol desteği yoktur. Şekil 14. Banarjee tarafından önerilen Hard Real Time Uygulamalar Yaklaşımı yapısı [16] Bu yaklaşımda ise Akış Etiketi alanında belirtilen minimum veya maksimum değerlerin tam olarak karşılanması gerekliliği vardır. Bu yaklaşımda 20 bitlik alanın 16 biti bandgenişliği, gecikme ve tampon gereksinimi gibi parametreleri belirtir. En uygulanabilir yaklaşımdır bundan dolayı bilimsel çalışmalarda baz alınarak kullanılmıştır[18]. 67

ULUSAL IPv6 KONFERANSI 2011 C. Jagadeesan Yaklaşımı [19] Bu yaklaşımda da Banarjee yaklaşımında olduğu gibi bandgenişliği, gecikme ve tampon bellek ihtiyaçları tanımlanmaktadır. Ancak bu yaklaşımda belirtilen parametreleri göstermek için Akış Etiketi alanındaki tüm bitlerin kullanımı önerilmektedir. Şekil 15. Jagadeesan tarafından önerilen Akış Etiketi alanı değerleri [19] Bu taslağa göre Akış Etiketi alanının ilk 8 biti bandgenişliği ihtiyacını tanımlamaktadır. 8 bitlik alanın ilk biti bandgenişliği değerinin maksimum mu yoksa minimum mu olarak talep edildiğini belirtir. Kalan 7 bit ise bandgenişliğinin değerini vermektedir. Sonraki 5 bit gecikme değerini ve son olarak kalan 7 bit ise tampon bellek ihtiyacını tanımlamaktadır. D. Yaklaşımların Değerlendirilmesi Bu yaklaşımlar içerisinde Conta yaklaşımı olarak incelenen taslak, kompleks yapıya sahiptir. Çünkü Akış Etiketi alanının RFC 2460 tarafından tanımlanan değişken olmayan yapısına karşı bu yaklaşım ağ üzerinde hareket ederken komşu yönlendiricilerin birbirlerine göndermek istedikleri özel bilgileri de taşıması açısından, bu alanın değişebilirliğini önerdiğinden dolayı kullanıma çok uygun değildir. Jagadeesan tarafından önerilen taslak, sınıflandırma yapmayıp sadece servis parametrelerini içermesi yani IntServ mimarisi tarzı bir yaklaşım sunmaktadır ve kullanılabilirliği konusunda literatürde uygulamasına rastlanmamıştır. Yukarıda anlatılan iki yaklaşıma karşılık Banarjee tarafından önerilen taslak en uygulanabilir yaklaşım olarak karşımıza çıkmaktadır. Özellikle hibrit bir model sunmasından dolayı hem IntServ hem de DiffServ mimarilerinin başarılı taraflarını üzerinde barındırmaktadır. Bundan dolayıdır ki Akış Etiketi kullanımı konusunda yayınlanmış makalelerde bu alanın kullanımı, Banarjee tarafından önerilmiş taslakların uygulanması şeklinde olmuştur[17][18]. Banarjee yaklaşımı literatürde başarılı bir yaklaşım olarak görmüş ve Akış Etiketi kullanımı yaklaşımlarının performans değerlendirilmesi aşamasında diğerleri göz ardı edilerek sadece bu önerinin farklı modelleri birbirleriyle karşılaştırılmıştır[20]. Bundan dolayı Akış Etiketi alanı kullanımında Banarjee yaklaşımı ileriye yönelik çalışmalarda çok daha ön planda bulunacaktır. Şekil 16. Banarjee tarafından önerilen Akış Etiketi formatlarının performansları [20] IV. SONUÇ Günümüz teknolojileri göz önüne alındığında artık internet altyapısından beklentiler değişmiştir. Gerçek zamanlı uygulamalar arttıkça QoS teriminin anlamı daha bir ön plana çıkmış ve uygulamalar için gerekli olan desteğin sağlanması için çeşitli yöntemler geliştirilmiştir. IPv6, başlık yapısında bulunan Akış Etiketi alanı ile uygulamaların ihtiyacı olan servis kalitesini karşılayabilecek durumdadır. Ancak bu alanın fonksiyonu IETF tarafından kesin olarak tanımlanmamıştır. Bundan dolayı bu alanın kullanımı ile ilgili yapılan öneriler bir standart haline getirilmemiş ve taslak olarak kalmıştır. Bu çalışma, diğer çalışmalara ışık tutması amacıyla şimdiye kadar kesin kurallar ile kullanım yapısı açıklanmamış ve sadece öneri modelleri bulunan Akış Etiketi alanının üç farklı kullanım önerisini açıklamakta ve bunlardan Banarjee yaklaşımının literatürdeki yerinin daha fazla olacağını öngörmektedir. KAYNAKLAR [1]B. Prakash, Using the 20 Bit Flow Label Field in the IPv6 Header to Indicate Desirable Quality of Service on the Internet B.E., B.M.S. College of Engineering, 2000. [2]C. Bouras, A.Gkamas, D. Primpas, K.Stomas, IPv6 deployment: Real time applications and QoS aspects Computer Communications, 2006. [3]S.Y.Ban, J.K. Choi, H.S. Kim, Efficent End to End Mechanism Using Egress Node Resourse Prediction in NGN Networks ICACT 2006. [4]L.Siregar, R.Budiarto, M.N. Omar, A.H. Rosli, Quality of Service Performance for Xcast in IPv6 Network NAv6 Centre, Universiti Sains Malasia, 2008. [5]M. E. Fiuczynski, V.K. Lam, B.N. Bershad (22.12.2010) The Design and Implementation of anipv6/ipv4 Network Address and Protocol Translator http://www.cs.princeton.edu/~mef/research/ napt/reports/usenix98/index.html [6]Alcatel Internetworking, (22.12.2010) Quality of Service, 2002, http://www.ind.alcatel.com/library/e-briefing/ebrief_qos. pdf [7]S. Hagen, IPv6 Essentials, Sebastopol, CA: O Reilly Press, 2002, pp-54-56. [8]P. Ferguson, G. Huston, Quality of Service: Delivering QoS on the Internet and in Corporate Networks New York, NY: Wiley Press, 1998, pp- 81-84. [9]Data Network Resource, (22.12.2010) http://www.rhyshaden. com/ipdgram.htm [10]W. Stallings, Data & Computer Communications, Delhi, India: Addison Wesley Longman Press, 2001, pp-71-75. [11]The ATM Forum Technical Committee, (22.12.2010) Traffic 68

Management Specification Version 4.1, AF-TM-0121.000, March 1999. ftp://ftp.atmforum.com/pub/approved-specs/af-tm-0121.000.pdf [12]Li,Y.T. (22.12.2010) DiffServ, 2003 http://www.hep.ucl.ac.uk/~ytl/qos/diffserv_01.html [13]S. Deering, R. Hinden, (22.12.2010) Internet Protocol, Version 6 (IPv6) Specification, IETF RFC. http://ietf.org/rfc/rfc2460.txt?number=2460 [14]T. Guozhen, Y. Hengwei, L. Yi, H.Ningning, QoS Provision for IPv6 Traffic Using Dynamic Packet State, Proc. of the Joint International Conference on Autonomic and Autonomous Systems and International Conference on Networking and Services, 2005. [15]A. Conta, B. Carpenter, (22.12.2010) A proposal for the IPv6 Flow Label Specification, IETF Internet Draft. 2001 http://tools.ietf.org/id/draft-conta-ipv6-flow-label-02.txt [16]R.Banerjee,,S.P. Malhotra, M. Mahaveer, (22.12.2010) A Modified Specification for use of the IPv6 Flow Label for providing efficient Quality of Service using a hybrid approach. IETF Internet Draft, 2002 http://tools.ietf.org/html/draft-banerjeeflowlabel-ipv6-qos-03 [17]I. Lee, S.Kim, A QoS Improvement Scheme for Real Time Traffic Using IPv6 Flow Labels Lecture Notes in Computer Science, Volume 3043/2004, 2004. [18]X. Tang, J. Tang, G.Huang, C. Siew, QoS Provisioning Using IPv6 Flow Label In the Internet ICICS-PCM 2003, p. 1253, 2003. [19]H.Jagadeesan, T. Singh, (22.12.2010) A Radical Approach in providing Quality-of-Service over the Internet using the 20-bit IPv6 Flow Label field, IETF Internet Draft,2002 http://tools.ietf.org/html/draft-jagadeesan-rad-approachservice-01 [20]Ahmed,E. Aazam,M. Qayyum,A. (22.12.2010) Comparison of Various IPv6 Flow Label Formats for End-To-End QoS Provisioning Center Of Research in Networks & Telecom. http://nust.academia.edu/ejazahmed/papers/147307/ Comparison_of_Various_IPv6_Flow_Label_Formats_for_End- To-End_QoS_Provisioning [21]B.Prekash Using The 20 Bit Flow Label Field in The IPv6 Graduate Thesis, Collage of Engineering, 2000 69

ULUSAL IPv6 KONFERANSI 2011 70