Protokoły routingu

zajawka

Protokoły routingu OSI

Dla zestawu protokołów OSI (Open Systems Interconnection) opracowano w ramach organizacji ISO (International Standard Organization) kompletny zbiór protokołów routingu. Są to: ES-IS (End System-to-Intermediate System), IS-IS (Intermediate System-to-Intermediate System) i IDRP (Interdomain Routing Protocol).

Wymienione protokoły zostały opisane w następujących dokumentach wydanych przez ISO:

• ISO 9542 – definiujący protokół ES-IS,
• ISO 10589 – definiujący protokół IS-IS,
• ISO 10747 – definiujący protokół IDRP.

Protokół ES-IS

Protokół ES-IS definiuje współdziałanie systemów ES (hostów) i systemów IS (routerów) w zbieraniu informacji o sobie, czyli proces nazwany konfigurowaniem. Konfigurowanie musi nastąpić przed pojawieniem się routingu. W trakcie tego procesu zostają ustalone adresy sieciowe innych węzłów.

Protokół ES-IS jest raczej protokołem poszukiwawczym (discovery) niż protokołem routingującym. Rozróżnia się trzy typy podsieci:

• podsieć punkt–punkt (point-to-point), taka jak sieć WAN z szeregowymi łączami dostarczającymi połączeń punkt-punkt pomiędzy dwoma systemami,
• podsieć rozgłoszeniowa (broadcast), kierująca komunikaty do wszystkich węzłów w podsieci,
• podsieć o uniwersalnej topologii (general-topology), taka jak sieć X.25, łącząca dowolną liczbę systemów.

Konfigurowanie ES-IS

Konfigurowanie ES-IS jest procesem, podczas którego oba systemy wzajemnie się rozpoznają w celu umożliwienia routingu pomiędzy nimi. W tym procesie są wymieniane w regularnych odstępach czasu dwa rodzaje komunikatów typu hello: ESH (ES hello message) i ISH (IS hello message). Komunikaty ESH są generowane przez systemy ES i wysyłane do wszystkich systemów IS w podsieci, podobnie komunikaty ISH są generowane przez systemy IS i wysyłane do wszystkich systemów ES w podsieci. Dzięki tym komunikatom systemy mogą rozpowszechniać generowane przez siebie adresy podsieci i warstwy sieciowej. Jeśli tylko jest to możliwe, komunikaty te są rozsyłane jednocześnie do wszystkich systemów.

Protokół IS-IS

IS-IS jest protokołem typu "link-state", który rozpowszechnia informacje o stanie łącz w celu utworzenia kompletnego obrazu topologii sieci (porównaj protokół OSPF). Aby umożliwić uproszczenie budowy routerów, protokół IS-IS wyróżnia systemy IS poziomu 1 i poziomu 2 (Level 1 router i Level 2 router). Routery poziomu 1 łączą ze sobą systemy w jednym obszarze, routery poziomu 2 łączą obszary między sobą, tworząc szkielet wewnątrzdomenowy.

Miary protokołu IS-IS

Protokół IS-IS używa jednej domyślnej miary, której wartość nie przekracza 1024. Miarę przydziela administrator sieci. Pojedyncze łącze może przyjąć wartość nie większą niż 64, wartość ścieżki uzyskuje się sumując wartości łączy.

Protokół IS-IS definiuje również trzy miary opcjonalne: opóźnienie (delay), wydatek (expense) i błąd (error). Miara kosztu opóźnienia odzwierciedla wielkość opóźnienia wprowadzanego przez łącze. Miara wydatku odzwierciedla koszty ponoszone na użycie łącza. Miara błędu wskazuje stopę błędów na danym łączu. Protokół IS-IS odwzorowuje wymienione cztery miary w opcji QoS nagłówka pakietu CLNP (Connectionless Network Protocol), używając tego odwzorowania do wyznaczenia tras w sieci.

Protokół IDRP

IDRP (Interdomain Routing Protocol) jest protokołem OSI, który specyfikuje komunikację pomiędzy routerami w różnych domenach. Jest to protokół kategorii "link-state", służący do routingu w trybie bezpołączeniowym, współdziała z protokołami CLNP, ES-IS i IS-IS. Projekt protokołu IDRP oparto na protokole BGP.

Routing protokołu IDRP

Trasa protokołu IDRP jest sekwencją identyfikatorów RDI, przy czym niektóre z nich mogą dotyczyć konfederacji. Każda baza danych BIS jest skonfigurowana tak, by "znać" domenę lub konfederację, do której należy. W celu zdobycia wiedzy o sąsiednich domenach wymienia z nimi informacje.

Podobnie jak w routingu "distance-vector" trasy do określonego miejsca przeznaczenia mają widok zewnętrzny z miejsca przeznaczenia. Do innych systemów BIS będą prowadziły tylko te trasy, które zostały uprzednio wybrane i które spełniają wymagania strategii lokalnych systemów BIS. Zmiana trasy może być tylko częściowa i ma miejsce, gdy zajdzie jedno z następujących zdarzeń:

• zostanie przyjęte przyrostowe uaktualnienie routingu z nowymi trasami,
• sąsiedni system BIS ulegnie uszkodzeniu,
• sąsiedni system BIS zostanie przywrócony do pracy.

Protokół RIP

Protokół RIP jest protokołem routingu, w którym zastosowano algorytm distance-vector. Jest on szeroko stosowany w sieciach jako protokół wewnętrzny IGP (Interior Gateway Protocol), co oznacza, że wykonuje routing pojedynczym autonomicznym systemem albo protokołem zewnętrznym EGP (Exterior Gateway Protocol) – wykonuje routing pomiędzy różnymi autonomicznymi systemami. Protokół RIP jest obecnie szeroko wykorzystywany w Internecie.

Protokół RIP (Routing-Information Protocol) jest używany w sieciach jako podstawowa metoda wymiany informacji o routingu pomiędzy routerami.

Specyfikacje protokołu RIP definiują dwa dokumenty RFC (Request For Comments) 1058 i 1723. RFC 1058 opisuje pierwszą implementację protokołu, natomiast jego wersję zaktualizowaną opisuje dokument RFC 1723.

Algorytm distance-vector

Distance-vector optymalizuje wybór trasy przy kryterium najmniejszej liczby skoków (hops) niezbędnych do osiągnięcia miejsca przeznaczenia (destination) lub kosztu ścieżki prowadzącej do miejsca przeznaczenia.

Uaktualnianie routingu

Protokół RIP wysyła komunikaty uaktualniające w określonych, stałych przedziałach czasu, na przykład co 30 s, lub w przypadku pojawienia się zmian w topologii sieci. Router po przyjęciu uaktualnienia routingu, które dotyczy zmian jednego z wejść, uaktualnia tablicę routingu (routing table), by odzwierciedlić nową trasę. Wartość miary przypisanej danej ścieżce wzrasta o jeden i jako następny skok jest wskazany nadawca. Routery RIP utrzymują do miejsca przeznaczenia tylko najlepszą trasę, to jest trasę z najmniejszą liczbą skoków. Router niezwłocznie po uaktualnieniu swojej tablicy routingu wysyła informacje o zmianie do pozostałych routerów w sieci. Są one wysyłane niezależnie od regularnie wysyłanych uaktualnień.

Miara routingu protokołu RIP

Jedyną miarą używaną przez protokół RIP do mierzenia odległości pomiędzy źródłem a miejscem przeznaczenia jest zliczanie skoków (hop-count). Każdemu skokowi na drodze od źródła do miejsca przeznaczenia zostaje przypisana wartość, najczęściej 1.

Gdy router przyjmie uaktualnienie tablicy routingu, które zawiera nowe lub zmienione wejście sieciowego miejsca przeznaczenia, to dodaje jedynkę do wartości miary wskazanej w uaktualnieniu i wpisuje zmianę do tablicy routingu. Adresem następnego skoku jest adres IP nadawcy .

Protokół RIP, dzięki ograniczeniu liczby skoków, które mogą pojawić się pomiędzy źródłem a miejscem przeznaczenia, zapobiega przesyłaniu strumienia danych bez końca w pętli. Maksymalna liczba skoków na ścieżce wynosi 15. Jeśli router przyjmie uaktualnienie routingu, które zawiera nowe lub zmienione wejście, i jeśli po zwiększeniu miary o jeden nastąpi przekroczenie granicy 15 skoków, to takie miejsce przeznaczenia w sieci staje się nieosiągalne.

Stabilność protokołu RIP

W celu dostosowania się do szybkich zmian topologii sieci protokół RIP wyposażono, podobnie jak i inne protokoły routingujące, w mechanizmy stabilizujące. Na przykład, by zapobiec skutkom błędnej informacji o routingu, w protokole RIP zaimplementowano mechanizmy split-horizon i hold-down. Powstaniu pętli zapobiega ograniczenie – na trasie pomiędzy źródłem a miejscem przeznaczenia – liczby skoków (do 15).

