APPN mimarisi ile diğer şebeke mimarilerinin bütünleştirilmesine ilişkin yöntemler

Integration methods of APPN architecture and other networking architectures

Tez No: 101088
Yazar: ALPER GÜVENER
Danışmanlar: PROF.DR. GÜNSEL DURUSOY
Tez Türü: Yüksek Lisans
Konular: Elektrik ve Elektronik Mühendisliği, Electrical and Electronics Engineering
Anahtar Kelimeler: Belirtilmemiş.
Yıl: 2000
Dil: Türkçe
Üniversite: İstanbul Teknik Üniversitesi
Enstitü: Fen Bilimleri Enstitüsü
Ana Bilim Dalı: Belirtilmemiş.
Bilim Dalı: Belirtilmemiş.
Sayfa Sayısı: 230

Özet

APPN MİMARİSİ İLE DİĞER ŞEBEKE MİMARİLERİNİN BÜTÜNLEŞTİRİLMESİNE İLİŞKİN YÖNTEMLER ÖZET SNA, IBM tarafından geliştirilen sıradüzensel bir mimaridir. SNA mimarisi yedi katmandan oluşur; Fiziksel Katman, Veri Bağı Kontrol Katmanı, Yol Kontrol Katmanı, İletim Kontrol Katmanı, Veri Akış Kontrol Katmanı, Sunum Hizmetleri Katmanı, Uygulama Katmanı. SNA'de Sanal Haberleşme Erişim Metodu (VTAM) ve Şebeke Kontrol Programı (NCP) olarak adlandırılan yazılımlar haberleşmeyi kontrol eden düzeneklerdir. Düğümlerin birbirleri ile haberleşmeleri için kurulan sanal yol üzerinden haberleşmeleri oturum olarak adlandırılır. SNA'de haberleşme çeşitli birimler arasında gerçekleşir. Bu birim sıra düzensel olarak şu şekilde belirtilebilir; Sistem Hizmet Kontrol Noktası (SSCP) birimi, fiziksel birim (PU) ve mantıksal birim (LU). Her SSCP'nin kendisine ait bir etki alanı vardır, SSCP sadece kendi etki alanındaki PU ve LU'ları denetleyebilir. APPN şebeke kullanıcılarının istekleri doğrultusunda SNA fonksiyonlarının üzerine geliştirilmiş bir mimaridir. Mimari şebeke kullanıcıları ve yöneticilerinin isteyebilecekleri bir çok özelliği sağlamaktadır. Bunlar. Kullanım kolaylığı. Yönetim kolaylığı. Uygulamada getirmiş olduğu esneklik. Dinamik yönlendirme. LU'lar kayıt etme SNA'den fonksiyonel bakımdan daha üstün olduğu için, APPN'in diğer platformlarda da kullanılması SNA'e göre daha hızlı olmuştur. APPN'in güçlü mimari altyapısı yeni alanlarda olması muhtemel uyumsuzluk gibi olumsuz etkileri ortadan kaldırmıştır. APPN şebekelerinde üç tip temel düğüm vardır, bunlar; Alçak Giriş Şebekesi Düğümü, Uç Düğüm ve Şebeke Düğümüdür. VTAM ve NCP'nin birleşimi ile oluşan düğüm diğer düğümlere bir APPN düğümü şeklinde görünür. Bu tip XIIdüğümlere karma düğüm denir. APPN fonksiyonlarının sağlanması için birçok yeni SNA formatı gerekmektedir. Düğümlerin birbirlerini tanımları için gerekli olan yeni bir XID'yi de yeni gelen bu formatlardan biridir. XI D tip 3 formatı APPN'in dinamik doğasının gerektirdiği bazı özellikleri yerine getirmektedir. Kontrol noktasının (CP) APPN mimarisinde düğüm yöneticiliği gibi önemli bir görevi vardır. CP'nin katılımı olmadan; komşu düğümlerle olan bağlar aktif edilemez, CP-CP oturumu kurulamaz, partner LU'nun yeri bulunamaz ve düğüm ile ilgili hiçbir işlem gerçekleştirilemez. Bir düğüm tarafından gerçekleştirilmekte olan fonksiyon ve hizmetlerin büyük bir çoğu CP tarafından yerine getirilmektedir. APPN mimarisinde dinamik kaynak bulma ve yönlendirme çeşitli hizmetler tarafından yerine getirilmektedir.. Konfıgürasyon Hizmetleri şebekedeki komşu düğümler ile olan bağları yönetmekten sorumludur. Bu işlem veri bağ kontrol seviyesinde yapılır ve bütün APPN düğümlerinde mevcuttur. Hem LEN hem de EN düğümlerinde Topoloji ve Yönlendirme Hizmetleri bir yerel topoloji veri tabanını güncellerler. Bu yerel topoloji veri tabanında tüm komşu düğümlere olan bağlar ile ilgili bilgiler bulunmaktadır. Ancak, şebeke düğümlerinde (NN) yerel topoloji veri tabanının yanında tüm APPN şebekesine ait topoloji bilgisinin tutulduğu bir şebeke topoloji veri-tabanı da bulunur. Bu bilgi diğer şebeke düğümleri ile de paylaşılır. Şebeke düğümleri topoloji veri-tabanındaki bilgileri kullanarak uçtan uca veri gönderilirken kullanılacak olan optimum yol bulunur. Uç düğümler (EN) bu fonksiyonu gerçekleştirme yeteneğine sahip değildirler, bunun yerine bu isteklerini bağlı oldukları şebeke düğüm hizmetçisine (NNS) bildirirler.. Dizin Hizmetleri tüm APPN düğümlerinde bulunan bir hizmet tipidir. Sadece yerel kaynaklarını kullanan APPN uç düğümlerinde Dizin Hizmeti önce yerel veri-tabanını araştırır. Eğer aranan kaynak yerel veri-tabanı nda bulunamazsa CP-CP oturumu kurduğu şebeke düğümünden bu hizmeti alır. Uç düğümün birden fazla şebeke düğümüne bağı olsa da yalnızca bir Şebeke Düğüm Hizmetçisi ile CP-CP oturumu olabilir. Böylece EN bu yerel kaynaklarını Şebeke Düğüm Hizmetçisine kaydettirir. Şebeke düğümleri APPN şebekesindeki tüm kaynaklara ilişkin veri-tabanlarını günceller. Bu hizmeti hizmet ettikleri EN adına da yaparlar. Şebekedeki tüm kaynakları bir Merkez Dizin Hizmetçisine de kaydetmek mümkündür. Bu merkezi hizmetçilerdeki bilgilere erişme ancak Şebeke Düğümleri tarafından talep edilebilir. XIII. Topoloji ve Yönlendirme Hizmetleri; tüm APPN düğümlerinde bulunmasına rağmen uç düğümler ve şebeke düğümlerindeki hizmet ve fonksiyonları farklıdır EN düğümlerinde Topoloji ve Yönlendirme Hizmetleri bir yerel topoloji veri tabanını güncellerler. Bu yerel topoloji veri tabanında tüm komşu düğümlere olan bağlar ile ilgili bilgiler bulunmaktadır. Ancak, şebeke düğümlerinde (NN) yerel topoloji veri tabanının yanında tüm APPN şebekesine ait topoloji bilgisinin tutulduğu bir şebeke topoloji veri-tabanı da bulunur. Bu bilgi diğer şebeke düğümleri ile de paylaşılır. Şebeke düğümleri topoloji veri-tabanındaki bilgileri kullanarak uçtan uca veri gönderilirken kullanılacak olan optimum yol bulunur. Uç düğümler (EN) bu fonksiyonu gerçekleştirme yeteneğine sahip değildirler, bunun yerine bu isteklerini bağlı oldukları şebeke düğüm hizmetçisine (NNS) bildirirler. Şebeke düğüm hizmetçisi Yol Seçme Hizmetini onlar için yerine getirir. Topoloji ve Yönlendirme Hizmeti, LU-LU oturumları için iki LU arasındaki en kısa yolu bulmaktan sorumludur.. Oturum Hizmetleri; oturum kurulması sırasında gerekli hizmetlere başvurur ve bu hizmetleri koordine eder. Oturum Hizmeti, şebekeye doğru BIND'ın (oturum kurma isteği) gittiğinden emin olur ve Düğümler Arası Oturum Yönlendirme Hizmetini gerçekleştirmek için tüm ara düğümlere eşi olmayan bir oturum belirteci atar. Aynı zamanda bu oturum belirteçlerinin devamlılığını sağlamakla ve LU'lara LU-LU oturumlarının kurulmasında ve kesilmesine de yardımcı olur. Oturum Hizmetinin diğer bir görevi de APPN şebeke bilgilerini takas etmek için kullanılan CP-CP oturumlarını kurmak ve gerektiğinde de kesmektir. HPR, APPN fonksiyonlarının geliştirilmiş halidir. APPN fonksiyonları Hızlı İletim Protokolü (RTP) ve Otomatik Şebeke Yönlendirme (ANR) fonksiyonları ile geliştirilmesi sonucunda ortaya HPR mimarisi çıkmıştır. HPR gerçekte bir mimarinin sağlayabileceğinden daha fazla fonksiyonları içermektedir. Bu mimarilere göre HPR'da temel ve üst seviye yapılar bulunmaktadır. Üst seviye yapılar şunlardır.. İletim Fonksiyonu : Bu fonksiyon HPR düğümleri arasında bir RTP bağlantısının kurulmasını sağlar.. RTP Bağlantısını Kullanarak Akış Kontrolü : Bu fonksiyon kullanılarak tipik APPN akış kontrolünün RTP bağlantısı üzerinden yapılmasını sağlar. Eğer bu fonksiyon desteklenmiyorsa akış kontrolü için FID2 kullanılır.. Link Katmanı Hata Kotarma : Bu üst seviye yapı her bağlantıda oluşabilecek hataları minimum seviyeye indirir, böylece yüksek hızlı haberleşme ortamı yaratılmış olur. XIVRTP, bir HPR alt şebekesinde uç noktalar arasında çift yönlü bir iletim ortamı hazırlar. Bu bağlantı uçtan uca trafiğin aktığı sanal bir hat oluşmasını sağlar. Bu sanal hat RTP bağlantısı olarak adlandırılmıştır. Bu hat aynı zamanda düğümler için iki temel fonksiyonu da beraberinde getirir. Bu fonksiyonlar;. Uçtan Uça Hata Kotarma. Uçtan Uca Akış ve Tıkanma Kontrolü RTP temel fonksiyonların üzerine gelen üst seviye bir fonksiyondur. ANR, HPR düğümleri için yeni bir yönlendirme mekanizması getirmiştir. ANR'ın kullanılmasındaki en önemli amaç, APPN şebekesindeki ara yönlendirmeler nedeniyle oluşabilecek yükü ortadan kaldırmaktır. Bu yükün azaltılması üç ANR fonksiyonu sayesinde olmaktadır. Bu fonksiyonlar;. Kaynak Yönlendirme. Hızlı Paket Bağlaşması. Ara yünlendirme düğümlerinde kullanılmayan oturumu sezme TCP/IP, Amerikan Savunma Bakanlığı tarafından uzun ömürlü kullanıma sahip olması amacıyla geliştirilen bir protokol takımıdır. TCP/IP'de hata tespiti uç noktalar tarafından yapılmaktadır. İP şebekelerinde yönlendirme dinamik olarak yapılmaktadır. Paketler şebekede birbirlerinden bağımsız olarak yönlendirilmektedir. Şebekede paketlerin gidebilecekleri yolların ve kullanılan algoritimlerin bilinmesine rağmen paketlez zaman zaman kaybolabilmektedir. Kaybolan bu paketlerin kotarılması IP'nin üzerindeki bir katmanda yer alan TCP ve UDP'nin sorumluluğundadır. İP şebekeleri ile sadece bir şebeke mimarisi oluşturulmamış, bununla birlikte dosya iletimi ve uzaktan şebeke girişi sağlama gibi bir takım uygulama standartları da geliştirilmiştir. SNA, APPN, HPR ve İP protokollerinin ortak bir şebekede birleştirilmesi için farklı yöntemler geliştirilmiştir. Bu yöntemler genel olarak iki grupta toplanabilir: Yazılım ve donanım çözümleri. Donanım, bu konuda iki farklı çözüm sunar. Farklı protokoller için ek fiziksel yollar oluşturmak. Çoğullama yöntemi ile farklı protokolleri ortak bir şebekeden geçirmek Ek fiziksel yollar, farklı protokolleri ortak platformdan geçirmek için en basit yoldur. Protokoller fiziksel olarak birbirlerinden ayrılmıştır. Protokoller gerçekte bütünleştirilmediği halde, şebeke yönetimi ortak bir platformdan gerçekleştirilebilir. Bu çözümü kullanmak için geçerli nedenlerden biri, ek protolün kısa bir süre için XVkullanılacak olmasıdır. Uzun süre kullanılmayacak bir protokol için fiziksel olarak birleştirilmiş bir şebeke kurmak ekonomik olmayacaktır. Güvenlik nedeniyle de şebekelerin fiziksel olarak ayrı tutulması tercih edilebilir. Farklı protokolleri ortak bir tabanda birleştiren çoğullayıcı donanımlar da vardır. Çoğullayıcılar karşılıklı olarak, farklı protokollerle gelen verileri anlaşabilecekleri bir protokole dönüştürürler. Farklı protokolleri taşımak için yazılım çözümleri de mevcuttur. Bu çözümlerden en basiti, çoğullayıcı donanım mantığında çalışır. Yazılım çözümü, yeni versiyonlara yükseltilmesi, bakımının daha kolay olması ve maliyetinin donamıma göre daha düşük olması nedeni ile avantajlıdır. Bunun yanında, daha yavaş olmaları ve üzerinde çalışmak için ek bie platforma ihtiyaç duymaları dezavantajlarıdır. Farklı protokolleri ortak bir tabanda birleştirmeyi hedefleyen standart yöntemler geliştirilmiştir. Bu yöntemler RFC lerde de yer almakta olup RFC 1356 ve RFC 1490 bunlardan biridir. RFC 1356 ve RFC 1490' da açıklanan her iki çözüm, desteklelen protokollerin ortak bir iletim ortamında kapsüllenmesi prensibine dayanır. Paketlerin içinde taşınan protokollerin tanımlanması için standart bir yöntem sunarlar. Bu bilgi, gelen veriyi destekleyip desteklemediğine karar vermesi gereken alıcı düğüm tarafından kullanılır. Bu yöntemler, şirketlerin, normalde birbirleri ile iletişimlerine izin verilmeyen şebekeler üzerinden sistemler arası veri transferi gerçekleştirmelerini sağlar. Farklı protokolleri ortak bir platformda birleştirerek, şirketlerin şebekelerini iyileştirmelerini sağlar. Yabancı bir protokolü ortak bir omurga şebekeden geçirmek için iki yöntem kullanılabilir:. Protokolü kapsülleyerek saydam bir şekilde şebekeden geçirmek. Protokolü ortak protokole dönüştürmek Şebeke üzerinde saydam aktarım yönteminde, protokol şebeke üzerinden herhangi bir kullanıcı verisi gibi geçirilmektedir, şebeke, aktarılan verinin içeriği hakkında bilgi sahibi değildir. Bunun yanında uç noktalar da aradaki şebeke bulutundan habersizdir. Bu yöntem, her tip protokolün omurgadan geçirilmesi konusunda basit çözüm sunarken, gerçek ortamlarda pek çok sorunu da beraberinde getirmektedir, şebekeden geçen trafik ve aktarım süresi artmaktadır. Alt alan SNA, APPN, HPR ve TCP/ İP protokolleri zaman aşımına karşı duyarlıdır. Zaman aşımı süreleri, ara şebekeden geçmek için gerekli ek yükler hesaba katılarak tasarlanmadığından, ek bir şebeke üzerinden geçilmesi durumunda zaman aşımı problemleri oluşabilir. Bu problemleri aşmak için alternatif çözüm, zaman aşımı süresinin uzatılmasıdır. Ancak bazı durumlarda süreyi değiştirmek mümkün XVIolmayabilir. Diğer bir çözüm, bağlantı seviyesindeki bazı mesajların (SNA arabirimlerindeki RR gibi) omurgaya girişte filtrelenmesidir. Bu çalışmada, Sistem Şebeke Mimarisi (SNA), İleri Eşdüzey Şebekesi (APPN), Yüksek Performans Yönlendirmesi (HPR) mimarileri ve İletim Kontrol Protokolü/ İnternet Protokolü (TCP/IP) protokol takımının mimari özellikleri ve çalışma mantıklarından bahsedilmiş ve bu mimarilerin birbirleri ile bütünleştirilmesine ilişkin yöntemler üzerinde durulmuştur. Çoklu protokol yapısına sahip katmanlı şebeke yapısına yer verilmiştir. Katmanlı şebeke yapısının bileşenleri olan katmanlar anlatılmıştır. Çoklu ortamlarda APPN (SNA) mimarisi ile TCP/IP'nin bütünleştirilme yöntemleri irdelenmiştir. Ayrıca bu mimarilerin bütünleştirilmesi kapsamında incelenen APPN'in, İP ile bütünleştirilmesine temel teşkil eden şebeke topoloji güncelleme mekanizması ayrıntılı bir şekilde incelenmiş ve bu mekanizma bilgisayar ortamında taklit edilmiştir. Tezde ayrıca, hazırlanan bu taklit programının çalışma mantığı akış diyagramları ile açıklanmıştır. XVII

