Merhaba arkadaşlar, Quality of Service makalelerimize devam ediyoruz. Makale serimizin bu bölümünde QoS uygulama modellerinden bahsederken genel olarak, Best Effort, IntServ ve DiffServ olarak üç başlıkta incelediğimiz uygulama modellerinin avantaj ve dezavantajları hakkında bilgiler vermeye çalışacağım.

QoS uygulama yöntem ve modellerine girmeden önce, QoS uygulamalarını gerçekleştirmek için üç adımlık bir yol katmemiz gerekmektedir. Bu üç adımlık yolun sonunda uygulayacağımız modele ve kullanacağımız yönteme karar vereceğiz.


QoS uygulamaları gerçekleştirirken ilk yapılacak işlem network trafiğini incelemek, dökümante etmek ve bizim için önem taşıyan trafik tipleri için gereksinimleri belirlemek gerekir. Bu gereksinimlerden, konumuz ağırlıklı olarak ses ve görüntü üzerinde QoS olacağı için, bu trafik tipleri için bazı önemli bilgilerin altını çizmekte fayda var. Ses paketleri kayıpsız olmalıdır, karşı tarafa net bir şekilde ulaşmalıdır, gecikme az olmalıdır. Bu noktada des trafiği için önerilen 150 ms’nin altında bir delay ve %1’in altında bir paket kaybıdır. Ancak bu şekilde kaliteli bir telefon görüşmesi sağlanabilecektir.

Görüntü içinde aynı şartlardan bahsetmek mümkün. Belki biraz daha esnek olabilir ama yinede mümkün olduğunca bu rakamların üzerne çıkmayan delay ve paket kaybını sağlamak gerekecektir. Burada untulmaması gereken bu gereksinimlerin tek yön için olduğudur.

Bahsettiğimiz ses ve görüntü dışında da bizim için önemli trafikler varsa, transferinde hızın önemli olduğu trafikler varsa, bunlar ile ilgili gereksinimler tabi ki değişken olacaktır ve sizler tarafından belirlenecektir. Örneğin şirket içerisinde kullanılan ve çok yoğun bir şekilde veri akışı olan program içinde minumum delay ya da minumum paket kaybı gibi gereksinimler olabilir. Ben ağırlıklı olarak ses için görüş bildiriyor olsam da, aynı konfigürasyonlar, örneğin bir CRM ya da ERP uygulaması içinde yapılabilecektir.

Bu gereksinimlere karar verdikten sonra atılacak olan adım ise trafiğimizi tanımlamaktır. Evet biz neyin ne kadar önemli olduğuna yani hangi paket tiplerimizin ne kadar öncelikli olacağına karar verdikten sonra cihazlarımız üzerinde de bu önemi vurgulayabilmemiz için önce cihazımızın da bu trafik tiplerini ayırt edebilmesi gerekir.

Basit bir sınıflandırma şekildeki gibi yapılabilir. Ses, ERP, Mail-Web ve P2P paketleri ayrı sınıflara alınmıştır. Tabi ki daha birçok farklı trafik tipi olacaktır. Bu sadece bir örnek olmasına rağmen şunu da şimdiden belirtmek isterim ki, bizim herhangi bir sınıfa dahil etmediğimiz paketler “class-default” adında ki bir sınıfa otomatik olarak dahil olurlar.

Trafik sınıflarımızı oluşturmak için access-listlerden faydalanabilir. Örneğin belirli portları kullanarak çalışan bir uygulama access-list ile kolaylıkla tanımlanabilecektir. Hatta burada belir ip subnetleri için policy belirleme gibi bir opsiyonumzda olacaktır. (Aklımıza hemen internet bağlantısının büyük bir bölümünü ken ip adresimize rezerve etmek gelmemeli : -) )

Bunun yanında daha sonra detaylı olarak bahsedeceğimiz NBAR’da (Network-Based Application Recognition) sıklıkla kullanılmaktadır. Paketlerimizi Application Layer’da tanımlama imkanı sağlayan NBAR bizlere bir çok kolaylık sağlayacaktır. Trafik sınıflandırma işlemlerinden, daha sonra takip edeceğiniz teknik makalelerde de faydalı olacağını düşündüğüm için makaleler boyunca “Classification”, işaretleme işlemlerinden ise “Marking” olarak bahsedeceğim

Şu an komutların ne olduğuyla fazla ilgilenmeden, örnekte de görebileceğiniz gibi NBAR sayesinde ses paketlerini direkt olarak router’a gösterebilmekteyim.

Sınıflandırma işlemini, çeşitli yöntemlerden birini kullandıktan sonra son olarak yapılacak işlem, bu trafik tipleri için policyleri belirlemek olacaktır. Bu policyler örnek olarak;

1. Minumum bandwidth belirleme
2. Maximum bandwidth belirleme
3. Sıkıştırma
4. Priority verme

gibi rule’lardan oluşabilir.

