İnternet'te servis kalitesi

İNTERNETTE SERVİS kalitesi Nuran VAROL Bu çalışmada, İnternet üzerinde kullanılmakta olan gerçek zamanlı uygulamaların farklı servis gereksinimlerinin nasıl karşılanabildiği üzerinde durulmuştur. Bu konuda oluşturulmuş olan tümleştirilmiş servis modelleri, bu modellerin günümüze dek kullanılan ve hala kullanılmaya devam edilen en iyi çaba servis modeline göre farklılıkları incelenmiş ve bu servis modellerine neden gereksinim duyulduğu irdelenmiştir. Servis modellerini tamamlar şekilde geliştirilmiş ve bir standart haline gelmiş olan RSVP kaynak rezervasyon protokolünün yapısı ve kullanımı değerlendirilmiştir. Ayrıca RSVP ile tümleştirilmiş servislerin, birlikte gerçek zamanlı uygulamalara IP QoS'i nasıl ve hangi koşullarla sağladığı açıklanmıştır. Sonuç olarak gerçek zamanlı uygulamalara sağlanacak servis kalitesini elde etmemiz için bize sağlanan yapılar yapabildikleri ve yapamadıkları ile incelenmiş ve zayıf yanları için önerilerde bulunulmuştur. İnternet'in bugüne kadarki gelişiminde, paketlere ağ tarafından sunulan, en iyi çaba servis modeli ile hizmet verilmektedir. Alıcı, paketleri hemen işler ve geç kalan paketleri atlayıp işlemine devam eder. Gönderici de kaybolan veya ağda ilerlerken bozulan paketleri yeniden göndererek uygulamanın devamını sağlamaktadır. Ancak belirli zaman dilimi içinde alınmadığında anlamım yitiren paket trafiğinin olduğu uygulamaların gelişimi ile, yeni servis modellerine de ihtiyaç ortaya çıkmıştır; Kontrollü Yük ve Garantili Servis modelleri. Bu modeller, paket üzerinde verilecek servisler için bir taahhüt verir. Bu taahhütün yerine getirilmesi için, düğümler üzerinde rezervasyonların yapılması gerekmektedir. Bu bize, uygulama gereksinimlerinin ağ elemanlarına aktarılması, her bir düğüme rezervasyon ile ilgili parametrelerin taşınması ve isteklerin bildirilmesi için bir iletişim mekanizmasının kurulmasını gerektirir. Ayrıca veri paketlerin geçtiği yol üzerindeki düğümlerin bu isteklere cevap verebilecek destek mekanizmaya sahip olması sonucunu da ortaya çıkartmaktadır. Bunlardan birincisi kaynak rezervasyon protokolü, diğeri ise QoS kontrol servisleri ile yapılmaktadır. Gönderici uygulama, yaratacağı trafiğe ilişkin bilgileri ve uygulamanın gereksinim duyduğu QoS servis modeline ilişkin parametreleri kendi yerel RSVP sürecine bildirir. RSVP, yönlendirme protokolüne göre yönlendirilmiş paketler üzerinde rezervasyon yapılması için düğümlere bu bilgileri aktarır. Her düğüm, gelen bu bilgileri alır ve kendi üzerinde yol durum bilgilerini saklar. Bu bilgiler, gönderici uygulama tarafından tahmin edilen trafik bilgileri, bir önceki düğümün İP adresi, gönderici İP adresi, TCP/UDP gönderici iskele ve protokol kimlik numarasıdır. Düğüm, ayrıca gelen RSVP paketlerinin içinden duyurulu tekli geçiş bilgilerini çeker. Bu bilgileri günceller ve tekrar RSVP paketlerini oluşturarak bir sonraki düğüme gönderir. Alıcı uygulamaya, düğümler üzerinde yol durumu oluşturulmuş ve duyurulu tekli geçiş bilgileri güncellenmiş olarak paketler gelir. Alıcı, bu bilgileri RSVP API'yı üzerinden uygulamaya geçirir. Uygulama seçilen servis modeline bağlı olarak QoS isteğini oluşturur ve yolu tersten dolaşarak düğümlerde rezervasyonu isteğinde bulunur. Düğümler bu istekleri, kendi karar ve kabul kontrol mekanizmalarına göndererek, kaynaklar için yeterlilik ve istekte bulunan içinde yetki sorgulaması yapar. Eğer istekler, bu mekanizmalar tarafından olumlu sonuçlanır ise, düğüm sıralayıcısında QoS seviyesi belirlenir ve veri çıkış arayüzündeki sımflandırıcı da QoS gerçeklenir. Gerçekleme, gönderici uygulamaya kadar yolu tersten dolanarak sağlanır. En son gönderici uygulamaya göndermesi gereken MTU, maksimum-minimum paket boyları gibi bilgiler ulaştırılır. Gönderici-alıcı arasındaki RSVP mesajları sürekli gönderilerek, ağ üzerinde rezervasyonun kalıcı olması sağlanır. Rezervasyon geçeklemesi servis modellerinin hangisinin kullanıldığına bağlıdır. Kontrollü yük servisi, ağın yüksüz durumda sağlayacağı servis kalitesini, yüklü durumda da sağlamayı garanti eder. Dolayısı ile düğümler paketin iletim hızı, boyu, maksimum ve minimum paket boyunu bilmek ve yüklü durumda iken de bu parametreleri yüksüz koşullardaki performansı sağlayacak şekilde değiştirmelidirler. Garantili servis ise, paketin minimum gecikmesini ve band genişliğini garanti eder. Dolayısı ile düğümler kontrollü yük servisindeki gibi, yukarıda belirtilen parametleri kontrol etmenin yanı sıra minimum gecikme ve band genişliğini de bilmek zorundadır. IPv4 ve IPv6, servis modellerinin alt yapısmı desteklemektedir. Özellikle IPvö'da akış etiketi ile QoS yapısı oluşturulmuştur. RSVP'nin geniş ölçekli gerçeklemeri düşünülürken oldukça dikkatli olmak gerekir. Zira gerçeklemenin başarısını önemli ölçüde etkileyebilecek bazı eksiklik ve kısıtlamalar mevcuttur. xıTez sırasında yapılan analizler göstermiştir ki Ölçeklenebilme en kısıtlayıcı faktördür. Her bir düğümde kaynak durumlarının saklanması nedeni ile, RSVP oturumlarının sayısı arttıkça kaynak gereksinimleri de doğru orantılı olarak artacaktır. İşlem gücü, saklama alanı düğümler de yetersiz duruma gelebilecektir. RSVP mesajlarını tıkanma kayıplarından korumak için, trafik kontrol mekanizmaları, ağ üzerinde daima minimal band genişliği sağlarlar. RSVP oturumlarının sayısı arttıkça, gereken band genişliği de artacaktır. Dolayısı ile İnternet omurgası gibi trafik akışlarının çok fazla olduğu yönlendiriciler de çok sayıda rezervasyonları desteklemek kolayca tüm kaynakları doldurabilir. Trafik akışını karşılamak için özellikle omurgalar da kullanılan yönlendiricinin bazı yüksek hızlı arayüzlerinde paket sınıflama ve sıralama geçeklemesi zordur. RSVP üzerinden, kullanıcıların yetkisiz olarak kaynağı ellerinde tutmalarına neden olabilecek güvenlik açığı vardır. Mesaj bütünlüğü, mesaj güvenliğini sağlayamamaktadır. Ulaşım katmanı başlığı şifrelenerek, aradaki yönlendiricilerin veri paketlerine ilişkin iskele numaralarını görmeleri engellenebilir. Ancak şifreleme mekanizmasının, yönlendiricinin işlem gücüne getireceği maliyet dikkate alınmalıdır. Karar-kontrol verileri, RSVP dışında oluşturulur ve RSVP mesajları ile taşınır. Ancak aktarımın RSVP üzerinde yapılması nedeni ile, çok sayıda alıcı içeren bir çoklu yayın grubunda, tüm alıcılara karar verilerinin taşınması ölçekleme sorununu da beraberinde getirir. Mevcut olan yapıyı, bölgesel yetki alanlarında çalışacak olan rezervasyon kurulum sunucuları ile değiştirirsek, sözü edilen problemlere çözüm bulabiliriz. Tez çalışmasında ortaya çıkartılan bu yeni yapı ile sağlanacak avantajlar:. Rezervasyon kurulum sonucunda tutulacak durum bilgisi ile, yönlendiriciler üzerindeki yük azaltılır.. Ağın değişen durumları için oluşacak tazeleme mesajlarının, tüm düğümlere ulaştırılarak parametre kontrol ve değişikliği yerine ilgili olanına yönlendirilmesi ile trafik akışını azaltır.. Mevcut yapıda, gelecekteki bir zaman diliminde istenilen QoS'i sağlamak için, kaynaklar sürekli olarak rezerve edilir. Bu yapı hem düğümler de durum bilgisi artışına, hem de tazeleme mesajları ile trafik artışına sebep olur. Merkezi kurulum sunucuları ile istenilen zamanda rezervasyon sağlanarak kaynak israfına engel olunur.. Merkezi karar ve kabul kontrol mekanizması oluşturulur. Merkezi kurulum sunucuları, kendi küçük yönetimsel bölgelerini kontrol ederlerken, aynı zaman da kurulum sunucuları arasında haberleşme ile daha büyük ölçekli gerçeklemeler sağlanabilir.