SK Moduł 4: Różnice pomiędzy wersjami

Aktualna wersja na dzień 18:15, 22 gru 2006

Technologia Frame Relay powstała w związku z zapotrzebowaniem użytkowników sieci Internet na szybką i wydajną technologię do transmisji danych. Wynikało to z:

rosnącej popularności środowisk graficznych wśród użytkowników, rosnącego zapotrzebowania na pasmo przez aplikacje, rosnących możliwości obliczeniowych komputerów PC, które wymagały szybszego dostarczania danych, stale powiększającej się liczby użytkowników sieci Internet, rosnącej popularności sieci LAN i konieczności podłączania ich do sieci operatorów. Technologia FR była stosunkowo niedroga i pozwalała nawet na podłączanie bezpośrednio do sieci FR komputerów użytkowników. Początkowo FR była rozwijana w laboratoriach Bell Labs jako fragment specyfikacji technologii ISDN. Jednak sukces jaki odniosła spowodował, że wkrótce stała się odrębną technologią sieciową. Można powiedzieć, że FR była właściwym rozwiązaniem w odpowiednim czasie. Mogła współpracować z ATM, była skalowalna, elastyczna, z niskim narzutem nagłówków w pakietach i wysoką dostępnością. Dopiero ostatnie lata z rosnącą popularnością na rozwijanie usług związanych z przesyłaniem strumieni audio i video w sieciach komputerowych spowodowało, że zaczęto szukać innych rozwiązań. Zwłaszcza, że konkurencyjny Ethernet, rozwijany od ponad 30 lat, przekroczył bariery stosowania go tylko w sieciach LAN i zaczął być stosowany w sieciach rozległych

Sieć FR jest siecią pakietową z komunikacją połączeniową. Pracuje na poziomie drugiej warstwy modelu ISO/OSI (patrz slajd).

Podstawowe zadanie sieci FR jest bardzo proste: dostarczyć dane w bezpieczny sposób między dwoma maszynami. Rodzaj danych nie ma żadnego znaczenia. Dane, po otrzymaniu ich od warstw wyższych, są enkapsulowane w nagłówki FR oraz pole pozwalające na wykrycie błędów w ramce. Pole to jest sprawdzane w pierwszej kolejności przez maszynę odbierającą ramkę. Jeżeli błąd nie zostanie wykryty sprawdzane są dalsze pola z nagłówka. Operacje wykonywane przez FR na poziomie warstwy łącza danych są dużo prostsze niż w innych protokołach. Jest to jedna z przyczyn szybkiego przesyłania danych przez sieci FR. W szczególności operacje te sprowadzają się do: użycia flagi do sprawdzenia pojawienia się ramki w łączu oraz sprawdzenia, czy ramka nie zawiera błędów. Jeśli jest uszkodzona zostaje usunięta i warstwa łącza danych nie wykonuje żadnych operacji związanych z retransmisją.

Zazwyczaj protokoły transmisji danych używają mechanizmu potwierdzania otrzymania pakietu z danymi. Po otrzymaniu potwierdzenia, komputer wysyłający dane, może wykasować kopię ramki ze swoich buforów. W przypadku nie otrzymania potwierdzenia ramka zostanie wysłana jeszcze raz. W operacje te nie jest angażowana aplikacja wysyłająca/odbierająca dane. Program użytkownika "ufa" warstwom niższym, że prześlą przez sieć potrzebne mu dane.

Sieć FR wszystkie operacje związane z wykrywaniem błędów przenosi na maszynę odbierającą lub wysyłającą dane - UNI (ang. User-to-Network Interface). Konwencjonalna operacja CRC (ang. Cyclic Redundancy Check) jest wykonywana przy użyciu pola FCS (ang. Frame Check Sequence). Jednak jeżeli zostanie wykryty błąd, powstały podczas transmisji, ramka jest usuwana, a do nadawcy wysyłane jest negatywne potwierdzenie odebrania ramki. Dzięki temu, że potwierdzaniem odbioru ramek w sieci FR zajmują się stacje końcowe, przesyłanie danych w węzłach może odbywać się znacznie szybciej. Szybkość ta jest funkcją szybkości działania danego węzła oraz wielkości ruchu, który obsługuje. Maksymalna przepustowość jaką może zapewnić to 34 Mb/s. Ponieważ swoje działanie opiera na łączach cyfrowych sieć FR charakteryzuje niska stopa błędów. Ponadto urządzenia obsługujące sieci FR potrafią wykryć błędy nagłówka, formatu, cyklicznego kodu nadmiarowego FCS pakietu. Ramki z wykrytym błędem są usuwane z sieci przez urządzenie, które stwierdziło wystąpienie błędu. Do urządzenia, które wysłało uszkodzoną ramkę wysyłane jest negatywne potwierdzenie jej odbioru i następuje retransmisja. Przyczynę, dla której sieć FR "spycha" obowiązki związane z potwierdzaniem odbioru ramki, przedstawia slajd.

Jak widać w konwencjonalnym rozwiązaniu pole z danymi jest przechowywane w buforze do czasu zakończenia wykonywania operacji wykrywania błędu. W tym czasie dane nie mogą być wysłane dalej. Przy takim podejściu maszyna, urządzenie przesyłające musi czekać na otrzymanie całej ramki z polem danych żeby móc zacząć procedurę CRC. Po jej zakończeniu wysyłane jest potwierdzenie lub negatywne potwierdzenie otrzymania ramki.

Ponieważ jednak w sieci FR urządzenia pośredniczące w przesyłaniu nie wysyłają potwierdzeń, nie muszą one czekać na otrzymanie całej ramki z danymi. Mogą ją zacząć transmitować dalej już po otrzymaniu nagłówka. Dzięki temu sieć FR nie musi stosować techniki "zapamiętaj i wyślij" (ang. store-and-forward) i w skuteczny sposób zmniejszyć opóźnienia w transmisji ramek. Takie podejście do przełączania ramek jest nazywane "przekaż dalej" (ang. cut-through switching). Wadą takiego podejścia jest niemożność sprawdzenia czy ramka nie uległa uszkodzeniu, aż do momentu kiedy dotrze do odbiorcy. Oczywiście takie podejście ma swoje dobre i złe strony. W sieciach z niską stopą błędów można sobie pozwolić na wykrywanie uszkodzeń ramek przez stacje końcowe. Jest to znacznie bardziej efektywne niż wymiana dodatkowych komunikatów przez urządzenia pracujące w sieci.

Urządzenia pracujące w szkielecie często są nazywane siecią FR. Nazwa bierze się z faktu, że nie stanowią one prostego połączenia punktów na brzegach sieci. Są one połączone logicznymi ścieżkami zdefiniowanymi w sieci. Szkielet sieci tworzy topologię gwiazdy. Choć niekoniecznie. Sieć FR pozwala elastycznie dostosowywać topologię do aktualnych potrzeb. Urządzenia mogą być częściowo połączone każde z każdym (ang. full mesh), a dalej tworzyć strukturę gwiazdy.

Sieć FR WAN używa dwukierunkowej komunikacji połączeniowej między każdą parą urządzeń dostępowych DTE (ang. Data Terminal Equipment) takich jak: FRAD-y (ang. Frame Relay Access Devices), terminale, komputery, routery, mosty (ang. bridge) czy multipleksery. Ścieżka łącząca dwa takie urządzenia może przebiegać przez kilka węzłów DCE (ang. Data Circut - terminating Equipment), połączonych ze sobą kanałami fizycznymi. Tak jak przedstawia to slajd.