Czasomierze protokołu RIP

W celu dostosowania do potrzeb wydajności routingu, protokół RIP wyposażono w kilka czasomierzy (timers). Wśród nich są: czasomierz uaktualnienia routingu (routing-update timer), limitu czasu trasy (route timeout timer) i czyszczenia trasy (route-flush timer). Czasomierz uaktualnienia routingu wyznacza przedziały czasu pomiędzy kolejnymi okresami uaktualniania. Jest to stały przedział nie przekraczający 30 s. Do każdego wejścia do tablicy routingu jest przypisany czasomierz limitu czasu trasy; w przypadku jego wyczerpania trasa zostaje oznaczona jako nieważna. Mimo tego jest nadal utrzymywana w tablicy routingu aż do momentu, gdy zostanie wyczerpany czasomierz czyszczenia trasy.

Protokół BGP

Protokół BGP wykonuje routing międzydomenowy w sieciach pracujących z protokołem TCP/IP. Należy do klasy protokołów zewnętrznych. Wykonuje routing pomiędzy wieloma systemami autonomicznymi (domenami) i wymienia informacje o routingu i dostępności z innymi systemami posługującymi się protokołem BGP. Protokół BGP został tak zaprojektowany, aby zastąpić swego poprzednika, obecnie już zdezaktualizowany protokół EGP (Exterior Gateway Protocol). Protokół BGP efektywnie rozwiązuje problemy związane z routingiem międzydomenowym oraz skalowaniem sieci Internet.

Protokół BGP (Border Gateway Protocol) wykonuje we współczesnych sieciach zadania związane z wyborem ścieżek dla ruchu międzydomenowego, oraz rozwiązuje problemy skalowalności Internetu.

Działanie protokołu BGP

Przy wyborze optymalnej trasy protokół BGP posługuje się algorytmem distance-vector. W trakcie inicjacji połączenia równorzędne routery BGP wymieniają kompletne kopie swoich tablic routingu, które mogą być obszerne. Jednak wtedy wymieniane są tylko zmiany (delty), co sprawia, że długie sesje BGP są bardziej efektywne od krótkich.

Jedną z najważniejszych funkcji protokołu BGP jest wykrywanie pętli na poziomie systemu autonomicznego.

Protokół BGP wykonuje trzy typy routingu: 1. wewnątrz systemów autonomicznych – między dwoma lub większą liczbą routerów BGP zlokalizowanych w jednym systemie autonomicznym, na przykład w przedsiębiorstwie, uczelni lub u jednego dostawcy usług internetowych; 2. na zewnątrz systemów autonomicznych – między dwoma lub większą liczbą routerów w różnych systemach autonomicznych; 3. przez systemy autonomiczne – między dwoma lub większą liczbą routerów BGP, które wymieniają ruch przez system autonomiczny, nie obsługujący protokołu BGP.

Routing protokołu BGP

Podobnie jak każdy protokół routingu, BGP utrzymuje tablice routingu, przesyła uaktualnienia routingu i podejmuje decyzje o trasie kierowania ruchu, opierając się na miarach routingu. Główną funkcją systemu BGP jest wymiana z innymi systemami BGP informacji o dostępności sieci, w tym informacji o ścieżkach systemów autonomicznych. Informacja ta jest niezbędna do konstrukcji grafu połączeń systemów autonomicznych, z którego można eliminować pętle i wprowadzać w życie strategiczne decyzje z poziomu systemów autonomicznych. Każdy router utrzymuje tablicę routingu, zawierającą wszystkie możliwe ścieżki do poszczególnych sieci. Jednak router nie odświeża tej tablicy. Zamiast tego informacja o routingu, otrzymana od równorzędnego routera, jest przechowywana do czasu, gdy zostanie odebrane przyrostowe uaktualnienie.

Urządzenia pracujące z protokołem BGP wymieniają informacje o routingu podczas inicjacji i uaktualniania. Gdy router jest włączany do sieci po raz pierwszy, routery BGP wymieniają swoje wewnętrzne tablice routingu. Podobnie, gdy zachodzą zmiany w tych tablicach, routery wysyłają te fragmenty tablicy, które zostały zmienione. Routing BGP uaktualnia tylko zgłoszenia ścieżek optymalnych do sieci, natomiast nie wysyła regularnie harmonogramowanych uaktualnień.

Protokół BGP używa tylko jednej miary routingu do wyznaczenia optymalnej ścieżki do danej sieci. Miara ta składa się z arbitralnie przyjętej liczby jednostkowej, która określa stopień preferencji konkretnego łącza. Zazwyczaj miarę tę przypisuje do każdego z łączy administrator sieci, kierując się różnorodnymi kryteriami. Może to być liczba systemów autonomicznych przez które przechodzą ścieżka, stabilność, szybkość, opóźnienie lub koszt.

Rodzaje komunikatów protokołu BGP

Dokument RFC 1771 definiuje cztery typy komunikatów: otwierający, uaktualniający, zgłoszeniowy i podtrzymujący.

Komunikat otwierający (open message) otwiera sesję komunikacyjną protokołu BGP pomiędzy równorzędnymi routerami i jest pierwszym komunikatem, wysyłanym przez obie strony po ustaleniu połączenia na poziomie protokołu transportowego. Komunikat otwierający jest potwierdzany komunikatem podtrzymującym wysyłanym przez równorzędny router. Natychmiast po potwierdzeniu komunikatu otwierającego mogą być wymieniane komunikaty uaktualniające, zgłoszeniowe i podtrzymujące.

Komunikat uaktualniający (update message) zapewnia uaktualnianie routingu w innych systemach BGP, pozwala routerom odtworzyć u siebie obraz topologii sieci. W celu zapewnienia niezawodnego dostarczania uaktualnień do ich przesyłania używa się protokołu TCP (Transmission Control Protocol). Komunikaty otwierające mogą wycofywać z tablicy routingu jedną lub więcej niewykonalnych tras i podczas ich wycofywania zgłaszać nowe.

Komunikat zgłoszeniowy (notification message) jest wysyłany w przypadku wykrycia błędu. Zgłoszenia są używane do zamykania i otwierania sesji i informowania wszystkich przyłączonych routerów o przyczynie zamknięcia sesji.

Komunikat podtrzymujący (keep-alive message) powiadamia równorzędne routery BGP o tym, że router jest aktywny. Częstotliwość wysyłania komunikatu jest dobrana tak, aby zapobiec wygaszeniu sesji.

Protokół OSPF

Protokół OSPF opracowała grupa robocza IGP (Interior Gateway Protocol) należąca do IETF i został zdefiniowany w dokumencie RFC 1247.

OSPF jest protokołem otwartym, co oznacza, że jego specyfikacja jest ogólnie dostępna. Protokół OSPF jest protokołem routingującym klasy link-state, wykorzystującym algorytm SPF (Dijkstry).

Protokół OSPF (Open Shortest Path First) został zaprojektowany w celu zwiększenia efektywności przetwarzania w sieciach pracujących z protokołem IP. Jest udoskonaleniem protokołu RIP, ponieważ pozwala na wybór ścieżki na podstawie wieloparametrowego kryterium kosztu określanego jako routing najniższego kosztu (least-cost routing).

Routing typu link-state

Wybór trasy odbywa się na podstawie wielu czynników, na przykład takich jak szybkość i opóźnienie wprowadzane przez łącze, potrzeba ominięcia określonych obszarów lub różnorodne priorytety. Decyzję o wyborze trasy podejmuje się na podstawie algorytmu SPF, który uwzględnia:

• liczbę routerów, które musi przejść pakiet, by dotrzeć do miejsca przeznaczenia, zwaną liczbą skoków (hops),
• szybkość transmisji linii, łączących poszczególne systemy autonomiczne,
• opóźnienia spowodowane przeciążeniem sieci. Router może skierować pakiety trasą omijającą przeciążone fragmenty sieci,
• koszt trasy, którego miara jest określana przez administratora sieci, najczęściej oparta na rodzaju użytego medium transmisyjnego.

Protokół OSPF wysyła zgłoszenia LSA (Link-state advertisement) do wszystkich routerów znajdujących się w danym obszarze hierarchicznym. W zgłoszeniach LSA są zawarte między innymi informacje o przyłączonych interfejsach i użytych miarach. Po zgromadzeniu informacji o łączach (link-state) routery, stosując algorytm SPF, wyznaczają najkrótszą ścieżkę do każdego węzła.

Hierarchia routingu

W odróżnieniu od protokołu RIP protokół OSPF może działać w układzie hierarchicznym. Największą jednostką w hierarchii jest system autonomiczny AS (Autonomous System), który jest zbiorem sieci pod wspólną administracją, a które mają wspólną strategię routingu. OSPF jest protokołem routingu wewnętrznego systemów AS (wewnętrzna brama), może jednak przyjmować i wysyłać trasy do innych systemów AS.

