Geri Dön

İnternet'te servis kalitesi

Quality of service on the Internet

  1. Tez No: 83135
  2. Yazar: NURAN VAROL
  3. Danışmanlar: DOÇ. DR. MEHMET BÜLENT ÖRENCİK
  4. Tez Türü: Yüksek Lisans
  5. Konular: Bilgisayar Mühendisliği Bilimleri-Bilgisayar ve Kontrol, Computer Engineering and Computer Science and Control
  6. Anahtar Kelimeler: RSVP, QoS, gerçek zamanlı uygulamalar, tümleştirilmiş servisler XII, RSVP, QoS, real-time applications and integrated services XVll
  7. Yıl: 1999
  8. Dil: Türkçe
  9. Üniversite: İstanbul Teknik Üniversitesi
  10. Enstitü: Fen Bilimleri Enstitüsü
  11. Ana Bilim Dalı: Kontrol ve Bilgisayar Mühendisliği Ana Bilim Dalı
  12. Bilim Dalı: Belirtilmemiş.
  13. Sayfa Sayısı: 107

Özet

Üniversitesi : İstanbul Teknik Üniversitesi Enstitüsü : Fen Bilimleri Ana Bilim Dalı : Kontrol ve Bilgisayar Mühendisliği Programı : Kontrol ve Bilgisayar Mühendisliği Tez Danışmanı : Doç. Dr. Bülent ÖRENCİK Tez Türü ve Tarihi : Yüksek Lisans - Ocak 1999 ÖZET İ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ü (RSVP), 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 sunucunda 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.

Özet (Çeviri)

