Kaynak Rezervasyon Protokolü - Resource Reservation Protocol

Kaynak Ayırma Protokolü ( LCV ) bir olan aktarım katmanı protokolü bir genelinde rezerv kaynaklarına tasarlanan ağa kullanarak entegre hizmetler modeli. RSVP, bir IPv4 veya IPv6 üzerinden çalışır ve çok noktaya yayın veya tek noktaya yayın veri akışları için alıcı tarafından başlatılan kaynak rezervasyonları kurulumunu sağlar . Uygulama verilerini aktarmaz, ancak İnternet Kontrol Mesajı Protokolü (ICMP) veya İnternet Grup Yönetim Protokolü (IGMP) gibi bir kontrol protokolüne benzer . RSVP, RFC  2205'te açıklanmıştır .

RSVP, ana bilgisayarlar ve yönlendiriciler tarafından , uygulama veri akışları için belirli hizmet kalitesi (QoS) düzeyleri talep etmek veya sunmak için kullanılabilir . RSVP, uygulamaların rezervasyonları nasıl yerleştireceğini ve artık ihtiyaç duyulmadığında ayrılmış kaynakları nasıl bırakabileceklerini tanımlar. RSVP işlemleri genellikle kaynakların bir yol boyunca her düğümde ayrılmasına neden olur. RSVP bir yönlendirme protokolü değildir ancak mevcut ve gelecekteki yönlendirme protokolleriyle birlikte çalışmak üzere tasarlanmıştır.

RSVP tek başına telekomünikasyon ağlarında nadiren kullanılır. 2003 yılında, teletrafik mühendisliği için geliştirme çabası RSVP'den RSVP- TE'ye kaydırıldı . Sinyallemede Sonraki Adımlar (NSIS), RSVP için önerilen bir yedekti.

Ana özellikler

  1. RSVP, tek yönlü akışlar için kaynak ister : göndericiden bir veya daha fazla alıcıya yalnızca bir yönde bir trafik akışı.
  2. RSVP bir yönlendirme protokolü değildir ancak mevcut ve gelecekteki yönlendirme protokolleriyle çalışır.
  3. RSVP, bir veri akışının alıcısının o akış için kaynak rezervasyonunu başlatması ve sürdürmesi bakımından alıcıya yöneliktir.
  4. RSVP , ana bilgisayar ve yönlendiricilerin kaynak rezervasyonlarının yumuşak durumunu (her düğümdeki rezervasyonun periyodik olarak yenilenmesi gerekir) korur , dolayısıyla ağ değişikliklerine dinamik otomatik uyarlamayı destekler.
  5. RSVP, birkaç rezervasyon stili (bir dizi rezervasyon seçeneği) sağlar ve çeşitli uygulamalara uyması için protokol revizyonlarına gelecekteki stillerin eklenmesine izin verir.
  6. RSVP, RSVP'ye karşı opak olan trafik ve politika kontrol parametrelerini taşır ve korur.

Tarihçe ve ilgili standartlar

RSVP'nin temel kavramları ilk olarak 1993'te önerildi.

