WUSK’99 WieloUslugowe Sieci Korporacyjne

28

Piotr Pacyna {pacyna@kt.agh.edu.pl}

WSPÓLPRACA IP I ATM ? MOZLIWOSCI I PERSPEKTYWY

Streszczenie: W miare rozwoju sieci lokalnych i rozleglych pracujacych w oparciu o protokól IP, rosnie potrzeba ich integracji z innymi technologiami sieciowymi dla zapewnienia uniwersalnej, jednolitej platformy, w której mozna bedzie implementowac rózne aplikacje. Wsród tych technologii, bardzo wazna jest ATM. Sieci IP i ATM, jakkolwiek bardzo rózne, moga ze soba wydajnie wspólpracowac, tworzac srodowiska hybrydowe laczace zalety obu tych technologii i uzupelnia-jace sie nawzajem. Jednakze wybór odpowiedniego rozwiazania wymaga znajomosci ich zalet, wad i ograniczen. Celem tego opracowania jest wskazanie potencjalnych mozliwosci wspólpracy IP z ATM i zarysowanie mozliwych kierunków migracji takich srodowisk.

Slowa kluczowe: IP, ATM, LANE, Classical IP, MARS, MPOA, NHRP, multicast, IPv6

1 WSTEP

Niniejsze opracowanie koncentruje sie na dwóch niezwykle waznych, a równoczesnie kontro-wersyjnych technologiach sieciowych: technologii zwiazanej z protokolem Internet Protocol (IP) oraz technologii Asynchronous Transfer Mode (ATM). Watpliwosci towarzyszace tej pierwszej zwiazane sa z pytaniem o przydatnosc protokolu IP, postrzeganego coraz czesciej jako protokól stanowiacy uniwersalna platforme dla wprowa-dzenia róznorodnych uslug sieciowych. Kontrowersyjnosc technologii ATM - od samego poczatku projektowanej z mysla o integracji uslug - zwiazana jest z pytaniem o jej role w swiecie stop-niowo dominowanym przez IP i towarzyszace mu technologie sieciowe. Pytania te staja sie coraz bardziej aktualne, w miare jak postepuje rozwój Internetu. Rozwój ten powoduje, ze protokól IP juz teraz uznawany jest przez wielu za podstawowy, zajmujacy centralne miejsce w srednio- i dlugoterminowej polityce instytucji dzialajacych na rynku telekomunikacyjnym. Jakkolwiek trudno jest przewidziec przyszlosc, to jednak mozna przyjac, ze IP i ATM beda ze soba wspólpracowac, oraz ze moze nastapic czesciowe zatarcie sie róznic i granic pomiedzy tymi dwiema technologiami. Sytuacja ta jest o tyle zaskakujaca, ze obie technologie - IP i ATM - maja zupelnie rózny rodowód. Protokól IP, stosowany u swych poczatków w sieci ARPANET oraz w intranetach uniwersyteckich, sluzyl srodowisku akademickiemu do transmisji danych. Natomiast technologia ATM, ze swoja zaawansowana sygnalizacja, architektura i planem adre-sacyjnym, blizsza jest sieciom telekomunikacyjnym. Mimo to, musialo uplynac okolo pietnascie

29

lat od jej narodzin, zanim zostala 'dostrzezona' przez operatorów telekomunikacyjnych i uznana za te, która moze zaspokoic rosnaca potrzebe integracji podstawowych uslug telefonicznych, zaawansowanych uslug transmisji danych i uslug multimedialnych. Róznice pomiedzy sieciami IP i ATM widoczne sa takze w sposobie obslugi ruchu. Obecne sieci IP umozliwiaja transmisje pakietów o zmiennej dlugosci wedlug reguly 'best effort'. Bez-polaczeniowe uslugi unicast oraz multicast wykorzystuja broadcastowa nature wspóldzielonego medium transmisyjnego do rozwiazywania adresów IP w adresy MAC. Sieci IP nie oferuja mechanizmów, które umozliwialyby realizacje polaczen z przewidywalnymi parametrami jakosciowymi. Z tego powodu aplikacje nie stosuja metod wyrazania swoich wymagan w za-kresie jakosci obslugi (Quality of Service, QoS). Wyklucza to mozliwosc wprowadzenia do tych sieci waznej grupy aplikacji, obejmujacej aplikacje glosowe oraz wideo. Transmisja reali-zowana jest wedlug reguly 'best effort', co oznacza, ze pakiety sa wprowadzane do medium fizycznego, a mechanizmy kontroli przeplywu sprowadzaja siec do stanu równowagi w przy-padku natloku oraz wymuszaja retransmisje utraconych pakietów. Cechy te powoduja, ze sieci budowane obecnie w oparciu o IP staja sie niewystarczajace do tworzenia zintegrowanego srodowiska dla aplikacji o róznych wymaganiach w zakresie QoS.

Technologia ATM z kolei pracuje w trybie polaczeniowym, wobec czego fundamentalnym poje-ciem jest tu pojecie sciezki i kanalu wirtualnego (Virtual Path/Virtual Circuit, VP/VC). W zwiazku z polaczeniowa natura komunikacji, w ATM nie istnieja tak podstawowe uslugi jak multicast czy broadcast, kluczowe dla funkcjonowania technologii LAN. Z tego powodu ATM okresla sie mianem Non-Broadcast Multiple Access network (NBMA).

Uniwersalnosc ATM nie pozostaje bez wplywu na stopien jej zlozonosci. ATM w istocie jest technologia bardziej skomplikowana, niz jakakolwiek inna sposród obecnie stosowanych. O ile koncepcja komórki, o stalej wielkosci i ustalonej strukturze, sprzyja budowaniu wysokowydaj-nych urzadzen komutujacych, o tyle efektywna wspólpraca tych urzadzen wymaga bardzo duzej nadbudowy w postaci oprogramowania implementujacego liczne protokoly. Potrzeba stoso-wania tych protokolów jest w znacznej mierze nastepstwem polaczeniowego trybu pracy. Architektura tych protokolów determinuje sposób wspólpracy ATM z protokolami wyzszych warstw, w tym z IP.

Podstawowy protokól sygnalizacyjny, sygnalizacja styku terminal uzytkownika ? siec ATM (UNI 4.0 [2]), jest oparty na protokolach sygnalizacyjnych dla sieci publicznych ITU-T Q.2931 i Q.931. UNI 4.0 wykorzystuje protokól SSCOP (Service Specific Convergence Protocol Q.2100, Q.2110, Q2130), bedacy protokolem warstwy lacza danych, gwarantujacy poprawne dostar-czenie wiadomosci sygnalizacyjnej.

