Wśród protokołów sieciowych opracowanych dla pakietowych sieci komputerowych najpopularniejszym jest protokół IP. Wiele sieci, zarówno rozległych (np. Internet), jak i lokalnych (typu Ethernet, Token Ring czy FDDI) wykorzystuje IP w warstwie sieciowej do transferu danych. W każdym z tych przypadków protokół IP uwzglednia własności i specyfike wymienionych protokołów warstw niższych.

Z uwagi na powszechnośa stosowania IP, wynikającą z jego niewątpliwych zalet, projektanci systemu ATM podjeli działania mające na celu adaptacje protokołu IP do współpracy z siecią ATM.

Prace ATM Forum oraz grupy roboczej Internetu, IETF, doprowadziły do przygotowania specyfikacji protokołu znanego pod nazwą „IP over ATM" (IPoATM). Zasady IPoATM zostały opublikowane w materiale RFC 1577. Zgodnie z tą specyfikacją możliwa jest integracja sieci ATM z pakietowymi sieciami komputerowymi stosującymi protokoły TCP(UDP)/IP.

IPoATM (określane też mianem „Classical IP over ATM" w celu odróżnienia tej propozycji od nowych koncepcji) może bya traktowane jako uzupełnienie (rozwiązanie komplementarne) standardu emulacji LAN. IPoATM ma na celu, podobnie jak LANE, umożliwia realizacje aplikacji współpracujących sieci LAN, bez ich modyfikacji, koncentrując sie jednakże wyłącznie na wykorzystaniu sieci ATM do integracji sieci jednorodnych, tj. z protokołami IP.

Zarówno LANE, jak i IPoATM, nie wykorzystują jednej z najważniejszych cech połączen ATM – możliwości żądania wymaganej jakości transmisji QoS. Przyczyny są różne. LANEz definicji ukrywa własności ATM przed wyższymi warstwami i udaje zwyczajną siea LAN. Natomiast „Classical IP over ATM" nie w pełni wykorzystuje możliwości ATM, ze wzgledu na ograniczenia obecnej wersji IP (IPv4). Wraz z rozwojem wersji 6 IP (ang. IP Next Generation) spodziewane jest wykorzystywanie QoS.

Środowisko Internetu jest zainteresowane możliwością wykorzystania technologii ATM w strukturach sieci globalnej. Technika IPoATM oferuje nowe możliwości integracji i rozwoju zarówno środowisk sieciowych Internetu, jak i ATM. Oprogramowanie IPoATM (zgodnie ze specyfikacją RFC 1577) może bya zainstalowane w adapterach ATM, routerach ATM i innych urządzeniach brzegowych wspomagających współprace sieci ATM z sieciami IP.

Protokół „Classical IP over ATM" jest prosty koncepcyjnie i łatwy w implementacji. Może on funkcjonowaa zarówno w sieciach ATM ze stałymi połączeniami wirtualnymi (PVC), jak i komutowanymi (SVC), pozwalając na realizacje połączen w obrebie tzw. logicznych sieci IP ustawionych w sieci ATM (ang. LIS - Logical IP Subnetwork). Aby efektywnie realizowaa bezpołączeniowy transfer pakietów (datagramów) protokołu IP, poprzez zorientowane połączeniowo sieci ATM, konieczne staje sie odwzorowywanie adresów IP stacji w adresy ATM bądź identyfikatory ID połączen wirtualnych w sieci ATM (obejmujące identyfikatory ścieżki i kanału logiczno-wirtualnego). Dokument RFC 1577 definiuje też zasady enkapsulacji, bądź „wkładania", pakietów IP w struktury danych ATM oraz opisuje mechanizmy zestawiania i uaktualniania połączen miedzy stacjami bądź systemami. Zasadnicza cześa specyfikacji IPoATM dotyczy transferu danych w obrebie jednej logicznej sieci LIS. Połączenia miedzy różnymi podsieciami LIS muszą odbywaa sie poprzez routery, nawet wtedy, gdy pomiedzy tymi podsieciami istnieje fizyczne połączenie ATM (rysunek 5.1).

Rys.5.1 Przesyłanie pomiedzy podsieciami LIS


Odwzorowanie sieci ATM w siea IP – definicja podsieci LIS

W specyfikacji protokołu IPoATM istnieje pojecie logicznej podsieci IP LIS (ang. Logical IP Subnetwork). Określa ono grupe stacji i routerów dołączonych do jednej sieci ATM i tworzących zamknietą logicznie podsiea IP.

Podsiea LIS stanowi samodzielną jednostke administracyjną sieci ATM. Działa i komunikuje sie z otoczeniem niezależnie od innych podsieci LIS zdefiniowanych w tej samej sieci ATM. Urządzenia wewnątrz jednej podsieci LIS komunikują sie ze sobą bezpośrednio, przy pomocy połączen wirtualnych ATM. Stacje wchodzące w skład podsieci LIS nie muszą bya umieszczone fizycznie blisko siebie, gdyż na połączenia wirtualne nie są nałożone ograniczenia odległościowe.

Połączenie pomiedzy urządzeniami należącymi do różnych podsieci LIS przechodzi przez router IP, który należy do jednej lub wiecej podsieci LIS i bezpośrednio znajduje sie w sieci ATM. To rozwiązanie pozwala na łączenie bardzo dużej liczby podsieci LIS w ramach jednej sieci ATM. Podział sieci ATM na dwie podsieci LIS obrazuje rysunek 5.2.

Rys. 5.2 Odwzorowanie sieci ATM w siea IP

W każdej podsieci LIS znajduje sie jeden serwer ATMARP, który prowadzi usługi zamiany adresów IP w adresy ATM. Jest on dostepny pod tym samym adresem dla wszystkich urządzen LIS stosujących połączenia typu SVC. RFC 1577 nie określa w jaki sposób stacje poznają adres swojego serwera. Zazwyczaj konfiguracja wykonywana jest recznie, przez operatora sieci.

Urządzenia stosujące połączenia PVC nie muszą znaa adresu serwera ATMARP, gdyż nie stosują usługi zamiany adresu IP w ATM.

Dokument RFC 1577 definiuje precyzyjnie szereg własności urządzen należących do jednej podsieci LIS:

taki sam numer podsieci IP oraz maska adresu;

bezpośrednie połączenie z siecią ATM;

interfejs odwzorowujący adresy IP w ATM (ATMARP) i odwrotnie ATM w IP (InATMARP) w przypadku, gdy połączenia są typu SVC;

interfejs odwzorowujący adresy IP w VC, gdy połączenia są typu PVC;

możliwośa komunikowania sie z każdą stacją w podsieci LIS poprzez siea ATM;

każda stacja IP posiada własny adres ATM oraz adresy jednego lub wiecej (jeżeli stacja należy do kilku LIS) serwerów ATMARP należących do podsieci LIS.


Enkapsulacja pakietów LLC/SNAP

IPoATM umożliwia przesyłanie różnego typu pakietów warstwy sieciowej i transportowej, przy wykorzystaniu jednego połączenia w sieci ATM. Dzieki temu ograniczona została liczba utrzymywanych połączen oraz usuniete opóźnienia związane z każdorazowym nawiązywaniem połączenia.

Aby taka multipleksowana transmisja była możliwa, stacja docelowa musi rozróżniaa typy otrzymywanych pakietów. Dlatego każdy pakiet poprzedzany jest polem identyfikacyjnym. W specyfikacji IPoATM przyjeto enkapsulacje LLC/SNAP (ang. Logical Link Control/Subnetwork Acces Protocol). Multipleksacja pakietów nastepuje w podwarstwie LLC. RFC 1577 dopuszcza także inne metody enkapsulacji.

Pakiety IP są dostarczane do warstwy adaptacji ATM AAL i obsługiwane tam zgodnie z protokołem AAL5, opracowanym z myślą o transferze ruchu o zmiennej szybkości bitowej VBR i asynchronicznego UBR. Jednostki danych tego protokołu (AAL5 PDU) oprócz nagłówka LLC/SNAP, identyfikującego typ pakietu, zawierają oraz pole danych oraz informacje sterujące AAL5 (pole długości jednostki PDU i sume kontrolną CRC).

Dla protokołu IPoATM przyjeto standardową długośa pakietów IP równą 9180 bajtów, pozwalającą na obsługe ramek o maksymalnych długościach stosowanych w sieciach Ethernet, Token Ring, FDDI czy też SMDS (ang. Switched Multimegabit Data Service) bez konieczności ich podziału. Jednocześnie IPoATM dopuszcza, zgodnie ze specyfikacją protokołu AAL5, obsługe pakietów o długościach do 64-kilobajtów - wymaga to jednak skonfigurowania wszystkich stacji podsieci LIS tak, aby obsługiwały pakiety o tej samej długości. Zauważmy, że jest to również maksymalny rozmiar pakietów w sieci IP.


Format pakietów ATMARP i InATMARP

Wewnątrz podsieci LIS mechanizm zamiany adresów IP na ATM (i odwrotnie) oparty jest na protokołach:

ATMARP (ang. ATM Address Resolution Protocol)

InATMARP (ang. Inverse ATM Address Resolution Protocol)

Stanowią one odpowiedniki Ethernet’owych protokołów ARP i InARP. Wszystkie stacje podsieci LIS muszą obsługiwaa protokoły ATMARP i InATMARP.

W pakietach ATMARP i InATMARP zachowano format zbliżony do ich Ethernet’owych pierwowzorów: ARP i InARP. Używane są te same wartości w polach typu adresu, typu protokołu i kodu operacji. Dla zachowania zgodności również położenie wymienionych pól jest takie samo. Pozostałą cześa pakietu zajmują informacje specyficzne dla sieci ATM.

Pakiety ATMARP otrzymały unikatowy typ adresu. Stosowany jest także dodatkowy kod operacji odpowiadający odpowiedzi ARP_Nak. Poniższa tabela przedstawia format pakietów ATMARP/InATMARP opublikowany w RFC 1577:

 

Nazwa pola

długośa pola

Opis
ar$hrd 16 bitów typ adresu (dla ATM Forum 0x0013)
ar$pro 16 bitów typ protokołu (dla IP 0x0800)
ar$shtl 8 bitów typ i długośa źródłowego numeru ATM (q)
ar$sstl 8 bitów typ i długośa źródłowego pod_adresu ATM (r)
ar$op 16 bitów kod operacji

(ARP_REQUEST, ARP_REPLY, InARP_REQUEST, InARP_REPLY, ARP_NAK)

ar$spln 8 bitów długośa adresu protokołu źródłowego (s)
ar$thtl 8 bitów typ i długośa docelowego numeru ATM (x)
ar$tstl 8 bitów typ i długośa docelowego pod_adresu ATM (y)
ar$tpln 8 bitów długośa adresu protokołu docelowego (s)
ar$sha q oktetów źródłowy numer ATM (E.164 lub ATM Forum NSAPA)
ar$ssa r oktetów źródłowy pod_adres ATM (ATM Forum NSAPA)
ar$spa s oktetów adres protokołu źródłowego
ar$tha x oktetów docelowy numer ATM (E.164 lub ATM Forum NSAPA)
ar$tsa y oktetów docelowy pod_adres ATM (ATM Forum NSAPA)
ar$tpa z oktetów adres protokołu docelowego

Tabela.5.1 Format pakietów ATMARP/InATMARP opublikowany w RFC 1577

W zależności od typu stosowanych połączen (PVC lub SVC) wystepują różnice w sposobie odwzorowywania adresów.


Połączenia typu PVC

W sieciach ATM, ze stałymi połączeniami wirtualnymi (PVC), adresy IP są odwzorowywane w identyfikatory połączen wirtualnych (ścieżki VPI i kanału VCI) w sposób manualny. Oznacza to, że użytkownik każdej stacji jest odpowiedzialny za konfiguracje własnej tablicy adresowej, poprzez umieszczenie w niej par: adres IP stacji docelowej i identyfikator połączenia wirtualnego. Tego typu uproszczona konwersja adresowa może bya efektywna jedynie w przypadku małych sieci (czesto jednak bywa jedynym rozwiązaniem).

W przypadku wiekszych sieci stacje używają protokołu InATMARP. Każda stacja musi znaa własne połączenia PVC do innych stacji w sieci. W celu ustalenia adresu ATM odbiorcy, wysyłane jest do niego zapytanie InARP_Request po istniejącym połączeniu PVC. Sytuacja taka przedstawiona jest na rysunku 5.3. Stacja odległa odpowiada pakietem InARP_Reply, zawierającym jej adres IP.

Rys.5.3 Przesyłanie zapytania i odpowiedzi InATMARP w sieci ATM

Jeżeli stacja posiada wiecej niż jeden adres IP w podsieci LIS, to dla każdego adresu musi wysłaa odpowiedź InAPR_Reply.


Połączenia typu SVC

W przypadku realizacji w sieci ATM komutowanych połączen wirtualnych (SVC), stacje koncowe muszą dokonywaa odwzorowywania adresów IP na adresy ATM i identyfikatory połączen wirtualnych w sposób automatyczny, tj. na żądanie. Nieodzownymi elementami protokołu IPoATM stają sie wówczas algorytm ATMARP i serwer adresowy ATMARP. Serwer ten staje sie centralnym elementem każdej wirtualnej podsieci LIS. Utrzymuje on baze danych (tablice adresową) odwzorowującą adresy IP w adresy ATM wszystkich stacji w LIS. Kierowane są do niego prośby stacji koncowych, bądź urządzen brzegowych sieci ATM, o wskazanie nieznanego adresu ATM, odpowiadającego znanemu adresowi IP stacji docelowej.

Fizycznie serwer ATMARP jest pakietem oprogramowania zainstalowanym na serwerze plików bądź stacji roboczej. Może także rezydowaa w routerze, wzglednie przełączniku ATM w danej podsieci.

Procedura rejestracji nowego urządzenia w podsieci LIS rozpoczyna sie od otwarcia połączenia VC typu punkt-punkt do serwera ATMARP. Serwer po wykryciu połączenia od nowego klienta wysyła do niego zapytanie InATM_Request. Odpowiedź zawiera informacje konieczne do utworzenia nowej pozycji w bazie danych serwera.

W celu utrzymywania aktualnych informacji i minimalizacji rozmiaru tablicy, serwer wyrzuca pozycje, które nie były używane przez ostatnie 20 minut.

Na rysunku 5.4 przedstawiono proces łączenia sie dwóch stacji (A i B) należących do tej samej podsieci LIS z połączeniami SVC.

Kiedy stacja A chce wysłaa pierwszy pakiet do stacji B wysyła zapytanie ARP_Request do serwera ATMARP (1) o adres ATM stacji B. Serwer odszukuje w swojej bazie danych adres ATM odpowiadający adresowi IP zawartemu w zapytaniu i wysyła ten adres w odpowiedzi ARP_Response (2). Stacja A ustanawia bezpośrednie połączenie ATM (typu SVC) ze stacją B (3) i wysyła pakiet danych. Kiedy stacja B chce odpowiedziea na otrzymany pakiet, także wysyła zapytanie (4) do serwera ATMARP, aby poznaa adres ATM nadawcy. Po uzyskaniu tego adresu stacja B zazwyczaj orientuje sie, że już ma otwarte połączenie z takim adresem. Wobec tego nie bedzie ustanawiaa nowego połączenia. Od tego momentu możliwa jest dupleksowa, bezpośrednia komunikacja miedzy stacjami (5).

Rys.5.4 Proces łączenia sie stacji w ramach podsieci LIS

Warto zauważya, że w porównaniu z protokołem ARP sieci Ethernet, nie wystepuje tu nadmiarowośa przesyłanej informacji. W IPoATMzapytanie kierowane jest tylko do jednego serwera, a nie do wszystkich stacji w sieci.

W obrebie jednej podsieci LIS stacje komunikują sie za pośrednictwem wirtualnych połączen typu punkt-punkt. Pakiety IP są umieszczane w jednostkach PDU protokołu AAL5 w urządzeniach brzegowych sieci ATM. Komórki ATM tworzone z jednostek PDU są nastepnie przesyłane przez wezły i przełączniki sieci ATM do miejsca ich przeznaczenia lub urządzenia brzegowego sieci ATM. Tam nastepuje złożenie komórek w jednostki PDU i utworzenie pakietu IP.

Z punktu widzenia warstwy sieciowej (protokołu IP) transmisja przez siea ATM jest jednoetapowa, bez wzgledu na liczbe przełączników uczestniczących w przekazywaniu komórek ATM.


Routery w ATM – łączenie stacji należących do różnych podsieci LIS

Opisany powyżej protokół IPoATM może funkcjonowaa jedynie na obszarze jednej logicznej podsieci LIS. Komunikacja pomiedzy odrebnymi podsieciami LIS, zdefiniowanymi na obszarze danej sieci ATM, wymaga użycia routerów, łączących poszczególne podsieci LIS.

Rozważmy transmisje danych miedzy dwiema stacjami w odrebnych podsieciach LIS połączonych routerem. Oprogramowanie IP rozpoznaje sytuacje, kiedy stacja chce wysłaa pakiet pod adres nie należący do danej podsieci LIS. W takim wypadku pakiet kierowany jest do routera wyznaczonego dla tej sieci. Gdy istnieje połączenie stałe PVC adres routera ustalany jest według zawartości tablicy adresowej stacji. W przypadku podsieci LIS z połączeniami SVC, wysłanie pakietu poprzedza zapytanie do serwera ATMARP o adres ATM-owy routera. Stacja nadawcza dokonuje podziału pakietu IP na komórki ATM, a router składa je z powrotem w pakiet IP. Nastepnie router odczytuje adres IP przeznaczenia pakietu i powtarza cały proces, przesyłając pakiet do stacji docelowej.

Wymagane jest wiec zestawienie dwóch połączen wirtualnych oraz segmentacja i scalanie przesyłanego pakietu.

Takie wykorzystanie routerów zapewnia bezpieczenstwo i umożliwia filtrowanie ruchu w sieci. Spada jednakże szybkośa transmisji, a routery mogą czesto pracowaa przeciążone. Zapobiec może temu odpowiednie konfigurowanie podsieci LIS. Czesto wykorzystywane zasoby dzielone, takie jak serwery plików, powinny bya członkami kilku podsieci LIS. Ogranicza sie w ten sposób liczbe pakietów przesyłanych przez routery.


Rozszerzenia standardu RFC 1577

Wąskim gardłem klasycznego IPoATMjest brak możliwości bezpośredniej transmisji miedzy różnymi podsieciami LIS. Problem jest poważny, gdyż routery nie są w stanie realizowaa funkcji decydujących o atrakcyjności ATM, tj. zarządzania jakością transmisji (QoS), minimalnego opóźnienia i dużej przepustowości.

Prowadzone są badania nad bardziej zaawansowanymi implementacjami IPoATM. Grupa MPOA (ang. Multiprotocol Over ATM), związana z ATM Forum, pracuje nad osadzeniem takich protokołów jak IP, IPX/SPX czy Appletalk na sieci ATM z pominieciem routerów.

Druga grupa – ROLC (ang. Routing over Large Clouds) – wywodzi sie z IETF. W kregu jej zainteresowania znajdują sie sieci ATM, Frame Relay i SMDS. Grupa ROLC przedstawiła propozycje protokołu NHRP (ang. Next Hop Request Protocol). Jest on podobny do protokołu ATMARP. Jednakże żądanie odwzorowania adresu jest przekazywane z jednego routera ATM do drugiego, aż do osiągniecia stacji docelowej lub routera brzegowego sieci ATM. Rozdział 5.8 poświecono na szerszy opis protokół NRHP.

Oddzielnym obszarem prac jest przygotowanie wersji protokołu wykorzystującego mechanizm rozgłaszania komunikatów w sieci ATM (IP multicast over ATM). Problem ten omówiono w rozdziale 5.9.


Protokół NHRP

W obrebie jednej sieci ATM może wystepowaa wiele podsieci LIS. Aby ułatwia transmisje pomiedzy stacjami należącymi do różnych podsieci LIS, został opracowany protokół NHRP. Umożliwia on stworzenie sieci NBMA (ang. Non-broadcast Multi-access), która pozwala na połączenie bardzo dużej ilości urządzen w sieci, ale niemożliwe jest przesyłanie wiadomości rozgłoszeniowych (typu multicast czy broadcast), jak typowe sieci LAN. Siea NBMA może obejmowaa całą siea ATM z wchodzącymi w jej skład podsieciami LIS.

W ramach jednej sieci NBMA możliwe jest wydzielenie wielu regionów samodzielnych administracyjnie, tzn. podsieci logicznych zwanych domenami. W każdej z nich może bya zaimplementowany protokół NHRP, który zezwala na bezpośrednie połączenia wewnątrz jednej domeny. Umożliwia też logiczne blokowanie połączen miedzy różnymi domenami (np. przez implementacje oprogramowania typu firewall).


Serwery NHS

Protokół NHRP zastepuje serwery ATMARP serwerami NHS (ang. Next Hop Server). Każda podsiea logiczna LIS posiada własny serwer NHS. Utrzymuje on tablice adresową odwzorowującą adresy IP w adresy ATM wszystkich stacji należących do danej podsieci, a także maski adresów sieciowych IP, dostepnych przez routery należące do domeny.

Podobnie jak w przypadku ATMARP, każda nowa stacja musi znaa adres serwera NHS danej podsieci IP i wykonaa procedure rejestracji.

Różnica pomiedzy serwerami ATMARP a NHS polega na sposobie zestawiania połączenia miedzy różnymi podsieciami IP w ramach jednej sieci NBMA. W tym wypadku serwery NHS pracują jak routery.

Grupa ROLC proponuje dwa modele konfiguracji serwerów NHS: statyczny (określany ang. server mode) i dynamiczny (ang. fabric mode).

W modelu statycznym każdy NHS jest na stałe wyposażony w tablice routingu zawierającą maski adresów IP obsługiwanych przez wszystkie inne serwery NHS w sieci NBMA. Takie rozwiązanie jest odpowiednie dla małych sieci.

Model dynamiczny przewiduje, że serwery NHS bedą same budowały tablice routingu w oparciu o algorytmy routingu. Zakłada sie także, iż na ścieżce wyznaczonej przez algorytm znajdzie sie serwer NHS obsługujący daną stacje docelową. W praktyce oznacza to, że wszystkie routery wyjściowe sieci NBMA muszą pracowaa jako serwery NHS dla adresów poza siecią NBMA, osiągalnych z tych routerów. Także routery obsługujące stacje podłączone bezpośrednio do NBMA muszą jednocześnie bya ich serwerami NHS.


Zasada działania protokołu NHRP

Każda stacja, która wysyła pakiet do innej stacji w sieci NBMA, formułuje zapytanie NH_Request o adres ATM odbiorcy i przesyła je do „własnego" serwera NHS (na rysunku 5.5 (1)). Serwer NHS sprawdza, czy adres odbiorcy znajduje sie w bazie serwera. Jeżeli tak, zwraca go w odpowiedzi NH_Reply. W innym przypadku, serwer NHS sprawdza w tablicy routingu, który serwer NHS znajduje sie na ścieżce do odbiorcy i przesyła do niego zapytanie (2). Zapytanie przesyłane jest pomiedzy serwerami NHS (3 i 4) do momentu, gdy jeden z nich stwierdzi, że poszukiwana stacja należy do jego domeny.

Rys.5.5 Schemat przesyłania zapytania i odpowiedzi miedzy serwerami NHS

Wtedy wysyła odpowiedź NH_Reply tą samą drogą, którą przybyło zapytanie, poprzez wszystkie serwery NHS biorące udział w transmisji zapytania. Działanie to ma na celu uaktualnienie tablic wszystkich wspomnianych serwerów NHS (zapamietanie adresów stacji docelowej i serwera NHS obsługującego podsiea IP o danej masce). Dzieki temu, nastepnym razem, serwer może udzielia odpowiedzi bez konieczności przesyłania zapytania do innych serwerów NHS, upraszczając całą procedure ustalania adresu ATM odbiorcy. Jednak stacja może zażądaa wyszukania z pominieciem zapamietanych adresów (ang. authoritative mapping).


Bezpieczeñstwo i ograniczenia protokołu NHRP

Zasada działania protokołu NHRP pozwala na zestawienie połączenia pomimo zakazów administracyjnych.

W celu rozwiązania problemu bezpieczenstwa i ograniczen dostepu serwery NHS mogą zwracaa adres odpowiedniego serwera firewall, zamiast adresu stacji docelowej. Można także wykorzystaa filtracje adresów na poziomie sieci ATM, w celu uniemożliwienia zestawienia bezpośredniego połączenia z zewnątrz do danej sieci logicznej.

Zapamietywanie dróg nowych serwerów może spowodowaa powstanie petli w systemie routerów. ROLC zaleca wprowadzenie dodatkowych komunikatów miedzy serwerami NHS, które informowałyby o wykrytych zmianach w topologii routingu, przez umieszczenie w odpowiedzi bitu wskazującego czy dane połączenie bedzie stabilne. Jeżeli tak nie jest, to serwery NHS nie powinny zapamietywaa adresu ATM.

Inną słabością protokołu jest niezdolnośa do autokonfiguracji, co koliduje z założeniami sieci ATM.


Przesyłanie wiadomości do wszystkich lub grupy użytkowników

Standard IPoATM nie umożliwia przesyłania wiadomości rozgłoszeniowych (typu broadcast i multicast). W tym celu został wprowadzony nowy serwer o nazwie MARS (ang. Multicast Address Resolution Server), bedący ewolucją serwera ATMARP. Jego zadaniem jest odwzorowywanie adresów IP typu rozgłoszeniowego w grupe adresów ATM.


Przesyłanie wiadomości do wszystkich użytkowników

Serwer MARS posiada baze danych w postaci {adres broadcast; ATM1, ATM2,...ATMn} i może obsługiwaa wiecej niż jedną podsiea LIS. W przypadku rozgłaszania (broadcastingu) wszystkie rejestrujące sie stacje są dopisywane do jednej grupy. Dlatego, aby uniknąa niekorzystnych nastepstw, rekomendowany jest jeden serwer MARS dla każdej podsieci LIS.

Każda stacja musi rejestrowaa sie w serwerze MARS. W tym celu wysyła komunikat MARS_Join. Serwer MARS dopisuje ją do bazy danych i rozsyła jej adres ATM do wszystkich aktywnych stacji zarejestrowanych w bazie. Dzieki temu mogą one dynamicznie dodaa nowy wezeł do istniejących połączen punkt-wiele_punktów.

Kiedy stacja chce wysłaa wiadomośa do wszystkich użytkowników, wysyła zapytanie MARS_Request do serwera MARS (rysunek 5.6). W odpowiedzi MARS_Reply otrzymuje ona adresy ATM wszystkich stacji zarejestrowanych w bazie. Nastepnie stacja nadawcza ustala połączenie typu punkt-wiele_punktów ze stacjami o otrzymanych adresach ATM. Stacja nadawcza jest tu korzeniem. Gdy serwer MARS nie posiada adresów grupy, wysyłana jest odpowiedź negatywna MARS_Nak.

Rys.5.6 Przesyłanie wiadomości do wielu użytkowników

Wiadomości typu broadcast mogą bya wysyłane w dwóch różnych przypadkach:

· do wszystkich klientów LIS, gdy znane są adresy IP i maska podsieci;

· do wszystkich klientów sieci fizycznej bez znajomości adresów IP oraz maski.

W przypadku sieci Ethernet rezultat wysyłania wiadomości typu broadcast w obu przypadkach bedzie identyczny. Wiadomośa otrzymają wszystkie stacje, niezależnie czy są one w innej podsieci logicznej lub też nie są stacjami IP.

Ze wzgledu na to, że protokół ATM jest zorientowany połączeniowo, stacje należące do podsieci LIS powinny zarejestrowaa sie w serwerze MARS. W sytuacji, gdy jedna ze stacji nie zarejestruje sie, wysłanie wiadomości typu broadcast, w wyżej wymienionych wypadkach, nie bedzie miało identycznych rezultatów.


Przesyłanie wiadomości do grupy użytkowników

Obsługa przesyłania wiadomości do grupy użytkowników może bya rozwiązana w dwojaki sposób:

· tak jak jest to opisane powyżej dla przesyłania wiadomości do wszystkich użytkowników, gdy serwer MARS wysyła tylko adresy ATM należące do wskazanej grupy, a stacja jest odpowiedzialna za ustanowienie połączenia typu punkt-wiele_punktów (rysunek 5.6);

· wprowadzenie nowej jednostki jaką jest serwer MCS (ang. Multicast Server), obsługującej grupe rozgłoszeniową. W tym wypadku serwer MARS wysyła adres ATM aktywnego serwera MCS obsługującego daną grupe (rysunek 5.7).

W pierwszym przypadku rejestracja odbywa sie identycznie jak w przypadku przesyłania wiadomości do wszystkich użytkowników, ale stacja musi podaa grupe adresów, do której chce należea. Wysłanie wiadomości wymaga w tym wypadku podania grupy, dla której jest ona przeznaczona. Baza danych serwera MARS posiada po jednej pozycji typu {adres grupy: ATM1, ATM2,...ATMn}dla każdej grupy rozgłoszeniowej.

W drugim przypadku po rejestracji stacji w serwerze MARS komunikat przekazywany jest dalej do serwera MCS, który obsługuje grupe rozgłoszeniową, do której nowa stacja chce dołączya. Serwer MCS dodaje wtedy nowy wezeł do połączenia punkt-wiele_punktów.

Rys.5.7 Przesyłanie wiadomości do grupy użytkowników z serwerem MCS

Jeżeli stacja podsieci LIS chce wysłaa wiadomośa do grupy, wysyła ją do serwera MCS, który przesyła ją dalej do wszystkich członków grupy (rysunek 5.7). W tym rozwiązaniu każda grupa posiada własny serwer MCS.

Serwer MCS może obsługiwaa kilka grup, ale musi wtedy umiea rozpoznawaa, do której grupy kierowana jest wiadomośa według zawartości AAL_SDU. Taki serwer MCS rejestruje sie u serwera MARS jako serwer MCS dla kilku grup i posiada po jednym połączeniu punkt-wiele_punktów dla każdej z grup. Połączenie usuwane jest dopiero w przypadku zakonczenia pracy serwera MCS lub gdy nie ma już żadnych liści (poszczególne stacje po kolei wyrejestrowały sie).

Serwery MARS i MCS mogą dzielia ze sobą fizyczne interfejsy, ale każdy z nich musi miea własny adres ATM.

Serwer MARS może przesłaa wiadomości o zmianie grupy. Wśród przesłanych adresów ATM do serwera MCS te, które są nowe, dołączane są do połączenia jako kolejne liście, a te, których brakuje są usuwane.

Centrum Informatyczne Trójmiejskiej Akademickiej Sieci Komputerowej
ul. G. Narutowicza 11/12, 80-233 Gdańsk   |   tel. 58-347-24-11
email: office@task.gda.pl   |   NIP: 584-020-35-93