University : Istanbul Technical University Institute : Graduate School of Natural and Applied Sciences Science Program : Control and Computer Engineering Program : Control and Computer Engineering Supervisor : Assoc. Prof. Bülent ÖRENCİK Degree Awarded and Date : Master of Science - January 1999 SUMMARY QUALITY OF SERVICE ON THE INTERNET Nuran VAROL Since the beginning of Internet, we are using applications like ftp and telnet. The main characteristics of these applications are they are client server applications and they are used to send data between computers. While doing this one peer of the application is sending data through the network and the network is trying to deliver the data to the destination. The receiver is always waiting the data to process it. The data may be lost before the delivery and this time the sender will send it again. This type of applications is called elastic applications, because they are tolerant to packet loss and packet delays. The elastic applications are serviced with point to point best effort data delivery. Best effort data delivery was adequate for elastic applications because the receivers will always wait for the data to proceed and the senders resends the data whenever it is lost. Years passed and highly sophisticated digital audio and video applications have been developed. These applications are now working on the Internet. There are a number of applications such as remote video, audio broadcast, multimedia conferencing, visualization and virtual reality that are broadly used on the Internet. Best effort service model couldn't provide the necessary support to real-time applications referenced above because of the variable queuing delays and congestion losses. So the Internet infrastructure must be modified to support real-time QoS (Quality of Service) which provides some control over end-to-end packet delays. Real-time QoS was not the only issue for a next generation of traffic management in the Internet. The network operators were requesting the ability to control the sharing of bandwidth on a particular link among different traffic Xlllclasses. In this study, the main topic is how the service requirements of real-time applications working through the Internet are satisfied. To satisfy all these requirements an extension to the service model of the Internet is made and called the“Integrated Services Model”. The essence of integrated services model was the requirement for some service guarantees. In the integrated services model, two service models are proposed:. Guaranteed Quality of Service. Controlled Load Network Element Service Quality of service is implemented for a particular data flow by mechanisms collectively called traffic control. These mechanisms include: 1. Policy Control 2. Admission Control 3. Packet classifier 4. Packet scheduler Policy control determines whether the user has permission to make the so-called traffic management request where admission control determines whether the node has sufficient available resources to supply the requested QoS. Packet classifier determines the QoS class (and perhaps the route) for each packet. Packet scheduler, on the other hand, implements QoS service models defined by the integrated services model implemented. All those traffic control modules are running on all nodes taking part in the integrated services. Guaranteed service model guarantees that datagrams will arrive within the guaranteed delivery time and will not be discarded due to queue overflows, provided the data flow's traffic stays within its specified traffic parameters. This service model is intended for applications, which require a firm guarantee that a datagram will arrive no later than a certain time after it is being transmitted by its source. Guaranteed service model doesn't attempt to minimize the difference between the minimal and maximal queuing delays, it merely controls the maximal queuing delays. On the other hand, controlled load service model provides the same service level to application data flows that they may receive from best effort service model under unloaded conditions. Assuming the network is functioning correctly, applications may assume that:. The network to the receiving end nodes will successfully deliver a very high percentage of transmitted packets. The percentage of packets not successfully delivered must closely approximate the basic packet error rate of the transmission medium. XIV. The transit delay experienced by a very high percentage of the delivered packets will not greatly exceed the minimum transmit delay experienced by any successfully delivered packet. This minimum transit delay includes speed of light delay plus the fixed processing time in routers and other communications devices along the path. The Internet integrated services framework provides the ability for applications to choose among multiple, controlled levels of delivery service for their data packets. To support this capability, two things are required:. Individual network elements (subnets and IP routers) along the path followed by an application's data packets must support mechanisms to control the quality of service delivered to those packets.. A way to communicate the application's requirements to network elements along the path and to convey QoS management information between network elements and the application must be provided In the integrated services framework the first function is provided by QoS control services such as controlled load and guaranteed. The second function may be provided in a number of ways, but is frequently implemented by a resource reservation setup protocol. As stated above the requirements of applications should be transmitted to the network elements and the necessary resources should be reserved. RSVP, the resource reservation protocol, is designed for the integrated services Internet and it is used by a host to request specific qualities of service from the network for particular application data streams or flows. RSVP is also used by routers to deliver QoS requests to all nodes along the paths of the flows and to establish and maintain state to provide the requested service. As a result, RSVP requests will generally result in resources being reserved in each node along the data path. RSVP requests resources for simplex flows and it makes these requests in only one direction. Each sender host will send its RSVP Path messages along the data path to set up path states in the nodes. The path state will include the previous node IP address, sender's traffic specs, sender template including the filter specs from the sender's point of view and a special data structure called ADSPEC that includes the information about traffic control modules running on the routers. The ADSPEC information will be updated on each node and the resulting ADSPEC information will carry the characteristics of the data path. Each receiver host will send its RSVP reservation requests in Resv messages to senders. These messages will be transmitted in the opposite direction of the data flows. Each node along the data path receiving the Resv messages will create the reservation states and maintain them. The last stop for the Resv messages will be the senders to make them set their traffic control parameters for the application data. xvThe RSVP process running on the nodes along the data path will transfer the request to policy and admission control modules. If any of the controls fail, the reservation request will be refused and the RSVP process will return an error message to the receivers. If each of the controls is successful then the data flows specified in the filter specs will be selected and the requested QoS specified in the flowspecs will be applied to the selected data flows. RSVP with all its capabilities has some limitations. The limitations are listed below: » Scalability: the necessary resources (processing power, storage area,...etc) required to run RSVP on a router will increase in amount when the number of independent RSVP sessions increase. Because every RSVP session will generate the necessary path states and store them in router's memory and also every session will require extra processing for traffic control modules.. Policy Control: RSVP is subject to carrying the policy data, not to produce or to process it. The protocol specification itself is not clearly defining the policy data that is to be transmitted. So RSVP should rely on local policy control modules and sources for policy data. 9 Immediate Reservations: The proposed standard for the RSVP release 1 has been primarily concerned with setting up immediate reservations, that is, the QoS takes effect immediately and remains in effect for an indefinite duration. There are a variety of circumstances in which users of the real time applications will want to make a reservation reserving a QoS now that will take effect in the future. In the current release the application should make a reservation now and reserve the necessary resources till usage. This is not an efficient use of the resources. » Security: RSVP sends its messages in clear text. This makes the protocol mechanism vulnerable to unauthorized users using the passing RSVP data and requesting for reservations that they are not authorized to. The only protection in the protocol specification is MD5 checksums to protect message integrity. For the last limitation we offer the use of a powerful key management infrastructure. The key management structure will help implementers to encrypt the RSVP header. The encrypted header will prevent unauthorized parties to use RSVP header information for making illegal reservations. By using the encryption technologies the filterspecs will be protected. For the first three limitations we offer an infrastructure which employs reservation setup servers for administrative domains. This will help us to centralize the policy control. The policy control mechanism will take place in reservation setup servers for the specific administrative domain. The policy control mechanism itself will be much easier to implement. The usage of reservation setup servers will decrease the state refreshing messages. Whenever a topology change occurs or the reservation state change occurs, the refresh messages will be sent to the necessary network elements only. xviThis will help us to overcome scalability limitations. The states stored in the router's memory will decrease in amount and the processing load will be distributed to both the network element and the server itself. The reservation setup server will keep record of the reservation requests and schedule them so there is no need to develop extensions to RSVP release 1 to implement the reservations made for the future. The server will initiate the reservations when the reservation is needed. By using the reservation server no reservation state needs to be set up in the routers until the reservation is established. No multicast routing state needs to be set up either, until the reservation is established.