2 WYMAGANIA DOTYCZACE WSPÓLPRACY IP I ATM

Popularnosc Internetu oraz mnogosc aplikacji, które pracuja w oparciu o protokól IP, a z dru-giej strony wszechstronnosc zastosowan i duze przeplywnosci bitowe oferowane przez ATM doprowadzily do sytuacji, w której obie te technologie sieciowe sa czesto integrowane. ATM lokowana w warstwie lacza danych, a IP w warstwie sieciowej, stanowia bardzo obiecujaca kom-binacje. Jednakze ich wspólpraca ujawnia szereg trudnych problemów, w wielu przypadkach jeszcze nierozwiazanych. Trudnosci moga pojawic sie zwlaszcza wtedy, gdy w hybrydowej sieci IP/ATM uruchamiane sa aplikacje multimedialne, o nie zawsze precyzyjnie okreslonych wymaganiach jakosciowych, lub korzystajace z multicastowego trybu pracy.

30

Mozna uznac, ze hybrydowe sieci IP/ATM zaspokoja zróznicowane potrzeby dopiero wtedy, gdy obydwie technologie beda [1]:

?? przezroczyscie obslugiwac istniejace aplikacje, protokoly i systemy operacyjne, ?? zapewnia wzajemna translacje adresów IP i ATM, ?? zapewnia obsluge sesji polaczeniowych dla istniejacych aplikacji, ?? umozliwia obsluge sesji polaczeniowych i bezpolaczeniowych dla przyszlych aplikacji, ?? beda realizowac uslugi multicast, broadcast i anycast,

?? zapewnia wydajna wspólprace stacji przylaczonych do klasycznych sieci LAN oraz stacji przylaczonych bezposrednio do ATM.

3 WARSTWOWY MODEL WSPÓLPRACY IP Z ATM

Opracowanie schematu adresacyjnego dla sieci ATM bylo nastepstwem decyzji o przyjeciu tzw. warstwowego modelu wspólpracy (overlay model), który determinuje relacje i punkty styku pomiedzy protokolami sieci LAN a technologia ATM. Model ten rozdziela funkcje protokolów LAN i funkcje protokolów ATM, oraz wprowadza do ATM nowy plan adresacyjny, calkowicie niezalezny od obowiazujacych w sieciach LAN. W konsekwencji tego sieci ATM dysponuja wlasna przestrzenia adresowa oraz wymagaja stosowania protokolów rozwiazywania adresów (resolution protocol) w celu odwzorowania adresów uzywanych przez protokoly warstw wyz-szych, w tym przez IP, w adresy ATM. Dalsza konsekwencja przyjecia modelu warstwowego jest potrzeba okreslenia niezaleznego protokolu doboru trasy w sieci ATM.

Przyjecie modelu warstwowego spowodowalo, ze w bardzo wielu dokumentach, w tym w do-kumentach IETF RFC dotyczacych wspólpracy IP z ATM, ta druga jest postrzegana jako technologia warstwy lacza danych. Jest to o tyle paradoksalne, ze przeciez posiada wszystkie istotne cechy protokolu warstwy sieciowej, z których najwazniejsze to niezalezny protokól doboru trasy i wlasna adresacja.

4 ADRESACJA

Jedna z najwazniejszych funkcji protokolu UNI, wprowadzona juz w UNI 3.0/3.1, byl jedno-lity plan adresacyjny, który umozliwia identyfikacje urzadzen (ATM endpoints) w sieci. Zostal on wprowadzony przez ITU-T jako zgodny z planem E.164, obowiazujacym w publicznych sieciach telefonicznych. Aby umozliwic tworzenie wydzielonych sieci, ATM Forum rozsze-rzylo ten plan o dwa nowe typy adresów, oparte skladniowo na adresach OSI NSAP. Sa to: Data Country Code format (DCC format) oraz International Code Designator (ICD format). Dodatkowo, aby umozliwic wspólprace sieci wydzielonych z sieciami publicznymi, wprowa-dzono trzeci format umozliwiajacy odwzorowanie adresu E.164 w adres NSAP.

Adresacja okreslona w UNI 3.0/3.1 umozliwiala identyfikacje wylacznie pojedynczych stacji, a zestawianie polaczen punkt-wielopunkt wymagalo iteracyjnego przylaczania kolejnych stacji koncowych (add leaf). Dopiero nowa wersja protokolu sygnalizacyjnego UNI 4.0 wprowa-dzila pojecie adresów grupowych i mozliwosc zestawienia takiego polaczenia przy pomocy pojedynczego wywolania (call setup). Wciaz nierozwiazana kwestia pozostaja adresy anycast, tj. takie, w których adresuje sie jeden dowolny wezel, sposród tych, które oferuja specyficzna

31

usluge. Przy tego typu usludze przyjmuje sie, ze polaczenie powinno nastapic z tym wezlem, który znajduje sie 'najblizej' w sensie metryki stosowanego protokolu routingu.

5 REJESTRACJA ADRESÓW – ILMI

Aby ulatwic konfiguracje i zarzadzanie adresami ATM, w tym przede wszystkim przypisy-wanie adresów do interfejsów urzadzen koncowych, ATM Forum zdefiniowalo mechanizm rejestracji adresów poprzez protokól ILMI. Dzieki temu protokolowi interfejs sieciowy stacji koncowej moze poprzez styk UNI przekazac do komutatora swój adres MAC, i w odpowiedzi uzyskac brakujaca czesc pelnego adresu ATM (tzw. prefix sieciowy). Obecnie mechanizm ten wykorzystywany jest glównie w celu autokonfiguracji stacji, choc jego zastosowanie moze byc rozszerzone w przyszlosci. ILMI wykorzystuje protokól zarzadzania SNMP by pozyskac informacje z bazy MIB znajdujacej sie w komutatorze. ILMI nie wymaga konfiguracji, a jedynie uaktywnienia w stacji koncowej, bowiem dialog z komutatorem odbywa sie zawsze w kanale wirtualnym VPI/VCI 0/16. Funkcje ILMI nie ograniczaja sie do rejestracji stacji w sieci. ILMI pracujacy na styku miedzy-wezlowym poprzez NNI (Network-Node Interface) umozliwia np. okreslenie charakterystyki sasiedniego wezla sieciowego.

6 QOS ROUTING