System AS można podzielić na pewną liczbę obszarów (areas), które są grupami sąsiednich sieci i przyłączonych hostów. Poszczególne obszary sprzęgają routery graniczne obszaru (area border routers). Router graniczny utrzymuje oddzielną dla każdego obszaru bazę danych o topologii (topological database).

Baza danych o topologii jest obrazem sieci wyrażonym w powiązaniach między routerami. Zawiera zbiór zgłoszeń LSA pochodzących od wszystkich routerów w danym obszarze. Ponieważ routery w jednym obszarze otrzymują tę samą informacje, to ich bazy dot. topologii są identyczne.

Topologia obszaru jest niewidoczna dla urządzeń znajdujących się poza nim. Podział systemów AS na obszary przyczynia się do zmniejszenia ruchu związanego z routingiem.

Wydzielenie obszarów stworzyło dwa typy routingu OSPF: wewnętrzny, jeśli źródło i miejsce przeznaczenia znajdują się w tym samym obszarze, oraz zewnętrzny, jeśli znajdują się one w dwu różnych obszarach.

Za dystrybucję informacji pomiędzy obszarami jest odpowiedzialna sieć szkieletowa OSPF (OSPF backbone). Składa się ona ze wszystkich routerów granicznych, linii, które nie łączą routerów wewnątrz obszaru, oraz przyłączonych do nich routerów.

Szkielet jest również obszarem OSPF, stąd wynika, że routery szkieletu używają takich samych procedur i algorytmów do utrzymania informacji routingu w szkielecie, jak każdy inny router w obszarach sprzężonych ze szkieletem. Topologia szkieletu jest niewidoczna dla routerów wewnątrz obszarów, ponieważ nie należy do topologii obszarów.

Routery brzegowe systemów autonomicznych pracujące z protokołem OSPF dowiadują się o zewnętrznych trasach przez zewnętrzne protokoły bramowe, takie jak protokół EGP (Exterior Gateway Protocol) lub protokół BGP (Border Gateway Protocol) (zob. protokół BGP).

Dodatkowe właściwości protokołu OSPF

Wśród dodatkowych właściwości protokołu OSPF można wymienić: jednakowy koszt (equal cost), routing wielościeżkowy (multipath routing) i routing oparty na żądaniach TOS (type-of-service) wyższej warstwy. Routing oparty na żądaniach TOS wspomaga te protokoły warstwy wyższej, które mogą określić szczególne typy usług. Na przykład aplikacja może określić pewne dane jako pilne. Jeśli protokół OSPF dysponuje szybkimi łączami, to może ich użyć do przekazywania pilnych danych.

Protokół OSPF może posługiwać się jedną lub wieloma miarami. W przypadku użycia jednej miary jest ona przyjmowana arbitralnie i nie zachodzi potrzeba obsługi TOS. W przypadku użycia większej liczby miar TOS jest wspomagany oddzielnie każdą z nich i związanymi z nimi tablicami routingu. Ponieważ TOS protokołu IP zawiera trzy bity – opóźnienie (delay), przepustowość (throughput) i niezawodność (reliability) – to do dyspozycji jest osiem kombinacji. Jeśli przykładowo trzy bity TOS określają małe opóźnienie, niską przepustowość i wysoką niezawodność, to protokół OSPF wylicza trasy do wszystkich miejsc przeznaczenia opierając się na tym wyznaczniku TOS.

Do zgłoszenia każdego miejsca przeznaczenia są dołączane maski podsieci IP, dające możliwość użycia opcji zmiennej długości maski podsieci (variable-length subnet mask). Dysponując tą opcją, sieć IP można podzielić na wiele podsieci o różnych rozmiarach, dzięki czemu administrator może bardzo elastycznie konfigurować sieć.

Protokół IP

IP jest bezpołączeniowym protokołem komunikacyjnym, generującym usługi datagramowe. Datagramy są to pakiety, zawierające między innymi adres źródła i miejsca przeznaczenia oraz całość lub fragment danych przekazywanych między źródłem a miejscem przeznaczenia. Przepływ datagramów w sieci odbywa się bez kontroli kolejności dostarczania ich do miejsca przeznaczenia, kontroli błędów i bez potwierdzania odbioru. W tej sytuacji za uporządkowanie pakietów we właściwej kolejności i sprawdzenie, czy dotarły wszystkie i bez błędów, jest odpowiedzialny odbiorca. Tak znaczne uproszczenie funkcji wykonywanych w czasie transportu datagramów sprawia, że protokół IP jest szybki i efektywny.

Protokół IP (Internet Protocol) został zaprojektowany w celu umożliwienia współdziałania wielu systemów typu host. Znalazł szerokie zastosowanie w sieciach lokalnych LAN i WAN. IP łącznie z TCP (Transmission Control Protocol) są oficjalnymi protokołami sieci Internet.

W sieciach z protokołem IP przepływem pakietów sterują routery IP (IP router) łączące sieci przyłączone albo lokalnie, albo zdalnie i przesyłające datagramy pomiędzy nimi.

Adresy sieciowe protokołu IP

Adresy IP są sklasyfikowane w pięciu grupach adresów: klasach A, B, C, D i E. Każdy adres składa się z czterech liczb oddzielonych kropkami (na przykład 204.251.122.127). Każda z liczb przedstawiona w postaci binarnej jest reprezentowana przez 8 bitów, stąd nazwa – oktet. Adres w każdym oktecie ma zakres od 0 do 255. Pierwsza liczba (oktet) określa jedną z pięciu klas adresów. Pierwszy oktet adresów klasy A jest liczbą mieszczącą się w przedziale od 1 do 127. Pierwszy oktet adresów klasy B jest liczbą mieszczącą się w zakresie od 128 do 191. Pierwszy oktet adresów klasy C jest liczbą mieszczącą się w zakresie od 192 do 223. Pierwszy oktet adresów klasy D jest liczbą mieszczącą się w zakresie od 224 do 240.

W zależności od klasy adresu pozostałe oktety mają różne znaczenie. W adresach klasy A tylko pierwszy oktet jest używany do definiowania adresu sieci; pozostałe trzy oktety (24 bity) tworzą unikatowe adresy węzłów sieci lub hostów.

W adresach klasy B pierwsze dwa oktety są używane do definiowania adresów sieci, pozostałe dwa są adresami hostów.

W adresach klasy C pierwsze trzy oktety są używane do definiowania adresów sieci, czwarty oktet adresuje hosty. Jeśli dysponujemy adresem klasy C, na przykład 204.251.122.0, to w sieci o takim adresie możemy zainstalować 254 węzły (adresy 0 i 255 są zarezerwowane).

Dla abonentów zewnętrznych unikatowy adres ma postać 204.251.122.0. Urządzenia w tej sieci mogą mieć adresy 204.251.122.1, 2, 3... itd., aż do 254.

Łatwo się domyślić, że jeśli przydzielimy adresom sieci większą liczbę oktetów, to większa będzie możliwość adresowania. Na całym świecie w klasie A dysponujemy tylko 127 adresami sieci. Zostały one zagarnięte przez pierwszych użytkowników protokołu IP, takich jak MIT (Massachusetts Institute of Technology) i inne uniwersytety oraz korporacje, takie jak Xerox.

W klasie A jest używany do określenia adresu sieci tylko pierwszy oktet, pozostałe 24 bity można użyć do stworzenia prawie 17 milionów adresów hostów. Obecnie uzyskanie jednego spośród 127 adresów sieci w klasie A graniczy z cudem.

W klasie B jest przeszło 16 000 adresów sieci, z których każdy dysponuje 65 534 unikatowymi 16-bitowymi adresami hostów. Są one zarezerwowane dla przedsiębiorstw i instytucji posiadających co najmniej 4000 hostów i które mogą uzasadnić konieczność posiadania 32 podsieci. Chociaż pozostało jeszcze trochę adresów tej klasy, to jest ich coraz mniej i coraz trudniej je uzyskać. W klasie C jest nieco ponad 2 miliony adresów sieci, z których każdy może udostępnić 254 adresy węzłów. Użytkownicy klasy C łagodzą rozrost sieci przez użycie zasad adresowania klasy A lub B w obrębie sieci i zastosowanie urządzeń translacyjnych do komunikacji ze światem zewnętrznym.

Datagram protokołu IP

Datagram IP zawiera informacje niezbędne do dostarczenia pakietu danych od nadawcy do odbiorcy. W sieciach niezdolnych do przesyłania dużych datagramów, tam gdzie wymagany jest podział pakietu na co najmniej dwa datagramy, są wykorzystywane pola: identyfikacji, flag i umiejscowienia fragmentu.

Protokół IPv6

Ogromny rozwój Internetu ujawnił kilka wad protokołu IPv4. Pole adresowe o długości 32 bitów może co prawda teoretycznie zidentyfikować ponad 4 miliardy systemów, ale zdefiniowane klasy adresów znaczne ograniczają tę liczbę. Ponadto w poprzednich wersjach protokołu IP nie przewidziano odpowiedniego poziomu zabezpieczeń i wspomagania przepływu informacji w czasie rzeczywistym, wymaganego w sytuacjach, takich jak przenoszenie głosu przez Internet.