Bütün bu sınıflandırma ve policy belirleme işlemlerini eskiden interface bazlı yapılan konfigürasyonların yerini alan ve çok daha kolay tasarlanabilen MQC (Modular QoS Command Line Interface) ve SDM (Security Device Manager) kullanarak yapacağız. (Komut satırında kullanabileceğimiz, özellikle ses trafiği için tasarlanmış AutoQoS komutundan da makalelerimiz içerisinde bahsedeceğiz.)

Module QoS, interfacelerden bağımsız olarak sınıflan oluşturmamıza, bu sınıflar için policyler belirlememize olanak sağladığı için, çok geniş planlanan QoS konfigürasyonları ciddi bir şekilde kolaylaşktırmaktadır. Bütün konfigürasyonlar Global Konfigürasyon modundan başlayarak yapılır ve en sonunda istediğimiz interfacelere uygulanır. Aynı sınıflar birden fazla policy içerisinde kullanılabilir. Aynı policyler birden fazla interface için çalıştırılabilir. Ve hatta policy içerisinde başka policyler çalıştırılabilir. Bütün bu esneklikler ile Modular QoS CLI hepimiz için faydalı olacaktır.

Best Effort için kısaca QoS’in olmadığı durum diyebiliriz. Trafik tipleri için herhangi bir tanımlama ya da policy yoktur. Defaul olarak bütün networkler bu model ile çalışır. Best Effort modeli, mektup gönderme işlemlerine benzetebiliriz. Artık kullanmıyor olsakta mektup yazma dönemini yaşayan arkadaşlar olmuştur. Bir mektubu herhangi bir posta idaresine teslim ettiğinizde, sizin gibi mektup göndermek isteyen bir çok kişinin mektubu ile aynı muameleyi görür.Servis garantisi yoktur, tam olarak gittiği zaman gittiğini anlayabilirsiniz, bu süre bazen 3 gün bazen 1 hafta olabilir. Hatta mektubunuz yolda kaybolsa bile bunun farkına varmazsınız. Gittiyse gitmiştir.

Best Effort modelde bütün trafikler, aynı posta idaresindeki mektuplar gibidir. İmkanlar dahilinde hedefe gönderilir. Bir paketin ses paketi yada P2P bir uygulamaya ait bir paket olması pek birşey ifade etmez. Paket hedefe ulaşmışsa, ulaşmıştır.

Bir başka yöntem olan IntServ ise, mektubu, özel bir kurye ile göndermek gibidir diyebiliriz. Mektup mutlaka ve sizin istediğiniz zamanda hedefine ulaşacaktır. Paketler için bu böyledir. Kaynaktan hedefe kadar olan bütün hoplar boyunca, gönderilecek paketler için bandwidh reserve edilir ve sonuçta delay, paket kaybı gibi sorunlar yaşanmadan paketler hedefe ulaştırılır.

Path boyunca her hop üzerinde bandwidthin reserve edilme zorunluluğundan dolayı çok kullanılmamaktadır. Routerlardan birisi gereksinimleri sağlayamazsa, uygulamalar data transferini başlatmayacaktır. Buna karşın, bandwith ve delay her zaman istenen seviyede olabileceği için son derece kesin çözümler sunabilmektedir.

Bandwidth reservasyonu RSVP (Resource Reservation Protocol) ile sağlanır.

Bu protokol ile birlikte uygulamalar ve routerlar arasında gönderilen mesajlar yardımıyla rezervasyon işlemi tamamlanır. Routerlardan herhangi biri gerekli gereksinimleri sağlayamaz ise Notification mesajı gönderecek ve data transfer edilemeyecektir. Data transferi sağlandıktan sonra RSVP TearDowb mesajı ile kaynaklar servest bırakılır.

Best Effort ve IntServ üzerinde, asıl konumuz DiffServ olacağı iin fazla durmadan yolumuza devam ediyoruz.

DiffServ ile paketleri sınıflandırırız, daha da önemli ve faydalı olan paketleri daha sonra tanınmak üzere işaretleriz ve her hop için ayrı ayrı policylerimiz belirleriz. Her paket tipi için farklı policyler berlirleyebilme imkanını bize sağladığı için bir hayli esnektir. Burada paketleri işaretlemek için IPv4 headerlarında ToS (Type of Service) alanını kullanacağız. 8 bitlik bu alan bize, IP Precedence ve DSCP olmak üzere, birbiri ile uyumlu iki farklı işaretleme yöntemi sağlamaktadır. Bu yöntemlerden daha sonra detaylı bahsedeceğiz.

Subnetting sevmeyenler için, bitler ile yine çalışacağız hatırlatmasınıda buradan yapmak isterim :- )

Bu alana bağlı olan IP Precedence ya da DSCP değerleri defaul olarak 0’dır.

Evet arkadaşlar makale serimizin bu bölümünde kısaca QoS uygulama model ve yöntemlerinden bahsettik. Bundan sonraki makalelerimiz DiffServ modeli üzerinde kurulu olacak. Bundan sonraki makalemizde Classification’dan yani paketlerimizi nasıl sınıflandırabileceğimizden bahsederek yolumuza devam edeceğiz. Herkese iyi çalışmalar.