Jednym z najwazniejszych osiagniec ATM Forum w ostatnim czasie bylo wprowadzenie proto-kolu doboru trasy Private Network-Node Interface (PNNI). Protokól ten zostal opracowany dla sieci prywatnych, tzn. stosujacych adresacje NSAP. Sieci publiczne ATM beda stosowaly inny protokól, oparty na protokole sygnalizacyjnym ITU-T B-ISUP. PNNI jest najbardziej zaawansowanym i równoczesnie najbardziej skomplikowanym protokolem sposród obecnie uzywanych. Zlozonosc ta wynika z ogromnej skalowalnosci, zdolnosci doboru trasy z uwzglednieniem wymagan jakosciowych marszrutowanego polaczenia (QoS-based routing) oraz nieistniejacej w protokolach typu spanning-tree mozliwosci doboru alternatyw-nych tras (alternate path routing). PNNI jest wiec protokolem marszrutujacym zadanie zestawienia polaczenia pomiedzy dwoma stykami UNI, oraz inicjujacym procedury alokacji zasobów w wezlach tranzytowych. PNNI jest rozszerzeniem sygnalizacji UNI, wprowadzajacym nowe obiekty sygnalizacyjne (information elements ? IE). Jego wspólpraca z UNI polega na tlumaczeniu, w brzegowym komutatorze, zadan sygnalizacyjnych pojawiajacych sie na styku UNI, na zadania sygnalizacyjne PNNI, i oczy-wiscie na translacji odwrotnej w wezle stacji docelowej. Wzajemna wspólprace UNI z PNNI niech ilustruje fakt, ze sygnalizacja miedzywezlowa PNNI odbywa sie w tym samym kanale wirtualnym VCI=5, który jest wykorzystywany do sygnalizacji UNI. Aby zminimalizowac ryzyko odrzucenia zgloszenia o ustalonych wymaganiach w zakresie QoS, protokól PNNI marszrutuje polaczenie kierujac sie wiedza o stanie sieci. Stan ten jest znany dzieki okresowemu rozglaszaniu przez wezly informacji o chwilowym obciazeniu oraz dzieki zaawan-sowanym mechanizmom 'uogólniania' tej informacji w duzych sieciach ATM. Metody uogól-niania pozwalaja uniknac rozrostu objetosciowego informacji wspomagajacej proces decyzyjny (topology state information) i przy tym maja scisly zwiazek z unikalna cecha hierarchicznego dobo-ru trasy. Hierarchicznosc protokolu polega na tym, ze niektóre decyzje podejmowane sa na róznych 'etapach' routowania przy wykorzystaniu informacji o róznym poziomie szczególowosci.

32

7 WSPÓLPRACA IP/ATM

Biorac pod uwage rosnaca potrzebe laczenia sieci LAN pracujacych w oparciu o protokól TCP/IP, oraz wlasciwosci technologii ATM, takie jak wysokie przeplywnosci bitowe, skalowalnosc, mozliwosc integracji uslug i mozliwosci róznicowania jakosci uslug (QoS), mozna uznac, ze zapewnienie wspólpracy ATM z sieciami TCP/IP bedzie mialo decydujace znaczenie dla suk-cesu rynkowego technologii ATM .

Ze wzgledu na warstwowy model wspólpracy ATM z innymi protokolami sieciowymi, stoso-wane sa tu dwa warianty wspólpracy. W wariancie pierwszym (tzw. native mode) wprowadza sie mechanizmy rozwiazywania adresów, by odwzorowywac adresy IP wprost w adresy ATM. Drugi wariant, prostszy, to zastosowanie koncepcji emulacji sieci lokalnej w sieci ATM, znany jako LANE.

8 LANE

Protokól emulacji sieci LAN na ATM (LANE) definiuje dla protokolu IP interfejs do sieci ATM. Interfejs jest identyczny z tymi, jakie sa stosowane w klasycznych sieciach LAN. Dzieki temu protokól IP moze pracowac w sieci ATM bez zadnych modyfikacji i odbywa sie to w sposób niewidoczny dla IP. Przejscie z technologii Ethernet do ATM polega wiec wylacznie na wy-mianie kart sieciowych Ethernet na karty ATM z zaimplementowanym protokolem LANE, tzw. Lan Emulation Client (LEC). Nie jest wymagana ingerencja w oprogramowanie systemowe ani uzytkowe, stosowane w tej stacji. Protokól LANE równiez nie wymusza zadnych zmian w ko-mutatorach, innych jak tylko uruchomienie i skonfigurowanie tego protokolu (Lan Emulation Server, LES/BUS).

Z punktu widzenia wspólpracy na styku stacja koncowa-siec, protokól LANE okresla interfejs pomiedzy klientem tej uslugi a siecia (interfejs LUNI). Wymaga on, by kazdy klient LANE po-siadal unikalny adres ATM, z którym jest kojarzony jeden lub wiecej adresów MAC (tzn. adres warstwy lacza danych), osiagalnych poprzez ten wlasnie adres ATM. Rozwiazywanie adresów MAC w adresy ATM i na odwrót jest podstawowa funkcja LANE. W ten sposób LANE staje sie protokolem mostowania adresów MAC za posrednictwem ATM (bridge). Dzieki niemu stacje koncowe moga zestawiac bezposrednie polaczenia pomiedzy soba w celu wymiany danych. Zesta-wione polaczenia sa podtrzymywane przez pewien czas, po uplywie którego zostaja automa-tycznie rozlaczone. Mechanizmy buforowania odwzorowan adresów MAC/ATM umozliwiaja szybkie odtworzenie polaczenia, gdy jest ono ponownie potrzebne. Podczas pracy urzadzenia sie-ciowego korzystajacego z LANE, pakiety danych sa kopertowane w stosowny pakiet LAN MAC.

Podstawowa wada LANE v. 1.0 bylo to, ze nie korzystal on ze sztandarowych 'dobrodziejstw' ATM, takich jak mozliwosc okreslania parametrów jakosciowych zestawianych polaczen. Sytu-acja ta ulegla zmianie w LANE 2.0, jednak watpliwosci co do skalowalnosci samego rozwiazania i wydajnosci pozostaly. Zaleta LANE jest mozliwosc obslugi polaczen multicastowych.

9 CLASSICAL IP

Transmisja jednostek dowolnego protokolu sieciowego warstwy trzeciej zgodnie z modelem warstwowym dotyka zawsze dwóch aspektów: 1) enkapsulacji pakietów oraz 2) rozwiazywa-nia adresów.

33

