← rfc/
╔══════════════════════════════════════════════════════════════════════════╗
RFC 721 · protokol

Bir Ana Bilgisayardan Ana Bilgisayara Protokolde Bant Dışı Kontrol Sinyalleri

Yazar
Larry Garlick (SRI-ARC)
Kurum
Tarih
1 Eylül 1976
Durum
Network Working Group Yorum Talebi
Kanal
protokol/

Bir Ana Bilgisayardan Ana Bilgisayara Protokolde Bant Dışı Kontrol Sinyalleri

Network Working Group
Request for Comments: 721
NIC: 36636
Yazar: Larry Garlick (SRI-ARC)
Tarih: 1 Eylül 1976


Bu not, bir ana bilgisayardan ana bilgisayara protokolde kullanılmak üzere güvenilir bir bant dışı sinyalin uygulanması sorununu ele almaktadır. Bu çalışma, Cerf ve arkadaşlarının Transmission Control Protocol (TCP) içinde böyle tatmin edici bir mekanizmanın bulunmamasından kaynaklanmaktadır [referans 4, 6]. Böyle bir bant dışı sinyal (kesmeler) için bazı gereksinimlerin ve bu gereksinimlerin uygulanmasına ilişkin sonuçların tartışılmasına ek olarak, TCP durumu için problemin bir incelemesi sunulacaktır.

ARPANET ana bilgisayardan ana bilgisayara protokolü ne veri ne de kontroller için güvenilir iletimi desteklememekle birlikte, bant dışı bir kontrol sinyali için sahip olduğumuz diğer gereksinimleri karşılamaktadır ve TCP durumu için bir çözüm sağlamak amacıyla ondan yararlanılacaktır.

TCP şu anda tüm veri ve kontrolleri aynı mantıksal kanal üzerinde ele almaktadır. Güvenilir iletimi sağlamak için, tüm veriler ve kontrollerin çoğu için pozitif onay ve yeniden iletim sağlar. Kesmeler veriyle aynı kanalda olduğundan, TCP bir kesme gönderildiğinde akış kontrolüne tabi olmamak için veriyi temizlemek zorundadır.

İşlevsel Gereksinimler

Bir kesmenin güvenilir şekilde teslim edilmesinin sağlanması arzu edilir. Gönderici, gönderdiği her kesme için hedefte bir ve yalnızca bir kesmenin teslim edildiğinden emin olmalıdır. Protokolün, kesmelerin kullanıcıya teslim edilme sırası ile ilgilenmesi gerekmez.

Kesme sinyali, veri akış kontrolü mekanizmalarından bağımsız olmalıdır. Veri için tamponlar sağlanıp sağlanmadığına veya diğer kontrollerin ele alınıp alınmadığına bakılmaksızın bir kesme teslim edilmelidir. Kesme, diğer veri ve kontrollerin güvenilir teslimini etkilememelidir.

Ana bilgisayardan ana bilgisayara protokolün, kesme kanalı ile veri-kontrol kanalı arasında senkronizasyon sağlaması gerekmez. Aslında, kanalların bağlanması veri-kontrol kanalındaki sıra numaralarının ilerlemesine dayanıyorsa, kesme kanalı yukarıda istenildiği gibi artık akış kontrolünden bağımsız değildir. Veri akışı ile senkronizasyon, bir kesme üretildiğinde veri akışının işaretlenmesi yoluyla kullanıcı tarafından gerçekleştirilebilir. Kesmenin diğer kontrollerle bağlanması gerekmez; çünkü bağlantının durumunu hiçbir şekilde etkilemez.

Kesme kullanıcıya teslim edildikten sonra, ana bilgisayardan ana bilgisayara düzeyinde onunla ilişkili başka hiçbir anlamsal özellik yoktur.

Sonuçlar

Kesmelerin güvenilir teslimini ve teslimin hesap verebilirliğini sağlamak için bir onaylama düzeni gereklidir. Kesme onaylarını doğru kesme ile ilişkilendirmek için, kesmeler için bir adlandırma kuralı gereklidir. Sıra numaraları, bir sıralama mekanizması sağlama potansiyeliyle birlikte böyle bir adlandırma kuralı sunar.

Kesmeleri akış kontrolünden bağımsız kılmak için ayrı bir kesme kanalı gereklidir. Kesmeleri adlandırmak için ayrı bir sıra numarası uzayı da gereklidir. Sıra numaraları başka bir kanalla aynı sıra numarası uzayından geliyorsa, bir kesme gönderimi o kanaldaki sıra numaralarını yeniden senkronize etme gereksinimi nedeniyle engellenebilir.