Özet (Çeviri)

INTEGRATION METHODS OF APPN ARCHITECTURE AND OTHER NETWORKING ARCHITECTURES SUMMARY SNA is an hierarchical architecture which is developed by IBM. SNA consist of seven layers; Physical Layer, Data Link Layer, Path Control Layer, Transmission Control Layer, Data Flow Control Layer, Presentation Layer and Application Layer. In SNA, communication is controlled by VTAM (Virtual Telecommunication Access Method) and NCP (Network Control Program. Each Node communicates each other over a virtual path, conversations of node pairs called as session. Communication in SNA occurs between units. These units are in hierarchical order; SSCP (Service Service Control Point), PU (Physical Unit), Logical Unit (LU). Each SSCP has an domain. It can control the Pus or Lus in its domain. APPN has grown out of the demands of network users. Though the architecture has been available for quite a while, it was not until recently that APPN came into its own and IBM moved its considerable influence fully behind it. The architecture provides many of the features that network users and managers required. These include:. Ease of use. Ease of management. Flexibility in implementation. Dynamic routing. LU registration Because it is even more fully architected than subarea SNA, APPN has been able to expand into other platforms at a quicker pace than subarea SNA did. The strong architectural basis of APPN has allowed the design to prosper and expand into new areas without resulting in incompatibilities and inconsistencies. APPN XVIIInetworks consist of three basic types. These are LEN, EN, and NN. In addition, the combination of VTAM and NCP can provide the appearance of an APPN node to other nodes within an APPN network. This combined node is known as a composite node. The APPN node has been designed with a strong architectural viewpoint. This has led to the formation of a node structure that provides clear interfaces. These interfaces fulfill the need for expansion of the architecture and the development of a code base that provides the functionality of APPN. APPN node are described and the interface between components are defined in order to provide a method of creating an APPN node. Because it was built upon a new base, it was isolated from the architectural problems of subarea SNA. APPN architecture has defined three types of nodes. Each of these types provide a different level of support for the APPN architecture and was defined to allow a migration from subarea SNA. The three nodes types are:. Low-entry networking (LEN). End node (EN). Network node (NN) CP, no links to adjacent nodes could be activated, no CP-CP sessions could take place, no partner LUs could be located or routes established to, and no node operations would ever be executed. In APPN architecture dynamic resource allocation and dynamic routing is done by some services. These services;. Configuration Services. As part of the CP, Configuration Services manages all of the local links to adjacent nodes in the network. It does this at the Data Link Control (DLC) level and is present in all APPN node types.. Topology and Route Selection Services. Although Topology and Routing Ser vices are present on all APPN nodes, the functions and services differ some what from LEN and APPN End Nodes to APPN Network Nodes. On both LEN and APPN End Nodes, Topology and Routing Services maintain a local topology database. This local topology database includes information on links to all adjacent nodes. However, all APPN Network Nodes maintain not only a local topology database, but also a network topology database that includes information on the complete topology of the APPN network, both on the nodes themselves and the intermediate links between them. This information is col lected and exchanged with other Network Nodes. APPN Network Nodes are capable of using this topology database information to calculate optimum routes through the network from endpoint to endpoint in a session. End Nodes are not XIXcapable of this, but must request their Network Node Server to perform the Route Selection Services for them. For LU-LU sessions, the Topology and Routing Services provides the best route between the two LUs.. Directory Services. Directory Services also differ somewhat from End Nodes to APPN End Nodes and also to Network Nodes. In LEN End Nodes, Directory Services will only search for network resources defined in a local database. This is a consequence of the inability of LEN End Nodes to form CP-CP sessions. On APPN End Nodes, which maintain information on local resources only (usually meaning the LUs), Directory Services also searches the local database first. However, if the resource cannot be found locally, the APPN End Node may use the distributed search facilities provided by the APPN Network Node with which the APPN End Node has CP-CP sessions. And although an APPN End Node can be linked to more than one APPN Network Node, there can be active CP- CP sessions with exactly one, the current Network Node Server (NSS). So the APPN End Node may register these local resources at its Network Node Server. APPN Network Nodes maintain databases on all resources available throughout the entire APPN network. They can locate these on behalf of the End Nodes they serve (their domain). It is also possible to define a Central Directory Server for the complete registration of all network resources. Information from this central server may be requested from APPN Network Nodes when supplying Directory Services.. Session Services. In the Control Point, Session Services coordinates and invokes the required APPN Services in order to set up a session. HPR is an extension of base APPN functionality. It is extended through the use of two new components. These are RTP and ANR. HPR is actually more than a single architecture. Instead, it is a set of architectures that provide additional functionality that is supported by base APPN nodes. The architectures are provided in a typical base-and-tower structure. The towers defined by HPR include:. Transport option. The transport option allows the creation of an RTP connection between HPR nodes.. Control flows using RTP connection. This option allows for typical APPN control flows to flow across RTP connections. If this tower is not supported, these control flows use a FID2 transport. This tower requires that the node also support for the transport tower. xx. Link layer error recovery. This tower reduces error recovery along each connection. By reducing the overhead associated with error recovery at each node, higher speed connections can be supported. This tower is available with or without the transport tower. RTP provides a full-duplex connection between endpoints within an HPR subnetwork. This connection provides a virtual, end-to-end pipe through which session traffic flows. This is known as an RTP connection. This pipe also allows for two major additional functions for these nodes. These functions are:. End-to-end error recovery. End-to-end flow and congestion control ANR provides for the new routing mechanism for HPR nodes. The purpose of ANR is to reduce the overhead associated with intermediate routing nodes within an APPN network. The reduced overhead is a result of three key ANR functions. These functions are:. Source routing. Fast packet switching. No session awareness in intermediate routing nodes TCP/IP architecture was derived from some early work conducted by the DOD. The objective of this work was to create a network architecture that was highly flexible and could recover from almost any message failure. It also had to be highly dynamic in both its network routing and in operation; single-point of failure was not conducive to the objective of survivability. Routing through IP networks was dynamic. Each frame was independently routed through the network. Although the network learned about the available paths and algorithms that were developed to optimize routes, frames still often were lost in the network. Recovery of these frames is the responsibility of the higher layers, such as UDP and TCP. IP networks developed not only the network architecture, but also some“standard”applications, such as file transfer and remote logon. These applications were standardized through a consensus. As these applications were developed, they also became a component of the codebase for TCP/IP. Software techniques exist for the transportation of different protocols. The simplest of these provides for the same type of multiplexing as is exhibited by the hardware multiplexers. The distinguishing factor of the software solutions is that they are easier to upgrade and that they are normally lower in cost At the same time, XXIthey are generally slower and require a platform upon which they must operate. Software solutions also include several“standards-based”methods that allow diverse data streams to be incorporated into a common base of data transport. Both of these solutions define a method of encapsulating the supported protocols onto a common transport base. They also standardize how the messages that are transported can provide self-definition of what protocol is contained within the packets. This self-definition is used by the receiving station to determine how to support the incoming data. This support may be done by not supporting the protocol. In this case, the receiving station would reject either a connection that specified a protocol that it did not support, or would discard packets that specified one of these protocols. If the protocol is supported, the receiving station can provide the necessary support needed to pass the encapsulated data to its destination and the protocol support necessary to perform this transport. The protocol converter provides a dual image to the two network interfaces. The first image is a termination of the nonnative protocol. This protocol termination creates an endpoint for the nonnative protocol. At this point, the nonnative interface appears to have reached its destination. A second protocol interface is initiated at the converter. This second interface provides the path to the actual data destination. User data is extracted from the first interface and passed onto the second. The end user's view is that a contiguous path to the data destination exists. Theoretically, these users have no awareness of the discontinuous nature of the communication path. In order to actually provide this transparency, the protocol converter must add here to the respective protocols and allow some type of status coordination to be conducted by the protocol converter between the two sessions. By allowing this composite view of the network, the protocol converter can partake in the network management and can accurately reflect the status of the complete communication path. Thus, if a composite view of the network is available, the converter can show a nonactive status if either of the two sessions is unavailable. As has been alluded to, network management in this configuration can become a challenge. This is caused by the lack of a complete picture of the communication path and its status. The second mode of operation allows knowledge of the remote, nonnative interface to be communicated to the backbone management platform. In this case, knowledge of the remote network interface is passed to the backbone management platform. This situation allows for an accurate picture of network connectivity to be developed and utilized. The difficult point for the second mode of operation is to XXIIcreate a way of depicting the accurate status of the remote interface, while concurrently providing a consolidated view of the network availability. Often these are conflicting requirements that result in some type of compromised management view of the network. As has been alluded to, network management in this configuration can become a challenge. This is caused by the lack of a complete picture of the communication path and its status. In the case of the encapsulated, transparent transport through the backbone network, depiction of the actual transport path is difficult, if not impossible, This is because there must be a method of gaining awareness of the path that the transparent data takes through the backbone network and associating this with the path from the nonnative attachment and the data destination. This is a very difficult association to make and one that can often dynamically change. The ability to depict this path is normally not included. It is the responsibility of the network control technician to understand that this is occurring and to determine whether connectivity exists through the backbone. Network management of the protocol converter can occur in two modes. The first is a limited management interface that terminates at the converter; there is no awareness of the status of the remote nonnative network by the management interface of the backbone network. DLSw was created as a standard method of allowing SNA and NetBIOS data to be transported across a nonnative network. An IP transport network is the foundation of the backbone between DLSw nodes. This type of network architecture is created for several reasons. Among these are the inexpensive cost of TCPIIP components. There has been such a growth in this segment of the networking arena that these components have become commodities. The development of client server products that have been built on inexpensive platforms that often use TCPIIP as their native transport has increased the development of IP-based networks. The objective of DLSw was to develop a standard method of allowing SNA and NetBIOS to be transported across IP-based networks. Although several vendors had developed proprietary methods, interoperability was all but impossible. As the demands for this type of configuration are large, the design had to overcome several potential problems. Among these were:. Session timeouts caused by the long delay in acknowledgments arriving at an origin. XXIII. The retransmission to a destination was done locally, rather than requiring retransmission across the WAN interface.. Reducing the broadcasts that are carried across relatively slow WAN interfaces.. The multiplexing of multiple LLC sessions across a single TCP/IP session. The interconnection between DLSw nodes is that of a virtual bridge. This bridged configuration allows the interface between a pair of DLSw nodes to be viewed as a single hop. The elimination of hops is especially important for token ring networks.Addressing between DLSw nodes is complex. The first level of addressing is of the logical connection between a pair of DLSw nodes. In this study System Network Architecture (SNA), Advance Peer to Peer Network (APPN), High Performance Routing (HPR) architectures and TCP/IP protol suite is mentioned. Also integration methods of these architectures are analyzed. Multi- protocol networks and its components are examined. In these kind of networks, integration of APPN architecture and TCP/IP is discussed. Network topology update, which is the keyword of integration of APPN and IP, is described and is simulated by a Java based program in a computer environment. Logic of the program is explained with flow charts in the thesis. XXIV

Benzer Tezler

Geri Dön