Enkapsulacja Aby uniknac zestawiania osobnych polaczen dla kazdego strumienia danych wymienianego pomie-dzy dwoma stacjami, okreslono dla modelu warstwowego dwie metody komunikacji (RFC1483). W rozwiazaniu okreslanym jako VC multiplexing otwierane sa osobne polaczenia dla kazdego protokolu warstwy sieciowej, wykorzystywanego przy transmisji danych pomiedzy dwoma stac-jami. Rodzaj protokolu, dla którego zestawiane jest polaczenie, jest sygnalizowany na etapie zestawiania polaczenia. Wszystkie strumienie generowane pomiedzy dwoma stacjami i wykorzys-tujace dany protokól sa multipleksowane w tym kanale wirtualnym (VC). Jest to rozwiazanie proste i dlatego stosowane w LANE. Moze byc stosowane wszedzie tam, gdzie bezposrednia lacznosc pomiedzy aplikacjami jest pozadana z pominieciem protokolów warstw nizszych. Jednakze takie rozwiazanie niestety wyklucza mozliwosc wspólpracy z wezlami sieciowymi pracujacymi w innej technologii niz ATM. W rozwiazaniu LLC/SNAP Encapsulation, pakiety nalezace do wielu protokolów sieciowych wspóldziela ten sam kanal wirtualny. Aby umozliwic poprawna identyfikacje pakietów przez stacje koncowa, sa one opatrywane naglówkiem Logical Link Control ? Service Network Access Point (LLC/SNAP). Stad nazwa tej techniki, stosowanej m. in. w metodzie Classical IP i MPOA.

Rozwiazywanie adresów Implementacja protokolu IP na infrastrukturze sieciowej ATM napotyka na zasadniczy problem wynikajacy z róznych wlasciwosci sieci lokalnych LAN, dla których pierwotnie opracowany byl protokól IP, oraz sieci ATM. W sieciach lokalnych powszechnie wykorzystywany jest pro-tokól ARP (Address Resolution Protocol), przy pomocy którego zostaje ustalony adres warstwy lacza danych, czyli tzw. MAC, odpowiadajacy adresowi IP stacji, do której adresowany jest pakiet. Ustalenie to odbywa sie na drodze zapytania skierowanego do wszystkich stacji, z których odpowiada jedynie posiadajaca wlasnie ten adres IP, o którym mowa w zapytaniu, lub router, który jest pierwszym wezlem tranzytowym na drodze w kierunku do tej stacji. Skierowanie zapytania do wszystkich stacji w sieci lokalnej mozliwe jest dzieki istnieniu wielodostepnego, wspóldzielonego medium transmisyjnego i istnieniu uslugi typu broadcast. ATM jest przykladem sieci typu non-broadcast multiple access, a wiec sieci tworzacej srodo-wisko pozbawione uslugi typu rozgloszeniowego. Prowadzi to do koniecznosci zaimplemen-towania specjalizowanej bazy (ATMARP server), przechowujacej wzajemne odwzorowania adresów IP i adresów warstwy lacza danych (NSAP address). Wraz z tym serwerem wpro-wadzone zostaje pojecie podsieci logicznej IP (Logical IP Subnet ? LIS) bedacej grupa stacji IP (hostów lub routerów), przylaczonych do tej samej fizycznej sieci ATM oraz nalezacych do tej samej podsieci IP (w sensie adresacji IP). Zestawienie polaczenia VC pomiedzy dowolnymi dwoma hostami nalezacymi do tej samej podsieci IP jest zawsze poprzedzone odwolaniem do ARP serwera w celu pozyskania adresu NSAP odleglej stacji. Aktualnosc bazy danych jest gwa-rantowana dzieki procedurze rejestracji w bazie kazdej stacji IP, po kazdym uruchomieniu stacji. Podstawowym ograniczeniem koncepcji Classical IP jest to, ze kazdy pakiet przesylany pomie-dzy hostami nalezacymi do dwóch róznych podsieci IP musi przejsc przez co najmniej jeden router, a wiec musi byc 'wyniesiony' z warstwy lacza danych do warstwy sieciowej, poddany routingowi, a nastepnie musi byc przekazany z powrotem do warstwy drugiej. Wprowadza to koniecznosc korzystania z co najmniej dwóch odcinków kanalu wirtualnego (do i od routera) oraz, co gorsze, opóznienia wynikajace z: 1) odtworzenia pakietu IP z komórek ATM w których byl przenoszony; 2) opóznienia kolejkowania w routerze; 3) przetworzenia pakietu przez modul doboru trasy; 4) ponownej segmentacji pakietu w komórki ATM z uwzglednieniem warstwy adaptacji AAL5. Drugie powazne ograniczenie wynika z braku obslugi multicastu.

34

10 NHRP

Powyzsze ograniczenie Classical IP doprowadzilo do opracowania substytutu modelu 'klasycz-nego', który ma postac nowych modulów oprogramowania rezydujacych w wybranych wezlach sieci ATM, majacych umozliwic zestawienie bezposredniego polaczenia VC pomiedzy komuni-kujacymi sie stacjami. Zestawienie takiego polaczenia wymaga znajomosci adresu NSAP odleglej stacji, który w tym przypadku jest ustalany poprzez skierowanie odpowiedniego zapy-tania do tzw. serwera NHRP. Kazda podsiec IP, w tym równiez podsiec stacji zamierzajacej zestawic polaczenie VC, musi w tym celu posiadac serwer NHRP, który moze byc dedyko-wany dla tej podsieci lub wspóldzielony przez kilka podsieci. Jezeli serwer obsluguje podsiec, do której nalezy odlegla stacja, wówczas podaje stacji pytajacej adres NSAP. W przeciwnym razie przekazuje zapytanie do serwera NHRP znajdujacego sie blizej stacji odleglej. Wybór kolejnego – 'blizszego' serwera – odbywa sie w oparciu o tablice routingu IP sieci Classical IP, z których korzystaja serwery NHRP. Przekazanie zapytania moze byc wielokrotne, az osiagnie taki serwer NHRP, który potrafi udzielic autorytatywnej odpowiedzi. Dzieki mechanizmowi NHRP, przez routery przechodzi tylko pakiet zapytania. Po ustaleniu adresu NSAP i przeka-zaniu go do stacji pytajacej, zostaje zestawione bezposrednie polaczenie VC (shortcut) pomiedzy stacjami, pomijajace posrednie routery IP. Z perspektywy pakietów IP, przejscie przez takie polaczenie jest traktowane jako jeden 'hop'. Wsród wad NHRP czesto wymienia sie brak mozliwosci autokonfiguracji, brak obslugi multi-castu, broadcastu oraz to, ze wspólpracuje wylacznie z protokolem IP.