Sieć FR idealnie nadaje się do obsługi ruchu jaki typowo generują użytkownicy, czyli sporadycznego, rzadko wykorzystującego całkowite dostępne pasmo. Z tego powodu technologia ta jest chętnie wykorzystywana przez operatorów telekomunikacyjnych do podłączania sieci LAN klientów do sieci Internet. Najczęściej do takiego podłączenia wykorzystywane są routery lub komputery PC z odpowiednimi kartami. Do routerów, kart przyłączone są modemy lub konwertery (najczęściej działające w którejś z odmian technologii DSL (ang. Digital Subscriber Line), np. HDSL, ADSL. Urządzenia te są podłączone bezpośrednio do jednoparowego przewodu miedzianego (niektóre modemy, np. firmy RAD pozwalają na podłączenie dwóch par przewodów), do którego na drugim końcu jest przyłączone analogiczne urządzenie. Użycie większej liczby par pozwala podnieść maksymalną szybkość transmisji modemów lub konwerterów. Innym możliwym sposobem jest użycie podobnego zestawu urządzeń (routery, konwertery) do łączenia sieci LAN z Internetem przy wykorzystaniu światłowodu. Wówczas potrzebne są jeszcze mulipleksery, które pozwalają na wydzielanie kanałów cyfrowych w traktach światłowodowych. Zaletą drugiego rozwiązania jest jego zasięg. Dobrej klasy multipleksery pozwalają na transmisję sygnału na dziesiątki kilometrów. W przypadku kabli miedzianych najczęstszym problemem jest ich duża stopa błędów. Dla sieci FR musi ona być poniżej 10-8. Jeśli kabel spełnia ten warunek można uzyskać przepustowości ok. 1 Mb/s na odcinkach ok. 10 km. Przy krótszych połączeniach i dobrej jakości kablach nowoczesne modemy pozwalają na transmisję danych z szybkością nawet 4 Mb/s.

Do danych użytkownika dodawany jest dwubajtowy nagłówek. Domyślnie wielkość ramki to 4096 bajtów. Maksymalnie może ona wynosić 8188 bajtów.

W zależności od tego, na jak długo obwody są zestawione w sieci dzieli się je na dwie grupy: stałe PVC (ang. Permanent Virtual Circuits) - bardzo popularne i jedynie dostępne na początku istnienia sieci FR. Zestawiane na stałe (aż do następnej zmiany), przełączane SVC (ang. Switched Virtual Circuits) zestawiane na żądanie. Używane są nieco rzadziej niż PVC, choć ich popularność na pewno jest wyższa niż w latach poprzednich. Każde z takich połączeń logicznych jest charakteryzowane dwoma parametrami transmisyjnymi: CIR (ang. Committed Information Rate), EIR (ang. Excess Information Rate). W przypadku kanałów PVC są one ustalane raz, przy zestawieniu łącza i nie są potem renegocjowane. Kanały SVC ustalają te parametry każdorazowo przy zestawianiu połączenia. CIR określa gwarantowaną przepływność minimalną. Pozwala on sieci dostosować się do aplikacji generujących tzw. ruch wybuchowy (w którym niekiedy pojawia się duża liczba danych w krótkim czasie). Miarą tej wybuchowości jest parametr Bc (ang. Committed Burst). Jest to ilość danych w bitach, którą sieć zgadza się przenieść w normalnych warunkach w przedziale czasu Tc. Dane mogą być przenoszone w formie jednej lub wielu ramek. Jeśli szybkość transmisji przekracza wartość CIR, to ramki mają ustawiany bit DE (ang. Discard Eligibility). Z kolei EIR określa nie gwarantowaną przepływność maksymalną. Z EIR związany jest parametr Be oznaczający ilość nadmiarowych danych w bitach, które sieć zgadza się przesłać, jeśli istnieją wolne zasoby.

Całkowita przepustowość dostępna dla użytkownika równa jest CIR + EIR. Ramki powodujące przekroczenie tej wartości są definitywnie odrzucane. Przykładowo, jeśli u operatora mamy wykupiony kanał wirtualny o parametrach CIR = 64 kb/s i EIR = 512 kb/s, to sieć podejmie próbę przeniesienia chwilowego ruchu z maksymalną przepustowością 576 kb/s. Przykład ilustruje rysunek 3.6.

Ramki transmitowane z szybkością przekraczającą wartość CIR + EIR mają ustawiany bit DE i mogą być usuwane z sieci FR przez urządzenia, które są przeciążone. Jeżeli szybkość wybuchowego ruchu przekracza możliwości sieci do przeniesienia go (parametry Be + Bc), wówczas urządzenie w węźle wejściowych zajmuje się usuwaniem ramek nadchodzących z szybkością przekraczającą ten limit.

Najpowszechniejszym mechanizmem sterowania przeciążeniami w sieci jest adaptacja okna emisyjnego do warunków panujących w sieci. Podobnie jak w przypadku protokołu TCP lub protokołu X.25. Jednakże w sieci FR nie można w pełni wykorzystać tego mechanizmu, jak np. w protokole TCP. Nie ma bowiem zaimplementowanych odpowiednich mechanizmów kontroli. Zachowanie się sieci FR w przypadku przeciążenia zależy do zaimplementowanych w niej protokołów. Jeśli w sieci FR dojdzie do przeciążenia to wówczas przeciążony węzeł DCE wysyła komunikaty do nadających urządzeń DTE, a te przekazują je dalej do stacji końcowych. W końcu docierają one do protokołów warstw wyższych na tych stacjach. Dopiero one mogą wpływać na emisję ramek przez odpowiednio ograniczając lub zwiększając ich rozmiar i szybkość przesyłania. Widać więc, że reakcje na przeciążenia w sieci FR nie są tak szybkie jak w sieciach TCP/IP. Dlatego też chcąc wykorzystywać FR w warstwie łącza danych przy obsłudze transmisji danych audio lub video należy używać jeszcze innych protokołów, np. RSVP (ang. Resource Reservation Protocol). FR jako takie umożliwia implementowanie następujących mechanizmów sterowania przeciążeniami:

FECN (ang. Forward Explicit Congestion Notification), BECN (ang. Backward Explicit Congestion Notification), CLLM (ang. Consolidated Link Layer Manager), prosta kontrola przepływu (ang. Simple flow control). Ponieważ komunikaty o przeciążeniu, wysyłane przez DCE i przekazywane dalej przez DTE, muszą być obsłużone najpierw przez te typy urządzeń, informują się one nawzajem w jawny sposób o wystąpieniu przeciążenia. Robią to za pomocą jednobitowych informacji zaszytych w nagłówku ramki. Odbiorca otrzymuje bit FECN, nadawca BECN. Urządzenie DTE musi odpowiedzieć na sygnał BECN zmniejszeniem szybkości transmisji. W przeciwnym razie DCE zacznie kasować ramki, którym nadawca nadał niższy priorytet. Może również arbitralnie nadawać niższy priorytet wszystkim ramkom z przepływnością przekraczającą CIR. BECN/FECN jest najpopularniejszym sposobem informowania o przeciążeniach.

Dane audio oraz video w sieciach FR można przesyłać na dwa sposoby. Pierwszy polega na wykorzystaniu FR jako takiej bez żadnych "modyfikacji". Urządzenia obsługujące FR wspierają tego typu transmisje poprzez stosowanie:

kodowania i kompresji głosu, wykrywania sygnałów mowy, kasowania echa, używania buforów niwelujących zmiany opóźnień w czasie (ang. jitter), kształtowania ruchu, fragmentacji pakietów ze zwykłymi danymi, zmniejszania wielkości ramek, dynamicznej kontroli przeciążeń, wykorzystującej mechanizmy kolejek i odrzucania pakietów z danymi, przesyłania danych głosowych przez kolejki o wyższych priorytetach obsługi, niż te ze zwykłymi danymi. W rzeczywistości, urządzenia obsługujące FR używają kombinacji tych mechanizmów. W ten sposób zmniejszają one zapotrzebowanie na pasmo oraz przeciwdziałają opóźnieniom i stratom pakietów z danymi głosowymi. Mimo wszystko, brak zapewnienia mechanizmów sterowania przeciążeniami na poziomie protokołu FR jest wadą, która została zniwelowana tylko w ograniczonym stopniu. Dlatego też najczęściej, przy przesyłaniu danych głosowych, stosowane jest przesyłanie ich w pakietach protokołu IP przy wykorzystaniu FR (ang. Voice over IP over Frame Relay). Dzięki protokołowi IP możliwe jest już stosowanie protokołu RSVP, RTP (ang. Real Time Protocol) oraz kompresja nagłówków RTP.

Protokół interfejsu zarządzania LMI (ang. Local Management Protocol) powstał w 1990r. z inicjatywy Frame Relay Forum. Ma on duże znaczenie dla FR gdyż wnosi:

adresowanie globalne, połączenia grupowe, obwód wirtualny LMI dla komunikatów. Adresowanie globalne nadaje numerom DLCI status unikatowych adresów w urządzeniach DTE sieci FR. Wówczas cała sieć FR przeobraża się w typową sieć LAN aż do routerów, FRAD-ów z jej obrzeża. Indywidualne interfejsy i komunikujące się z nimi węzły mogą być rozpoznawane przez typowe w sieciach LAN mechanizmy, np. protokoły odwzorowujące adresy międzysieciowe na adresy fizyczne. Połączenia grupowe gdzie komunikaty odbiera każdy komputer w danej podsieci wpływają na szerokość pasma. Dzięki nim nie jest obciążana cała sieć. Modyfikacje tras routingu zostają zawężone do grupy routerów lub FRAD-ów. Każdy z użytkowników w grupie otrzymuje również kopie komunikatów z raportami o stanie grupy i modyfikacjach. Połączenia grupowe są zazwyczaj ustawiane na dłuższy okres. Do adresowania multicast zostały zastrzeżone numery DLCI 1019-1022. Obwód wirtualny LMI został przeznaczony do sygnalizacji dostarczającej informacji o statusie i konfiguracji łącz. Usługi protokołu LMI są dostępne na poziomie interfejsu abonenta. Między przełącznikiem, a urządzeniem dostępowym tworzony jest specjalny kanał wirtualny. Przesyłane są nim cyklicznie listy ważnych DLCI, komunikaty określające stan każdego obwodu, stan sieci. Zapewnia też synchronizację między DTE a DCE.

Sieci i urządzenia FR umożliwiają ich wykorzystanie w różnego rodzaju zastosowaniach. Możliwość szybkiego przenoszenia przez FR ramek protokołów warstw wyższych, np. IP, na dużych odległościach czyni z tej technologii rozwiązanie np. tzw. problemu ostatniej mili szybkiego lokalnego dostępu do sieci. Dodatkowo, użytkownicy dbający o bezpieczeństwo swoich danych otrzymują niemalże gotowe rozwiązanie stosując kanały PVC lub SVC. Nie wyklucza ono stosowania szyfrowanych kanałów VPN (ang. Virtual Private Network). FR może stanowić również dobrą bazę dla aplikacji przesyłających dane typu audio lub video.

Przez wiele lat istniał podział na sieci przeznaczone do transmisji danych oraz głosu. Sieci te istniały równolegle do siebie oraz budowano dedykowane infrastruktury dla ich potrzeb. Podnosiło to koszty budowania sieci oraz ich utrzymania. Ze względu na swoją charakterystykę, sieci te trudno było zintegrować. Wynika to z charakterystyki działania tych sieci. Sieci transmisji danych są sieciami typu PTM (ang. Packet Transfer Mode) a sieci transmisji głosu sieciami STM (ang. Synchronous Transfer Mode). W klasycznych sieciach PTM podstawową jednostką "nośną" jest pakiet. Pakiet może mieć różną długość, a co za tym idzie czas transferu pakietu nie jest stały. Pakiety pochodzące z różnych źródeł i mające różne miejsce przeznaczenia mogą być transmitowane w różnej kolejności bez szczególnych zależności czasowych. W przypadku sieci STM, dla celu transmisji, przyznawana jest szczelina czasowa. Dzięki temu pomiędzy dwoma komunikującymi się punktami zapewniona jest stała przepływność i opóźnienie. Pozwala to na realizację usług związanych z transmisją głosu i obrazu w czasie rzeczywistym. Efektem ubocznym jest niewykorzystane pasmo w przypadku, gdy nie odbywa się żadna transmisja. ATM (ang. Asynchronous Transfer Mode) powstał jako próba połączenia tych dwóch nieco niekontatybilnych technologii. Choć standard ATM ma obecnie charakter przejściowy (patrz wnioski końcowe), to jednak jest dość powszechnie stosowany.

Standard ATM został opracowany jako element specyfikacji B-ISDN (ang. Broadband Integrated Services Digital Network) przez CCITT (ang. Consultative Committee for International Telegraph and Telephone) w 1988 roku. W zamierzeniu standard miał pozwolić na zintegrowanie technologii sieci LAN (ang. Local Area Network), WAN (ang. Wide Area Network) i PTSN w jedną. Za pomocą technologii ATM miało być możliwe świadczenie usług w:

sieciach LAN - poprzez interfejsy ATM w urządzeniach typu komputery, przełączniki itp; emulacje sieci LAN w tradycyjnych technologiach LAN takich jak Ethernet i Token Ring oraz poprzez emulacje ATM w sieciach LAN; sieciach WAN - poprzez interfejsy ATM oraz poprzez przenoszenie innych technologii WAN poprzez sieć ATM (np. Frame Relay over ATM); sieciach PTSN - poprzez interfejsy ATM w centralach telefonicznych oraz emulowanie łączny np. łączy E1. W przypadku gdyby ATM udało się wdrożyć na szeroką skalę, powstałaby jednolita sieć świadcząca usługi transmisji danych oraz usługi związane z telefonią. Nie stało się tak, gdyż powstały spore opóźnienia podczas definiowania kolejnych standardów. W sieciach LAN pojawił się Fast Ethernet, a następnie Gigabit Ethernet. Technologie te oferowały znaczny przyrost prędkości pracy sieci bez konieczności zapoznawania się z nową technologią. Koszty przełączników oraz kart sieciowych ethernet zaczęły spadać, podczas gdy koszty przełączników ATM oraz kart już nie. Koszty wdrożenia ATM w LAN-ie stały się na tyle duże, że obecnie nie buduje się sieci LAN w oparciu o ATM. Taniej jest budować sieci LAN z wykorzystaniem technologii ethernet.

Problemy ze standaryzacją różnorodnych usług w ATM-ie miało rozwiązać powstałe we wrześniu 1999 roku ATM Forum. Organizacja ta powstała z inicjatywy dużych firm produkujących sprzęt sieciowy oraz operatorów telekomunikacyjnych i skupia obecnie około 600 członków. Publikuje ona standardy związane z technologią ATM. Informacje o prowadzonych pracach oraz standardy dostępne są na stronie internetowej organizacji pod adresem www.atmforum.org.

W sieciach ATM mamy do czynienia z połączonymi przełącznikami realizującymi operacje przełączania komórek ATM oraz urządzaniami końcowymi, które są przyłączone do przełączników i przesyłają poprzez sieć ATM dane. Urządzeniem ATM może być komputer z kartą ATM, przełącznik ethernet z kartą ATM lub szereg innych urządzeń.

Sieć ATM jak każda sieć posiada system adresowania urządzeń w sieci. Urządzenia w sieci ATM są identyfikowane poprzez dwudziestobajtowe pole adresowe. Adresy mogą należeć do jednej z trzech konwencji:

DDC (ang. Designated Country Code) - jest formatem wykorzystującym specyfikacje ISO 3166, dzięki czemu można określić kraj, w którym adres jest zarejestrowany; ICD (ang. International Code Desigantor - podobnie jak DDC pozwala określić kraj, z tym, że wykorzystywana jest norma British Standards Institute; E.164 - jest formatem adresu zdefiniowanym zgodnie z numeracją przyjętą w sieci ISDN.

Znaczenie poszczególnych pól adresowych jest następujące:

AFI (ang. Authority and Format Identifier) - określa stosowaną konwencję adresowania. Przyjmuje następujące wartości: 39 - jeśli adres jest w formacie DDC; 46 - jeśli adres jest w formacie ICD; 45 - jeśli adres jest w formacie E.164. DCC, ICD lub E.164 - prefiksy określające sieć, do której klient jest dołączony, zawierające dane o kodzie kraju wedle jednej z przyjętych konwencji. Pole to ma długość 2 bajtów dla DCC i ICD oraz 8 dla E.164; HO-DSP (ang. High Order Domain Specific Part) - pole określające adres organizacji zarządzającej siecią. Pole ma długość 10 bajtów dla formatów DCC i ICD oraz 4 dla E.164; ESI (ang. End System Identifier) - idendyfikator stacji wewnątrz sieci prywatnej. Rozmiar jego wynosi 6 bajtów dla wszystkich konwencji adresowych. ESI powinien być niepowtarzalny i najczęściej jest adresem nadanym przez producenta urządzenia (np. MAC Address); SEL (ang selector) - jednobajtowe pole, które nie jest używane do identyfikacji urządzeń i najczęściej jego wartość wynosi zero. Gdy urządzenie spełnia jakąś dodatkową funkcję w sieci to identyfikator ma inną wartość. Adresy ATM, choć identyfikują urządzenia w sieci, nie identyfikują przesyłanych komórek. Wynika to z faktu braku w komórce ATM pól adresowych nadawcy i odbiorcy. Adresy ATM są wykorzystywane wyłącznie do zestawiania połączeń pomiędzy poszczególnymi urządzeniami.

W sieci ATM dwa komunikujące się urządzenia dla celów transmisji muszą zestawić lub mieć zestawione połączenie. Standard ATM definiuje dwa typy połączeń:

stały obwód wirtualny PVC (ang. Pernament Virtual Circuit) - tego typu obwód jest zestawiany przez administratora. Administrator w zależności od sprzętu konfiguruje porty urządzeń, trasę poprzez przełączniki, adresy oraz, jeśli trzeba, parametry określające jakość transmisji; przełączany obwód wirtualny SVS (ang. Switched Virtual Circuit) - tego typu obwód jest zestawiany na żądanie za pomocą protokołów sygnalizacyjnych. Protokoły zapewniają zestawienie połączenia poprzez przełączniki z żądaną jakością transmisji. Podczas zestawiania trasy, każdy przełącznik ATM sprawdza możliwość spełnienia wymaganych warunków transmisji. W wypadku posiadania odpowiednich zasobów przełącznik przesyła żądanie do następnego przełącznika. Po zestawieniu połączenia nadawany jest 24-bitowy identyfikator określający wirtualny kanał i ścieżkę. W koncepcji ATM, w ramach pojedynczego łącza fizycznego, są transmitowane komórki należące do różnych połączeń. Nie są one identyfikowane adresami nadawcy i odbiorcy, jak np. w sieci IP, ale są rozróżniane na podstawie zawartości pól VPI (ang. Virtual Path Identifier) oraz VCI (ang. Virtual Channel Identifier). Komórki mające te same identyfikatory VPI i VCI tworzą wirtualny kanał, który realizuje jednokierunkowy transport komórek. W celu realizacji połączenia dwukierunkowego należy zestawić parę połączeń. W sieci ATM realizuje się połączenia typu VCC (ang. Virtual Channel Connection), które jest połączeniem pomiędzy dwoma punktami dostępu do sieci ATM. Połączenie składa się z wielu logicznych łączy VCL ( ang. Virtual Channel Link). Łącza VCL mają znaczenie lokalne i są identyfikowane poprzez zawartość pola VCI w nagłówku komórki należącej do połączenia. Zawartość VCI może się zmieniać po przejściu przez kolejne węzły sieci powodując zmiany VCL. Połączenia VCC mogą mieć strukturę wielopunktową, która może być wykorzystana w przypadku transmisji rozgłoszeniowych. Wirtulany kanał składający się z wyznaczonej poprzez VCL trasy gwarantuje integralność i sekwencyjność komórek ATM. Kanał może się cechować określonym pasmem przenoszenia. Parametry kanału są negocjowane w trakcie nawiązywania połączenia. Grupa kanałów tworzy wirtualną ścieżkę VP (ang. Virtual Path), która również może mieć przypisane pasmo. Sieć ATM może realizować połączenia typu VPC (ang. Virtual Path Connection), które może być zainicjowane w punkcie dostępu do sieci lub w węzłach o odpowiednich uprawnieniach. Połączenia VPC, podobnie jak VCC, składają się z wirtualnych łączy VPL (ang. Virtual Path Link), które są identyfikowane poprzez pole VPI. Pole to może ulegać zmianie podczas transmisji, podobnie jak pole VCI. Połączenie typu VPC jest połączeniem jednokierunkowym i dla transmisji dwukierunkowej należy zestawić dwa połączenia. Połączenia VPC pozwalają operatorom na zestawienie połączenia dla klienta, który potrzebuje posiadać wiele wirtualnych kanałów. Wzajemne relacje pomiędzy kanałami i ścieżkami ilustruje slajd.

W koncepcji ATM, w ramach pojedynczego łącza fizycznego, są transmitowane komórki należące do różnych połączeń. Nie są one identyfikowane adresami nadawcy i odbiorcy, jak np. w sieci IP, ale są rozróżniane na podstawie zawartości pól VPI (ang. Virtual Path Identifier) oraz VCI (ang. Virtual Channel Identifier). Komórki mające te same identyfikatory VPI i VCI tworzą wirtualny kanał, który realizuje jednokierunkowy transport komórek. W celu realizacji połączenia dwukierunkowego należy zestawić parę połączeń.

W sieci ATM realizuje się połączenia typu VCC (ang. Virtual Channel Connection), które jest połączeniem pomiędzy dwoma punktami dostępu do sieci ATM. Połączenie składa się z wielu logicznych łączy VCL ( ang. Virtual Channel Link). Łącza VCL mają znaczenie lokalne i są identyfikowane poprzez zawartość pola VCI w nagłówku komórki należącej do połączenia. Zawartość VCI może się zmieniać po przejściu przez kolejne węzły sieci powodując zmiany VCL. Połączenia VCC mogą mieć strukturę wielopunktową, która może być wykorzystana w przypadku transmisji rozgłoszeniowych. Wirtulany kanał składający się z wyznaczonej poprzez VCL trasy gwarantuje integralność i sekwencyjność komórek ATM. Kanał może się cechować określonym pasmem przenoszenia. Parametry kanału są negocjowane w trakcie nawiązywania połączenia. Grupa kanałów tworzy wirtualną ścieżkę VP (ang. Virtual Path), która również może mieć przypisane pasmo. Sieć ATM może realizować połączenia typu VPC (ang. Virtual Path Connection), które może być zainicjowane w punkcie dostępu do sieci lub w węzłach o odpowiednich uprawnieniach. Połączenia VPC, podobnie jak VCC, składają się z wirtualnych łączy VPL (ang. Virtual Path Link), które są identyfikowane poprzez pole VPI. Pole to może ulegać zmianie podczas transmisji, podobnie jak pole VCI. Połączenie typu VPC jest połączeniem jednokierunkowym i dla transmisji dwukierunkowej należy zestawić dwa połączenia. Połączenia VPC pozwalają operatorom na zestawienie połączenia dla klienta, który potrzebuje posiadać wiele wirtualnych kanałów. Wzajemne relacje pomiędzy kanałami i ścieżkami ilustruje slajd.

W technologii ATM dane przenoszone są za pomocą komórek. Komórki charakteryzują się stałym rozmiarem 58 bajtów z czego 5 jest przeznaczonych na nagłówek, a 48 na transmisje danych. Struktura nagłówka różni się w zależności od typu końcówki sieci. Zakończenie może być typu NNI (ang. Network to Network Interface lub Node to Node Interface) lub UNI (ang. User to Network Interface). Format komórki przedstawiony jest na slajdzie.

Znaczenie poszczególnych fragmentów jest następujące: GFC (ang. Generic Flow Control) - czterobitowe pole w nagłówku UNI. Jego wartość jest ustawiana przez przełącznik ATM. Użytkownik może wykorzystać to pole do wydzielenia wielu klas usług, w ramach jego sieci, które będą świadczone z różną jakością; VPI (ang. Virtual Path Identifier) - jest polem o rozmiarze 8 bitów na styku UNI lub 12 bitów na styku NNI, które określa przynależność komórki do wirtualnej ścieżki. Ścieżek może być 256 na styku UNI lub 4096 na styku NNI; VCI (ang. Virtual Channel Identifier) - jest polem o rozmiarze 16 bitów określającym przynależność komórki do wirtualnego kanału. PT (ang. Payload Type) - jest trzybitowym polem, określającym czy komórka jest komórką sygnalizacyjną czy użytkownika; CLP (ang. Cell Loss Priority) - jest jednobitowym polem określającym priorytet komórki. Wartość CLP=1 oznacza, że komórka może być utracona w sytuacji natłoku. Wartość CLP=0 oznacza, że komórka nie powinna być utracona ale nie oznacza to 100% gwarancji na dostarczenie komórki; HEC - jest ośmiobitowym polem sumy kontrolnej. Suma ta jest wyznaczana wyłącznie z nagłówka komórki. Mechanizm sumy pozwala na korekcję pojedyńczych błędów i wykrycie większej ich liczby.

Identyfikatory wirtualnych ścieżek, kanałów i pozostałe części nagłówka mogą być kodowane w różnych formatach, w celu identyfikacji komórek nie będących komórkami użytkownika. Przykładem mogą być komórki metasygnalizacji używane do zestawienia połączeń lub komórki puste (ang. idle cells) służące jako wypełniacz przy wyrównywaniu prędkości. Generalnie w ATM-ie rozróżnia się następujące typy komórek:

Idle - nie przenoszące żadnej informacji, generowane są w celu dostosowania szybkości przepływu; Valid - przesłane prawidłowo bez błędów w nagłówku lub takie, w których błąd ten udało się skorygować za pomocą sumy kontrolnej; Invalid - przesłane z błędami, których nie udało się skorygować; Assigned - w warstwie ATM dostarczające usługi aplikacjom; Unasigned - wszystkie komórki, które nie są przydzielone.

W modelu sieci ATM można wyróżnić trzy warstwy: fizyczną, ATM i warstwę adaptacyjną. Każda z warstw realizuje określone funkcje.

Warstwa fizyczna realizuje funkcje związane z dostępem do medium transmisyjnego. W warstwie tej można wyróżnić dwie podwarstwy:

PM (ang. Physical Media Dependent Sublayer - realizującą funkcje związane z dostępem do medium transmisyjnego. W ramach tych funkcji określone są parametry nadajnika, odbiornika, kodowania bitów, generowania i odtwarzania informacji synchronizujących. TC (ang. Transmission Convergence Sublayer) - realizującą funkcje adaptacji strumienia komórek ATM do przepływu przez fizyczny nośnik. Warstwa ta generuje oraz sprawdza sumę kontrolną w polu HEC nagłówka komórki. Podwarstwa TC generuje także puste komórki, gdy są one potrzebne do dostosowania strumienia ATM do strumienia medium transmisyjnego. Warstwa fizyczna może wykorzystywać różne nośniki (media transmisyjne), choć dla potrzeb ATM zaleca się stosowanie łącz światłowodowych. Najczęściej w ATM wykorzystuje się interfejsy takie jak SONET (ang. Synchronous Optical NETwork), SDH (ang. Synchronous Digital Hierarchy), PDH (ang. Plesiochronous Digital Hierarchy). Oferują one różne prędkości transmisji. Poniższa tabela pokazuje zestawienie prędkości transmisji dla interfejsów SONET kompatybilnych z SDH. Najczęściej spotykanymi interfejsami są interfejsy STM-1 (ang. Synchronous Transfer Mode i STM-4. W przypadku ich użytkowania efektywna prędkość dla użytkownika wynosi odpowiednio 146,76 Mb/s dla STM-1 i 599,04 dla STM-4. Wynika to z faktu, iż co 27 komórka jest przeznaczona dla transmisji sterujących warstwą fizyczną. Oprócz interfejsów na stykach STM są również zdefiniowane interfejsy ATM-TAXI o przepływności 100 Mb/s oraz ATM 25 Mb/s. Ponadto są implementowane wolniejsze rozwiązania przeznaczone np. do obsługi modemów xDSL (ang. Digital Subscriber Line).

Warstwa ta odpowiada za ustanowienie połączenia, ustalenie parametrów przepływu oraz za kontrolę. Warstwa ta realizuje swoje funkcje niezależnie od typu użytego nośnika. Użytkownik za pomocą tej warstwy otrzymuje szereg funkcji, które pozwalają mu na przeźroczystą realizację transferu swoich danych poprzez sieć. W przypadku urządzeń końcowych do tej warstwy z warstwy adaptacyjnej przesyłane są 48-bajtowe pola danych. Warstwa ATM opatruje je 5-bajtowym nagłówkiem, który w połączeniu z danymi stanowi komórkę ATM. Warstwa ta nie tworzy pola sumy kontrolnej HEC. W przypadku odbioru danych następuje w warstwie oddzielenie nagłówka od danych, które są wysyłane do warstwy adaptacyjnej. W przypadku realizacji tej warstwy na przełącznikach, jest ona odpowiedzialna za połączenia ATM o różnych wartościach parametru QoS, a także za translację identyfikatorów VCI/VPI.

Warstwa adaptacyjna ATM (ang. ATM Adaptation Layer) jest warstwą pośredniczącą pomiędzy warstwami wyższymi, w których działają aplikacje użytkowe, a warstwą ATM. Warstwa ta jest implementowana wyłącznie w urządzeniach końcowych. W skład warstwy wchodzą dwie podwarstwy:

podwarstwa SAR (ang. Segmentation and Reasebly) - segmentacji i składania, która odpowiada za zamianę jednostek PDU (ang. Protocol Data Unit) warstwy adaptacyjnej na pola danych komórek ATM. Dla stacji odbiorczej jednostka ta odpowiada za składanie jednostek PDU z poprawnie odebranych komórek. Podwarstwa ta jest usytuowana bezpośrednio nad warstwą ATM; podwarstwa CS ( ang. Convergence Sublayer ) - podwarstwa zbieżności odpowiedzialna za realizację usług ALL i współpracę z warstwami wyższymi. Warstwa AAL jest przeznaczona do współpracy z różnego rodzajami aplikacji przesyłającymi dane, dźwięk, lub obraz w postaci cyfrowej. Różne typy danych wymagają przydziału różnych zasobów sieci. Przy przydziale zasobów sieci, warstwa AAL musi uwzględniać następujące cechy żądań: rodzaj powiązań czasowych pomiędzy źródłem transmitowanej informacji, a jej przeznaczeniem; charakter przepływności bitowej (może być stały lub zmienny); tryb wymiany danych (połączeniowy lub bezpołączeniowy). Warstwa AAL stanowi swego rodzaju filtr przydzielający zasoby sieci. Ze względu na różnorodność charakterystyk transmisji danych, w obrębie warstwy AAL wydzielono kilka typów warstw adaptacji AAL: AAL typ 1 - jest wykorzystywany przy usługach klasy A (patrz niżej), które wymagają stałej, gwarantowanej prędkości transmisji w trybie połączeniowym. Jest przeznaczony do realizacji transmisji głosu, dźwięku, video i innych usług multimedialnych, w tak zwanym czasie rzeczywistym. AAL typ 2 - jest wykorzystywany przy usługach klasy B, które nie wymagają stałej, gwarantowanej prędkości transmisji ale wymagają nie przekraczania limitu maksymalnego opóźnienia. Przykładem tego typu transmisji jest transmisja kompresowanego obrazu wideo, gdzie zamiast przesyłania klatki po klatce przesyłane są różnice pomiędzy nimi; AAL typ 3/4 - jest wykorzystywana przy usługach klasy C/D, które nie wymagają transmisji danych ze ścisłymi zależnościami czasowymi. Dane mogą być transmitowane w trybie połączeniowym jak i bezpołączeniowym; AAL typ 5 - jest podobny do typu 3/4, lecz umożliwia transmisję danych, które nie wymagają ścisłych zależności czasowych ale pracują w trybie połączeniowym. Poszczególnym warstwom AAL przypisane są różne klasy ruchu.

W standardzie ATM zdefiniowane są dwa rodzaje styków, które ponadto istnieją w dwóch odmianach:

styk UNI ( ang. User-to-User Interface) - ten styk określa zasady połączenia użytkownika z siecią i ma następujące odmiany: prywatny UNI (ang. private UNI) - przeznaczony do połączeń pomiędzy przełącznikiem ATM, a urządzeniem końcowym pracującym w obrębie tej samej prywatnej sieci ATM; publiczny UNI (ang. public UNI) - przeznaczony do przyłączenia urządzenia końcowego lub prywatnej sieci ATM do publicznej sieci ATM. styk NNI ( ang. Network to Network Interface) - przeznaczony jest do łączenia przełączników ATM lub sieci ATM i posiada dwie podwersje: prywatny NNI (ang. private NNI) - przeznaczony dla przełączników pracujących w sieciach prywatnych; publiczny NNI (ang. public NNI) - przeznaczony dla przełączników pracujących w sieciach prywatnych; Z interfejsami ATM związana jest sygnalizacja. Na dzień dzisiejszy dla styku UNI najcześciej używa się jednej z trzech wersji sygnalizacji: UNI 3.0, UNI 3.1, UNI 4.0. Wersja 4.0 jest najbardziej rozbudowana, gdyż obejmuje elementy związane z transmisją głosu. Z sygnalizacją na styku UNI związany jest też protokół ILMI (patrz niżej), zaś z sygnalizacją na styku NNI protokół PNNI (patrz niżej).

Protokół ILMI (ang. Integrated Local Managment Interface ) jest odpowiedzialny za autokonfigurację wielu parametrów protokołu ATM. Pozwala na wyznaczanie adresów serwerów inicjujących różne usługi i protokoły sieciowe, a także na automatyczne nadanie urządzeniu końcowemu adresu ATM.

Protokół PNNI (ang. Private Network to Network Interface) ma realizować określanie tras czyli routing w sieci ATM. Niestety z różnych przyczyn powstanie protokołu zostało opóźnione. Obecnie ustandaryzowane są dwie wersje tego protokołu PNNI-0 i PNNI-1. Protokół PNNI-0, którego następnie przemianowano na IISP (ang. Interim Inter-switch Signaling Protocol) jest prostym protokołem routingu dla sieci ATM. Wyznaczanie trasy dla komórki odbywa się na podstawie statycznych tras wpisanych do przełącznika. Wyznaczanie tras komórek w ramach protokolu IISP oparte jest na statycznej tablicy tworzonej przez administratora sieci. Tablica ta składa się z elementów o następującej strukturze:

(adres ATM, długość adresu, indeks interfejsu) Długość adresu lub prefiks oznacza ilość bitów adresu ATM używanych przy porównywaniu. Można powiedzieć, że jest to "maska podsieci" podobna do maski podsieci w sieciach IP. Mechanizm ten pozwala na tworzenie wpisów określających trasę zarówno do pojedyńczych stacji końcowych, jak i do całych grup stacji identyfikowanych prefiksem adresu. Indeks interfejsu ma znaczenie lokalne i określa fizyczny port, lub kanał PVP. Stosowanie prefiksów może doprowadzić do sytuacji, w której dwie pozycje w tablicy wskazują na dwie różne drogi. W takiej sytuacji wybierana jest ta, która ma dłuższy prefiks. Na przykład w tablicy są dwa następujące wpisy:

Adres ATM 4700:1234:5678:9000:0000, prefiks 48, indeks 7 Adres ATM 4700:1234:2567:9000:0000, prefiks 56, indeks 8

Jeśli zajdzie konieczność wysłania pakietu do stacji o adresie ATM 4700:1234:5678:9012:2345 to pakiet zostanie przesłany zgodnie z drugą regułą, gdyż jest w niej dłuższy prefiks. ILMI zestawia połączenia w oparciu o kanały UBR lub ABR. Nie jest możliwe ustawianie za pomocą protokołu ILMI parametrów związanych z jakością transmisji. Protokół ILMI pozwalał na budowę sieci ATM, ale sieć zbudowana w oparciu o ten protokół nie pozwalała na pełne wykorzystanie możliwości sieci, szczególnie związanych z jakością oferowanych usług. Protokół PPNI-1 realizuje dynamiczny routing w sieci ATM. Komórka podróżuje zgodnie z trasami, których charakterystyki są umieszczone w przełącznikach - z tym, że trasy te są dynamicznie umieszczane przez protokół PNNI-1. Trasa, która jest wyznaczana przez ten protokół może posiadać parametry związane z wymaganiami QoS (ang. Quality Of Service). Może więc być realizowana w zależności od potrzeb w technikach ABR, VBR czy też CBR. Protokół PNNI-1 umożliwia tworzenie zarówno małych sieci jak i dużych sieci operatorskich.

Technologia ATM miała pozwolić na integrację sieci transmisji danych z sieciami przeznaczonymi do transmisji głosu. Aby można było zastosować ATM w sieciach transmisji danych, czyli generalnie w sieciach komputerowych, opracowano szereg standardów, które przeznaczone były dla sieci LAN i WAN.

Sieci LAN, w momencie tworzenia standardów ATM, były tworzone w oparciu o technologię Ethernet i Token Ring. Konieczne stało się zintegrowanie tych technologii w sieciach ATM. Ze względu na koszty, nie można było, dokonać wymiany już istniejących interfejsów w urządzeniach. Postanowiono, więc połączyć istniejące technologię. Nie jest to łatwe, gdyż pomiędzy tymi technologiami są spore różnice w działaniu. Przesłanie danych w sieci ATM wymaga zestawienia połączenia, co nie jest wymagane w sieci Ethernet. W Ethernecie adresy mają długość 6 bajtów, a w sieciach ATM 20 i do tego adresacja ma strukturę hierarchiczną. Informacje o adresach ATM nie są przesyłane w komórkach, natomiast informacje o adresach Ethernet są zawarte w pakietach. W komórkach ATM są wyłącznie informacje o numerach kanału i ścieżki, a i te informacje mogą być zmieniane poprzez poszczególne węzły sieci. Aby uporać się z tymi problemami opracowano standard LAN Emulation (LANE) w wersji 1. Podstawowym założeniem LANE było umożliwienie współpracy pomiędzy komputerami pracującymi w sieciach lokalnych oraz w sieciach ATM w ramach wspólnego segmentu sieci LAN. Z punktu widzenia sieci LAN sieć ATM wygląda i zachowuje się jak segment klasycznej, bezpołączeniowej sieci LAN działającej w technologii Ethernet lub Token Ring. LANE maskuje istnienie sieci ATM dla programów korzystających z warstwy MAC (ang. Media Access Control) i warstw wyższych, dzięki czemu nie jest konieczna wymiana lub modernizacja istniejącego oprogramowania.

LANE samo w sobie określa mechanizmy współpracy pomiędzy obiektami logicznymi realizującymi funkcje klientów oraz serwerów. W przypadku pojedynczej, emulowanej sieci LAN można wyróżnić następujące obiekty: LEC (ang. LAN Emulation Client) - obiekt klienta, powinien być co najmniej jeden; LES (ang. LAN Emulation Server) - obiekt serwera emulującego sieć LAN; BUS (ang. Broadcast and Unknown Serwer) - obiekt serwera dla ruchu broadcastowego; LECS (ang. LAN Emulation Configuration Server) - obiekt serwera konfiguracyjnego. Obiekty serwerów odpowiedzialne są za: odwzorowanie adresów MAC na adresy ATM; transmisje danych pomiędzy klientami LEC oraz dystrybucję ruchu typu broadcast i multicast; konfigurację i współpracę pomiędzy elementami sieci ELAN (ang. Emulated LAN). Obiekty serwerów są oprogramowaniem, które może być zainstalowane zarówno na urządzeniach końcowych, jak i na przełącznikach ATM. Poszczególne serwery mogą być umieszczone na różnych urządzeniach, choć najczęściej ulokowane są na jednym. Upraszcza to konfigurację tych serwisów. Klienci LEC umieszczani są na urządzeniach brzegowych sieci ATM. Mogą być to hosty ATM (np. komputer z kartą ATM) lub przełączniki brzegowe (np. przełącznik Ethernet z kartą ATM).

Jednym z podstawowych elementów sieci LANE jest LEC. Do jego zadań należy:

przesyłanie danych do innego klienta LEC lub do serwera BUS w sytuacji realizacji ruchu multicast lub broadcast; rejestracja swoich danych w serwerze LES; przechowywanie adresów w sytuacji, gdy LEC pełni funkcje Proxy LEC. LEC nie rejestruje wtedy wszystkich adresów MAC w serwerze LES. LES w poszukiwaniu powiązania adresu MAC-ATM przesyła zapytania do wszystkich klientów Proxy LEC. Pełnienie roli interfejsu dla pozostałych składników sieci ELAN (BUS, LES, LECS). Klient LEC zestawia z serwerem LECS połączenie w celu uzyskania danych konfiguracyjnych takich, jak adresy serwerów LES i BUS. Następnie zestawia połączenie z serwerem LES, w którym dokonuje rejestracji powiązanych ze sobą adresów. Rejestracja w serwerze LES oznacza przyłączenie klienta do ELAN-u, który ten serwer obsługuje. Aby ELAN był w pełni funkcjonalny, klient LEC zestawia jeszcze połączenie do serwera BUS, za pomocą którego będzie wysyłał ruch multicastowy i broadcastowy; enkapuslacja ramek LAN w komórki ATM i przesyłanie ich poprzez sieć ATM. LANE w transmisji danych wykorzystuje warstwę AAL5. Funkcjonalność LEC implementowana jest w kartach ATM, przełącznikach oraz routerach. Z reguły możliwe jest uruchomienie więcej niż jednego klienta na pojedynczym urządzeniu. Pozwala to tworzyć wirtualne sieci LAN na bazie ATM.

Serwer LES jest centralną częścią usługi LANE. Zapewnia on klientom LEC niezbędne informacje potrzebne do zestawienia połączeń z innymi klientami LEC. Do podstawowych zadań serwera LES należą:

przyłączenie do sieci ELAN klientów LEC. LES na podstawie danych zawartych w żądaniu klienta LEC może klienta przyłączyć do ELAN-u lub odrzucić żądanie; rejestracja adresu klienta LEC oraz stworzenie na podstawie zarejestrowanych adresów LEC bazy odwzorowań adresów MAC na adresy ATM; W sieci ATM może być uruchomionych wiele serwerów LES ale, zgodnie ze specyfikacją LANE 1.0, jeden serwer LES obsługuje jedną sieć ELAN. Ten fakt ograniczył wdrożenia technologii LANE w sieciach LAN. Mało kto chciał uzależniać działanie sieci od jednego elementu. Powstały firmowe implementacje, które pozwalały na tworzenie serwerów zapasowych. Nie były to rozwiązania kompatybilne ze sobą, co zmuszało użytkowników do zakupu urządzeń od jednego producenta.

Serwer BUS jest usługą, którą zazwyczaj uruchamia się na tym samym urządzeniu, na którym działa serwer LES. Serwer realizuje funkcje rozsyłania pakietów typu broadcast i multicast do klientów zlokalizowanych w obrębie pojedynczej emulowanej sieci LAN. Serwer BUS jest identyfikowany poprzez specjalny adres ATM skojarzony z adresem broadcastowym MAC. Do serwera BUS przyłączeni są klienci LEC.

Serwer LECS jest bazą danych zawierającą informacje konfiguracyjne na temat poszczególnych podsieci ELAN. Działa on najczęściej na adresie ATM 47007900000000000000000000-00A03E000001-00 oraz używa stałych kanałów VPI=0 i VCI=17. Użycie domyślnych adresów pozwala klientom LEC na szybkie odszukanie serwera LECS. W bazie danych serwera LECS znajdują się adresy ATM serwerów LES i BUS. Poszczególne serwery są przypisane do ELAN-ów, a ELAN-y są identyfikowane poprzez nazwy. Z każdym ELAN-em związane są także informacje określające typ emulowanej sieci (Ethernet lub Token Ring) oraz rozmiary ramek w danej sieci. Klient LEC chcąc dołączyć się do ELAN-u w swoim zgłoszeniu podaje nazwę sieci ELAN, do której chce uzyskać połączenie, a w odpowiedzi otrzymuje adresy serwerów LES i BUS dla tej sieci. Konfiguracja serwera LECS sprowadza się do podania adresów ATM serwerów LES/BUS, określenia typu sieci oraz nadania jej nazwy. W dużej części urządzeń konfiguracja jest jeszcze bardziej uproszczona i sprowadza się do podania nazwy ELAN-u i typu sieci zaś serwisy LES/BUS są automatycznie tworzone, a ich adresy umieszczane w bazie danych LECS.

W standardzie LANE 1.0 istnieją dwa typy połączeń: połączenia sterujące oraz połączenia do transportu danych. Każdy z klientów LEC zestawia połączenia VCC dla potrzeb sterowania transmisją danych z serwerami LES, LECS, BUS. Dodatkowe połączenia sterujące ustanawia także serwer LES. W sumie w standardzie LANE 1.0 istnieją następujące połączenia kontrolne:

Configuration Direct VCC - dwukierunkowy kanał typu punkt-punkt zestawiany przez serwer LES do serwera LECS; Control Direct VCC - dwukierunkowy kanał typu punkt-punkt zestawiany przez klienta LEC do serwera LES; Control Distribute VCC - jednokierunkowe połączenie typu punkt-wielopunkt zestawiane przez serwer LES do wszystkich klientów LEC. Wykaz połączeń sterujących pokazuje slajd.

W przypadku połączeń związanych z transportem danych mamy do czynienia z połączeniami:

Data Direct VCC - dwukierunkowy kanał pomiędzy dwoma klientami LEC; Multicast Send VCC - dwukierunkowy kanał zestawiany przez klienta LEC do serwera BUS; Mutlicast Forward VCC - jednokierunkowe połączenie typu punkt - wiele punktów, które zestawia serwer BUD do klientów LEC. Połączenia te znajdują się na slajd. Serwer BUS może przesyłać dane do klientów LEC przez dwa typy łączy Multicat Send VCC jak i Multicast Forward VCC. Niezależnie do rodzaju wybranego łącza dane, które ma otrzymać klient LEC, muszą być nadesłane w odpowiedniej kolejności i nie mogą się duplikować.

Architekturę sieci LANE można opisać za pomocą modelu odniesienia ISO/OSI. W tym modelu LANE 1.0 mieści się w warstwie łącza danych (patrz slajd). Z punktu widzenia ATM, LANE jest usytuowana nad warstwą AAL5. Takie usytuowanie LANE czyni ją niewidoczną dla aplikacji działających w sieciach LAN.

Aby uruchomić LANE 1.0, w pierwszej kolejności należy uruchomić serwery LES, LECS, BUS. Konfiguracja polega na nadaniu nazwy ELAN-owi oraz na uruchomieniu serwerów LES i BUS, które ten ELAN będą obsługiwać. Następnie należy skonfigurować serwer LECS. Do jego bazy należy wprowadzić adresy serwerów LES i BUS oraz nazwę skojarzonego z nimi ELAN-u.

W kliencie LEC konfiguracja sprowadza się do podania nazwy ELAN-u, w którym klient ma pracować. Po włączeniu, klient za pomocą procedur związanych z ILMI pobiera prefiks sieci ATM, w której będzie pracował. Następnie, łącząc się z serwerem LECS (który pracuje na domyślnym adresie) za pomocą kanału o identyfikatorach VPI=0 i VCI=17, pobiera adresy serwerów LES i BUS obsługujących ELAN, do którego LEC ma się przyłączyć. Potem klient LEC rejestruje się w serwerze LES i zestawiane są połączenia kontrolne.

Obiekt klienta LEC jest przeznaczony do transmisji danych. W klasycznej sieci LAN urządzenie wysyła pakiet pod adres MAC. W sieci LANE jest podobnie z tym, że przed wysłaniem transmisji musi być zestawiony kanał. Aby było to możliwe, adresy MAC są odwzorowywane na adresy ATM. Z sieci ATM klient LEC otrzymuje 13-bajtowy prefiks, który jest dopełniany 6 bajtami adresu MAC. Pozostały 20-ty bajt ma znaczenie lokalne. W przypadku, gdy klient LEC chce wysłać dane pod jakiś adres, MAC wysyła zapytanie do serwera LES, który (jeśli jest w stanie udzielić odpowiedzi) wysyła ją do LEC. Jeśli serwer LES nie potrafi udzielić odpowiedzi, to wysyła zapytanie do wszystkich klientów LEC o dany adres MAC. Jeśli któryś z klientów LEC posiada informacje o danym adresie MAC, to odsyła ją do serwera LES a ten do klienta, który pytał.

Koncepcja sieci wirtualnej (ang. Virtual LAN) zakłada wyodrębnienie logicznych podsieci w ramach sieci, niezależnie od ich fizycznego połączenia. Pozwala to wyodrębniać użytkowników sieci, którzy mają mieć dostęp do określonych zasobów. Można także tworzyć wyizolowane grupy robocze. LANE spełnia te wymogi. Dla każdej wyodrębnionej sieci należy powołać oddzielny ELAN. Każda sieć ELAN jest oddzielną niezależną siecią LAN.

Mechanizmy LANE 1.0, choć bardzo dobrze naśladowały działanie sieci LAN, nie zyskały powszechnego wdrożenia. Główną przyczyną było powierzenie centralnej funkcji serwerom LES i BUS, których nie można było dublować. W przypadku ich awarii przestawała działać cała sieć. Problemy te rozwiązuje specyfikacja LANE 2.0, ale zanim ona powstała przełączniki Ethernet staniały do takiego stopnia, że obecnie nie opłaca się wdrażać sieci ATM w sieci LAN. Obecna funkcjonalność przełączników LAN przewyższa możliwości sieci LANE 1.0. Możliwe jest tworzenie VLAN-ów oraz ustawianie priorytetów dla pakietów. Sieci LANE pozostały wyłącznie jako rozwiązanie niszowe.

Mając na uwadze problemy związane ze specyfikacją LANE 1.0, ATM Forum opracowało nową specyfikację LANE o wersji 2.0. LANE 2.0 jest kompatybilna wstecz z wersją 1.0, a jednocześnie jest specyfikacją rozbudowującą możliwości sieci LANE.

Zadaniem specyfikacji LANE jest emulowanie połączenia pomiędzy różnymi segmentami sieci LAN poprzez sieć ATM. Sieć LAN może być zbudowana w oparciu o protokół Ethernet/802.3 lub Token-Ring/802.5. Aplikacje pracujące na komputerach wykorzystujące te protokoły nie powinny zauważać istnienia sieci ATM. Każdy ELAN z punktu widzenia sieci ATM jest zbiorem LEC-ów usytuowanych najczęściej na tak zwanych przełącznikach brzegowych oraz LEC-ów zlokalizowanych bezpośrednio na komputerach. Połączenie pomiędzy innymi LAN-ami mogą zapewnić wyłącznie routery. Z punktu widzenia modelu ISO/OSI LANE 2.0 jest usytuowane poniżej warstwy 2.

Specyfikacja LANE v.2.0 definiuje 5 podstawowych obiektów odpowiedzialnych za realizację usług w emulowanej sieci LAN. Są to:

LEC (ang. LAN Emulation Client) - obiekt reprezentujący klienta; LES (ang. LAN Emulation Server) - obiekt odpowiedzialny za rejestrację klientów LEC; BUS (ang. Broadcast and Unknown Service) - obiekt odpowiedzialny za obsługę ruchu broadcastowego; LECS (ang. LAN Emulation configuration Server) - obiekt przeznaczony do udostępniania informacji konfiguracyjnych klientom LEC w czasie inicjalizacji; SMS (ang. Selective Multicast Server) - obiekt odpowiedzialny za obsługę ruchu multicastowego. Protokół LANE v.2.0 definuje także dwa protokoły: LNNI (ang. LAN Emulation Network Network Interface) - odpowiedzialny za komunikację pomiędzy obiektami LES, BUS, SMS, LECS; LUNI (ang. LAN Emulation User Network Interface) - odpowiedzialny za komunikację pomiędzy LEC, a pozostałymi elementami sieci LANE.

Z punktu widzenia modelu sieci komputerowej, LANE 2.0 pozostaje w tym samym miejscu modelu ISO/OSI co LANE 1.0. oraz jest w zamierzeniu twórców zgodne wstecz z LANE 1.0. Ma to pomóc w migracji już istniejących instalacji z LANE 1.0 do LANE 2.0. LANE 2.0 nie miałoby jednak racji bytu, jeśli nie wprowadzono by w nim zmian w stosunku do wersji 1.0. Zmiany te miały usunąć braki występujące w wersji 1.0. Zasadnicze różnice pomiędzy LANE 2.0 i LANE 1.0 to istnienie w LANE 2.0:

wielu obiektów typu LES, BUS, LECS - mogących obsługiwać te same ELAN-y; nowego obiektu SMS, który pozwala na rozdzielenie drzew broadcastowych i multicastowych; wsparcia dla różnych klas ruchu, w tym ABR; ośmiu klas jakości ruchu. Cechy te pozwalają na budowę sieci o wyższej niezawodności i jakości, niż w przypadku sieci zbudowanych w oparciu o specyfikację LANE 1.0. Pozwolą także na zastąpienie rozwiązań firmowych, w których firmy oferowały własne rozwiązania podnoszące niezawodność sieci. Stanie się więc możliwe budowanie sieci w oparciu o urządzenia pochodzące od różnych producentów.

Podstawowym zadaniem LECS jest uproszczenie zarządzania. Pełni on rolę centralnego repozytorium danych konfiguracyjnych. Udostępnia on informacje innym komponentom sieci LANE. Każdy z komponentów sieci LAN ustanawia, dla celów komunikacji z LECS-em, połączenie kanałem VCC zwane Configuration Direct VCC. Ponieważ w sieci LANE 2.0 może być wiele LECS-ów, LES-ów, BUS-ów oraz SMS-ów, to dopuszczalna jest sytuacja, w której np. dwa LES-y mogą być podłączone do różnych LECS-ów. LECS oferuje pozostałym komponentom sieci LANE specyficzne informacje, potrzebne im do konfiguracji. LEC w czasie uruchamiania otrzymuje od LECS-a adres LES-a, który obsługuje dany ELAN. Nieco inną informację otrzymują od LECS-a komponenty LES i SMS. LECS podaje im adresy sąsiednich serwerów LES i SMS obsługujących ten sam ELAN. Jedynym elementem sieci LANE 2.0, który nie otrzymuje informacji konfiguracyjnych od serwera LECS, jest BUS. Wynika to z faktu, że każdy BUS jest ściśle powiązany z serwerem LES i może bezpośrednio od niego otrzymywać dane konfiguracyjne. Konfiguracja sieci może ulegać zmianom w czasie pracy. Aby zachować w miarę możliwości spójną konfigurację sieci, możliwe jest by LECS dynamiczne odświeżał konfiguracje pozostałym komponentom sieci. Najprostszą metodą jest ponowne odpytanie LECS-a o konfigurację przez inny komponent sieci. Ponieważ w sieci LANE może być więcej niż jeden LECS, konieczny jest mechanizm synchronizacji baz danych zawartych w każdym LECS-ie. Synchronizacja ta jest dokonywana za pomocą kanałów synchronizacyjnych VCC. Niestety sam mechanizm synchronizacji danych, zawartych w LECS-ach, nie jest do końca zdefiniowany w specyfikacji LANE.

LES jest głównym komponentem odpowiedzialnym za prace emulowanej sieci LAN. Najczęściej realizowany jest w postaci oprogramowania na przełączniku ATM. Istnieją implementacje pracujące na brzegowych urządzeniach sieci ATM np. na routerach CISCO czy stacjach roboczych SUN. Każdy LES tworzy i utrzymuje bazę powiązań adresów ATM i MAC wszystkich stacji pracujących w danym LAN-ie. Adresy ATM najczęściej są tworzone w oparciu o prefiks sieci ATM i adres MAC stacji. Zadaniem serwera LES jest przyłączenie do sieci ELAN klienta LEC. Klient LEC może zostać przyłączony wyłącznie wtedy do ELAN-u, gdy jego żądanie przyłączenia będzie skierowane do LES-a, który ten ELAN obsługuje. Wyjątkiem są rozwiązania firm, które w konfiguracji zawierają tzw. ELAN domyślny. LES, który taki ELAN obsługuje, przyłącza do sieci każdego klienta LES zgłaszającego żądanie przyłączenia do sieci. Ułatwia to tworzenie prostej, emulowanej sieci, bo wystarczy włączyć urządzenia i sieć już działa. Niestety, istnienie takiego LES-a i ELAN-u prowadzi do wielu problemów. Wystarczy bowiem by LES obsługujący daną sieć ELAN w czasie startu urządzeń, wystartował nieco później niż LES obsługujący ELAN domyślny. Jest wtedy szansa, że żądania wysłane przez prawidłowo skonfigurowane LEC-e zostaną przechwycone przez domyślny LES. Sieć ELAN nie funkcjonuje wtedy prawidłowo. Ponieważ w sieci ELAN w specyfikacji LANE 2.0 dopuszczalne jest istnienie wielu serwerów LES, muszą one synchronizować swoje bazy danych. Czynią to ustanawiając pomiędzy sobą połączenia VCC zwane Control Cache VCC. Synchronizacja baz odbywa się za pomocą protokołu Server Cache Synchronization Protokol (SCSP). Aby sieć ELAN prawidłowo pracowała, wszystkie serwery LES, obsługujące dany ELAN, muszą mieć pomiędzy sobą połączenia, gdyż jedynie wtedy możliwa jest synchronizacja wszystkich serwerów LES. Konieczność ta wynika z modelu pracy sieci. Kiedy LEC zostaje włączony do sieci, jest on podłączany do najbliższego serwera LES wskazanego przez LECS-a. Kiedy LEC musi przesłać dane pod adres, którego nie zna, wysyła zapytanie o adres ATM do swojego serwera LES. Serwer LES może odpowiedzieć na zapytanie o adres ATM podając adres ATM klienta LEC lub przesłać zapytanie do innego serwera LES, który na te pytanie odpowie.

Serwer BUS jest komponentem odpowiedzialnym za obsługę pakietów broadcastowych (jeden do wszystkich) i pakietów, dla których nie udało się znaleźć ATM-owego adresu przeznaczenia. Serwer BUS bierze także udział w transmisji pakietów multicastowych (jeden do wielu) jeśli klientem LEC jest klient działający zgodnie ze specyfikacją LANE 1.0. Istnieją dwa sposoby realizacji serwera BUS. Pierwsza oparta jest na technologii VCC-Mapped. W takim wykonaniu serwer BUS przesyła pakiety broadcastowe do wszystkich klientów LEC niezależnie od tego, czy dany LEC zarejestrował jakiś MAC adres czy nie. Druga technologia jest nieco bardziej inteligentna. Pakiety broadcastowe są wysłane tylko tym klientom, którzy zarejestrowali jakieś adresy MAC. Pozwala to na zaoszczędzenie pasma, a także oszczędza klientowi LEC pracy związanej z usuwaniem niechcianych ramek. Każdy serwer BUS jest sparowany z serwerem LES. W specyfikacji LANE 1.0 i 2.0 nie jest wyszczególniony protokół komunikacyjny pomiędzy serwerem LES i BUS. Producenci implementują go sami. Najczęściej w czasie konfigurowania urządzenia wystarczy skonfigurować serwer LES, a serwer BUS będzie uruchomiony automatycznie z takim samym adresem ATM jak LES. W czasie inicjalizacji LEC, po wysłaniu zapytania o adres broadcastowy, otrzymuje też za pośrednictwem serwera LES adres skojarzonego serwera BUS. Klient ustanawia do serwera BUS połączenie Default Multicast Send VCC, a w odpowiedzi serwer BUS ustanawia Multicast Forwarding VVC do klienta. Klient LEC po zestawieniu takich połączeń staje się lokalnym klientem serwera BUS. Wszystkie pakiety broadcastowe, wysłane przez klienta LEC, są rozsyłane przez serwer BUS do jego lokalnych klientów LEC oraz do innych serwerów BUS obsługujących ten sam ELAN. Aby było to możliwe, wszystkie serwery BUS pracujące we wspólnym ELAN-ie muszą ustanowić pomiędzy sobą połączenie Multicast Forward VCC. Każdy klient LEC może także wysyłać do serwera BUS pakiety z nieznanymi adresami docelowymi oraz pakiety multicast. Jeśli klient LEC znajdzie adres docelowy dla danego pakietu multicastowego, to może go wysłać bezpośrednio do docelowych stacji. Jeśli nie, to może go wysłać bądź na adres serwer BUS, bądź na adres serwera SMS. Specyfikacja LANE 2.0 dopuszcza obie te możliwości. Wynika to z konieczności zachowania zgodności ze specyfikacją LANE 1.0, w której pakiety multicastowe mogły być wysyłane wyłącznie na adres serwera BUS. W przypadku pakietów z nieznanymi adresami docelowymi BUS rozsyła je do wszystkich klientów LEC. Jeśli któryś z klientów LEC zna adres, jego odpowiedź zostanie dodana do bazy adresowej serwera LES.

Serwer BUS nie dostarczał efektywnego mechanizmu transmisji pakietów multicastowych. W specyfikacji LANE 2.0 dodano wiec nowy obiekt, którego zadaniem jest przejęcie od serwera BUS obsługi ruchu multicastowego. Serwer SMS nie przejmuje jednak całości tego ruchu. Nie było to możliwe, ze względu na konieczność zachowania zgodności z poprzednią specyfikacją LANE 1.0. SMS w czasie inicjalizacji ustanawia połączenie z serwerem LES, którego adres otrzymał od serwera LECS. Do synchronizacji bazy z serwerem LES, SMS używa protokołu SCSP. Klienci LEC działający w oparciu o specyfikację LANE 1.0 nie zauważają istnienia serwera SMS i wysyłają wszystkie dane multicastowe do serwera BUS. Klient LEC napisany w oparciu o specyfikacje LANE 2.0 może ustanowić połączenie z serwerem SMS i do niego wysyłać dane multicastowe. Klient LEC v.2.0 może stać się członkiem grupy multicastowej. Grupę multicastową tworzy lokalny serwer LES poprzez rejestrację w swojej bazie następujących informacji: adres multicastowy, adres serwera SMS, adres klienta LEC. Serwer LES po zarejestrowaniu grupy rozsyła tę informację za pomocą protokołu SCSP do pozostałych serwerów LES oraz do serwera SMS. Kiedy serwer SMS otrzyma informację o grupie, tworzy drzewo Multicast Forward VCC, do którego jako liść dodaje klienta LEC. Odtąd LEC v.2.0 będzie otrzymywał dane multicastowe. Należy jednak pamiętać, że oprócz nowych klientów w sieci mogą znajdować się także klienci LEC v.1.0. Aby zapewnić poprawną współpracę obu typów klientów, serwer SMS pracuje przy transmisji multicastów prawie tak samo jak inteligentny serwer BUS. Nie może jednak przejąć pełnej funkcjonalności serwera BUS, gdyż nie ma możliwości obsługiwania zapytań o adres przy przesyłaniu strumieni danych jakie są generowanie w normalnym ruchu sieciowym (ang. unicast). Ponadto serwer BUS jest zawsze parą dla konkretnego serwera LES. Natomiast serwer SMS, posiadając pełną bazę klientów serwera LES, jest w swej funkcjonalności zbliżony do serwera LES, nie ma jednak możliwości bezpośredniej rejestracji LEC w swojej bazie.

Klient LEC pełni rolę interfejsu sprzęgającego sieć LAN z siecią ATM. Jako usługa jest realizowany w dwóch zasadniczych odmianach:

w postaci oprogramowania (sterownika) do karty sieciowej w komputerze lub routerze. W tym przypadku klient LEC rejestruje się w bazie adresowej serwera LES jako normalny klient z pełnym adresem; jako dodatkowy moduł oprogramowania w tak zwanych przełącznikach brzegowych. W tym przypadku klient LEC rejestruje się w bazie adresowej serwera LES jako proxy LEC. Serwer LES przesyła do tego typu klientów LEC wszystkie zapytania o powiązanie adresów MAC - ATM, których sam nie potrafi obsłużyć; Niezależnie od sposobu implementacji klient LEC realizuje następujące zadania: transmisji danych do innych klientów LEC dla normalnej transmisji danych między urządzeniami w sieci (unicast); transmisji danych do serwera BUS dla ruchu broadcastowego; transmisji danych do serwera SMS dla ruchu multicastowego; rejestracji swoich adresów w serwerze LES; enkapsulacji ramek danych z sieci LAN w ramki sieci ATM. Standardowo, w czasie inicjalizacji, klient LEC odpytuje serwer LECS o adresy serwerów LES i BUS. Następnie rejestruje swój adres ATM i adres MAC w bazie serwera LES. W niektórych implementacjach klientów LEC możliwe jest ręczne podanie adresów LES i BUS, a także nadanie adresu ATM klientowi LEC. Pozwala to uniknąć kłopotów związanych z błędami w implementacjach sygnalizacji UNI. Jednocześnie obniża to poziom bezpieczeństwa sieci, gdyż pozwala na podszycie się pod istniejącego klienta LEC.

Sieć zbudowana w oparciu o specyfikacje LANE 2.0 pracuje w architekturze klient-serwer. Klientem w tej sieci jest LEC. Za pomocą interfejsu LUNI (ang. LANE User to Network Interface) komunikuje się z serwerami realizującymi usługę LAN Emulation Service. Serwery LECS, LES, BUS, SMS do komunikacji pomiędzy sobą używają zestawu interfejsów LNNI (ang. LAN Emulation Network to Network Interface). Dla każdego typu połączeń pomiędzy serwerami sieci ATM zdefiniowano następujące interfejsy LNNI:

LECS LNNI, który odpowiedzialny jest za zestawianie kanałów: synchronizacyjnych do innych serwerów LECS (LECS synchronization VCC(s) to other LECS); konfiguracyjnych do serwerów LES i BUS (Configuration Direct VCC(s) from one or more LES and BUS). LES NNI, który odpowiedzialny jest za zestawianie kanałów VCC: konfiguracyjnych do serwera LECS (Configuration Direct VCC to an LECS); synchronizacyjnych do sąsiednich serwerów LES lub BUS (Cache Synchronization VCC to neighbour LES(s) or SMS(s)); kontrolnych do pozostałych serwerów LES (Controll Coordinate VCC to all other VCC). BUS LNNI, który odpowiedzialny jest za zestawianie multicastowych kanałów VCC do komunikacji z innymi serwerami BUS2 (Multicast Forward VCC to all other BUS); SMS LNNI, który odpowiedzialny jest za zestawianie kanałów: konfiguracyjnych do serwera LECS (Configuration Direct VCC to an LECS); synchronizacyjnych do sąsiednich serwerów LES lub SMS (Cache Synchonization VCC to neighbour LES(s) or SMS(s)); multicastowych do pozostałych serwerów SMS(s) i BUS(s) (Multicast Forward VCC to other SMS(s) and BUS(s)).

Jak widać z powyższych specyfikacji, sieć kanałów VCC protokołu LNNI realizuje trzy podstawowe zadania:

kontrolne, synchronizacyjne, transmisji danych. Prawidłowa realizacja powyższych zadań pozwala różnym serwerom serwisu LANE pracować z punktu widzenia klienta LEC tak jak jeden wspólny serwer. Aby ułatwić zarządzanie kanałami w sieci LANE przyjmuje się, że podstawową jednostką sieci jest zbiór sąsiednich serwerów. Tworzą one tzw. oko sieci (ang. mesh). Podstawowym zadaniem protokołu LNNI jest takie zestawienie kombinacji połączeń wewnątrz oka sieci, aby każdy serwer będący składnikiem takiej grupy otrzymywał komunikaty bez pośrednictwa innego serwera. Ponieważ możliwe są dwa typy połączeń VCC ("point to point" i "point to multipoint") oraz połączenia mogą inicjować różne serwery wchodzące w skład grupy, to możliwe jest powstawanie pętli połączeń. Aby zapobiec pętlom, a także brakowi połączeń, w protokole LNNI przyjęto szereg założeń, które muszą spełnić połączenia, aby sieć działała prawidłowo. Dwa pierwsze założenia to: każda wiadomość wysłana od dowolnego serwera w grupie musi trafić do wszystkich adresatów, do których jest adresowana; każda wiadomość nie może być wysłana więcej niż jeden raz do pozostałych węzłów sieci. Pozostałe założenia definiują zasady wyboru połączeń w wypadku, gdy połączenia się dublują. Kanały, które zostały uznane za niepotrzebne nie są od razu likwidowane. Usuwane są one dopiero po czasie przeterminowania. Przed upływem tego czasu mogą być w każdej chwili wykorzystane do celów transmisji. Zasady tworzenia i likwidowania kanałów ilustrują kolejne slajdy.

W fazie 1 serwer A inicjuje połączenia VCC (ciągła niebieska linia) zarówno point to multipoint jak i point to point do serwerów B,C,D.

W fazie drugiej serwer B tworzy połączenia VCC (kreskowana czerwona linia) point to point do serwerów A,C,D. Ponieważ istnieje już połączenie point to point do serwera A to jedno z nich musi zostać usunięte. Zostaje wybrane połączenie, które zainicjował serwer A. Serwer C musi mieć połączenie zarówno z serwerami sąsiednimi jak i z innymi serwerami. Aby zoptymalizować ruch, tworzy on dwa połączenie typu VCC (kreskowane zielone linie) point to multipoint, jedno wyłącznie do serwerów w obrębie swojej grupy, a drugie łączące zarówno z serwerami w obrębie grupy jak i po za nią.

W fazie 3 serwer D, który ma już połączenia point to point z serwerami A,B tworzy kanał VCC (kropkowana czerwona linia) point to multipoint do serwerów A,B,C.

Aby optymalizować ruch, serwer D przy wysyłaniu nie używa kanałów VCC point to point zestawionych do serwerów B,A. Używa do tego wyłącznie kanału point to multipoint.

W protokole SCSP zdefiniowano procedury i narzędzia niezbędne do synchronizacji baz danych tworzonych i posiadanych przez różne serwery serwisu LANE v 2.0. Jest to potrzebne, gdyż w serwisie LANE 2.0 mogą się duplikować serwery usług. Zadania realizowane przez protokół SCSP można podzielić na dwie grupy:

zadania sygnalizacyjne, zadania synchronizacyjne. Do zadań sygnalizacyjnych należy informowanie poszczególnych serwerów sieci LANE o tym, że zaszły zmiany w bazach danych. Zmiany te zachodzą na skutek włączania się nowych serwerów serwisu LANE do sieci, odłączania tychże serwerów, a także na skutek rejestracji nowych klientów LEC w różnych miejscach sieci ATM. Klienci LEC korzystający z usług sieci ATM nie powinni zauważać, gdzie są podłączeni oraz ile serwerów serwisu LANE świadczy im usługi. Rozważając sposób budowy protokołu SCSP można wyróżnić w nim dwie podwarstwy. W pierwszej warstwie określanej jako protocol independent sublayer zestawiane są połączenia pomiędzy sąsiednimi serwerami serwisu LANE. Dowolny serwer, który używa zestawu procedur składających się na tę podwarstwę, może zsynchronizować swoją bazę ze wszystkimi pozostałymi serwerami. Natomiast przy użyciu procedur składających się na podwarstwę określaną jako protocol dependent sublayer, dwa serwery korzystające z procedur składających się na tę podwarstwę mogą zsynchronizować tylko swoje bazy.

Integralną część specyfikacji LANE 2.0 stanowi specyfikacja protokołu LUNI. Definiuje ona interfejs komunikacyjny pomiędzy siecią LAN a siecią ATM. Protokół ten definiuje w jaki sposób ramki sieci lokalnej typu 802.3 oraz 802.5 są pakowane w ramki ATM. Operowanie na ramkach Ethernet i Token Ring powoduje, że zostaje zachowana pełna przeźroczystość dla aplikacji sieciowych, zbudowanych w oparciu o protokoły wyższych warstw, takich jak IP czy IPX. W ramach specyfikacji LUNI wprowadza się pojęcie klienta LEC (ang. LAN Emulation Client).

Protokół LUNI definiuje zadania, które muszą być realizowane przez klienta LEC. W większości zostały one opisane podczas omawiania zadań klienta LEC. W protokole LUNI zdefiniowane są także procedury tworzenia i usuwania kanałów VCC do realizacji poszczególnych zadań. Są to kanały inicjowane zarówno przez serwery serwisu LANE jak i klienta LEC. Kanały można podzielić na dwie zasadnicze grupy:

kanały kontrolne VCC dwukierunkowy point to point Configuration Direct VCC pomiędzy klientem LEC, a serwerem LECS (inicjowany przez klienta LEC); dwukierunkowy point to point Control Direct VCC pomiędzy klientem LEC, a serwerem LES (inicjowany przez klienta LEC); jednokierunkowy point to multipoint Control Distribute pomiędzy serwerem LES, a klientami LEC (inicjowany przez serwer LES). kanały transmisji danych: dwukierunkowy point to point Data Direct VCC pomiędzy klientami LEC (inicjowany przez klienta LEC); dwukierunkowy point to point Multicast Send VCC pomiędzy klientem LEC, a serwerem BUS (inicjowany przez klienta LEC); jednokierunkowy point to multipoint Multicast Forward VCC pomiędzy serwerem BUS, a klientami LEC (inicjowany przez serwer BUS).

Protokół LUNI v.2 jest rozszerzeniem specyfikacji LUNI v.1 i jest zgodny wstecznie z tą specyfikacją. Rozszerzenia LUNI 2.0 obejmują:

wsparcie dla QoS (Quality of Service); wsparcie dla Multicastów; multipleksacji ruchu w jednym kanale VCC. Wsparcie dla wymagań QoS obejmuje możliwość zestawiania kanałów VCC dla transmisji danych w standardzie ABRi (ang. Availble Bit Rate). W LANE 1.0 możliwe jest zestawianie wyłącznie kanałów w standardzie UBR (ang. Unspecified Bit Rate). Pozwala to na transmisję danych, które wymagają większej gwarancji jakości pasma. LANE v.2 pozwala definiować parametry QoS lokalnie dla każdego klienta LEC. Najniższe parametry jakości transmisji QoS odpowiadają transmisji w standardzie UBR. Dane wysyłane przez klienta LEC z ustawionymi parametrami QoS są otrzymywane przez odbierającego klienta LEC z zachowaniem jakości nadawania. Wsparcie dla multicastów obejmuje możliwość tworzenia takich grup multicastowych, w których odbierającymi będą tylko członkowie danej grupy. Możliwe się to stało po utworzeniu nowego obiektu w serwisach LANE serwera SMS. Pełne wykorzystanie jego właściwości jest możliwe dopiero wtedy, gdy klient LEC jest oparty o specyfikację LUNI 2.0. W LANE 1.0 multicasty były rozsyłane za pomocą serwera BUS, który rozsyłał je tak jak zwykłe pakiety broadcastowe. W LANE 2.0 klient LEC śle adresy multicastowe do serwera SMS. Następnie klient LEC rejestruje się w bazie serwera SMS jako klient, który chce odbierać pakiety multicastowe adresowane na konkretny adres multicastowy. W przypadku, gdy pakiety nie są adresowane do niego, to do niego w ogóle nie docierają. W przypadku sieci LANE 1.0 klient LEC musi odbierać i ignorować pakiety multicastowe, które nie są adresowane do niego. Pozwala to na oszczędność pasma i na lepsze wykorzystanie sieci. W LANE 1.0 w jednym kanale VCC przy transmisji danych nie jest możliwa multipleksacja ruchu do wielu różnych źródeł danych i typu danych. W takim kanale mogą być transmitowane zarówno dane kontrolne jak dane zawierające enkapsulowane pakiety sieci LAN.

Typowa sieć LAN pracuje w oparciu o drugą warstwę modelu ISO/OSI. Aby przesłać pakiet do innej sieci LAN, musi przejść on przez urządzenie realizujące usługi warstwy modelu ISO/OSI czyli przez router. Router może być aplikacją pracującą na komputerze (np. oprogramowanie KA9Q pracujące na komputerach PC), częścią systemu operacyjnego (np. jądro systemów operacyjnych Solaris i Linux potrafi routować pakiety) lub pracować jako specjalizowane urządzenie (np. routery firm CISCO, Nortel Networks, Olicom, Alcatel). Routery sprzętowe są bardzo wydajnymi urządzeniami, ale jednocześnie dość drogimi. W klasycznych sieciach LAN pojawiły się więc urządzenia łączące w sobie funkcjonalność routerów i przełączników. Nazywane są one przełącznikami warstwy trzeciej. Przełączniki tego typu analizują pierwszy pakiet ze strumienia danych, który ma być przesłany pomiędzy sieciami LAN, a następne pakiety traktuje jako kontynuację tego strumienia. Ta funkcjonalność pozwala na budowanie wysokowydajnych połączeń sieci LAN za stosunkowo nieduże pieniądze (koszt przełącznika przełączającego w warstwie 3 wyposażonego w 12 portów Fast Ethernet wynosi ok. 5.000 $). Podobną funkcjonalność dla sieci LAN zbudowanych w oparciu o specyfikacje LANE 2.0 ma zapewnić standard MPOA.

Standard MPOA v.1.1 ukazał się w maju 1999 roku. Jest on rozszerzeniem standardu MPOA 1.0, który ukazał się w lipcu 1997 roku. Standard MPOA określa sposób zastosowania protokołu NHRP (ang. Next Hop Resolution Protokol) w sieciach zbudowanych w oparciu o specyfikacje LANE 2.0. MPOA jest nadbudową nad siecią LANE (patrz rysunek 4.12 MPOA, a sieć LANE). MPOA pozwala różnym sieciom ELAN na przesyłanie pakietów z pominięciem routera. Pozwala to sieci ATM na:

znacznie bardziej efektywną komunikacje pomiędzy ELAN-ami; zmniejszenie liczby urządzeń potrzebnych do przesłania pakietów pomiędzy ELAN-ami; uproszczenie budowy sieci, gdyż zmniejsza się liczba urządzeń potrzebnych do zapewnienia połączeń międzysieciowych, a co za tym idzie upraszcza się konfiguracja sieci; obniżenie kosztów, bo mniejsza liczba routerów oznacza więcej wolnych portów dla innych urządzeń. Standard MPOA może być zaimplementowanych w sieciach ATM które: wspierają sygnalizacje UNI (ang. User Network Interface) w wersjach 3.0, 3.1, 4.0. pracują zgodnie ze specyfikacją LANE 2.0. Aby wdrożenie MPOA było możliwe, należy najpierw zaimplementować protokół NHRP, którego definicja znajduje się w dokumentach RFC 2332.

Model sieci MPOA składa się z dwóch komponentów:

serwera MPOA (MPS - MPOA Server), klienta MPOA (MPC - MPOA Client).

Serwer MPOA (MPS) jest funkcjonalnym odpowiednikiem routera. W jego skład wchodzi NHS (ang. Next Hop Serwer),który jest implementacją standardu NHRP z pewnymi rozszerzeniami. MPS współpracuje z klientami MPC. MPS jest najczęściej implementowany jako rozszerzenie na oprogramowania na routerach sprzętowych. Klient MPOA (MPC) jest lokowany na przełącznikach brzegowych (MPOA Egde Device) lub na komputerach bezpośrednio przyłączonych do sieci ATM (MPOA HOST). Zadaniem klienta MPOA jest wykrywanie strumienia pakietów, które muszą być przesłane przez router i przesłanie informacji o nich do serwera MPOA. Gdy okaże się, że transmisja danych jest skierowana do ELAN-u, który jest w tej samej sieci ATM i ma zaimplementowanego klienta MPC, to zestawiane jest połączenie VCC łączące bezpośrednio dwóch klientów LEC i nim są transmitowane dane. Sytuację tą ilustruje rysunek 4.13. Przykładowe drogi pakietów w sieci ze standardem MPOA.

Standard LANE 2.0 oraz jego uzupełnienie, czyli standard MPOA, pozwalają na budowę bardzo wydajnych sieci LAN. Zastosowanie obu standardów eliminuje wiele ograniczeń, które spotykało się w sieciach zbudowanych w oparciu o specyfikację LANE 1.0. Rozbudowane zostały zarówno serwisy (wprowadzono serwer multicastów, dzięki MPOA możliwy jest routing) oraz, co szczególnie ważne, poprawiono niezawodność sieci poprzez wprowadzenie dublujących się serwerów usług. Praktyczne zastosowanie tych standardów stoi jednak pod znakiem zapytania. MPOA zapewnia bardzo efektywny routing, ale jednocześnie ma bardzo słabe możliwości kontroli i filtracji ruchu. Wymaga także rozbudowania istniejących urządzeń o większą ilość pamięci i silniejsze procesory. Trzeba także pamiętać, że w dzisiejszych czasach zbudowanie sieci ściśle wiąże się z koniecznością wdrożenia różnorodnych mechanizmów bezpieczeństwa, które w standardzie LANE i MPOA nie są przewidziane. Główną jednakże przeszkodą w budowie sieci ATM LANE są i będą koszty. Pojedyncza karta do przełącznika ATM z czterema portami ATM 155 Mb/s kosztuje tyle ile 24-portowy przełącznik 10/100Mb/s dla sieci LAN. Karta ATM do komputera PC kosztuje średnio pięć sześć razy więcej niż dobrej klasy karta Fast Ethernet. W ofercie firm trudno jest znaleźć karty ATM szybsze niż 622 Mb/s. Jednocześnie w sieciach LAN mamy do czynienia z ofensywą Gigabit Ethernetu. Takiej prędkości transmisji nie gwarantuje żaden przełącznik ATM przeznaczony dla sieci LAN. Prawdopodobnie jedynym miejscem, gdzie znajdą praktyczne zastosowania standardy LANE 2.0 i MPOA będą sieci zbudowane na standardzie LANE 1.0. Są to jednak tylko przypuszczenia, gdyż koszty przejścia do LANE 2.0 mogą być na tyle wysokie, że będzie to także nieopłacalne. Wiele sieci ATM pracuje w oparciu o firmowe standardy, które zapewniają zarówno routing pomiędzy sieciami jak i zwiększoną niezawodność sieci. Sprawdzają się one na tyle dobrze, że podjęcie się ich wymiany spowodowałoby wyłącznie niepotrzebne koszty.

Standard LANE służy do transmisji danych przez sieci ATM w sieciach LAN. Dla sieci typu WAN nie za bardzo się nadaje. Do tego typu rozwiązań przeznaczonych jest szereg innych standardów. Jednym z szerzej stosowanych jest standard IP over ATM. W standardzie określony jest sposób odwzorowania pakietów IP na komórki ATM (RFC 1483) oraz sposób odwzorowania adresów ATM na adresy IP (RFC 2225). Standard IP over ATM pozwala na podział fizycznej sieci ATM na segmenty IP określane mianem LIS (ang. Logical IP Subnetwork). W ramach tej podsieci przyłączane do niej urządzenia mogą się komunikować korzystając bezpośrednio z protokołu IP. Komputery, które znajdują się w różnych podsieciach LIS, do komunikacji potrzebują routera.

Komórki ATM mają stałą długość zaś pakiety IP zmienną. Należy więc podzielić odpowiednio pakiety IP na mniejsze i dodać do nich informacje kontrolne. Dokument RFC 2225 zeleca by do enkapsulacji pakietów wykorzystywać multipleksacje pakietów LLC/SNAP opisaną w RFC 1453. Enkapsulacja LLC/SNAP umożliwia transmisję różnych protokołów warstwy sieciowej przy pomocy pojedynczego połączenia wirtualnego. Typ danych przenoszonych przez dany pakiet jest identyfikowany na podstawie nagłówka LLC/SNAP. Nagłówek ten składa się z 3 bajtów przeznaczonych do identyfikacji typu protokołu łącza danych (część LLC) i 5 bajtów przeznaczonych do jednoznacznej identyfikacji protokołu (część SNAP). Część SNAP składa się z pola EtherType określającego typ protokołu w ramach danej organizacji standaryzującej natomiast zawartość pola OUI identyfikuje tę organizację.

Dla pakietów IP zalecane wartości pól są następujące: 0xAAAA03 dla pola LLC, co odpowiada ramce Ethernet; 0x000000 dla pola OUI, co oznacza organizację odpowiedzialną za standaryzację Ethernetu; 0x0800 dla pola EtherType, co odpowiada pakietowi IP w ramce Ethernet. Właściwy pakiet IP zawarty jest w polu IP PDU. Dodatkowo warstwa ALL 5 dodaje do pakietu własne, specyficzne dla niej dane, takie jak sumy kontrolne (CRC) czy też pola wypełnienia (PAD).

Podobnie jak w LANE, także w IP over ATM zachodzi konieczność odwzorowania adresów IP na adresy ATM. Adresy ATM są niezbędne do zestawienia połączenia pomiędzy komunikującymi się urządzeniami. Po zestawieniu połączenia, połączenie jest jednoznacznie identyfikowane poprzez identyfikator wirtualnego połączenia, który jest złożony z pary VPI/VCI. Oznacza to, że po procesie zestawienia połączenia adres IP jest mapowany na identyfikator wirtualnego połączenia. Do odwzorowania adresów IP na adresy ATM służy protokół ATMARP a InATMARP do odwzorowań odwrotnych. Protokoły te są odpowiednikami protokołów ARP i InARP z tradycyjnych sieci IP. Zasadnicza różnica w działaniu polega na tym, że w klasycznych sieciach żądanie z protokołu ARP jest wysyłane do wszystkich stacji w podsieci, natomiast w sieci ATM jest wysyłane do serwera ATMARP. Serwer ATMARP ma tę wadę, że w przypadku jego awarii sieć przestaje działać. Działanie tych protokołów różni się nieco w zależności od użytych technik połączeń (PVC,SVC).

W technologii ATM administrator może zestawić kanał PVC. Kanał tego typu nie wymaga użycia technik sygnalizacji. Jeśli korzystamy z tej technologii, to na stałe można przypisać adresy IP do identyfikatorów wirtualny połączeń. Nie jest więc konieczne zastosowanie serwera ATMARP. Taka technika ma sens, gdy sieć jest nieduża. W przypadku większej podsieci zbudowanej w oparciu o kanały PVC można wykorzystać protokół InATMARP. Pozwoli on uzyskać adres IP urządzenia znajdującego się na drugim końcu kanału PVC. Pozwoli to administratorowi zmniejszyć liczbę wpisów w tablicy ARP.

W przypadku korzystania z kanałów SVC, urządzenia w sieci ATM muszą zestawić połączenie. Zestawienie połączenia wymaga znajomości adresu ATM urządzenia, do którego połączenie ma być zestawione. Adres ten może być otrzymany z pliku konfiguracyjnego w urządzeniu bądź otrzymany od serwera ATMARP. Aby było możliwe przesłanie zapytania do serwera ATMARP, w pliku konfiguracyjnym urządzenia należy podać adres serwera, który będzie daną podsieć obsługiwał. Serwer, na podstawie żądań od klientów, buduje własną tablicę odwzorowań, której używa następnie do udzielania odpowiedzi na zapytania ARMARP. Dane w serwerze są trzymane przez określony czas np. 20 minut po czym usuwane. Po otrzymaniu odpowiedzi od serwera ARP, klient zestawia kanał SVC do docelowego urządzenia za pomocą procedur ATM. Połączenia te są likwidowane po jakimś czasie nieużywania.

Koncepcja sieci ATM jest obecnie dojrzałą technologią, ale wydaje się, że dojrzała zbyt późno. Zanim opracowano technologię LANE 2.0, standardowe urządzenia sieci LAN potaniały na tyle, że jej wdrożenia stało się nieopłacalne. Dziś, gdy ATM jest technologią dopracowaną, w sieciach stosowany jest zwykle protokół IP. IP dociera wszędzie tam gdzie dociera ATM, a ATM nie wszędzie tam gdzie protokół IP. Na bazie IP realizowane są usługi transmisji głosu i obrazu - czyli to, co miało być domeną ATM. Powstają standardy, które pozwalają na bazie sieci IP realizować usługi z wymaganiami QoS. Wydaje się więc, że dni ATM są policzone. Nie nastąpi to wprawdzie zbyt szybko, gdyż wielcy operatorzy ponieśli bardzo duże koszty na zbudowanie infrastruktury sieci ATM. Koszty te muszą się zwrócić, zaś nowe technologię oparte na IP muszą być dopracowane.

@@ Linia 552: / Linia 552: @@
 {| border="0" cellpadding="4" width="100%"
 |valign="top" width="500px"|[[Grafika:SK_M4_Slajd51.png|thumb|500px]]
-|valign="top"|Serwer BUS jest komponentem odpowiedzialnym za obsługę pakietów broadcastowych (jeden do wszystkich) i pakietów, dla których nie udało się znaleźć ATM-owego adresu przeznaczenia. Serwer BUS bierze także udział w transmisji pakietów multicastowych (jeden do wielu) jeśli klientem LEC jest klient działający zgodnie ze specyfikacją LANE 1.0. Istnieją dwa sposoby realizacji serwera BUS. Pierwsza oparta jest na technologii VCC-Mapped. W takim wykonaniu serwer BUS przesyła pakiety broadcastowe do wszystkich klientów LEC niezależnie od tego, czy dany LEC zarejestrował jakiś MAC adres czy nie. Druga technologia jest nieco bardziej inteligentna. Pakiety broadcastowe są wysłane tylko tym klientom, którzy zarejestrowali jakieś adresy MAC. Pozwala to na zaoszczędzenie pasma, a także oszczędza klientowi LEC pracy związanej z usuwaniem niechcianych ramek. Każdy serwer BUS jest sparowany z serwerem LES. W specyfikacji LANE 1.0 i 2.0 nie jest wyszczególniony protokół komunikacyjny pomiędzy serwerem LES i BUS. Producenci implementują go sami. Najczęściej w czasie konfigurowania urządzenia wystarczy skonfigurować serwer LES, a serwer BUS będzie uruchomiony automatycznie z takim samym adresem ATM jak LES. W czasie inicjalizacji LEC, po wysłaniu zapytania o adres broadcastowy, otrzymuje też za pośrednictwem serwera LES adres skojarzonego serwera BUS. Klient ustanawia do serwera BUS połączenie iDefault Multicast Send VCC, a w odpowiedzi serwer BUS ustanawia Multicast Forwarding VVC do klienta. Klient LEC po zestawieniu takich połączeń staje się lokalnym klientem serwera BUS. Wszystkie pakiety broadcastowe, wysłane przez klienta LEC, są rozsyłane przez serwer BUS do jego lokalnych klientów LEC oraz do innych serwerów BUS obsługujących ten sam ELAN. Aby było to możliwe, wszystkie serwery BUS pracujące we wspólnym ELAN-ie muszą ustanowić pomiędzy sobą połączenie Multicast Forward VCC. Każdy klient LEC może także wysyłać do serwera BUS pakiety z nieznanymi adresami docelowymi oraz pakiety multicast. Jeśli klient LEC znajdzie adres docelowy dla danego pakietu multicastowego, to może go wysłać bezpośrednio do docelowych stacji. Jeśli nie, to może go wysłać bądź na adres serwer BUS, bądź na adres serwera SMS. Specyfikacja LANE 2.0 dopuszcza obie te możliwości. Wynika to z konieczności zachowania zgodności ze specyfikacją LANE 1.0, w której pakiety multicastowe mogły być wysyłane wyłącznie na adres serwera BUS. W przypadku pakietów z nieznanymi adresami docelowymi BUS rozsyła je do wszystkich klientów LEC. Jeśli któryś z klientów LEC zna adres, jego odpowiedź zostanie dodana do bazy adresowej serwera LES.
+|valign="top"|Serwer BUS jest komponentem odpowiedzialnym za obsługę pakietów broadcastowych (jeden do wszystkich) i pakietów, dla których nie udało się znaleźć ATM-owego adresu przeznaczenia. Serwer BUS bierze także udział w transmisji pakietów multicastowych (jeden do wielu) jeśli klientem LEC jest klient działający zgodnie ze specyfikacją LANE 1.0. Istnieją dwa sposoby realizacji serwera BUS. Pierwsza oparta jest na technologii VCC-Mapped. W takim wykonaniu serwer BUS przesyła pakiety broadcastowe do wszystkich klientów LEC niezależnie od tego, czy dany LEC zarejestrował jakiś MAC adres czy nie. Druga technologia jest nieco bardziej inteligentna. Pakiety broadcastowe są wysłane tylko tym klientom, którzy zarejestrowali jakieś adresy MAC. Pozwala to na zaoszczędzenie pasma, a także oszczędza klientowi LEC pracy związanej z usuwaniem niechcianych ramek. Każdy serwer BUS jest sparowany z serwerem LES. W specyfikacji LANE 1.0 i 2.0 nie jest wyszczególniony protokół komunikacyjny pomiędzy serwerem LES i BUS. Producenci implementują go sami. Najczęściej w czasie konfigurowania urządzenia wystarczy skonfigurować serwer LES, a serwer BUS będzie uruchomiony automatycznie z takim samym adresem ATM jak LES. W czasie inicjalizacji LEC, po wysłaniu zapytania o adres broadcastowy, otrzymuje też za pośrednictwem serwera LES adres skojarzonego serwera BUS. Klient ustanawia do serwera BUS połączenie Default Multicast Send VCC, a w odpowiedzi serwer BUS ustanawia Multicast Forwarding VVC do klienta. Klient LEC po zestawieniu takich połączeń staje się lokalnym klientem serwera BUS. Wszystkie pakiety broadcastowe, wysłane przez klienta LEC, są rozsyłane przez serwer BUS do jego lokalnych klientów LEC oraz do innych serwerów BUS obsługujących ten sam ELAN. Aby było to możliwe, wszystkie serwery BUS pracujące we wspólnym ELAN-ie muszą ustanowić pomiędzy sobą połączenie Multicast Forward VCC. Każdy klient LEC może także wysyłać do serwera BUS pakiety z nieznanymi adresami docelowymi oraz pakiety multicast. Jeśli klient LEC znajdzie adres docelowy dla danego pakietu multicastowego, to może go wysłać bezpośrednio do docelowych stacji. Jeśli nie, to może go wysłać bądź na adres serwer BUS, bądź na adres serwera SMS. Specyfikacja LANE 2.0 dopuszcza obie te możliwości. Wynika to z konieczności zachowania zgodności ze specyfikacją LANE 1.0, w której pakiety multicastowe mogły być wysyłane wyłącznie na adres serwera BUS. W przypadku pakietów z nieznanymi adresami docelowymi BUS rozsyła je do wszystkich klientów LEC. Jeśli któryś z klientów LEC zna adres, jego odpowiedź zostanie dodana do bazy adresowej serwera LES.
 |}
@@ Linia 560: / Linia 560: @@
 {| border="0" cellpadding="4" width="100%"
 |valign="top" width="500px"|[[Grafika:SK_M4_Slajd52.png|thumb|500px]]
-|valign="top"|Serwer BUS nie dostarczał efektywnego mechanizmu transmisji pakietów multicastowych. W specyfikacji LANE 2.0 dodano wiec nowy obiekt, którego zadaniem jest przejęcie od serwera BUS obsługi ruchu multicastowego. Serwer SMS nie przejmuje jednak całości tego ruchu. Nie było to możliwe, ze względu na konieczność zachowania zgodności z poprzednią specyfikacją LANE 1.0. SMS w czasie inicjalizacji ustanawia połączenie z serwerem LES, którego adres otrzymał od serwera LECS. Do synchronizacji bazy z serwerem LES, SMS używa protokołu SCSP. Klienci LEC działający w oparciu o specyfikację LANE 1.0 nie zauważają istnienia serwera SMS i wysyłają wszystkie dane multicastowe do serwera BUS. Klient LEC napisany w oparciu o specyfikacje LANE 2.0 może ustanowić połączenie z serwerem SMS i do niego wysyłać dane multicastowe. Klient LEC v.2.0 może stać się członkiem grupy multicastowej. Grupę multicastową tworzy lokalny serwer LES poprzez rejestrację w swojej bazie następujących informacji: adres multicastowy, adres serwera SMS, adres klienta LEC. Serwer LES po zarejestrowaniu grupy rozsyła tę informację za pomocą protokołu SCSP do pozostałych serwerów LES oraz do serwera SMS. Kiedy serwer SMS otrzyma informację o grupie, tworzy drzewo Multicast Forward VCC, do którego jako liść dodaje klienta LEC. Odtąd LEC v.2.0 będzie otrzymywał dane multicastowe. Należy jednak pamiętać, że oprócz nowych klientów w sieci mogą znajdować się także klienci LEC v.1.0. Aby zapewnić poprawną współpracę obu typów klientów, serwer SMS pracuje przy transmisji multicastów prawie tak samo jak inteligentny serwer BUS. Nie może jednak przejąć pełnej funkcjonalności serwera BUS, gdyż nie ma możliwości obsługiwania zapytań o adres przy przesyłaniu strumieni danych jakie są generowanie w normalnym ruchu sieciwym (ang. unicast). Ponadto serwer BUS jest zawsze parą dla konkretnego serwera LES. Natomiast serwer SMS, posiadając pełną bazę klientów serwera LES, jest w swej funkcjonalności zbliżony do serwera LES, nie ma jednak możliwości bezpośredniej rejestracji LEC w swojej bazie.
+|valign="top"|Serwer BUS nie dostarczał efektywnego mechanizmu transmisji pakietów multicastowych. W specyfikacji LANE 2.0 dodano wiec nowy obiekt, którego zadaniem jest przejęcie od serwera BUS obsługi ruchu multicastowego. Serwer SMS nie przejmuje jednak całości tego ruchu. Nie było to możliwe, ze względu na konieczność zachowania zgodności z poprzednią specyfikacją LANE 1.0. SMS w czasie inicjalizacji ustanawia połączenie z serwerem LES, którego adres otrzymał od serwera LECS. Do synchronizacji bazy z serwerem LES, SMS używa protokołu SCSP. Klienci LEC działający w oparciu o specyfikację LANE 1.0 nie zauważają istnienia serwera SMS i wysyłają wszystkie dane multicastowe do serwera BUS. Klient LEC napisany w oparciu o specyfikacje LANE 2.0 może ustanowić połączenie z serwerem SMS i do niego wysyłać dane multicastowe. Klient LEC v.2.0 może stać się członkiem grupy multicastowej. Grupę multicastową tworzy lokalny serwer LES poprzez rejestrację w swojej bazie następujących informacji: adres multicastowy, adres serwera SMS, adres klienta LEC. Serwer LES po zarejestrowaniu grupy rozsyła tę informację za pomocą protokołu SCSP do pozostałych serwerów LES oraz do serwera SMS. Kiedy serwer SMS otrzyma informację o grupie, tworzy drzewo Multicast Forward VCC, do którego jako liść dodaje klienta LEC. Odtąd LEC v.2.0 będzie otrzymywał dane multicastowe. Należy jednak pamiętać, że oprócz nowych klientów w sieci mogą znajdować się także klienci LEC v.1.0. Aby zapewnić poprawną współpracę obu typów klientów, serwer SMS pracuje przy transmisji multicastów prawie tak samo jak inteligentny serwer BUS. Nie może jednak przejąć pełnej funkcjonalności serwera BUS, gdyż nie ma możliwości obsługiwania zapytań o adres przy przesyłaniu strumieni danych jakie są generowanie w normalnym ruchu sieciowym (ang. unicast). Ponadto serwer BUS jest zawsze parą dla konkretnego serwera LES. Natomiast serwer SMS, posiadając pełną bazę klientów serwera LES, jest w swej funkcjonalności zbliżony do serwera LES, nie ma jednak możliwości bezpośredniej rejestracji LEC w swojej bazie.
 |}
@@ Linia 606: / Linia 606: @@
 |valign="top" width="500px"|[[Grafika:SK_M4_Slajd55.png|thumb|500px]]
 |valign="top"|Jak widać z powyższych specyfikacji, sieć kanałów VCC protokołu LNNI realizuje trzy podstawowe zadania:
-kontrolne;
+kontrolne,
-synchronizacyjne;
+synchronizacyjne,
 transmisji danych.
-Prawidłowa realizacja powyższych zadań pozwala różnym serwerom serwisu LANE pracować z punktu widzenia klienta LEC tak jak jeden wspólny serwer. Aby ułatwić zarządzanie kanałami w sieci LANE przyjmuje się, że podstawową jednostką sieci jest zbiór sąsiednich serwerów. Tworzą one tzw. oko sieci (ang. mesh). Podstawowym zadaniem protokołu LNNI jest takie zestawienie kombinacji połączeń wewnątrz oka sieci, aby każdy serwer będący składnikiem takiej grupy otrzymywał komunikaty bez pośrednictwa innego serwera. Ponieważ możliwe są dwa typy połączeń VCC ("point to point" i "point to multipoint") oraz połączenia mogą inicjować różne serwery wchodzące w skład grupy, to możliwe jest powstawanie pętli połączeń. Aby zapobiec pętlom a także brakowi połączeń, w protokole LNNI przyjęto szereg założeń, które muszą spełnić połączenia, aby sieć działała prawidłowo. Dwa pierwsze założenia to:
+Prawidłowa realizacja powyższych zadań pozwala różnym serwerom serwisu LANE pracować z punktu widzenia klienta LEC tak jak jeden wspólny serwer. Aby ułatwić zarządzanie kanałami w sieci LANE przyjmuje się, że podstawową jednostką sieci jest zbiór sąsiednich serwerów. Tworzą one tzw. oko sieci (ang. mesh). Podstawowym zadaniem protokołu LNNI jest takie zestawienie kombinacji połączeń wewnątrz oka sieci, aby każdy serwer będący składnikiem takiej grupy otrzymywał komunikaty bez pośrednictwa innego serwera. Ponieważ możliwe są dwa typy połączeń VCC ("point to point" i "point to multipoint") oraz połączenia mogą inicjować różne serwery wchodzące w skład grupy, to możliwe jest powstawanie pętli połączeń. Aby zapobiec pętlom, a także brakowi połączeń, w protokole LNNI przyjęto szereg założeń, które muszą spełnić połączenia, aby sieć działała prawidłowo. Dwa pierwsze założenia to:
 każda wiadomość wysłana od dowolnego serwera w grupie musi trafić do wszystkich adresatów, do których jest adresowana;
 każda wiadomość nie może być wysłana więcej niż jeden raz do pozostałych węzłów sieci.
-Pozostałe założenia definiują zasady wyboru połączeń w wypadku, gdy połączenia się dublują. Kanały, które zostały uznane za niepotrzebne nie są o razu likwidowane. Usuwane są one dopiero po czasie przeterminowania. Przed upływem tego czasu mogą być w każdej chwili wykorzystane do celów transmisji. Zasady tworzenia i likwidowania kanałów ilustrują kolejne slajdy.
+Pozostałe założenia definiują zasady wyboru połączeń w wypadku, gdy połączenia się dublują. Kanały, które zostały uznane za niepotrzebne nie są od razu likwidowane. Usuwane są one dopiero po czasie przeterminowania. Przed upływem tego czasu mogą być w każdej chwili wykorzystane do celów transmisji. Zasady tworzenia i likwidowania kanałów ilustrują kolejne slajdy.
 |}
@@ Linia 642: / Linia 642: @@
 zadania sygnalizacyjne,
 zadania synchronizacyjne.
-Do zadań sygnalizacyjnych należy informowanie poszczególnych serwerów sieci LANE o tym, że zaszły zmiany w bazach danych. Zmiany te zachodzą na skutek włączania się nowych serwerów serwisu LANE do sieci, odłączania tychże serwerów, a także na skutek rejestracji nowych klientów LEC w różnych miejscach sieci ATM. Klienci LEC korzystający z usług sieci ATM nie powinni zauważać, gdzie są podłączeni oraz ile serwerów serwisu LANE świadczy im usługi. Rozważając sposób budowy protokołu SCSP można wyróżnić w nim dwie podwarstwy. W pierwszej warstwie określanej jako protocol independent sublayer zestawiane są połączenia pomiędzy sąsiednimi serwerami serwisu LANE. Dowolny serwer, który używa zestawu procedur składających się na tę podwarstwę, może zsynchronizować swoją bazę ze wszystkimi pozostałymi serwerami. Natomiast przy użyciu procedur składających się na podwarstwę określaną jako protokol dependent sublayer, dwa serwery korzystające z procedur składających się na tę podwarstwę mogą zsynchronizować tylko swoje bazy.
+Do zadań sygnalizacyjnych należy informowanie poszczególnych serwerów sieci LANE o tym, że zaszły zmiany w bazach danych. Zmiany te zachodzą na skutek włączania się nowych serwerów serwisu LANE do sieci, odłączania tychże serwerów, a także na skutek rejestracji nowych klientów LEC w różnych miejscach sieci ATM. Klienci LEC korzystający z usług sieci ATM nie powinni zauważać, gdzie są podłączeni oraz ile serwerów serwisu LANE świadczy im usługi. Rozważając sposób budowy protokołu SCSP można wyróżnić w nim dwie podwarstwy. W pierwszej warstwie określanej jako protocol independent sublayer zestawiane są połączenia pomiędzy sąsiednimi serwerami serwisu LANE. Dowolny serwer, który używa zestawu procedur składających się na tę podwarstwę, może zsynchronizować swoją bazę ze wszystkimi pozostałymi serwerami. Natomiast przy użyciu procedur składających się na podwarstwę określaną jako protocol dependent sublayer, dwa serwery korzystające z procedur składających się na tę podwarstwę mogą zsynchronizować tylko swoje bazy.
 |}
@@ Linia 660: / Linia 660: @@
 |valign="top"|Protokół LUNI definiuje zadania, które muszą być realizowane przez klienta LEC. W większości zostały one opisane podczas omawiania zadań klienta LEC. W protokole LUNI zdefiniowane są także procedury tworzenia i usuwania kanałów VCC do realizacji poszczególnych zadań. Są to kanały inicjowane zarówno przez serwery serwisu LANE jak i klienta LEC. Kanały można podzielić na dwie zasadnicze grupy:
 kanały kontrolne VCC
-dwukierunkowy point to point Configuration Direct VCC pomiędzy klientem LEC a serwerem LECS (inicjowany przez klienta LEC);
+dwukierunkowy point to point Configuration Direct VCC pomiędzy klientem LEC, a serwerem LECS (inicjowany przez klienta LEC);
-dwukierunkowy point to point Control Direct VCC pomiędzy klientem LEC a serwerem LES (inicjowany przez klienta LEC);
+dwukierunkowy point to point Control Direct VCC pomiędzy klientem LEC, a serwerem LES (inicjowany przez klienta LEC);
-jednokierunkowy point to multipoint Control Distribute pomiędzy serwerem LES a klientami LEC (inicjowany przez serwer LES).
+jednokierunkowy point to multipoint Control Distribute pomiędzy serwerem LES, a klientami LEC (inicjowany przez serwer LES).
 kanały transmisji danych:
 dwukierunkowy point to point Data Direct VCC pomiędzy klientami LEC (inicjowany przez klienta LEC);
-dwukierunkowy point to point Multicast Send VCC pomiędzy klientem LEC a serwerem BUS (inicjowany przez klienta LEC);
+dwukierunkowy point to point Multicast Send VCC pomiędzy klientem LEC, a serwerem BUS (inicjowany przez klienta LEC);
-jednokierunkowy point to multipoint Multicast Forward VCC pomiędzy serwerem BUS a klientami LEC (inicjowany przez serwer BUS).
+jednokierunkowy point to multipoint Multicast Forward VCC pomiędzy serwerem BUS, a klientami LEC (inicjowany przez serwer BUS).
 |}
@@ Linia 678: / Linia 678: @@
 wsparcie dla Multicastów;
 multipleksacji ruchu w jednym kanale VCC.
-Wsparcie dla wymagań QoS obejmuje możliwość zestawiania kanałów VCC dla transmisji danych w standardzie ABRi (ang. Availble Bit Rate). W LANE 1.0 możliwe jest zestawianie wyłącznie kanałów w standardzie UBR (ang. Unspecified Bit Rate). Pozwala to na transmisję danych, które wymagają większej gwarancji jakości pasma. LANE v.2 pozwala definiować parametry QoS lokalnie dla każdego klienta LEC. Najniższe parametry jakości transmisji QoS odpowiadają transmisji w standardzie UBR. Dane wysyłane przez klienta LEC z ustawionymi parametrami QoS są otrzymywane przez odbierającego klienta LEC z zachowaniem jakości nadawania. Wsparcie dla multicastów obejmuje możliwość tworzenia takich grup multicastowych, w których odbierającymi będą tylko członkowie danej grupy. Możliwe się to stało po utworzeniu nowego obiektu w serwisach LANE serwera SMS. Pełne wykorzystanie jego właściwości jest możliwe dopiero wtedy, gdy klient LEC jest oparty o specyfikację LUNI 2.0. W LANE 1.0 multicasty były rozsyłane za pomocą serwera BUS, który rozsyłał je tak jak zwykłe pakiety broadcastowe. W LANE 2.0 klient LEC śle adresy multicastowe do serwera SMS. Następnie klient LEC rejestruje się w bazie serwera SMS jako klient, który chce odbierać pakiety multicastowe adresowane na konkretny adres multicastowy. W przypadku, gdy pakiety nie są adresowane do niego, to do niego w ogóle nie docierają. W przypadku sieci LANE 1.0 klient LEC musi odbierać i ignorować pakiety multicastowe, które nie są adresowane do niego. Pozwala to na oszczędność pasma i na lepsze wykorzystanie sieci. W LANE 1.0 w jednym kanale VCC przy transmisji danych nie jest możliwa multiplekasacja ruchu do wielu różnych źródeł danych i typu danych. W takim kanale mogą być transmitowane zarówno dane kontrolne jak dane zawierające enkapsulowane pakiety sieci LAN.
+Wsparcie dla wymagań QoS obejmuje możliwość zestawiania kanałów VCC dla transmisji danych w standardzie ABRi (ang. Availble Bit Rate). W LANE 1.0 możliwe jest zestawianie wyłącznie kanałów w standardzie UBR (ang. Unspecified Bit Rate). Pozwala to na transmisję danych, które wymagają większej gwarancji jakości pasma. LANE v.2 pozwala definiować parametry QoS lokalnie dla każdego klienta LEC. Najniższe parametry jakości transmisji QoS odpowiadają transmisji w standardzie UBR. Dane wysyłane przez klienta LEC z ustawionymi parametrami QoS są otrzymywane przez odbierającego klienta LEC z zachowaniem jakości nadawania. Wsparcie dla multicastów obejmuje możliwość tworzenia takich grup multicastowych, w których odbierającymi będą tylko członkowie danej grupy. Możliwe się to stało po utworzeniu nowego obiektu w serwisach LANE serwera SMS. Pełne wykorzystanie jego właściwości jest możliwe dopiero wtedy, gdy klient LEC jest oparty o specyfikację LUNI 2.0. W LANE 1.0 multicasty były rozsyłane za pomocą serwera BUS, który rozsyłał je tak jak zwykłe pakiety broadcastowe. W LANE 2.0 klient LEC śle adresy multicastowe do serwera SMS. Następnie klient LEC rejestruje się w bazie serwera SMS jako klient, który chce odbierać pakiety multicastowe adresowane na konkretny adres multicastowy. W przypadku, gdy pakiety nie są adresowane do niego, to do niego w ogóle nie docierają. W przypadku sieci LANE 1.0 klient LEC musi odbierać i ignorować pakiety multicastowe, które nie są adresowane do niego. Pozwala to na oszczędność pasma i na lepsze wykorzystanie sieci. W LANE 1.0 w jednym kanale VCC przy transmisji danych nie jest możliwa multipleksacja ruchu do wielu różnych źródeł danych i typu danych. W takim kanale mogą być transmitowane zarówno dane kontrolne jak dane zawierające enkapsulowane pakiety sieci LAN.
 |}