Pakiety protokołu IPv6

Najbardziej istotnymi różnicami w porównaniu do pakietów protokołu IPv4 jest udoskonalenie systemu adresowania, który używa 128 bitów w miejsce 32, oraz format pakietu, który pozwala umieszczać opcje w nagłówkach rozszerzających. Zapewnia to optymalizację przepływu pakietów przez routery, ponieważ każdy host i router, badając nagłówki, może trafnie dobrać funkcje sterujące przepływem pakietów.

Inne funkcje wspomagają koncepcję "zainstaluj i pracuj" (plug and play), dzięki której nowe węzły w sieci mogą otrzymać parametry i własne adresy bez absorbowania w każdym przypadku serwera. Przewidziano również wspomaganie dla przepływów w czasie rzeczywistym (głos i wideo). Umożliwi to w przyszłości Internetowi i sieciom intranet dostawę usług telefonicznych i telewizji kablowych.

Pole określające wersję protokołu ma 4 bity (6 na tym polu oznacza, że jest to nagłówek protokołu IPv6). Pole priorytetu również ma 4 bity, informacja tu zawarta wskazuje priorytet pakietu. Przykładowo uaktualnienia protokołów zarządzania siecią lub routingu mogą mieć przydzielony priorytet wyższy od poczty elektronicznej. W ten sposób pakiety o największym znaczeniu będą miały szansę na przejście przez zatłoczoną sieć.

24-bitowe pole etykiety przepływu (Flow Label) jest używane do identyfikowania transmisji danych, które wymagają specjalnej obsługi. Pomysł ten jest co prawda w fazie eksperymentu, lecz może już być użyty w sieci Internet do wspomagania przesyłania danych w czasie rzeczywistym.

Pole długości (Payload) jest liczbą 16-bitową, która określa długość pakietu wyrażoną w oktetach (od 576 do 65 535 oktetów). Jeśli należy przesłać więcej danych, to można użyć opcji Jumbo Payload Option. Daje ona większe możliwości w porównaniu do protokołu IPv4, który ogranicza długość pakietu do 65 535 bajtów.

Pole Next Header zajmuje 8 bitów i identyfikuje nagłówek następujący bezpośrednio po nagłówku IPv6, na przykład nagłówek TCP lub jeden z nagłówków rozszerzających protokółu IPv6.

Pole Hop Limit ma długość 8 bitów. Pola adres źródła i adres miejsca przeznaczenia zajmują pola o długości 128 bitów.

Porównując nagłówek IPv6 z istniejącym nagłówkiem IPv4, widać, że pole priorytetu IPv6 jest podobne do pola TOS, funkcje pola Next Header są podobne do funkcji pola Protocol IPv4 oraz pole Hop Limit w IPv6 działa podobnie do pola czas życia.

Nagłówki opcjonalne

Podstawowy nagłówek IPv6 jest tylko dwa razy dłuższy od nagłówka IPv4 (40 oktetów w stosunku do 20). Zwiększenie wydajności uzyskuje się przez optymalizację operacji związanych z nagłówkiem pakietu i przesuwając niektóre opcjonalne funkcje do nagłówków rozszerzenia.

Jeśli na przykład jest żądana funkcja fragmentacji, to informacja o niej jest umieszczana w specjalnym nagłówku rozszerzenia. W ten sposób ogranicza się liczbę pól tylko do niezbędnych. Host wysyłający pakiet określa wymagane opcjonalne nagłówki rozszerzenia, które z kolei są badane przez routery.

Tak więc pakiet IPv6 może mieć zero, jeden lub większą liczbę nagłówków rozszerzających. Pole Next Header identyfikuje nagłówek, który przychodzi w następnej kolejności.

Zdefiniowano sześć opcjonalnych, rozszerzających nagłówków:

• Opcja Hop-by-Hop (skok po skoku) – przenosi informację, która musi być sprawdzana i przetwarzana w każdym węźle wzdłuż drogi przesyłania pakietu, również w węźle docelowym.
• Opcja Destination (miejsca przeznaczenia) – przenosi informację, która wymaga sprawdzenia pakietu tylko w miejscu przeznaczenia. Obecnie brak jest przykładu na zastosowanie tej opcji, jednak jej zdefiniowanie wskazuje na to, jak protokół IPv6 w przyszłości będzie spełniać trudne dziś do przewidzenia wymagania.
• Routing Header (nagłówek routingu) – specyfikuje pośrednie węzły tworzące ścieżkę od źródła do miejsca przeznaczenia.
• Fragment Header (nagłówek fragmentacji) – używany przez węzeł źródłowy w celu dzielenia komunikatu na fragmenty, które mogą być przetwarzane przez znajdujące się po drodze routery.
• Authentication (uwierzytelnianie) – zapewnia integralność i uwierzytelnianie danych, używając metod, takich jak MD5 (Message Digest 5).
• Encapsulating Security Payload (ESP) – zapewnia poufność danych, na przykład używając metody DES (Data Encryption Standard).

Strukturalizacja pakietu IPv6, w podstawowym nagłówku poprzedzającym opcjonalne nagłówki rozszerzające, w przyszłości uprości dodawanie nowych własności i funkcji do tego protokołu.

Rodzaje adresów w protokole IPv6

Protokół IPv6 całkowicie rozwiązuje problem wyczerpywania się adresów: zwiększa bowiem przestrzeń adresową z 32 do 128 bitów. Dokument RFC 1884 (IPv6 Addressing Architecture) definiuje trzy rodzaje adresów protokołu IPv6:

• Unicast – zapewnia komunikację typu punkt–punkt (point-to-point).
• Anycast – pozwala komunikować się z najbliższym urządzeniem z grupy urządzeń.
• Multicast – pozwala komunikować się z wieloma urządzeniami z grupy urządzeń.

Anycast jest nowym typem adresu, który na przykład umożliwia komunikację z najbliższym routerem. Router ten będzie mógł rozpowszechnić informację w innej grupie urządzeń. W ten sposób host wysyła zaktualizowane dane do jednego routera, który z kolei będzie odpowiedzialny za retransmisję tej informacji do wszystkich zgrupowanych urządzeń.

Adres typu Multicast ogranicza zasięg pakietu, to znaczy określa, jak daleko ma dotrzeć. Przykładowo, używając adresu Multicast dla telekonferencji w pewnym przedsiębiorstwie, można zapewnić, że pakiet z sieci lokalnej nie przedostanie się przez router i nie powędruje do sieci globalnej.

Nowe funkcje wspomagające

Rozwinięto nowe operacje protokołu, które wspomagają wymagania funkcjonalne IPv6. Najbardziej przekonywającym przykładem są nagłówki Authentication i ESD, które zapewniają warstwie zabezpieczenia (secure layer) protokołu IPv6 niezbędne funkcje dla przyszłej komercjalizacji sieci Internet.

Innym przykładem są funkcje protokołu autokonfiguracji niezależnej od przynależności państwowej (Stateless Autoconfiguration Protocol), umożliwiającego włączenie komputera na zasadzie "plug-and-play".

Protokół autokonfiguracji zapewnia środki, by komputer włączony do dowolnej sieci sam sobie przydzielił adres IPv6, który w części jest oparty na jego karcie sieciowej.

Ponieważ adres karty jest unikatowy, to przydzielony sobie adres IPv6 również będzie unikatowy, co zapobiegnie dublowaniu się adresów.

Zastosowanie protokołu IPv6 wymaga szeregu zmian w dotychczas użytkowanym oprogramowaniu sieciowym, na przykład wprowadzenia zmian w protokole RIP (Routing Information Protocol) lub w protokole OSPF (Open Shortest Path First).

Aplikacje użytkowników końcowych i systemy operacyjne również mogą wymagać zmian, by miały dostęp do własności, jakimi dysponuje protokół IPv6. Przykładem niech będą rozszerzenia do systemu operacyjnego Unix (Berkley). Interfejs programów użytkowych tego systemu (powszechnie znany jako interfejs stocket) jest używany przez wiele aplikacji opierających się na protokole TCP/IP. Ten rodzaj aplikacji API koniecznie trzeba zmienić, by wykorzystać nowe możliwości przynoszone przez protokół IPv6, takie jak pola priorytetów i etykietowania przepływów zawarte w podstawowym nagłówku.

Protokół IP multicast

Protokół IP multicast, zamiast wysyłać indywidualnie pakiety do poszczególnych miejsc przeznaczenia, wysyła tylko jeden pakiet do wszystkich odbiorców w grupie multicast (multicast group), która jest identyfikowana jednym adresem IP grupy (miejsca przeznaczenia). Routing IP typu multicast (routing IP multicast) powstał, ponieważ techniki unicast i broadcast okazały się niezdolne do zapewnienia odpowiedniej wydajności nowo powstających aplikacji. Adresacja multicast ma zastosowanie, gdy zachodzi potrzeba przekazania jednego datagramu IP do wielu hostów w warunkach dużego natężenia ruchu. Ma to miejsce na przykład w sytuacji rozpowszechniania obrazów wideo z jednego źródła do wielu odbiorców (miejsc przeznaczenia).