11 MPOA

Standard MPOA, opracowany przez ATM Forum we wspólpracy z IETF, jest pierwszym, który umozliwia protokolom routowalnym wykorzystanie zalet sieci ATM. Rozszerza on mozliwosci LANE, Classical IP oraz NHRP poprzez wprowadzenie wystandaryzowanej metody rozproszo-nego mechanizmu doboru trasy. MPOA redukuje opóznienia przejscia pakietu przez siec, poprzez wyeliminowanie posrednich wezlów routujacych i wprowadzenie bezposredniego ka-nalu wirtualnego pomiedzy stacja nadawcza i odbiorcza. W tym celu funkcje klasycznego routera zostaja podzielone na dwie grupy. Pierwsza z nich (host functional group) obejmuje komunikacje pomiedzy stacjami koncowymi a urzadzeniami sieciowymi. Druga grupa (edge device functional group) realizuje uslugi sie-ciowe wlaczajac w to ustalenie trasy, która powinien byc przekazany pakiet. Zalozenia, które przyswiecaly twórcom MPOA, obejmuja:

?? umozliwienie komunikacji poprzez ATM na poziomie warstwy trzeciej, zarówno stacjom przylaczonym bezposrednio do ATM, jak równiez stacjom przylaczonym do ATM za posrednictwem routerów;

?? umozliwienie tworzenia podsieci IP lub podsieci pracujacych w oparciu o inne pro-tokoly;

?? umozliwienie stacjom przylaczonym do ATM bezposredniej lacznosci; ?? zastosowanie jednolitego, rozproszonego routingu pomiedzy róznymi segmentami

sieci, wykorzystujac zarówno mechanizmy routingu, jak mostowania, do zlokalizo-wania brzegowego urzadzenia sieciowego mozliwie najblizej stacji koncowej.

Dla osiagniecia tych zalozen MPOA integruje i wykorzystuje rózne techniki, w tym: LANE, NHRP, MARS-MCS (Multicast Address Resolution Server and Connection Server), sygnali-zacje UNI 3.1, enkapsulacje RFC1483 ? Tabela 1.

35

Tabela 1. Zestawienie metod implementacji IP na ATM

Model Zasieg Klient Serwer(y)

LANE ELAN LEC LECS, LES, BUS

Classical IP LIS klient ATMARP serwer ATMARP

MARS klaster klient MARS MARS, MCS

NHRP LAG NHC NHS

MPOA podsiec MPC MPS

12 MULTICAST W SIECI ATM

Obsluga polaczen multicastowych w srodowisku NBMA wymaga odrebnego serwera, tzw. serwera multicast, którego zadaniem jest utrzymywanie polaczenia ze wszystkimi stacjami, zainteresowanymi odbieraniem tych samych danych, i powielanie pakietów dla kazdej takiej stacji – Tabela 2. Zródla danych polaczone sa z serwerem kanalami wirtualnymi typu punkt-punkt, podczas gdy stacje odbiorcze sa przylaczone do serwera laczem typu punkt-wielopunkt. Sygnalizacja UNI 3.1 umozliwia iteracyjne dolaczanie przez wezel nadawczy do istniejacego kanalu point-to-multipoint kolejnych stacji (procedura root initiated join) [2, 7]. Sygnalizacja UNI 4.0 wprowadza nowy rodzaj adresów, tzw. adresy grupowe, dzieki którym mozliwe jest zestawienie polaczenia wielopunktowego w jednym kroku, jak równiez pózniejsze przylaczenie nowych czlonków, inicjowane przez samego przylaczajacego sie (leaf initiated join).

Tabela 2. Porównanie mozliwosci róznych technik IP/ATM pod katem realizacji uslugi multicast

model unicast multicast Broadcast

LANE tak tak tak

Classical IP tak - -

MARS mozliwe tak tak

NHRP tak - -

MPOA tak - -

MPLS tak tak -

IP multicast wykorzystuje taki wlasnie sposób zarzadzania kanalami wirtualnymi i powielania danych. Aby jednak mozliwe bylo poslugiwanie sie multicastowymi adresami IP w tym srodo-wisku (adresami klasy D), niezbedne jest rozwiazanie adresu multicastowego IP w zespól adresów, badz w jeden adres grupowy ATM NSAP. Funkcje te spelnia Multicast Address Reso-lution Server (MARS), bedacy rozszerzeniem stosowanego w Classical IP serwera ARP. MARS przezwycieza jedna z wad Classical IP, jaka jest brak wsparcia dla polaczen multicastowych. Wprowadzenie multicastu IP do sieci ATM generuje caly szereg skomplikowanych problemów, z których jeden to koniecznosc zastosowania w warstwie trzeciej multicastowego protokolu doboru trasy. Obecnie istnieje kilka propozycji takich protokolów, w tym Distance Vector Multicast Routing Protocol (DVMRP) oraz zyskujacy popularnosc Protocol Independent Multi-cast (PIM). Przypuszcza sie, ze w oparciu o takie protokoly beda generowane w przyszlosci optymalne drzewa polaczen, wykorzystywane pózniej przez protokól PNNI do zestawiania kanalów wirtualnych, rozwidlajacych sie mozliwie najblizej wezlów koncowych. Obsluga dy-namicznych polaczen multicastowych wymaga takze osobnego protokolu sygnalizacyjnego

36

(Internet Group Management Protocol, IGMP), który sluzy do rozglaszania faktu wystepo-wania w danej podsieci IP stacji nalezacych do grupy multicastowej. Jest to o tyle istotne, ze tylko wówczas wspomniane wczesniej protokoly routingu moga dobierac trasy w sposób optymalny. Obsluga multicastu jest wazna kwestia dla intranetów korporacyjnych. Umozliwia oszczedne gospodarowanie zasobami sieciowymi, w przypadku wielopunktowych polaczen telefonicz-nych za posrednictwem IP (voice telephony over IP, VoIP), w przypadku wideokonferencji, a przede wszystkim wtedy, gdy istnieje koniecznosc czestej lub wrecz ciaglej aktualizacji danych przechowywanych w wielu wezlach sieci koroporacyjnej. Pierwsza komercyjna usluga zbudowana w oparciu o IP multicast zostala uruchomiona w minionym roku w USA, gdzie jeden z najwiekszych producentów samochodów wykorzystuje ja do ciaglego rozsylania danych do sieci swoich resellerów. Trwaja tez przygotowania do uruchomienia serwisów informacyj-nych, pracujacych w trybie on-line, dotyczacych notowan gieldowych i informacji gospodarczych. W tym przypadku szacuje sie, ze grupy multicastowe moga osiagnac liczebnosc kilkunastu tysiecy stacji. Wazne jest to, ze informacja docierac bedzie do wszystkich niemal równoczes-nie, poniewaz replikacja danych prowadzona bedzie w róznych wezlach sieciowych, a nie w centralnym serwerze, który móglby miec trudnosci z obsluga tak duzej liczby klientów.

