BroadBand QoS

Broadband, XDSL tarafında uygulama iki farklı yönü ile değerlendirmek gerekiyor. İlk olarak kullanıcı hızının düzenlenmes, yani hizmet hızına uyarlanması gerekir. İkinci olarak birden fazla servis verilmesi durumunda, bu servisler arasında önceliklendirme gereklidir. Her servis için farklı bir fiziksel hat kullanımı durumunda PE-CE arasında bir qos uygulamasına genel olarak ihtiyaç olmayabilir.

TR-147 6.1 6.2 belirtildiği gibi kullanıcının bağlı olduğu cihaz, access-node (DSLAM) ve servisinin uygulandığı cihaz network-node (BNG/BRAS) aynı cihazlar değildir. Dolayısı ile kullanıcının hız bilgisinin bir şekilde BNG aktarılması gerekmektedir. Çünkü, PE->CE arasında bir önceliklendirme veya QoS için uygulanması için hattın hızının net olarak bilinmesi gerek. Bu şekilde QoS uygulamaları hatta doluluk olduğunu anlar.

Kullanıcının hız bilgisi ise aslında satın aldığı servis hızıdır. Ayrıca kullanıcı ses ve/veya IPTV gibi önceliklendirilmesi gereken servislerde almış olabilir. Eğer bu servisler farklı fiziksel bağlantı kullanmıyor ise (VPI/VCI veya tamamen farklı DSL port), bir birleri arasında önceliklendirme gerekecekdir.

Bazı kullanıcı servislerindede, örnek olarak XMb’a kadar gibii satılan hızın sabit olmadığı durumlar vardır.

Kullanıcıya satılan hız sabit veya değişken olabilir. Her iki durumdada QoS uygulaması için temel alınması gereken durum, kullanıcının fiziksel hızıdır.

• Access Node Control Protocol (ANCP) : ANCP kullanılarak Access node ve network node arasında bir iletişim kurulmuş olur. Basitce access node, network node’a kullanıcının hız bilgisini raporlar. Network Node, BRAS/BNG’de bu bilgiyi kullanarak kullanıcının hızını bildirilen değere uyarlar. Uygulama açısından Cisco IOS terimleri ile anlatırsak, BNG’ye her kullanıcı için bir in ve out policy-map gönderilir. BNG’de ANCP’den aldığı hız değerlerine göre bu söz konusu policy-map’leri düzenler.

policy-map BB_GENERIC_PARENT_DOWN

class class-default

shape average 20000000 → Bu değer ANCP ile DSLAM tarafından değiştirilebilir.

Burada dikkat edilmesi gereken, kullanılan policy-maplerde farklı classlar kullanılıyor ise burada her bir class için kullanılan hız değerlerinin percent based olarak tanımlanması gerekir. Eğer statik olarak bir değer tanımlanmış ise, kullanıcının fiziksel hızına bağlı olarak tüm sınıfların toplam hızının, kullanıcının hız değerinden büyük olma durumu ortaya çıkabilir ve bu QoS uygulama hatası olarak yansır.

policy-map BB_GENERIC_PARENT_DOWN

class class-default

shape average 4000000 → ANCP ile 4Mb bilgisi verilmiş.

service-policy BB_GENERIC_CHILD_DOWN

policy-map BB_GENERIC_CHILD_DOWN

class BB_QoS_VOIP_DOWN

police cir 256000 bc 8000

class BB_QoS_IPTV_DOWN

police cir 4000000 bc 8000

Voice + IPTV : 256K+4Mb > class default : 4Mb, dolayısı ile hata QoS uygulama hatası alınacakdır. Bu durumda ANCP değeri uygulanmaz. Bu gibi durumlara dikkat edilmelidir. Bunun için percent based QoS uygulaması önerilir.

• PPPoE dsl-sync-rate : Access Node, DSLAM, DHCP option 82 kullanımına benzer şekilde kullanıcın hız bilgisini pppoe tag’I şeklinde gönderebilir. Bu bilgi daha sonra AAA sunucusu tarafından veri tabanında alınan hız değerini düzenlemek için kullanabilir. Bu tarz bir uygulama policy server, AAA sunucusu üzerinde hesaplama yapmayı gerektirir. Cisco IOS dinamik olarak QoS uygulama özellikleri (ASR 1000 parameterized QoS) ile birlikte kullanışlı bir seçenek olabilir. Bu seçenek aynı zamanda bitstream access methodları içinde kullanılabilir (tabi access node servis sağlayııcnın, dslam tarafında pppoe tag konfigurasyonunu yapmış olması gereklidir).

Basitçe pppoe tag temelli şu şekilde bir uygulama seçilebilir. ANCP’ye göre biraz daha kontrollü ve bitstream’de desteleyen bir yapı olmuş olur. ANCP’de kullanılabiliyor ise benzer şekilde kullanılabilir. ANCP’nin loop vb giib yararlarıda kullanılmış olur.

1 – Tüm kullanıcılara tek bir template policy-map uygulanır.

2 – Veri tabanında, kullanıcının hizmet aldığı hız bilgisi ve isteniyor ise alt hız sınıfları eklenir. Bunun için Cisco IOS’in radius attributelar ile kullanıcı policy-map’ine sınıf ekleme/çıkarma veya silme özelliği kullanılabilir. Bu şekilde cihaz configleri üzerinde minumum konfig kullanılmış olur.

3 – PPPoE tagleri kullanılarak, kullanıcının fiiziksel hızı Auhentication sırasında dikkate alınır. Policy sunucu, radius, kullanıcının veri tabanındaki tanımlı hız değerlerini aldıkdan sonra bir hesaplamadan sonra uygun değerleri gönderir. Burada hesaplamanın temek amacı, kullanıcıya yanlış bir hız tanımı göndermemektedir. Basitçe şu şekilde bir hesaplama yapılabilir ;

 

Kullanıcının fiziksel hız değeri > hizmet değeri ise hizmet değerini temel al, eğer değil ise hata durumunu ele al. Hata durumunda yapılabilecekler, hata policy-map kullanmak ki bu operatöre kullanıcı session’ına bakarken kolaylık sağlar. Aynı zamanda uygulanan policy-map CDR’larda da kullanılacağı için raporlamada da kolaylık sağlayacakdır. Diğer bir seçenek ise kullanıcı bağlantı talebini reddetmek. Bu durumda operatör için neden reddildiğini göre bilmek önemlidir. Reddetmek yerine bir sayfaya redirection gibi methodlar kullanılarak kullanıcı bilgilendirilebilir. Diğer bir seçenekde kullanıcının fiziksel hızını temel almakdır. Fakat bu durumdada raporlama kısmında sorun olabilir.

Ayrıca şu kontrollde yapılmalıdır;

Kullanıcının toplam hızı > Alt sınıfların toplam hızından. Bu nedeni ise eğer alt sınıf değerleri el ile giriliyor ve percent based değil’de statik tanımlı ise sorun olabilir. Operatör yanlış değerler girmiş olabilir. Yine yukarıdaki gibi hata durumu ele alınır.

Hangi yöntem kullanılır ise kullanılsın, QoS uygulamasının raporlanması, hataların toplabilir olması önemlidir.

Bir başka önemli konuda DSL overhead hesaplanmasıdır. http://pflog.net/dsl_overhead/. En kötü %15’lik bir fazlalık vardır.