Veri, kontroller ve kesmeler için tek bir kanal kullanan mevcut TCP’de, veri temizleme işlemi akış kontrolü mekanizmasını baypas etmek için kesme ile birleştirilir. Ancak, yeniden senkronizasyon kontrollerinin temizlenmesine izin verilmez ve bu kontrollerin alınması, önceki tüm verilerin onaylanmasına bağlıdır. ARPANET protokolü, güvenilir iletimi sağlamamakla birlikte, kesme-kontrol kanalının veri kanalından ayrılmasını sağlar.

Çoklu Kanallar ve Sıra Numaraları

Bir bağlantı için birden fazla kanal kullanılacaksa, sıra numarası bakımının verimli şekilde yapılabilmesi için kanalların sıra numaralarının nasıl bağlanabileceğini belirlemek ilginç hale gelir.

TCP’de olduğu gibi, her veri ve kontrol oktetine sıra numarası atanması, pozitif onaylama ve sıralamaya olanak tanır. Ancak, paketler zaman aşımında yeniden iletildiğinden ve çok yollu paket anahtarlamalı ağlar bir paketin uzun süre ağda kalmasına neden olabildiğinden, yinelenen paketlerin ve sırasız paketlerin varlığı hesaba katılmalıdır. Alınan her paket üzerinde, aşağıdaki eylemlerden hangisinin yapılması gerektiğini belirlemek için bir sıra numarası kabul edilebilirlik testi gerçekleştirilmelidir:

Kanal 0 için Kabul Edilebilirlik

Bir paket için yapılacak eylemi belirlemek amacıyla kabul edilebilirlik aralıkları tanımlanır. Aşağıdaki üç aralık, sıra numarası uzayını karşılıklı olarak dışlayan ve birlikte tamamen kapsayan aralıklardır (bkz. Şekil 1):

KABUL EDİLEBİLİRLİK ARALIKLARI