13 QOS W WARSTWIE SIECIOWEJ

Jednym z podstawowych zadan stawianych protokolom warstwy trzeciej jest zapewnienie uniwersalnej lacznosci pomiedzy wszystkimi stacjami pracujacymi w sieci, niezaleznie od rodzaju i wlasnosci sieci fizycznej, oraz zapewnienie jednolitego interfejsu dla protokolów warstw wyzszych – przede wszystkim protokolów transportowych. Biorac pod uwage dynamike rozwoju sieci, w których podstawowym protokolem jest IP, mozna smialo przyjac, ze obecnie jedynym protokolem mogacym zaoferowac uniwersalna lacznosc jest IP. Wobec tego, oraz wobec rosnacego zainteresowania technikami multimedialnymi, nalezy sie spodziewac, ze w niedlugim czasie powstawac beda róznorodne aplikacje korzystajace z IP, integrujace glos, grafike i obraz ruchomy. Wymaga to wprowadzenia rozszerzen protokolu tak, aby spelnic szczególne wymagania aplikacji w zakresie jakosci uslugi sieciowej, czyli quality of service (QoS). Kwestie te sa przedmiotem prac kilku grup roboczych w organizacji IETF (Internet Engineering Task Force) czuwajacej nad rozwojem Internetu. W efekcie ich prac powstalo kilka inicjatyw, które przygotowaly rózne modele sieci Internet uwzgledniajace potrzeby QoS. Najwazniejsze to: IntServ, DiffServ oraz MPLS. Model IntServ Model Integrated Services (IntServ) definiuje mechanizmy, dzieki którym mozliwa jest obsluga aplikacji z naleznymi im parametrami jakosciowymi. Rdzeniem tej koncepcji jest protokól sygnalizacyjny RSVP, stosowany przez stacje koncowe do przekazywania wezlom sieciowym parametrów definiujacych nature strumieni multimedialnych i wynikajacych z nich potrzeb trans-misyjnych. Parametry TSpec sa takze wykorzystywane do oceny i ewentualnego ingerowania w strumien w wezle, jezeli jego charakterystyka wykracza poza ramy kontraktu zawiazanego pomiedzy aplikacja a siecia, w oparciu o podany wczesniej zespól parametrów. Z tego powodu RSVP jest protokolem, którego funkcje sa zblizone do funkcji protokolów sygnalizacyjnych UNI oraz NNI, z tym, ze jego dzialania dotycza strumieni informacyjnych na poziomie warstwy trzeciej, tj. na poziomie pakietów IP, a nie komórek ATM – rys. 1 [11]. Translacja parametrów TSpec na odpowiadajace im parametry polaczen ATM stanowi osobne zagadnienie i zostala szczególowo potraktowana w dokumentach RFC dotyczacych wspólpracy modelu IntServ IP z ATM.

37

Istotna róznica pomiedzy sygnalizacja RSVP i ATM jest to, ze RSVP stosuje model, w którym rezerwacja jest inicjowana przez odbiorce strumienia. Daje to odbiorcy duza swobode w decy-dowaniu o tym, jakie parametry sa dla niego satysfakcjonujace i znakomicie ulatwia realizacje transmisji multicastowej, w której uczestnicza odbiorcy o róznych wymaganiach w zakresie QoS. Jednakze model ten nie znajduje prostego przelozenia na model stosowany w ATM, gdzie polaczenie wielopunktowe jest zawsze zestawiane przez nadawce, i w obecnej wersji sygnali-zacji UNI 4.0 nie dopuszcza heterogenicznosci odbiorców.

Aplikacja

FlowSpec.

WymaganiaQoS Gwarancje

w zakresie QoS

Kontraktruchowy

FlowID

VPI / VCI

RSVP

Sygnalizacja UNI / NNI

PIM,IGMP

RoutingPNNI

Packetscheduler

Trafficmanagement

Model IntServ

ATM

– warstwy transportowa i sieciowa

– warstwa lacza danych

Rys. 1. Wspólpraca modelu Integrated Services Internet z ATM pod katem wprowadzania QoS

Model DiffServ

Specyficzna cecha modelu IntServ jest to, ze zapewnia on gwarancje jakosciowe dla kazdej sesji z osobna, gdzie sesja jest wyznaczana jednoznacznie poprzez protokól (IP), adres docelowy i numer portu. Obsluga kazdej sesji wymaga wiec uruchomienia osobnych procedur sterowania i nadzoru nad kazdym strumieniem przechodzacym przez router (per micro-flow QoS guaran-tees). Jak mozna przypuszczac, takie podejscie pozwala osiagac bardzo precyzyjne gwarancje jakosciowe. Jednakze z drugiej strony jest to podejscie nieskalowalne i nie nadajace sie do zastoso-wania w sieciach szkieletowych, gdzie stosowane sa lacza o przeplywnosciach rzedu 622 Mbit/s, w których równoczesnie istnieje bardzo wiele sesji.

Problemy ze skalowalnoscia tego modelu oraz potrzeba wypracowania duzo prostszych mechaniz-mów, niz rozwiazania w relacjach end-to-end z rozbudowana sygnalizacja, doprowadzily do powstania w 1998 roku inicjatywy Differentiated Services (DiffServ). Jej celem jest opracowanie prostszych metod opartych o róznicowanie klas uslug dla ruchu IP. Mechanizm ten wykorzystuje pole Type of Service (TOS) znajdujace sie w naglówku pakietu IP do oznaczenia priorytetu, z jakim pakiet ten powinien byc przetwarzany w routerach. Idea modelu DiffServ zaklada istnie-nie tzw. routerów brzegowych, które poddaja ocenie pakiety przychodzace od uzytkownika i nadaja im okreslony priorytet w oparciu o zdefiniowany w routerze profil aplikacji, która wyge-nerowala pakiet, lub w oparciu o profil uzytkownika. Profile sa definiowane przez administra-tora sieci i odzwierciedlaja kontrakty zawarte pomiedzy operatorem sieci a uzytkownikami. Wewnatrz domeny modelu DiffServ, pakiety sa obslugiwane stosownie do okreslonych przez operatora regul PHB (Per-Hop Behaviour), które moga uwzgledniac rózne zasady kolejkowa-nia pakietów, odrzucania lub rózne sposoby doboru trasy. Model ten cieszy sie obecnie uznaniem producentów sprzetu, specjalistów od inzynierii ruchu, operatorów sieciowych i dostawców Internetu (ISPs). Panuje przekonanie, ze przyszle sieci