Protokół IP multicast (Internet Protocol multicast) jest techniką routingu, która pozwala kierować ruch IP z jednego lub wielu źródeł do wielu miejsc przeznaczenia.

Protokół IGMP

Protokół IGMP (Internet Group-Membership Protocol) jest podstawowym komponentem multicastu IP. Do tworzenia grup multicast protokół IGMP wykorzystuje adresy IP klasy D. Protokół IGMP został opisany w dokumencie RFC 1112. Host identyfikuje przynależność do grupy wysyłając komunikaty IGMP. Routery pod dyktando protokołu IGMP nadsłuchują komunikatów IGMP i regularnie wysyłają zapytania w celu rozróżnienia, które grupy w poszczególnych sieciach LAN są aktywne, a które nie.

Protokoły routingu multicast

Do identyfikacji grup multicast i zestawianie tras do nich można użyć jednego z wielu protokołów routingu. Może to być PIM (Protocol-Independent Multicast), DVMRP (Distance-Vector Multicast Routing Protocol) i MOSPF (Multicast Open Shortest Path Protocol).

Protokół PIM

W zależności od rodzaju ruchu protokół PIM pracuje w dwu trybach, dense (skupionym) i sparse (rzadkim).

Tryb dense używa algorytmu RPF (Reverse Path Flooding), który jest podobny do protokołu DVMRP. Istnieją jednak różnice, na przykład protokół PIM pracujący w trybie dense, w odróżnieniu od protokołu DVMRP, nie wymaga specjalnego protokołu unicast, może pracować z dowolnym protokołem tego typu używanym w sieci. Tryb sparse jest przeznaczony dla intersieci ze stosunkowo niewielką liczbą sieci LAN, ale wieloma strumieniami danych. Definiuje punkty spotkań, które później są używane jako punkty rejestracji w celu zapewnienia właściwego routingu pakietów.

Jeśli nadawca chce przesłać dane, to pierwszy router, licząc od źródła, wysyła dane do punktu spotkania. Gdy odbiorca chce odebrać dane, ostatni router od strony odbiorcy rejestruje się w punkcie spotkania. Po wykonaniu tych czynności strumień danych może przepłynąć od nadawcy do punktu spotkania i do odbiorcy. Routery uczestniczące w połączeniu optymalizują ścieżkę i automatycznie eliminują niepotrzebne skoki, nawet w punkcie spotkania.

Protokół DVMRP

DVMRP (Distance-Vector Multicast Routing Protocol) wykorzystuje technikę RPF i jest używany jako podstawowy protokół dla internetowego szkieletu multicast MBONE (multicast backbone).

Protokół DVMRP został zdefiniowany w dokumencie RFT 1075 i ma pewne wady. Protokół DVRMP ma złą opinię zwłaszcza z powodu kiepskiej skalowalności sieci, wynikającej z refloodingu, szczególnie w wersjach, w których nie zaimplementowano oczyszczania. Taki płaski mechanizm routingu unicast protokołu DVMRP wpływa na jego zdolności skalowania.

Działanie RPF polega na tym, że router w momencie otrzymania pakietu wysyła jego kopie do wszystkich ścieżek z wyjątkiem zwrotnej do źródła. Jeśli do routera jest przyłączona sieć LAN, która nie chce przyjąć określonej grupy multicast, to router w celu zatrzymania strumienia danych wysyła do źródła komunikat czyszczący.

W operacjach RPF protokołu DVMRP są używane techniki refloodingu i adresacji unicast. Podczas refloodingu routery DVMRP okresowo zalewają przyłączoną sieć w celu osiągnięcia nowego hosta. Mechanizm floodingu używa algorytmu, który bierze pod uwagę częstotliwość floodingu i wymagany czas dla nowej grupy multicast do przyjęcia strumienia danych. Technika unicast DVMRP jest używana do określenia, który interfejs prowadzi z powrotem do źródła strumienia danych. Choć technika ta nie występuje poza protokołem DVMRP, to podobna jest do użytej w protokole RIP, opartej na zliczaniu skoków. Środowisko unicast DVMRP pozwala na użycie innych ścieżek niż używanych w ruchu multicast.

Protokół MOSPF

MOSPF (Multicast Open Shortest Path First) jest rozszerzeniem protokołu OSPF. Wykorzystuje protokół routingu unicast, który wymaga zdobycia przez każdy router w sieci informacji o wszystkich dostępnych łączach.

Router protokołu MOSPF wylicza trasy ze źródła do wszystkich możliwych członków grupy dla określonej grupy multicast. Informacja o nich jest przechowywana w tablicach stanu łącz protokołu OSPF. Tak ustalone trasy dla każdej pary źródło–grupa multicast przechowuje do czasu wystąpienia zmian w topologii sieci.

MOSPF może pracować tylko w sieciach, które używają protokołu OSPF. Na podstawie analizy jego licznych implementacji można stwierdzić, że:

• najlepiej się sprawdza w środowisku, w którym jest stosunkowo mało aktywnych par źródło–grupa,
• może obsłużyć znaczące pasmo pomiędzy routerem a hostem w środowisku, które jest niestabilne lub ma wiele aktywnych par źródło-grupa.

Protokół NLSP

Twórcom protokołu NLSP zależało w pierwszym rzędzie na zniesieniu wszelkich ograniczeń, jakie wnoszą dwa nieefektywne już dzisiaj protokoły: RIP (Routing-Information Protocol) i towarzyszący mu SAP (Service Advertisement Protocol). NLSP spełnia te założenia i wiele innych. Łączy on oryginalne koncepcje Novella z przymiotami adaptacyjnego protokołu IS-IS (Intermediate System-to-Intermediate System) OSI.

NLSP (NetWare Link-Services Protocol) jest nowoczesnym protokołem trasowania dynamicznego przede wszystkim w średnich i dużych sieciach informatycznych z łączami WAN.

Zarys koncepcji trasowania NLSP

NLSP jest protokołem trasowania adaptacyjnego, nazywanym często routingiem typu Link State. Druga z tych nazw jest nagłówkiem bardzo ważnej tabeli stanów wszystkich łączy i stanów usług – grafem całej sieci, przechowywanym przez każdy router NLSP. Tabela Link State nie jest nigdy przesyłana w całości. Jest natomiast uaktualniana albo co 2 godziny, albo po każdej zmianie konfiguracji czy usług lub po awarii. Wszystkie routery muszą dysponować tabelą o identycznej zawartości. Skompletowanie danych ułatwiają im specjalne pakiety LSP (Link State Packets).

W bazie danych routera znajduje się także relatywnie niewielka tabela jego bezpośredniego sąsiedztwa, nazywana tabelą przyległości – Adjacency Database. W myśl protokołu NLSP router A jest sąsiadem routera B, jeśli może się z nim komunikować bez pośrednictwa innego routera. Router należy do tylu przyległości, ile ma czynnych portów. Zawartości tabel przyległości – w przeciwieństwie do Link State – są różne w każdym routerze. Tabela określonego routera zawiera dane o sąsiednich routerach oraz opisy stanu połączeń z każdym z nich. Routery aktualizują swoje tabele na podstawie odpowiedzi uzyskiwanych po wyemitowaniu pakietów LAN Hello lub WAN Hello, zwykle co 20 sekund. Router w każdej przyległości reprezentuje jeden z nich, nazywany routerem desygnowanym DR (Designated Router). Będzie on pełnił kilka ważnych funkcji.

Po skompletowaniu tabeli Link State routery są gotowe do wypełniania swoich unikatowych tabel wyboru najlepszej trasy w grafie – Forwarding Database, przechowywanych w pamięci RAM. Procedurą wyboru steruje algorytm Dijkstry, a więc wyliczane trasy będą się charakteryzowały najniższym kosztem przesyłania danych. Router najpierw wyliczy koszt fragmentów tras prowadzących do węzłów, a następnie najniższy koszt całej trasy. A kiedy do tego samego celu prowadzi kilka tras o jednakowym koszcie, router zrównoważy ich obciążenia, kierując pakiety na każdą z nich. Jeśli najlepsza droga z A do E prowadzi przez B, C i D, to najlepsza droga z B do E prowadzi również przez C i D. Tak przekłada się na trasowanie spójność tabel Link State i wspólny algorytm wyboru dróg.

Tabela wyboru najlepszej drogi składa się z wierszy (rekordów) zawierających numery sieci dostępnych z określonego routera, kolejnego skoku, kosztu przejścia przez sieć (szybsza sieć, niższy koszt), numeru portu, na który zostanie skierowany pakiet, itp., podobnie jak tabela RIP. Modyfikacja tabeli następuje po każdej zmianie w tabeli Link State.