DR       AOR             ADR              DR
\\=====)[===========)[===================](========\\
        ^           ^^                   ^^
        !           !\                   !\
        !           ! FCLE               ! DRLE
      AOLE       AORE                 ADRE

Şekil 1

Tanımlar:

Herhangi bir x sıra numarası ve l paket metni uzunluğu için, eğer:

ise, paket onaylanmalıdır.

Eğer x ve l şu koşulları sağlıyorsa:

ise, x ayrıca kullanıcıya teslim edilebilir; ancak sıralı teslim, x = FCLE olmasını gerektirir.

Bir paket, tamamı bir aralığın dışında kalmadıkça bir aralıkta değildir. Bir paket birden fazla aralığa düştüğünde, öncelik sırası ADR, ardından AOR ve sonra DR’dir. Bir paket AOR içine düştüğünde, bir paket oluşturulması gerekse bile bir ACK gönderilmelidir. ACK, mevcut sol pencere kenarını belirtecektir. Bu, tüm yinelenenlerin onaylanmasını güvence altına alır.

ADRE, akış kontrolü penceresi aracılığıyla şimdiye kadar “ilan edilmiş” en büyük sıra numarasının tam olarak bir fazlasıdır. Bu, izinleri kendileri için açıkça verilmemiş olsa bile kontrollerin kabul edilmesine olanak tanır. Elbette, sıra numarası ADRE’ye eşit olan bir kontrol her gönderildiğinde, ADRE bir artırılmalıdır.

AOR, eski yinelenenlerin (bağlantının önceki örneklerinden kalan) saptanıp atılabilmesi için ayarlanır. Dolayısıyla:

Senkronizasyon ve Yeniden Senkronizasyon Sorunları

Ağda, bağlantının eski örnekleri tarafından atanmış sıra numaralarına sahip paketlerin (eski yinelenenler) tespit edilmesine ilişkin özel bir sorun ortaya çıkar. Bunun güvenilir şekilde ele alınabilmesi için, başlangıç sıra numarasının dikkatle seçilmesi [ref. 2, 3] ve ayrıca sıra numaralarının yeniden senkronize edilmesinin gerekli olup olmadığını belirlemek üzere periyodik kontroller yapılması gerekir. Böylesine ayrıntılı bir düzenin ek yükü pahalıdır ve her ek kanal için bunun tekrarlanması istenmez.

Kanal i için Kabul Edilebilirlik

Çoklu kanal durumunda elde edilebilecek tek tasarrufun, ek kanallar için kanal sıfırın başlangıç sıra numarasını ve yeniden senkronizasyon bakım mekanizmasını kullanmak olduğu sonucuna vardık. Bu, her ek kanalın kanal sıfırın sıra numaralarına (CZSN) bağlanmasıyla gerçekleştirilebilir; böylece kanal i üzerindeki her öğe bir çift sıra numarası taşır: geçerli CZSN ve kanal i’nin geçerli sıra numarası (CISN).

Kanal i üzerindeki öğelerin kabul edilebilirlik testi, her iki sıra numarasının bileşik bir testidir. Önce CZSN, kanal sıfırda alınan bir oktet olsaydı onaylanıp onaylanmayacağını görmek için denetlenir. Yalnızca atılacak durumda olsaydı, kanal i üzerindeki öğe atılır. CZSN testini geçen durumda, CISN; öğenin CISN sıra numarası uzayına göre teslim edilebilir ve onaylanabilir olup olmadığını görmek için denetlenir. CISN testi, bağlantının eski örneklerinden kalan eski yinelenenlerin varlığı dışında her şey için bir kontroldür ve kanal sıfır öğeleri için yapılan kontrole benzer şekilde gerçekleştirilir.

Bir TCP bağlantısı için ek kanalların uygulanabilmesi adına iki alternatifin mevcut olduğu gösterilmiştir:

  1. Her kanala kendi başlangıç sıra numarasını ve yeniden senkronizasyon bakım mekanizmasını sağlamak veya
  2. Kanal sıfırın mekanizması aracılığıyla tüm kanallar için tek bir başlangıç sıra numarası ve yeniden senkronizasyon bakım mekanizması sağlamak.

Herhangi bir yeniden senkronizasyon bakım mekanizmasını uygulama deneyimimiz olmadığından, iki alternatifi karşılaştırmak bizim için zordur.

TCP Durumu

TCP için tamamen güvenilir, ayrı bir kesme kanalı uygulamak, tam bir sıra numarası uzayına sahip bir kanal gerektirir. Burada bir uzlaşma yapmak ve kesme numarası uzayını, TCP’nin bant genişliğinde numara tüketimini desteklemek için gerekenden daha küçük tutmak mümkündür. Kaybedilen şey, akış kontrolünün veri-kontrol kanalından tam bağımsızlığıdır. Normalde, veri-kontrol sıra numaraları yeterince sık değişir; bu nedenle kesme numarası uzayında başa sarmalar sorun oluşturmaz.

Birçok kesmenin kısa sürede art arda üretilmesi durumunda işler biraz karmaşıklaşır. Kesme numaraları onaylansa bile, tam bir paket ömrü geçene kadar aynı veri-kontrol sıra numarasına atıfta bulunuyorlarsa yeniden kullanılamazlar. Bu durum, bir istisna dışında tüm durumlarda, veri-kontrol kanalında bir NOP gönderilerek giderilebilir; böylece bir sonraki kesme kümesi yeni bir veri-kontrol sıra numarasına atıfta bulunabilir. Ancak, veri-kontrol kanalı akış kontrolü nedeniyle bloke olmuşsa ve bir yeniden senkronizasyon kontrolü (TCP durumunda DSN) henüz gönderilmişse, yeniden senkronizasyon tamamlanıp yeni bir başlangıç sıra numarası seçilene kadar bir NOP üretilemez. Dolayısıyla başka bir kesme göndermek için TCP, ya bir paket ömrünü ya da veri-kontrol kanalında bir NOP gönderebileceğine dair bir göstergeyi beklemek zorundadır. (Gerçekte, gönderici alıcıdan gelen veriyi kabul etmiyorsa, bir paket ömrü dolmadan çok önce bağlantı büyük olasılıkla kapatılırdı. [referans 1])

Referanslar

  1. J. Postel, L. Garlick, R. Rom, “TCP Specification (AUTODIN II),” ARC Catalog #35938, Temmuz 1976.
  2. R. Tomlinson, “Selecting Sequence Numbers,” INWG Protocol Note #2, Eylül 1974.
  3. Y. Dalal, “More on Selecting Sequence Numbers,” INWG Protocol Note #4, Ekim 1974.
  4. V. Cerf, Y. Dalal, C. Sunshine, “Specification of Internet Transmission Control Program,” INWG General Note #72, Aralık 1974 (Gözden geçirilmiş). Ayrıca RFC 675, NIC Catalog #31505.
  5. V. Cerf, “TCP Resynchronization,” SU-DSL Technical Note #79, Ocak 1976.
  6. V. Cerf ve R. Kahn, “A Protocol for Packet Network Intercommunication,” IEEE Transactions on Communication, Cilt COM-20, No. 5, Mayıs 1974.
  7. C. Sunshine, “Interprocess Communication Protocols for Computer Networks,” Digital Systems Laboratory Technical Note #105, Aralık 1975.