12. TCP/IP’Yİ DİĞER PROTOKOLLERLE YIĞINLAMAK
İlk bakışta, TCP/IP’yi diğer protokoller ile birlikte yerleştirmek
göreceli olarak basit görünebilir. Aşağıdaki üç gereksinimden dolayı bu iş
biraz daha karışıktır: Bazı ürünlerde, yığınlama tembelce ve gelişigüzel yapılmıştır. Bu ise akış
ve cevap zamanı başarımının düşmesine ve önemli fonksiyon fazlalılıklarının
ortaya çıkmasına sebep vermiştir. 12.1 Minimum bir TCP/IP LAN Yığını Şekil 12-1’de tanıdık bir TCP/IP yığınını görülüyor. Şekildeki yığın
LAN’daki iki istasyonu bağlamak için alt-katmanında Ethernet kullanılan basit
ve randımanlı bir uygulamadır. Üst katman protokolleri (ULP’ler) satıcı yazılımı ve son-kullanıcı
uygulamalarından oluşur. Şekil 12-1 Minimum
TCP/IP LAN Yığını 12.2 İşletim Sistemi Bağımsızlığı Hakkında Bir Söz Şekil 12-2’ye işletim sistemi notasyonunu ekleyerek, bu protokollerin
birbirleri ile nasıl haberleştiğinin; işletim sistemlerinin her bir cihazdaki
katmanlar arasındaki arabirimleri nasıl yönettiğine, bağlı olduğunu
vurgulamak istedik. Örneğin, bir UNIX işletim sistemi DOS’tan farklı
arabirimler sağlar. Bununla birlikte, iki makinenin birbirleri ile haberleşme
yeteneği işletim sistemlerinin uyumlu olmasını gerektirmez. Gerekli olan
şudur ki; makineler arası eş katmanlar arasında alışverişi yapılan PDU’lar
her bir makinede anlaşılabilir olmalı ve katmanlar birbirlerini tamamlayıcı
fonksiyonları yerine getirmelidir. Şekil 12-2 İşletim
Sisteminin Bağımsızlığı 12.3 LLC’nin Üzerinde TCP/IP Şekil 12-3’de yaygın kullanılan bir LAN yığını gösterilmiştir. Burada
logical link control (LLC) ve media access control (MAC), IP ile fiziksel
katman arasına yerleştirilmişlerdir. Tipik olarak, bu yaklaşım bağlantısız
bir veri bağlantı protokolü olan LLC tip 1’i (LLC1) kullanır. LLC başlığının
kullanılması değerlidir çünkü bu varış ve kaynak servis access noktalarını
(SAP’lar) sağlar. SAP’lar LLC’nin üzerindeki katmanlardaki kullanıcıları
tanımlar. Tabii ki, bu basit örnekte, LLC üzerindeki kullanıcı katmanı
IP’dir. IP/802 yapısı için yaygın bir yaklaşım; adres çözümleme protokolünü
(ARP) kullanarak, 32-bit Internet adresinin bir 16- veya 48-bit IEEE 802
adresine haritalanmasını sağlamaktır. Şekil 12-3 IEEE 802
Yığını Birkaç uygulama, özellikle IBM token ring’leri, yığında LLC tip 2 (LLC2)
kullanarak LLC standardının tam repertuarını destekler. Bu uygulamalar
sayısız bilgi (unnumbered information (UI)) komutları, alışveriş
teşhisi (exchange identification (XID)) komutları ve cevapları, test (TEST)
komutları ve cevaplarının tümünü desteklerler. Ek olarak, bir XID veya TEST
komutu bir cevap bayrağı ile alındığında, varış/kaynak SAP adresleri
değiş-tokuş edilmeli ve P ve F bitlerinin ilişkisi saklanmalıdır. Şöyle ki, bir
P biti her durumda bir F bitini ister. IP bir LAN’da LLC2 üzerinde çalışmak zorunda değildir. LLC1, UI
alışverişi, XID, ve TEST çerçeveleri ile kullanışlı özellikler sağlar. LLC1’i
TCP/IP altında çalıştırmak tercih edilebilirdir çünkü bu, LLC’nin sıralama,
akış kontrol, ve onay işlemlerinin sağlanmasında TCP’ye dayanmasını sağlar.
Ek olarak, kaynak SAP’larının ve varış SAP’larının kullanılması IP için çok
kullanışlı bir servis sağlar. Bazı uygulamalar için, LAN işlemleri zaten
yüksek akış ve yüksek doğruluk sağlıyorsa, TCP’nin kullanımı bunlara sekte
vurabilir. Bu durumda kullanıcı TCP’yi değiştirmeyi tercih edebilir ve biz de
sıradaki başlık altında bunu tartışacağız. 12.4 TCP’yi UDP ile Değiştirmek Şekil 12-4’de çok az farklı bir yığın görülmektedir. Burada TCP yerine UDP
kullanılmıştır. Bu yığın basitliğinden dolayı ve eğer belirli değişiklikler
yapılırsa tipik olarak TCP tarafından sunulan trafik doğruluğunu hala
sağlayabildiğinden dolayı kullanışlı olabilir. En büyük değişiklik trafik doğruluğunun ULP veya LLC ile sağlanıyor
olmasıdır. Önce LLC’nin kullanılmasını tartışalım. Tip 2’nin sağladığı
bağlantı-yönlendirmeli link protokolü, trafiğin alıcı LLC’ye gittiğini
garanti eder. TCP’ye benzer olarak LLC2, bir SABM (set asynchronous balanced
mode) link yapısını kullanarak; sıralama, akış kontrol ve pencere kontrol
yetenekleri sağlar. Bu yaklaşımın riskleri vardır çünkü LLC hoş bir close’a
sahip değildir. Bağlantı yönetimini (closing) iyileştirmek için bir ULP’de
bazı araçlar kullanılmalıdır. Tabii ki, ULP acknowledgment’ler, akış kontrolü
ve sıralama sağlayabilir. Eğer üst-katman uygulamaları bu özelliklerle
çalışıyorsa, aktarım katmanı için UDP iyi bir seçimdir. Şekil 12-4 TCP
yerine UDP’nin Kullanılması LLC veya ULP seviyesinde bağlantı-yönlendirmeli servisleri
gerçekleştirmenin maliyetini tartmak gerekir. Tekrar, satıcının ULP’sini
dikkatlice inceleyin, çünkü bazı LLC2 ve ULP’ler bağlantı-yönlendirmeli
servisleri çakışan fonksiyonlar gerçekleştirebilirler. 12.5 IP Router Yığınları Şekil 12-5’de bir IP router’ının yığınları gösterilmiştir. Bu örnekte,
router iki LAN’ı birbirine bağlar: LAN’lardan biri 802.3 CSMA/CD ağı ve
diğeri 802.5 token ring ağıdır. Router’daki yığınlar, hangi portun
yönetildiğine bağlı olarak değişir. Bununla birlikte, yığınlardaki farklılık
yalnızca fiziksel ve MAC katmanlarında oluşur; LLC ve IP aynı kalır. Şekil 12-5 Tipik
LAN Router’ı 12.6 IP ve LAN Köprülerinin İlişkileri Şekil 12-6’da bir köprü ile birbirlerine bağlanmış iki LAN gösterilmiştir.
Bu durumda, MAC relay varlığı iki port (yani, iki ağ) arasında trafiği
rotalamaktan sorumludur. LLC’nin ana fonksiyonu üst katmanlardan MAC’a bir
arabirim sağlamaksa neden LLC’yi köprüye yerleştiriyoruz. Sebep şudur; IEEE
802.1 MAC köprüleri trafiğin hem giriş MAC portundan relay varlığı boyunca
çıkış MAC portuna, hem de köprü yönetim fonksiyonları için MAC’ten köprünün
kendi LLC’sine hareket edebilmesini sağlar. Trafik gateway’deki LLC’de iken,
geri MAC’e veya köprü öğrenme, köprü ilerletme gibi işlemler için relay
varlığına ilerletilebilir. Her olayda da, tüm 802 MAC köprüleri için LLC
gerekmektedir. Şekil 12-6 Tipik
LAN Köprüsü 12.7 IP ve X.25 IP ve X.25 çeşitli şekillerde birbirlerine bağlanabilirler: · LAN’lar 12.7.1 IP, X.25 ve LAN’lar Şekil 12-7’de bir LAN üzerinde X.25’in kullanımını gösterilmektedir. Bu
örnekte OSI TP4, IP’nin üzerindedir. LAN istasyonu, LAPB (link access
procedure balanced) veya V-serisi arabirimler gibi, daha alt-katman X.25
servislerini istemez. Bunun yerine, gateway’e taşımak için X.25 paketini LLC
veya MAC PDU’ları olarak paketler. Gateway’de trafik, yığınlardan ters bir
sırada geçer. Gateway’deki X.25 PLP katmanında, X.25 paket başlığı; kullanıcı
bilgisayarı ve gateway’deki protokol yığınının sol tarafı arasında mantıksal
bir kanal ilişkisi haritalamakta kullanılır. Daha sonra IP gateway’deki
işlemlerini yapar, ve gateway bundan sonra trafiği uygun çıkış portuna
aktarır. Bu örnekte, LAPB veri bağlantı kontrol çerçevesi X.25 paketi olarak
düzenler, ve trafik EIA-232 veya bir V-serisi arabirim üzerinden WAN paket
anahtarına iletilir. Bu yığın çalışır, ancak kullanışsızdır. Şekil 12-7 LAN
üzerindeki bir X.25 Hatırlayalım ki X.25 paket katmanı prosedürleri iki link üzerinden
istenebilir: (a) router ve LAN istasyonu arasında, ve (b) router ve paket
anahtarı arasında. Etki olarak, bu işlem router’ın iki bağlantı kurmasını
gerektirir. Router için daha iyi bir uygulama, kullanıcı bilgisayarından X.25
trafiğini kabul etmek ve transparan olarak paket anahtarına bunu iletmektir.
Böylece router kullanıcı ve paket anahtarı arasındaki bağlantıya doğrudan
katılmaz. Tabii ki, router hala daha paketleri incelemeli ve bunları doğru
cihazlara iletmelidir. 12.7.2 IP, X.25, ve halk veri ağları X.25’in bir LAN üzerine yerleştirilmesi yaygın bir uygulama değildir. Daha
yaygın olarak, bir kullanıcı host bilgisayarı X.25 ile bir halk veri ağının
(PDN) paket anahtarına bağlanır. Şekil 12-8’de bu yapının katmanları
gösterilmiştir. RFC 877, X.25-IP ve X.25-paket anahtarı arabirimleri için
birkaç basit kural belirtmiştir: · Her zamanki gibi bir hayali ağ kurulur. Host bilgisayarı X.25 modülü
aracılığı ile bir datagram alınca, anahtara bir çağrı-istek paketi gönderir.
Bundan sonra host, bir çağrı-bağlandı paketi alınca, IP datagramını iletir.
Tabii ki, host IP datagramını X.25 paketinin X.25 kullanıcı veri alanına
yerleştirerek ağa yollar. Şekil 12-8 IP,
X.25, ve bir PDN 12.7.3 IP, X.25, ve amatör paket radyo Bir IP-X.25 birleşiminde başka bir olasılık, X.25 paketlerini IP datagramları
olacak biçimde paketlemektir. Bu teknik, amatör paket radyo sistemleri
üzerinde çalıştırılan, AX.25 protokolünü desteklemek için kullanılır. Prosedür çok basittir. LAPB bayrakları, ve sıfır bit doldurma kullanılmamıştır.
Amatör paket radyoya, LAPB cyclic redundancy checks (CRC’ler) ve aynı zamanda
LAPB adresleri ve kontrol alanları da eklenmiştir. Bunun dışında, AX.25 tüm
diğer LAPB ve X.25 alanlarını sağlar. Internet paket alışverişi protokolü (Internet packet exchange protocol
(IPX)) Novell’s Netware’in IP-tipi ürünüdür. XNS protokolünden türetilmiştir.
Netware yaygın olarak uygulandığından, IPX trafiğinin internet ağları
arasında nasıl taşınabildiğini göstermek üzere kısa bir tartışma uygundur.
Şekil 12-9’dan de görüldüğü gibi yığın düzenlemesi üst katmandan alt katmana
doğru şöyledir: ULP, IPX, UDP, IP, alt-katman protokolleri (tipik olarak,
IEEE veya Ethernet gibi LAN’lar). Şekil 12-9 UDP/IP
üzerinde IPX kullanılması IP ve UDP başlıkları bu yığınlaşma düzeninden etkilenmezler. Bu yığın için
göz önüne alınacak en önemli husus adres haritalamadır. Bir IPX adres
boşluğu; bir ağ numarası ve bir host numarası içerir. Ağ numarası dört ve
host numarası altı oktetten oluşur. Bu birleşik numara IPX tarafından, her
bir IPX paketini varışa rotalamakta kullanılır. IP şemasına benzer biçimde,
ağ numarası varış ağa ulaşmak olan fonksiyonunu bir kez tamamlayınca, host
numarası varış ağına bağlı host’a trafiği rotalar. IPX UDP/IP arabirimi için,
RFC 1234 host numarasının ilk iki oktetinin 0’a set edilmesini, ve son dört
oktetin düğümün IP adresini göstermesini talep istemektedir. IPX’ler için maksimum iletim birimi (MTU) 576 oktettir. Bu yığın için
toplam PDU 604 oktet olacaktır: 576 IPX + 20 IP başlığı + 8 UDP = 604 Bu yığınlaşma düzenini destekleyen tüm uygulamalar 604 oktet bir IP paketini
alabiliyor olmalıdırlar. |