38

powinny oferowac QoS, ale przede wszystkim w sposób nieskomplikowany. DiffServ spelnia te oczekiwania i dodatkowo umozliwia jego stopniowe wprowadzanie: najpierw w postaci wy-dzielonych 'wysp' wspólpracujacych z obecnymi sieciami, a potem stopniowo pokrywajac coraz wieksze obszary. Ograniczeniem modelu jest bardzo mala ilosc klas ruchu, które mozna zdefi-niowac, oraz to, ze poszczególne strumienie w obrebie klasy nie sa od siebie izolowane. Istnieja propozycje, które rozwiazuja kwestie wspólpracy tych dwóch modeli, z których IntServ bylby stosowany w sieciach lokalnych i wydzielonych intranetach, natomiast DiffServ bylby stosowany w sieciach szkieletowych – rys. 2. Na styku tych domen stosowane bylyby routery brzegowe (edge routers), grupujace strumienie o podobnych wymaganiach QoS (w rozumieniu modelu IntServ) w jedna klase uslug. W ten sposób nastepowaloby 'tunelowanie' sesji RSVP przez siec DiffServ – rys. 3.

EFSiec

lokalnaSiec

rdzenioweaHost BR BR EF Host

Edge Device Edge Device

Domena Int Serv(RSVP aware)

Domena Diff ServRSVP Tunnel

EF Edge FunctionalityBR Router graniczny

RSVP

Domena Int Serv(RSVP aware)

Sieclokalna

Rys. 2. Prawdopodobny scenariusz wspólpracy modelu IntServ z DiffServ

Ze wzgledu na tunelowanie sygnalizacji RSVP, procedury kontroli zgodnosci parametrów rze-czywistych strumienia z deklarowanymi wykonywane bylyby jedynie w routerach brzegowych, natomiast wewnatrz domeny DiffServ strumienie te wspóldzielilyby przeznaczone dla swojej klasy zasoby (np. bufory, pasmo itp.) – rys. 3.

Dostep Router brzegowy(Edge Device)

Siec rdzeniowa ATM

StrumienieIntServ

Zintegrowanyklasyfikator

RSVP zadania / rezerwacje*

Int Serv / Diff Serv

Diff Serv / Best Effort

PVCs

SVCs

StrumienieDiffServ

Pakiety 'best effort'

konfiugracjaDiff Serv

Agregacja

*odwzorowane w ATM VCs

Rys. 3. Agregacja strumieni IntServ i DiffServ oraz ich grupowanie w klasy priorytetów

39

14 MPLS

Nowa, bardzo obiecujaca koncepcja polaczenia szybkosci przelaczania, osiaganej przez komu-tatory ATM, z prostota i elastycznoscia protokolu IP, jest przelaczanie pakietów. Podstawowa idea opiera sie na pomysle zastosowania w urzadzeniach komutujacych podobnych do komuta-torów ATM mechanizmów sterowania i doboru trasy znanych z sieci IP. Oznacza to, ze adresacja, dobór trasy oraz wprowadzanie pakietów do sieci prowadzone byloby przez klasyczne routery, natomiast przekazywanie pakietów wewnatrz sieci byloby realizowane przy uzyciu komutato-rów IP (IP switch). Obecnie istnieje szereg prototypowych architektur przelaczajacych, wsród których najwazniejsze to Ipsilon Switching, CISCO Tag Switching, IBM ARIS, Toshiba CSR, NEC IPSOFACTO. Doprowadzilo to do otwarcia procesu standaryzacyjnego zmierzajacego do wypracowania otwar-tego standardu, znanego jako Multi-Protocol Label Switching (MPLS). Obecnie, MPLS kon-centruje sie na kwestiach wspólpracy róznych rozwiazan firmowych. Trwaja prace nad protokolem Label Distribution Protocol (LDP), który ma zapewnic wspólprace w zakresie sygnalizacji pomiedzy routerami przelaczajacymi (Label Switching Router – LSR), oraz koordynacje dystry-bucji etykiet. Obecnie uwaga koncentruje sie na dystrybucji etykiet dla polaczen punkt-punt o niegwarantowanych parametrach jakosciowych, choc rozpoczely sie juz prace nad obsluga ruchu, wymagajaca takich gwarancji. Jakkolwiek koncepcja ta jest ogólna, to jednak wysilki koncent-ruja sie na integracji IP z ATM, jako technikach kluczowych dla upowszechnienia MPLS.

15 IPv6

Wymienione we wprowadzeniu cechy protokolu IP wprowadzaja powazne ograniczenia, które uniemozliwiaja realizacje zaawansowanych aplikacji multimedialnych na duza skale. Takie apli-kacje wymagaja skalowalnej architektury, gwarancji jakosciowych, uslugi multicast, autokonfi-guracji, zwiekszonego bezpieczenstwa danych, wiekszej troski o integralnosc danych, zwiek-szonej przestrzeni adresowej, i co wazne, bardziej wydajnych mechanizmów doboru trasy, np. poprzez zastosowanie doboru hierarchicznego i agregacje tras w sieci szkieletowej. Takie wymagania byly brane pod uwage przy opracowywaniu nowej wersji protokolu IP – IPv6. Byl on projektowany z intencja rozszerzenia funkcjonalnosci obecnie stosowanego protokolu IPv4, a w dluzszej perspektywie – zastapienia go. Protokól IPv6 ma, w porównaniu z IPv4, znacznie uproszczona budowe naglówka. Adresy IPv6 sa czterokrotnie dluzsze niz adresy IPv4, podczas gdy calkowity rozmiar naglówka wzrósl jedynie dwukrotnie. Wynika to glównie stad, ze niektóre informacje przenoszone zwykle w naglówku IPv4, jak równiez nowe informacje, sa w IPv6 przenoszone w postaci tzw. rozszerzen i opcji (header extensions/options). Jest to uzasadnione, gdyz rozszerzenia nie musza byc umieszczane w kazdym pakiecie wysylanym przez stacje, a te które sa wysylane, nie musza byc przetwarzane przez kazdy wezel posredni (router). Usprawiedliwia to idee wyniesienia informacji uzupelniajacej, np. wspierajacej proces doboru trasy poza naglówek podstawowy. Uproszczona struktura naglówka sprzyja zwiekszeniu wydaj-nosci routingu. Elastyczne prefiksy sieciowe oraz hierarchiczna struktura adresowa sprzyjaja agregacji informacji na temat doboru trasy i pomagaja ograniczyc rozmiar tablic routingu w rou-terach szkieletowych.