Wieloskładnikowa sieć globalna w ujęciu NLSP składa się z domen, domeny z obszarów, a obszary z sieci lokalnych lub segmentów. Obraz takiej sieci globalnej – wspomniany graf reprezentujący tabelę Link State – powstaje ze złożenia przyległości wszystkich routerów. Z tych względów protokół NLSP został wyposażony w kilka mechanizmów umożliwiających precyzyjne ustalanie i modyfikowanie sąsiedztwa przez łącza LAN i WAN oraz rozpropagowanie tych wszystkich obrazów przyległości po całej sieci. Tym najważniejszym funkcjom protokołu NLSP jego twórcy poświęcili bardzo wiele uwagi.

Węzeł umowny i router desygnowany

Sieci w NLSP reprezentują wyłącznie pseudowęzły. Dzięki tej oryginalnej koncepcji Novella router A zawęzi swoje sąsiedztwo tylko do jednego węzła umownego – pseudowęzła PN. Podobnie węzły B, C i D. Tabele przyległości tych routerów będą teraz zawierały tylko po jednym rekordzie, charakteryzującym stany ich połączeń z pseudowęzłem. Ponieważ jednak każdy węzeł musi aktywnie uczestniczyć w normalnym ruchu pakietów, jak też w ruchu wywołanym aktualizacją tabel – pseudowęzeł zostaje zastąpiony w tych wszystkich funkcjach przez router desygnowany.

Routerem desygnowanym w określonej przyległości zostaje router o najwyższym priorytecie, a przy równych priorytetach – router o najwyższym adresie MAC (Media Access Control). Router po takiej elekcji dodaje jeszcze do swojego priorytetu liczbę 20. Administrator sieci może podwyższyć priorytet do 100 lub nieco wyżej, ale nie więcej niż do 127, gdyż pole priorytetu każdego routera NLSP jest siedmiobitowe. Wszystkie routery po zainstalowaniu do sieci mają początkowo takie same priorytety – 44.

Do innych zadań routera desygnowanego należą jeszcze:

• komunikacja z węzłami korzystającymi z protokołów: trasowania RIP i ogłaszania usług – SAP;
• rozsyłanie pakietów kontrolnych CSNP (Complete Sequence Number Packets) do routerów sieci lokalnych, umożliwiających wykrycie zmian obrazu sieci przechowywanego przez te routery oraz DR;
• wysyłanie pakietów LAN Hello dwukrotnie częściej niż inne routery.

Trasowanie hierarchiczne NLSP

Silną stroną NLSP jest trasowanie hierarchiczne, trzystopniowe: w obrębie obszaru, domeny i wieloskładnikowej sieci globalnej.

• Obszar jest zbiorem połączonych ze sobą sieci, charakteryzujących się jednakowymi adresami obszaru.
• Domena stanowi zbiór obszarów, administrowanych przez tę samą organizację.
• Sieć globalną tworzą domeny, które są powiązane ze sobą łączami sieciowymi, ale zarządzają nimi różne organizacje.

Trasowanie odpowiadające tej hierarchii przeprowadza się na trzech poziomach (Level 1–3 routing): 1 – komunikacja między segmentami (sieciami) wewnątrz wspólnego obszaru; 2 – komunikacja między obszarami oraz z routerem poziomu 1 wewnątrz jego obszaru; 3 – komunikacja między domenami oraz z routerem poziomu 2 wewnątrz jego domeny.

Trasowanie hierarchiczne wydatnie upraszcza i przyspiesza dystrybucję, minimalizując ruch oraz informacje niezbędne do przesłania pakietów pod określonym adresem. Na przykład router poziomu 1 powinien znać jedynie szczegółowe dane o łączach i routerach ze swojego najbliższego sąsiedztwa. Kiedy przesyła pakiety do innego obszaru – musi tylko znaleźć najbliższy router poziomu 2. Z kolei w komunikacji między obszarami routery poziomu 2 ogłaszają swoje adresy w akceptowanych obszarach, a nie w całej sieci. Podobnie funkcjonują routery poziomu 3, odpowiadającego trasowaniu między domenami.

Tabela przyległości i pakiety Hello

Tabela przyległości routera NLSP zawiera dane o routerach z bezpośredniego sąsiedztwa oraz opisy ich połączeń (stanów). Taką tabelę kompletuje każdy router na podstawie odpowiedzi, jakie otrzymuje od swoich sąsiadów po rozesłaniu do nich specjalnych pakietów Hello. Z uwagi na duże różnice charakterystyk łączy LAN i WAN – protokół NLSP definiuje dwa rodzaje wspomnianych pakietów: LAN Hello i WAN Hello.

Kompletowanie tabel przyległości za pośrednictwem pakietów LAN Hello jest bardzo proste, gdyż sprowadza się do zidentyfikowania sąsiednich połączeń i routerów poziomu 1, funkcjonujących w tym samym obszarze trasowania.

Zalecanym trybem emisji pakietów LAN Hello jest zawsze multicasting, czyli adresowanie grupowe, obejmujące routery z przyległości. Jeśli jednak sterowniki kart sieciowych nie akceptują takiego trybu, pakiety będą rozgłaszane (broadcasting).

Pakiety WAN Hello umożliwiają routerom odnalezienie wzajemnych powiązań, rozstrzygnięcie przynależności do tego samego poziomu trasowania i sprawdzenie, czy inne routery i łącza są jeszcze aktywne. Routery generują pakiety WAN Hello w następujących sytuacjach: kiedy określają swoje bezpośrednie sąsiedztwo po raz pierwszy lub kiedy upłynął określony czas, albo też zawartość następnego Hello różni się od zawartości poprzedniego. Pakiety WAN Hello są emitowane cyklicznie tak długo, jak długo istnieje określone łącze.

Pierwsze ustalanie przyległości przez łącza WAN jest trudniejsze niż każde inne. Routery muszą najpierw poznać charakterystyki łącza zależne od medium. W tym celu muszą się posłużyć protokołem IPXWAN v.2 (Internetwork Packet eXchange Wide Area Network). Z kolei pakiety WAN Hello będą wykorzystywane podczas uaktualniania tabel przyległości. Podstawowym parametrem dialogu będzie wówczas dwubitowa zawartość pola Circuit Type. Jeśli łącze między dwoma routerami jest czynne, zapis takiego sąsiedztwa do tabeli przyległości nastąpi po czterostopniowym dialogu (jak na rysunku).

Router ustalający swoje przyległości WAN spodziewa się potwierdzania swojego pakietu Hello w precyzyjnie ustalonym czasie (Holding Time), kontrolowanym przez czasomierz (holding timer). W razie braku potwierdzenia w przewidzianym czasie router wykreśla odpowiedni rekord w swojej tabeli przyległości i rozsyła pakiety LSP, informujące środowisko o zmianie topologii.

Pakiety LSP, CSNP i PSNP

W sieci z routerami NLSP, oprócz pakietów Hello, pojawiają się jeszcze trzy inne pakiety:

• LSP (Link State Packet),
• CSNP (Complete Sequence Number Packet),
• PSNP (Partial Sequence Number Packet).

Wszystkie te pakiety służą jednemu celowi: utrzymywaniu spójnej, jednakowej tabeli Link State we wszystkich routerach NLSP. Pakiety LSP emitują wszystkie routery co 2 godziny lub router bezpośrednio po wykryciu w swoim otoczeniu zmiany topologii czy usługi. Pakiety LSP wysyłane do łącza WAN są potwierdzane, gdyż nadmierny ruch może przeciążyć węzły na krańcach takiego łącza. W sieci lokalnej obowiązują inne procedury kontroli spójności tabeli Link State, oparte na pakietach CSNP i PSNP.

Pakiety LSP przenoszą kompletne informacje (LSP information) o przyległościach routera, stanie jego połączeń i usługach. Każdy pakiet musi zawierać unikatowy identyfikator LSP ID (LSP IDentifier), złożony z numeru routera, numeru portu (circuit ID), z którego pochodzi pakiet, oraz z numeru fragmentu ID (fragment ID), kiedy cała informacja zajmuje więcej pakietów. Takie pakiety przesyła router do wszystkich innych routerów ze swoich przyległości, które uaktualniają swoje tabele Link State i przesyłają je dalej, do własnych przyległości itd. Sieć zalewają wtedy pakiety LSP (LSP flooding), gdyż każdy router musi otrzymać komplet pakietów, przenoszących w sumie pełny obraz sieci – tabelę Link State. Taki proces zostanie zainicjowany ponownie po upływie 2 godzin.

W okresach między kolejnymi zalewaniami sieci pakietami LSP może się wiele zdarzyć. Router po wykryciu zmiany w swoim otoczeniu emituje niezwłocznie pakiety LSP opatrzone identyfikatorem LSP ID i nie mniej ważnym numerem sekwencyjnym (sequence number), po którym routery rozpoznają aktualność informacji i podejmują decyzję o modyfikowaniu swoich tabel. Pakiety kierowane do łącza WAN są potwierdzane.