RSVP, IETF'den bir dizi RFC belgesinde açıklanmıştır:

  • RFC  2205 : Sürüm 1 işlevsel belirtimi, IETF tarafından RFC 2205'te (Eylül 1997) açıklanmıştır . Sürüm 1, "yalnızca" kaynak kullanılabilirliğine dayanan kabul (trafik) denetimine yönelik arabirimi açıklar. Daha sonra RFC2750 , giriş denetimi desteğini genişletti.
  • RFC  2210 , kontrollü yük RFC 2211 ve garantili RFC 2212 QoS kontrol hizmetleriyle RSVP kullanımını tanımlar. Entegre Hizmetler'de daha fazla ayrıntı . Ayrıca, RFC 2205'te RSVP tarafından tanımlanan veri nesnelerinin (kaynak rezervasyon bilgilerini taşıyan) kullanımını ve veri biçimini tanımlar.
  • RFC  2211 , Kontrollü Yük hizmetleri sağlamak için gereken ağ öğesi davranışını belirtir.
  • RFC  2212 , garantili QoS hizmetleri sağlamak için gereken ağ öğesi davranışını belirtir.
  • RFC  2750 , RSVP'de genel ilke tabanlı kabul kontrolünü desteklemek için önerilen bir uzantıyı açıklar . Uzantı, ilke nesnelerinin bir belirtimini ve ilke olaylarının ele alınmasına ilişkin bir açıklamayı içeriyordu. (Ocak 2000).
  • RFC  3209 , "RSVP-TE: LSP Tünelleri için RSVP Uzantıları" (Aralık 2001).
  • RFC  3473 , "Genelleştirilmiş Çok Protokollü Etiket Anahtarlama (GMPLS) Sinyalleme Kaynak Rezervasyon Protokolü-Trafik Mühendisliği (RSVP-TE) Uzantıları" (Ocak 2003).
  • RFC  3936 , "değiştirme için prosedürler R yeniden esource S er V tirme P (2004 Ekim) rotocol (LCV)", LCV değiştirmek için mevcut en iyi uygulamalar ve belirtir prosedürlerini açıklamaktadır.
  • RFC  4495 , "Bir Rezervasyon Akışının Bant Genişliğini Azaltmak için Kaynak Rezervasyon Protokolü (RSVP) Uzantısı" (Mayıs 2006), RSVP'yi mevcut bir rezervasyonun bant genişliğini rezervasyonu bozmak yerine azaltacak şekilde genişletir.
  • RFC  4558 , "Düğüm Kimliği Tabanlı Kaynak Rezervasyon Protokolü (RSVP) Merhaba: Bir Açıklama Beyanı" (Haziran 2006).

Anahtar kavramlar

LCV rezervasyon modelini iki önemli kavramlardır flowspec ve filterspec .

Akış belirtimi

LCV, bir akış için kaynakları ayırır. Bir akış, hedef adres, protokol tanımlayıcısı ve isteğe bağlı olarak hedef bağlantı noktası tarafından tanımlanır. Çok protokollü etiket anahtarlamada (MPLS) bir akış, etiket anahtarlamalı yol (LSP) olarak tanımlanır . Her akış için RSVP , akışın gerektirdiği belirli hizmet kalitesini (QoS) da tanımlar . Bu QoS bilgisine akış belirtimi denir ve RSVP, akış belirtimini uygulamadan yol boyunca ana bilgisayarlara ve yönlendiricilere iletir . Bu sistemler daha sonra kaynakları kabul etmek ve rezerve etmek için akış belirtimini analiz eder . Bir akış belirtimi şunlardan oluşur:

  1. hizmet sınıfı
  2. Rezervasyon özelliği - QoS'yi tanımlar
  3. Trafik spesifikasyonu - veri akışını tanımlar

Filtre özellikleri

Filterspec tanımlar bir etkilenmektedir paketlerin grubu flowspec (yani veri paketleri flowspec tarafından tanımlanan QoS almak için). Bir filtre belirtimi tipik olarak bir düğüm tarafından işlenen tüm paketlerin bir alt kümesini seçer. Seçim, bir paketin herhangi bir niteliğine bağlı olabilir (örneğin, gönderici IP adresi ve bağlantı noktası).

Şu anda tanımlanmış LCV rezervasyon stilleri şunlardır:

  1. Sabit filtre - belirli bir akış için kaynakları ayırır.
  2. Paylaşılan açık - çeşitli akışlar için kaynakları ayırır ve tümü kaynakları paylaşır
  3. Joker karakter filtresi - akışı belirtmeden genel bir akış türü için kaynakları ayırır; tüm akışlar kaynakları paylaşır

Bir LCV rezervasyon isteği oluşur flowspec ve filterspec ve çift bir denir flowdescriptor . Flowspec setleri bir düğüm de paket zamanlayıcı parametreleri ve filterspec setleri paket sınıflandırıcı de parametreleri.

Mesajlar

İki ana mesaj türü vardır:

  • Yol mesajları ( yol )