Jednym z nowych zadan stawianych przed protokolem warstwy trzeciej jest zdolnosc obslugi strumieni danych, adresowanych do duzych grup odbiorców, rozlokowanych w geograficznie od-leglych miejscach. Sieci z obsluga polaczen multicastowych powinny pracowac wydajnie, co wiaze sie z replikacja pakietów w tych wezlach sieci, gdzie nastepuje rozwidlenie sciezek przejscia pakietów. IP6 posiada mozliwosc wspólpracy z multicastowymi protokolami doboru trasy.

40

Nowoscia w tej wersji protokolu jest usluga 'anycast'. Wysylane pakiety sa dostarczane tylko do jednej stacji, sposród grupy oferujacych specyficzna usluge. Jest to zwykle stacja 'najblizsza' w sensie metryki stosowanego protokolu routingu. Wreszcie naglówek IP6 posiada nowe 24-bitowe pole traffic-flow identification, pozwalajace zidentyfikowac pakiet jako nalezacy do danego strumienia danych. Ta cecha bedzie wykorzysty-wana glównie przez aplikacje generujace strumienie wymagajace specjalnego traktowania przez routery. Etykiety te beda wykorzystywane do poinformowania wezla sieci, ze dany pakiet jest uprawniony do korzystania z zasobów wydzielonych na wylaczny uzytek strumienia.

16 PODSUMOWANIE

Przedstawiona powyzej ewolucja technik dotyczacych zapewniania wspólpracy IP z ATM poz-wala zaobserwowac, ze dotychczas wystapily trzy fazy integracji tych srodowisk – rys. 4.

Aplikacja AplikacjaAplikacja

W. Transportowa W. TransportowaW. Transportowa

IP

NHRP, MARS, ...LANE MPLS

MPLSAAL5 AAL5AAL5

ATM ATMATM

W. fizyczna W. fizycznaW. fizyczna

IP IP

ATM

Ada

pt.

TC

P/IP

Rys. 4. Ewolucja technik implementacji IP w sieci ATM

Faza pierwsza, która mozna okreslic jako 'IP over intermediate layer' polegala na wprowa-dzeniu warstwy posredniej, która calkowicie ekranowala TCP/IP od specyficznych cech sieci podkladowej ATM. Mowa tu oczywiscie o LANE. W fazie drugiej, umownie nazywanej 'IP over ATM', w której translacja adresów IP na NSAP odbywala sie albo przez dedykowane serwery, albo poprzez algorytmiczne odwzorowanie adre-sów IP na NSAP, podejmowano próbe zastosowania modelu warstwowego (overlay model). W tej fazie powstalo kilka technik, w tym Classical IP, NHRP, MPOA, MARS i inne. Obecnie mozna przyjac, ze rozpoczela sie faza trzecia, w której zaciera sie wyrazna granica pomiedzy IP i ATM. W tej fazie rozwaza sie wykorzystanie komutatora ATM do szybkiego przelaczania pakietów IP w oparciu o wartosci etykiet, w które zaopatrywany jest kazdy pakiet IP wprowadzony do sieci (Multiprotocol Label Switching – MPLS). Jest to rozwiazanie zapozy-czone z technologii ATM, gdzie przelaczanie odbywa sie w oparciu o etykiety, nadawane pakietom podczas przekraczania granic domeny MPLS, a ustalenie wartosci etykiet odbywa sie przy wykorzystaniu znanych z IP protokolów doboru trasy. W trakcie tych trzech faz powstalo wiele metod realizacji IP na ATM, stopniowo coraz dosko-nalszych. Ich pelne zestawienie zawiera Tabela 3.

41

Tabela 3. Zestawienie koncepcji i implementacji dotyczacych wspólpracy IP z ATM

Technika Organizacja Wersja Data Status

LANE 1.0 ATMForum 1.0 styczen 1995 af-lane-0021

LANE 2.0 ATMForum 2.0 lipiec 1997 af-lane-0084

Classical IPv1 IETF 1 styczen 1994 rfc1577

Classical IPv2 IETF 2 kwiecien 1998 rfc2225

MARS IETF 0 listopad 1996 rfc2022

NHRP IETF 1 kwiecien 1998 rfc2332

MPOA ATM Forum 1.0 lipiec 1997 af-lane-087

MPLS IETF - sierpien 1997 Internet drafts

RSVP IETF 1 wrzesien 1997 rfc2205

IntServ IETF - czerwiec 1994 rfc1633

DiffServ IETF - grudzien 1998 rfc2474, 2475, ..

Trunking IETF - 1993-1998

LITERATURA [1] Akyildiz Ian F., Bernhardt K. L., „ATM Local Area Networks: A Survey of Require-

ments, Architectures, and Standards”, IEEE Communications Magazine, July 1997 [2] The ATM Forum, „ATM User-Network Interface (UNI) Signalling Specification, Ver-

sion 4.0”, July 1996 [3] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, „Resource ReSerVation

Protocol (RSVP) ? „Version 1 Functional Specification”, RFC 2205, September 1997 [4] Wroclawski, J., „The Use of RSVP with IETF Integrated Services”, RFC 2210, Sep-

tember 1997 [5] White Paul P., „RSVP and Integrated Services in the Internet: a tutorial”, IEEE Com-

munications, May 1997 [6] Berger L., „RSVP over ATM implementation Requirements”, RFC 2380, August 1998 [7] Armitage, G., „Support for Multicast over UNI 3.0/3.1 based ATM Networks”, RFC 2022,

November 1996 [8] Laubach, M., „Classical IP and ARP over ATM", RFC 2225, April 1998 [9] Deering S., Hinden R., „Internet Protocol, Version 6 (IPv6) Specification”, RFC 2460,

December 1998 [10] Bay Networks, „The Case for IPv6”, Technical Whitepaper [11] Alles A., „ATM Internetworking”, Technical Whitepaper, 1995