Synchronizacją obrazu sieci we wszystkich routerach NLSP zajmują się routery desygnowane DR. Co około 30 s wysyłają one do routerów ze wszystkich swoich przyległości pakiety CSNP, przenoszące bardzo okrojony wypis z tabeli Link State, obejmujący: identyfikator LSP ID, numer sekwencyjny oraz sumę kontrolną każdej informacji LSP. Informacje wysyłane przez DR mogą być – w odniesieniu do informacji Link State adresatów – nowsze, identyczne lub starsze. Identyczne są pomijane, pozostałe wywołują różne reakcje.

Kiedy informacje z DR są nowsze, router z sąsiedztwa tworzy wtedy pakiet PSNP, który jest żądaniem skierowanym do DR o przesłanie szczegółowych informacji LSP opatrzonych tym samym identyfikatorem LSP ID, ale nowszym numerem sekwencyjnym. W przeciwnej sytuacji, a więc kiedy informacje DR są starsze, router, do którego był skierowany pakiet routera desygnowanego, zacznie rozpowszechniać swoje nowsze informacje w trybie multicast LSP. W taki sposób wszystkie routery będą miały jednakowy obraz Link State, niezależnie od sytuacji.

Hierarchiczne adresowanie NLSP

NLSP został przystosowany do schematu adresowania hierarchicznego. Każdy obszar trasowania jest rozpoznawany po dwu 32-bitowych numerach, z których jeden stanowi adres sieci (network address), na przykład 00112200 w zapisie szesnastkowym, a drugi maskę (mask), jak FFFFFF00 w tym samym zapisie. Para takich numerów nosi wspólną nazwę adresu obszaru (area address). FFFFFF – 24 jedynki w zapisie dwójkowym – identyfikuje obszar trasowania (tu 001122), a 00 (dwójkowo 00000000) – indywidualne numery sieci w tym obszarze: A1, czyli 10100001, C2 (11000010) czy 1B (00011011) itd. Adresy kolejnych sieci w obszarze przybiorą ostatecznie formy w rodzaju: 001122A1, 001122C2 itp.

W podobny sposób dochodzi się aż do adresu sieci globalnej. Odpowiednia maska wskaże wtedy, jaka część takiego adresu przypadnie na numer domeny, numer obszaru w tej domenie i wreszcie na numer sieci w obszarze.

Trasowanie obszaru może wykorzystywać aż 3 różne adresy obszaru, każdy z inną maską. Tak pokaźny i elastyczny system adresowania umożliwia organizowanie trasowania obszaru bez przerywania innych operacji sieciowych. W określonej domenie może być wykorzystana dowolna kombinacja takiego adresu obszaru.

Struktury pakietów NLSP Hello

Pakiety WAN i LAN Hello są bardzo podobne do siebie. Pierwszy składa się z 14 pól, drugi z 16. Pakietom WAN Hello nie są potrzebne pola: No Multicast, Priority i LAN IDentifier, a pakietom LAN Hello pola: State i Local WAN Circuit ID.

Protokół RSVP

Podstawowe właściwości

Strumień danych w terminologii RSVP jest sekwencją wiadomości, które pochodzą z tego samego źródła, mają pojedynczy lub grupowy adres docelowy i charakteryzuje je QoS. Z kolei sesja jest zbiorem strumieni danych o tym samym indywidualnym lub grupowym adresie docelowym. Dla protokołu RSVP każda sesja jest niezależna i niezależnie analizowana. RSVP zajmuje się sesjami grupowymi i pojedynczymi. W sesji grupowej kilku nadawców komunikuje się z kilkoma odbiorcami, podczas gdy strumień danych pochodzi zawsze od indywidualnego nadawcy.

RSVP (Resource reSerVation Protocol) jest nowoczesnym protokołem sygnalizacji, przeznaczonym do rezerwowania zasobów sieciowych przede wszystkim aplikacjom multimedialnym.

Przyporządkowania strumieniom odpowiednich zasobów sieciowych, takich jak szerokość pasma lub kontrolowana wartość opóźnień, są inspirowane głównie aplikacjami czasu rzeczywistego, na przykład wideokonferencjami lub głosem cyfrowym. Aplikacje te wymagają takiej jakości usług, której klasyczne protokoły intrasieci albo Internetu nie były w stanie zapewnić. W Internecie dało to początek protokołowi RTP (Real Time Application), tworzonemu od samego początku z myślą o środowisku wielopunktowym. W efekcie RTP będzie się mógł obarczać równie dobrze zarządzaniem w czasie rzeczywistym, jak i administrowaniem sesji typu multipoint. Dla zapewnienia transportu w czasie rzeczywistym dodano do tego protokołu następny – RTCP (Real Time Control Protocol). Pakiety RTP w istocie przenoszą tylko dane użytkowników, a nie informacje sterujące. Na tle jeszcze nielicznych protokołów nowej generacji dedykowanych rezerwowaniu zasobów RSVP wypada najkorzystniej:

• Rezerwuje zasoby dla aplikacji zarówno w trybie unicast, jak i multicast. Jest protokołem simpleksowym, strumienie są zawsze jednokierunkowe;
• Dysponuje różnymi stylami rezerwacji i modelami, przystosowanymi do wymagań różnorodnych aplikacji multimedialnych, obwodów wirtualnych czy usług NFS (Network File System);
• Nie jest protokołem routingu, a więc nie narzuca specyficznej metodyki trasowania. Może współpracować z różnymi protokołami trasowania, łącznie z przyszłymi;
• Do uaktywniania grup objętych rezerwacją wykorzystuje znany protokół IGMP (multicast) lub IGMP + PIM (unicast);
• Dynamicznie adaptuje się do rekonfiguracji grup użytkowników i topologii routerów;
• Automatycznie przystosowuje się do zmian trasy ruchu;
• Akceptuje zarządzanie SNMP (Simple Network Management Protocol);
• Wspiera obydwie wersje IP (Internetwork Protocol): IPv4 oraz IPv6;
• Zapobiega powstawaniu pętli;
• Sprawdza upoważnienia do rezerwowania zasobów;
• Stale kontroluje stan węzłów oraz łączy i powtórne inicjuje sesję w razie awarii;
• Preferuje stację odbiorczą: inicjowaniem i utrzymaniem rezerwacji zasobów dla określonego strumienia zajmuje się odbiorca tego strumienia;
• Jest przezroczysty dla routerów nie-RSVP.

Protokół RSVP przeprowadza rezerwację począwszy od odbiorcy lub grupy odbiorców w konfiguracji wielopunktu (multipoint). To pozornie dziwne rozwiązanie okazuje się w praktyce szczególnie przydatne właśnie w konfiguracjach punkt–wielopunkt i wielopunkt–wielopunkt. Kiedy do wielopunktu dochodzi nowy punkt, może on dołączyć do rezerwacji znacznie prościej niż mógłby to wykonać za niego nadawca.

Model RSVP

Wpisywaniem QoS w odpowiednie strumienie danych zajmuje się wieloczłonowy mechanizm sterowania ruchem (traffic control), złożony w warstwie niższej z klasyfikatora pakietów (classifier) i programu porządkowania pakietów (packet scheduler). Pierwszy z nich wybiera trasę i klasy usług dla każdego pakietu, zgodnie ze statusem rezerwacji, a drugi – przechowuje tabelę przepływu i przydziela zasoby transmisji dla każdego interfejsu związanego z medium określonego łącza danych. Te ostatnie funkcje może spełniać każdy inny mechanizm zależny od warstwy łącza danych.

Funkcjonowanie wspomnianych członów zależy od dwu lokalnych modułów decyzyjnych (MD), od których w istocie rozpoczyna się cały proces rezerwacji: AC (Admission Control) i PC (Policy Control). AC sprawdza, czy zasoby sieciowe węzła są wystarczające do spełnienia życzeń QoS określonej aplikacji, a PC bada uprawnienia administracyjne do ubiegania się o rezerwację zasobów. Jeśli obydwa warunki będą spełnione równocześnie, do klasyfikatora i modułu interfejsu warstwy łącza danych (scheduler) zostaną wprowadzone parametry, jakie serwisy protokołów RSVP i trasowania otrzymały od aplikacji drogą wymiany specjalnych pakietów Path i Resv. W przeciwnym razie w stronę aplikacji ubiegającej się o rezerwację zostanie wysłane zawiadomienie o błędzie (error notification).

Rezerwowanie zasobów