Yol mesaj veri yolu ve depolar boyunca gönderen ana gönderilen yol durumu yolu boyunca her bir düğümde.
Yol durumu bir önceki düğümün IP adresi ve bir veri nesneleri içerir:
  1. gönderen verilerinin biçimini bir Filterspec biçiminde açıklamak için gönderen şablonu
  2. veri akışının trafik özelliklerini açıklamak için gönderen tspec
  3. reklam verilerini taşıyan adspec (daha fazla ayrıntı için RFC 2210'a bakın).
  • Rezervasyon mesajları ( resv )
Resv mesaj geri veri yolu boyunca gönderen konakçıya alıcıdan gönderilir. Her düğümde, resv mesajının IP hedef adresi , ters yoldaki bir sonraki düğümün adresine ve IP kaynak adresi, ters yoldaki önceki düğüm adresinin adresine değişecektir.
Resv mesajı içeren flowspec olduğunu tanımlar kaynakları bu akış ihtiyaçlarını veri nesnesini.

RSVP mesajlarındaki veri nesneleri herhangi bir sırayla iletilebilir. RSVP mesajlarının ve veri nesnelerinin tam listesi için RFC 2205'e bakın.

Operasyon

Belirli bir QoS ile bir veri akışı göndermesi gereken bir RSVP ana bilgisayarı , çalışma yönlendirme protokolü tarafından önceden belirlenmiş tek noktaya yayın veya çok noktaya yayın yolları boyunca seyahat edecek her 30 saniyede bir bir RSVP yol mesajı iletecektir . Yol mesajı RSVP'yi anlamayan bir yönlendiriciye ulaşırsa , o yönlendirici mesajın içeriğini yorumlamadan iletir ve akış için kaynak ayırmaz.

Onları dinlemek isteyenler karşılık gelen bir resv ( rezerv kısaltması ) mesajı gönderir ve bu mesaj gönderene giden yolu izler. Resv mesajı içeren flowspec . Resv mesajı ayrıca sahiptir filterspec nesne; akış belirtiminde tanımlanan istenen QoS'yi alacak paketleri tanımlar. Basit bir filtre özelliği, yalnızca gönderenin IP adresi ve isteğe bağlı olarak UDP veya TCP bağlantı noktası olabilir. Bir yönlendirici RSVP resv mesajını aldığında :

  1. Talep parametrelerine göre rezervasyon yapın. Kabul kontrolü , istek parametrelerini işler ve paket sınıflandırıcıya seçilen veri paketlerinin alt kümesini doğru bir şekilde işlemesi talimatını verebilir veya üst katmanla paket işlemenin nasıl gerçekleştirilmesi gerektiği konusunda anlaşabilir. Desteklenemiyorsa, dinleyiciye bildirmek için bir red mesajı gönderilir.
  2. İsteği yukarı yönde iletin (gönderenin yönünde). Her düğümde, resv mesajındaki akış belirtimi , bir yönlendirme düğümü tarafından değiştirilebilir (örneğin, çok noktaya yayın akış rezervasyonu durumunda, rezervasyon talepleri birleştirilebilir).
  3. Yönlendiriciler sonra akış doğası depolamak ve isteğe bağlı olarak ayarlamak polis bunun için flowspec göre yöntem.

Belirli bir süre hiçbir şey duyulmazsa, rezervasyon zaman aşımına uğrar ve iptal edilir. Bu, gönderici veya alıcının çökmesi veya ilk önce rezervasyonu iptal etmeden kapanması durumunda sorunu çözer.

Diğer özellikler

Bütünlük
RSVP mesajları, mesaj içeriği ve bir mesaj özeti algoritması (genellikle MD5 ) kullanılarak paylaşılan bir anahtarın birleştirilmesiyle oluşturulan bir mesaj özeti ile eklenir . Anahtar, iki mesaj türü kullanılarak dağıtılabilir ve onaylanabilir: bütünlük sorgulama isteği ve bütünlük sorgulama yanıtı .
Hata raporlama
Bir düğüm bir hata algıladığında, bir hata koduyla bir hata mesajı oluşturulur ve göndericiye giden ters yolda yukarı yönde yayılır.
LCV akışı hakkında bilgi
İki tür tanı mesajı, bir ağ operatörünün belirli bir akışta RSVP durum bilgilerini istemesine olanak tanır.
Teşhis tesisi
Bir kullanıcının bir yol boyunca RSVP durumu hakkında bilgi toplamasını sağlayan standardın bir uzantısı.

RFC'ler

Referanslar

  • John Evans; Clarence Filsfils (2007). Çok Hizmetli Ağlar için IP ve MPLS QoS Dağıtma: Teori ve Uygulama . Morgan Kaufmann. ISBN'si 978-0-12-370549-5.

Dış bağlantılar