Benzer Tezler

  1. Tez No

    151283

    Quality of service enhancement in IP based networks using DiffServ

    DiffServ kullanılarak IP tabanlı ağlarda servis kalitesi geliştirme

    OKAN VURAL

    Yüksek Lisans

    İngilizce

    İngilizce

    2004

    Bilgisayar Mühendisliği Bilimleri-Bilgisayar ve Kontrolİstanbul Teknik Üniversitesi

    Bilgisayar Mühendisliği Ana Bilim Dalı

    DOÇ.DR. SEMA OKTUĞ

  2. Tez No

    95421

    Multicast routing in cellular networks considering quality of service

    Hücresel şebekelerde servis kalitesinin koruyan çoklu-yayın

    DENİZ YALÇIN

    Yüksek Lisans

    İngilizce

    İngilizce

    2000

    Bilgisayar Mühendisliği Bilimleri-Bilgisayar ve KontrolBoğaziçi Üniversitesi

    Bilgisayar Mühendisliği Ana Bilim Dalı

    DOÇ. DR. CEM ERSOY

  3. Tez No

    129501

    MPLS/VPN ağlarda servis kalitesi parametrelerinin seçimi

    Choosing quality of service parameters over MPLS/VPN networks

    BARIŞ ALTUNTAŞ

    Yüksek Lisans

    Türkçe

    Türkçe

    2003

    Bilgisayar Mühendisliği Bilimleri-Bilgisayar ve Kontrolİstanbul Üniversitesi

    Bilgisayar Mühendisliği Ana Bilim Dalı

    DOÇ. DR. AHMET SERTBAŞ

  4. Tez No

    615461

    On demand QOS bandwidth management approach in software defined networking

    Yazılım tanımlı ağlarda talep üzerine servis kalitesi bant genişliği yönetimi yaklaşımı

    MHD YASSIN ALNAHHAS

    Yüksek Lisans

    İngilizce

    İngilizce

    2019

    Elektrik ve Elektronik MühendisliğiAnadolu Üniversitesi

    Elektrik-Elektronik Mühendisliği Ana Bilim Dalı

    DOÇ. DR. NURAY AT

  5. Tez No

    126956

    İnternet protokolü üzerinden ses haberleşmesi

    Voice over IP

    ERCAN FİNCAN

    Yüksek Lisans

    Türkçe

    Türkçe

    2002

    Elektrik ve Elektronik Mühendisliğiİstanbul Teknik Üniversitesi

    Elektronik ve Haberleşme Mühendisliği Ana Bilim Dalı

    PROF. DR. GÜNSEL DURUSOY

Geri Dön