Adresowanie grupowe IP (multicasting IP) jest najlepszym sposobem rozsyłania datagramów do wielu punktów przeznaczenia. Transmisje grupowe są sygnalizowane adresami klasy D. Grupy są dynamiczne: stacja może przyłączyć się do grupy lub zrezygnować z niej w dowolnej chwili, musi być tylko przystosowana programowo do wysyłania i odbierania datagramów w trybie multicast. Ta funkcja IP nie ogranicza się tylko do jednej fizycznej podsieci, interfejsy propagują także informacje o przynależności do grupy i zarządzają trasowaniem w taki sposób, że każde urządzenie odbiera kopię każdego datagramu wysyłanego do grupy.

Urządzenia przekazują interfejsom swoją przynależność do grupy za pośrednictwem protokołu IGMP (Internet Group Management Protocol). Protokół ten został stworzony dla zapewnienia skuteczności w optymalnym wykorzystywaniu pasma (zasobów sieciowych). W większości przypadków ruch IGMP polega na okresowym wysyłaniu komunikatów przez interfejs zarządzający wielopunktem i jednej odpowiedzi dla każdej grupy urządzeń w podsieci. Na tym protokole opiera się również inicjowanie sesji grupowej RSVP. W trybie unicast do protokołu IGMP dochodzi jeszcze protokół PIM (Protocol-Independent Multicast).

Po uaktywnieniu grupy z pośrednictwem IGMP potencjalny nadawca sporządza wiadomość Path RSVP i kieruje ją pod adres docelowy IP. Wśród wielu ważnych informacji zawartych w takim pakiecie znajduje się jedna szczególna, przenoszona przez obiekt o nazwie SENDER_TEMPLATE: wzorzec danych nadawcy, opisujący w taki sposób dane jego aplikacji, że odbiorca może jednoznacznie określić zasoby niezbędne do przeprowadzenia transmisji. Wszystkie inne informacje są również przenoszone przez odpowiednie obiekty.

Każdy kolejny router RSVP, do którego przybywa pakiet Path, zapamiętuje adres poprzedniego routera, a w jego miejsce wpisuje swój adres i przesyła pakiet do następnego routera na ścieżce. W końcu pakiet Path dociera do stacji odbiorczej, która na podstawie otrzymanych danych sporządza pakiet Resv RSVP, nazywany żądaniem rezerwacji. Resv, podobnie jak Path, składa się z odpowiednich obiektów.

Podstawowe żądanie rezerwacji zawiera obiekt FLOWSPEC i FILTER_SPEC. Ta para obiektów nosi nazwę deskryptora strumienia (flow descriptor). FLOWSPEC specyfikuje życzenia QoS, a FILTER_SPEC wraz ze specyfikacją sesji definiują zbiór pakietów danych – strumień – przyjmujących QoS określony przez FLOWSPEC. Tak przygotowany pakiet zostaje wysłany do routera, skąd nadeszła wiadomość Path. Router może przyjąć lub odrzucić taką wiadomość. Po przyjęciu Resv router wykorzystuje FILTER_SPEC do ustawienia parametrów klasyfikatora, a FLOWSPEC do ustawienia parametrów w module scheduler lub w innym mechanizmie warstwy łącza danych, a następnie kieruje pakiet do sąsiedniego routera, którego adres zapamiętał podczas transmisji pakietu Path.

Rezerwacja zostanie zakończona, kiedy wiadomości Resv dotrą do nadawcy wiadomości Path. Aplikacja stacji nadawczej może wtedy rozpocząć transmisję, na przykład wideokonferencji lub audiokonferencji. Ponieważ jednak transmisje różnią się właściwościami, projektodawcy wprowadzili różne style rezerwacji. Informacje o stylach rezerwacji przenosi obiekt o takiej samej nazwie – STYLE, zawsze w pakiecie Resv.

Style rezerwowania zasobów

Żądanie rezerwacji propaguje się w stronę odpowiednich nadawców. Zbiór tych nadawców – scope – jest dziedziną żądania. Explicit określa listę wybranych nadawców, a wildcard – wszystkich nadawców do określonej sesji.

RSVP określa również dwa sposoby rezerwacji dla różnych nadawców w tej samej sesji: distinct – oddzielnie dla każdego nadawcy oraz shared – rezerwacja wspólna dla wszystkich pakietów od wybranych nadawców. Dziedzina i sposoby dają w sumie cztery możliwe kombinacje, z których zdefiniowano na razie trzy. Styl FF jest preferowany dla transmisji wideo, a SE i WF dla różnych transmisji audio.

Informacje o potrzebnym stylu przenosi obiekt STYLE w 24-bitowym polu Option Vector. Dwa najmniej znaczące bity tego pola zawierają kod sposobu rezerwowania zasobów, a trzy następne – kod dziedziny. Na przykład Explicit ma kod dwójkowy 010, a shared – 10. Po złożeniu będzie to liczba 10010, odpowiadająca stylowi SE. W zapisie szesnastkowym otrzymuje się 000012 i tę wartość przenosi obiekt STYLE w Przykładzie wiadomości Resv. Styl WF ma kod dwójkowy 10001, a FF-01010. Pozostałe bity pola Option Vector – 19 najstarszych – przenoszą na razie same zera.

Charakterystyki obiektów

Specyfikacje RSVP zawierają precyzyjne opisy dróg przemierzanych przez wszystkie wiadomości. Na wiadomość składają się sekwencje różnych obiektów. Specyfikacje definiują nie tylko obiekty, ale również porządek, w jakim będą one występowały w wiadomościach.

Implementacje RSVP

RSVP jest protokołem sygnalizacji. Węzłom na ścieżce do odbiorców sygnalizuje on nadejście strumienia danych, odpowiadającego określonej jakości usług. Sam ze swojej istoty nie pozwala przeprowadzać w sposób wyraźny ani rezerwacji zasobów na żądanie aplikacji, ani – na koniec – zwalniać te zasoby. Wszystkie operacje przeprowadza się na strumieniu, kierowanym do jednego lub wielu odbiorców. Strumień jest identyfikowany przez adres IP lub port przeznaczenia albo etykietę strumienia (flow label w IPv6). Te dobrze zdefiniowane mechanizmy ułatwiają implementację algorytmów kolejkowania, podwyższających skuteczność protokołu. Jednak odpowiedzialność za spełnianie wymagań QoS spada na oprogramowanie routera.

Protokół RSVP występuje coraz częściej z protokołem WFG (Weighted Fair Queuing) koncernu Cisco. RSVP rezerwuje w czasie nawiązywania komunikacji niezbędne pasmo dla routerów przetwarzających pakiety, podczas gdy WFG zarządza kolejkami na wejściu routerów, a następnie przydziela na wyjściu niezbędną szerokość pasma. Jednak nowoczesne protokoły można zaimplementować jedynie w miarę posiadania nowoczesnych urządzeń.

RSVP w kategoriach operatora jest protokołem ściśle związanym z rezerwacją, która musi być przeprowadzona we wszystkich węzłach sieci na ścieżce do odbiorcy lub na ścieżkach określonych przez wielopunkt. Trudności spotykane przy uruchomieniu tej złożonej procedury są dwojakiego rodzaju: jak nieustannie określać wartości zasobów dla jednych aplikacji, bez ograniczania możliwości innych, i jak zarezerwować zasoby na określonej ścieżce, skoro trasowanie pakietów IP może się zmienić w dowolnej chwili. Aplikowanie algorytmów sterujących kolejkami i priorytetami staje się tu tak samo ważne, jak sam protokół. Jednak swoboda w ich implementowaniu może doprowadzić do różnych konfliktów.

Protokół EIGRP

W latach osiemdziesiątych koncern Cisco System opracował dla swoich routerów protokół trasowania IGRP (Interior-Gateway Routing Protocol), który co pewien czas wzbogacał o moduły dedykowane różnym środowiskom sieciowym. W 1986 r. dla środowiska TCP/IP został opracowany moduł IP-IGRP.

EIGRP jest protokołem trasowania wprowadzonym przez Cisco pod koniec minionej dekady po doświadczeniach z kilkuletniej eksploatacji innego firmowego protokołu tego koncernu – IGRP. EIGRP jest rozszerzonym IGRP, stąd jego nazwa Enhanced IGRP.

IGRP zapoczątkował wypieranie z routerów Cisco mało efektywny protokół RIP (Routing Information Protocol). W rzeczywistości jest jednak jego unowocześnioną, znacznie bardziej wydajną wersją. Podobnie jak RIP jest protokołem typu distance–vector, ale wykorzystuje różne kombinacje czterech miar: opóźnienia międzysieciowego, pasma (1200 b/s – 10 Gb/s), obciążenia (1-255) i niezawodności (1-255). Integruje trasowanie wielościeżkowe, niejawnie zarządza trasami pakietów, rozgłasza informacje co 90 sekund (RIP co 30 s), wykrywa zapętlenia itp.

Pod koniec lat osiem dziesiątych Cisco wprowadza do IGRP bardzo skuteczne mechanizmy zapobiegające powstawaniu pętli, oparte na algorytmie DUAL (Diffusing – Update ALgorithm). Zmieniony protokół nosi odtąd nazwę EIGRP (Extended IGRP).

autor: autor strony: 195-211