@@ Linia 694: / Linia 694: @@
 {| border="0" cellpadding="4" width="100%"
 |valign="top" width="500px"|[[Grafika:SK_M4_Slajd63.png|thumb|500px]]
-|valign="top"|Standard MPOA v.1.1 ukazał się w maju 1999 roku. Jest on rozszerzeniem standardu MPOA 1.0, który ukazał się w lipcu 1997 roku. Standard MPOA określa sposób zastosowania protokołu NHRP (ang. Next Hop Resolution Protokol) w sieciach zbudowanych w oparciu o specyfikacje LANE 2.0. MPOA jest nadbudową nad siecią LANE (patrz rysunek 4.12 MPOA a sieć LANE). MPOA pozwala różnym sieciom ELAN na przesyłanie pakietów z pominięciem routera. Pozwala to sieci ATM na:
+|valign="top"|Standard MPOA v.1.1 ukazał się w maju 1999 roku. Jest on rozszerzeniem standardu MPOA 1.0, który ukazał się w lipcu 1997 roku. Standard MPOA określa sposób zastosowania protokołu NHRP (ang. Next Hop Resolution Protokol) w sieciach zbudowanych w oparciu o specyfikacje LANE 2.0. MPOA jest nadbudową nad siecią LANE (patrz rysunek 4.12 MPOA, a sieć LANE). MPOA pozwala różnym sieciom ELAN na przesyłanie pakietów z pominięciem routera. Pozwala to sieci ATM na:
 znacznie bardziej efektywną komunikacje pomiędzy ELAN-ami;
 zmniejszenie liczby urządzeń potrzebnych do przesłania pakietów pomiędzy ELAN-ami;
@@ Linia 730: / Linia 730: @@
 {| border="0" cellpadding="4" width="100%"
 |valign="top" width="500px"|[[Grafika:SK_M4_Slajd66.png|thumb|500px]]
-|valign="top"|Standard LANE służy do transmisji danych przez sieci ATM w sieciach LAN. Dla sieci typu WAN nie za bardzo się nadaje. Do tego typu rozwiązań przeznaczonych jest szereg innych standardów. Jednym z szerzej stosowanych jest standard IP over ATM. W standardzie określony jest sposób odwzorowania pakietów IP na komórki ATM (RFC 1483) oraz sposób odwzorowania adresów ATM na adresy IP (RFC 2225). Standard Ip over ATM pozwala na podział fizycznej sieci ATM na segmenty IP określane mianem LIS (ang. Logical IP Subnetwork). W ramach tej podsieci przyłączane do niej urządzenia mogą się komunikować korzystając bezpośrednio z protokołu IP. Komputery, które znajdują się w różnych podsieciach LIS, do komunikacji potrzebują routera.
+|valign="top"|Standard LANE służy do transmisji danych przez sieci ATM w sieciach LAN. Dla sieci typu WAN nie za bardzo się nadaje. Do tego typu rozwiązań przeznaczonych jest szereg innych standardów. Jednym z szerzej stosowanych jest standard IP over ATM. W standardzie określony jest sposób odwzorowania pakietów IP na komórki ATM (RFC 1483) oraz sposób odwzorowania adresów ATM na adresy IP (RFC 2225). Standard IP over ATM pozwala na podział fizycznej sieci ATM na segmenty IP określane mianem LIS (ang. Logical IP Subnetwork). W ramach tej podsieci przyłączane do niej urządzenia mogą się komunikować korzystając bezpośrednio z protokołu IP. Komputery, które znajdują się w różnych podsieciach LIS, do komunikacji potrzebują routera.
 |}
@@ Linia 741: / Linia 741: @@
 Dla pakietów IP zalecane wartości pól są następujące:
 xAAAA03 dla pola LLC, co odpowiada ramce Ethernet;
-x000000 dla pola OUI, co oznacza organizacje odpowiedzialną za standaryzacje Ethernetu;
+x000000 dla pola OUI, co oznacza organizację odpowiedzialną za standaryzację Ethernetu;
 x0800 dla pola EtherType, co odpowiada pakietowi IP w ramce Ethernet.
 Właściwy pakiet IP zawarty jest w polu IP PDU. Dodatkowo warstwa ALL 5 dodaje do pakietu własne, specyficzne dla niej dane, takie jak sumy kontrolne (CRC) czy też pola wypełnienia (PAD).
@@ Linia 767: / Linia 767: @@
 {| border="0" cellpadding="4" width="100%"
 |valign="top" width="500px"|[[Grafika:SK_M4_Slajd70.png|thumb|500px]]
-|valign="top"|W przypadku korzystania z kanałów SVC, urządzenia w sieci ATM muszą zestawić połączenie. Zestawienie połączenia wymaga znajomości adresu ATM urządzenia, do którego połączenie ma być zestawione. Adres ten może być otrzymany z pliku konfiguracyjnego w urządzeniu bądź otrzymany od serwera ATMARP. Aby było możliwe przesłanie zapytania do serwera ATMARP, w pliku konfiguracyjnym urządzenia należy podać adres serwera, który będzie daną podsieć obsługiwał. Serwer, na podstawie żądań od klientów, buduje własną tablice odwzorowań, której używa następnie do udzielania odpowiedzi na zapytania ARMARP. Dane w serwerze są trzymane przez określony czas np. 20 minut po czym usuwane. Po otrzymaniu odpowiedzi od serwera ARP,klient zestawia kanał SVC do docelowego urządzenia za pomocą procedur ATM. Połączenia te są likwidowane po jakimś czasie nieużywania.
+|valign="top"|W przypadku korzystania z kanałów SVC, urządzenia w sieci ATM muszą zestawić połączenie. Zestawienie połączenia wymaga znajomości adresu ATM urządzenia, do którego połączenie ma być zestawione. Adres ten może być otrzymany z pliku konfiguracyjnego w urządzeniu bądź otrzymany od serwera ATMARP. Aby było możliwe przesłanie zapytania do serwera ATMARP, w pliku konfiguracyjnym urządzenia należy podać adres serwera, który będzie daną podsieć obsługiwał. Serwer, na podstawie żądań od klientów, buduje własną tablicę odwzorowań, której używa następnie do udzielania odpowiedzi na zapytania ARMARP. Dane w serwerze są trzymane przez określony czas np. 20 minut po czym usuwane. Po otrzymaniu odpowiedzi od serwera ARP, klient zestawia kanał SVC do docelowego urządzenia za pomocą procedur ATM. Połączenia te są likwidowane po jakimś czasie nieużywania.
 |}

SK Moduł 4: Różnice pomiędzy wersjami

Aktualna wersja na dzień 18:15, 22 gru 2006

Menu nawigacyjne

Działania na stronie

Opcje strony

Narzędzia osobiste

Nawigacja

Szukaj

Narzędzia