4. KONFIGUROWANIE SIECI MPLS PRZY UŻYCIU

Transkrypt

1 4. KONFIGUROWANIE SIECI MPLS PRZY UŻYCIU PROTOKOŁU SNMP 4.1. WPROWADZENIE Centralnym elementem systemu zarządzania SNMP jest stacja NMS(ang. Network Management Station), czyli stacja zarządzająca. Wykorzystując protokół zarządzania SNMP konfiguruje ona zarówno płaszczyznę sterowania, jak i płaszczyznę transportu zarządzanych urządzeń. Dzięki standardowemu modelowi informacyjnemu jedna stacja zarządzająca może konfigurować sieci składające się z urządzeń wielu producentów. O zakresie możliwych działań z obszarów funkcjonalnych FCAPS decyduje wspomniany model informacyjny, w przypadku protokołu SNMP definiowany przez moduły MIB. Jak prezentuje Rys. 22, niektóre moduły udostępniają obiekty odpowiedzialne za konfigurację warstwy sterowania, transportu lub obydwu na raz. Wykorzystanie obiektów odpowiedzialnych za konfigurację warstwy transportu pozwala na nadpisanie ustawień będących wynikiem procesu sygnalizacyjnego w sieci, na przykład wartości etykiet przychodzących i wychodzących. Oznacza to również, że w skrajnym przypadku w sieci może nie być uruchomiony proces sygnalizacyjny, a cała konfiguracja warstwy transportu będzie podawana statycznie. Takie właśnie podejście zakładane jest w przypadku systemu laboratoryjnego. W rzeczywistych zastosowaniach takie podejście jest do zaakceptowania tylko dla niewielkich sieci. Przy większych sieciach lub przy wystąpieniu awarii pojawić się mogą problemy ze skalowalnością takiego rozwiązania[gmplsarch]. Bardziej elastycznym podejściem jest wykorzystanie obiektów warstwy sterowania, ponieważ stacja zarządzająca wysyła do routera ingress tylko żądanie zestawienia tunelu i to sieć jest odpowiedzialna za resztę konfiguracji. Przy pomocy protokołu sygnalizacyjnego routery wymieniają przypisania etykiet, więc każdy router na ścieżce wie, jaką etykietę otrzyma i jaką powinien wysłać do sąsiada downstream. W tej sytuacji wystarczy, że stacja zarządzająca monitoruje stan zarządzanych obiektów tylko na routerze ingress, ponieważ ma tam dostępne wszystkie potrzebne informacje dotyczące przebiegu procesu, łącznie z rzeczywistą trasą obraną przez ścieżkę LSP. W tym rozdziale scharakteryzowane zostaną standardowe moduły MIB służące do konfigurowania urządzeń w sieci MPLS. Rozważania przeprowadzone będą na ogólnym

2 SNMP LSR sterowania RSVP, LDP, IGP LSR sterowania Agent SNMP MIB MIB NMS transportu Eth, ATM transportu MIB... NMS Rys. 22: Płaszczyzny: sterowania, transportu i zarządzania poziomie. Szczegółowy opis i znaczenie poszczególnych obiektów modelu zaimplementowanych w systemie laboratoryjnym podany jest rozdziale MODUŁY MIB I ICH INTERPRETACJA Standaryzacją modeli informacyjnych dla urządzeń MPLS zajmują się grupy robocze IETF, w szczególności grupa robocza MPLS. Do chwili pisania tej pracy(luty 2010) powstały następujące moduły wymienione w tablicy 4. Tablica 4: Standardowe moduły MIB dla MPLS Nazwa modułu Numer RFC Data wydania MPLS-LSR-STD-MIB 3813 czerwiec 2004 MPLS-LDP-STD-MIB 3815 czerwiec 2004 MPLS-LDP-GENERIC-STD-MIB 3815 czerwiec 2004 MPLS-LDP-ATM-STD-MIB 3815 czerwiec 2004 MPLS-LDP-FRAME-RELAY-STD-MIB 3815 czerwiec 2004 MPLS-TE-STD-MIB 3812 czerwiec 2004 MPLS-FTN-STD-MIB 3814 czerwiec 2004 MPLS-FRR-GENERAL-STD-MIB draft styczeń 2010? MPLS-FRR-ONE2ONE-STD-MIB draft styczeń 2010? MPLS-FRR-FACILITY-STD-MIB draft styczeń 2010? PW-MPLS-STD-MIB 5602 lipiec 2009 MPLS-L3VPN-STD-MIB 4382 luty 2006 Moduł MPLS-LSR-STD-MIB moduł zdefiniowany w RFC3813, umożliwiający 67

3 konfigurowanie i monitorowanie pracy routera LSR w płaszczyźnie transportu. Zawiera obiekty służące do statycznego konfigurowania ścieżek LSP poprzez tworzenie segmentów wejściowych, wyjściowych i powiązań między nimi(ang. cross-connect), stosów etykiet i ustawianie parametrów interfejsów MPLS-owych. Moduł MPLS-FTN-STD-MIB moduł zdefiniowany w RFC3814 umożliwiający konfigurowanie i monitorowanie przypisań klas FEC do wierszy w tablicy NHLFE(patrz rozdział 3.2). Zawiera obiekty służące do tworzenia reguł przypisania przychodzących pakietów IP do klas FEC, przypisania tych reguł do poszczególnych interfejsów i definiowania akcji, które są wykonywane po przypisaniu właściwej klasy dla pakietu. Moduł MPLS-TE-STD-MIB moduł zdefiniowany w RFC3812 umożliwiający konfigurowanie i monitorowanie tuneli MPLS-TE w płaszczyźnie sterowania. Zawiera obiekty służące do tworzenia tuneli, ich wymagań na pasmo i definiowania dla tuneli ścieżek typu explicit route. Moduły MPLS-LDP-STD-MIB, MPLS-LDP-GENERIC-STD-MIB, MPLS-LDP-ATM-STD-MIB i MPLS-FRAME-RELAY-STD-MIB moduły zdefiniowane w RFC3815, umożliwiają konfigurowanie parametrów i monitorowanie protokołu LDP. Oprócz głównego modułu, przygotowane zostały trzy moduły dla każdego z następujących protokołów warstwy 2.: Ethernet, ATM i Frame Relay. Dostępne obiekty pozwalają określić m.in. parametry sesji LDP i powiązania ścieżek LSP z sesjami, w których zostały utworzone. Moduły MPLS-FRR-GENERAL-STD-MIB, MPLS-FRR-ONE2ONE-STD-MIB, i MPLS-FRR-FACILITY-STD-MIB moduły pochodzące z dokumentu roboczego draft-ietf-mpls-fastreroute-mib-13 umożliwiające konfigurowanie funkcji ścieżek zabezpieczających FRR, opisanych w[rfc4090] oraz w rozdziale 3.5 niniejszej pracy. Moduły zawierają obiekty służące do konfigurowania powiązań między tunelami zabezpieczanymi i zabezpieczającymi, monitorowania przebiegu ścieżek oraz ich stanu. Moduł MPLS-L3VPN-STD-MIB moduł zdefiniowany w RFC4382, umożliwiający konfigurowanie i monitorowanie wirtualnych sieci prywatnych warstwy 3.(L3VPN) na routerach LSR. Moduły te definiują obiekty służące do konfigurowania instancji VRF, interfejsów biorących udział w sieciach VPN oraz identyfikatorów route target i route distinguisher. Moduł PW-MPLS-STD-MIB moduł zdefiniowany w RFC5602 umożliwiający konfigurowanie i monitorowanie usługi typu pseudowire(emulacja łącza warstwy 2.) re-

4 MPLS-TE-STD-MIB MPLS-FTN-STD- MIB MPLS-FRR- GENERAL-STD-MIB MPLS-LSR-STD-MIB IF-MIB Rys. 23: Powiązania między podstawowymi modułami alizowanej w sieci MPLS. Moduł ten jest ściśle związany z modułem PW-STD-MIB [RFC5601] zawierającym obiekty konfiguracyjne dla połączeń pseudowire niezależne od wykorzystywanej sieci pakietowej. Z punktu widzenia przygotowanego laboratorium, najważniejszą rolę pełnią moduły MPLS-LSR-STD-MIB, MPLS-FTN-STD-MIB i MPLS-TE-STD-MIB. Dodatkowo wykorzystywany jest moduł MPLS-FRR-GENERAL-STD-MIB(który, nie jest jeszcze oficjalnie zatwierdzonym dokumentem IETF). Powiązania między wymienionymi modułami przedstawione są na Rys. 23. Moduł, z którego wychodzi strzałka korzysta z obiektów zdefiniowanych w module, w stronę którego skierowany jest grot. W następnych rozdziałach opisane zostanie znaczenie poszczególnych zarządzanych obiektów w odniesieniu do funkcji inżynierii ruchu i mechanizmów zabezpieczeń zabezpieczeń przedstawionych wrozdziałach3.4i Moduł MPLS-LSR-STD-MIB Obiekty w tym module MIB reprezentują konfigurację płaszczyzny transportu urządzenia LSR, a więc: segmenty wejściowe, wyjściowe, połączenia(ang. cross-connects) i stosy etykiet. Razem modelują funkcje przełączające(ilm i NHLFE), czyli definiują zachowanie routera LSR po odebraniu pakietu z etykietą. Tabela mplsinterfacetable Każdy wiersz z tabeli iftable(moduł IF-MIB[RFC2863]) reprezentujący interfejs z uruchomioną funkcją MPLS(wartość iftype = mpls(166)) ma w tej tabeli swój wiersz, w którym podawane są obsługiwane zakresy etykiet przychodzących, wychodzących, a także całkowita i dostępna przepustowość interfejsu(jeżeli indeks wiersza jest równy 0, to podawane wartości odnoszą się nie do konkretnego interfejsu, a do etykiet z globalnej prze- 69

5 strzeni(ang. per-platform). Wiersze w tej tabeli tworzone są automatycznie przez agenta LSR. W programie będącym podstawą laboratorium tabela ta nie jest wykorzystywana. Tabela mplsinterfaceperftable Tabela, która rozszerza(ang. augments) zestaw kolumn tabeli interfejsów MPLS o kolumny przechowujące wartości liczników związanych z MPLS, takich jak: liczba wejściowych etykiet przydzielonych na danym interfejsie, liczba pakietów z nieznanymi etykietami, liczba przydzielonych etykiet wyjściowych oraz liczba pakietów, które musiały być podzielone przed wysłaniem(ich rozmiar wraz ze stosem etykiet był większy niż wartość MTU(ang. Maximum Transfer Unit) na łączu. W programie będącym podstawą laboratorium tabela ta nie jest wykorzystywana. Tabela mplsinsegmenttable Wiersze w tej tabeli reprezentują segmenty wejściowe tworzące ścieżki LSP. Głównymi atrybutami segmentu wejściowego jest wartość etykiety(mplsinsegmentlabel) i interfejs(mplsinsegmentinterface). Jeżeli etykieta została przydzielona w trybie globalnym (ang. per-platform), to indeks interfejsu ustawiony jest na 0. Wiersze w tej tabeli mogą być tworzone przez operatora lub automatycznie, wraz z rozgłaszaniem etykiet przypisanych do tuneli LSP przez protokół sygnalizacyjny. Każdy segment wejściowy na ostatnim (lub przedostatnim jeżeli stosowany jest PHP) routerze ścieżki MPLS musi określić do jakiego protokołu warstwy 3. należy przesyłany pakiet(mplsinsegmentaddrfamily). Jest to konieczne z tego powodu, że router wyjściowy(lub przedostatni) zdejmuje etykietę kończącego się tunelu i, jeżeli była to ostatnia etykieta na stosie, musi przesłać do jego adresu docelowego. Jeżeli ze ścieżką związane są wymagania na pasmo, to wiersz w tej tabeli wskazuje na odpowiedni wiersz w tabeli mplstunnelresourcetable z modułu TE (mplsinsegmenttrafficparamptr). Jeżeli segment wejściowy jest fragmentem ścieżki, to atrybut mplsinsegmentxcindex wskazuje na wiersz w tablicy mplsxctable, łączący ten segment wejściowy z segmentem wyjściowym. Innym atrybutem segmentu wejściowego jest liczba etykiet zdejmowanych z przychodzących pakietów(mplsinsegmentnpop), która w większości wypadków wynosić będzie 1. Tabela mplsoutsegmenttable Tabela zawiera listę segmentów wychodzących ścieżek LSP. Jej zawartość może być ustalana statycznie(płaszczyzna zarządzania) lub dynamicznie(protokół sygnalizacyjny).

6 Dla każdego takiego ogłoszenia aktualny router zapamiętuje etykietę(mplsoutsegment- TopLabel) oraz interfejs(mplsoutsegmentinterface), na którym to ogłoszenie otrzymał. Adres węzła dokonującego to przypisanie zawarty jest w atrybucie mplsoutsegmentnexthopaddr. Podobnie jak w przypadku segmentu wejściowego, tak i z wyjściowym możne być powiązany wiersz w tablicy mplsxctable(mplsoutsegmentxcindex)oraz wymagania ścieżki na pasmo(mplsoutsegmenttrafficparamptr). Jeżeli na aktualnym routerze dla danej ścieżki realizowany jest mechanizm PHP(zdejmowanie etykiety na przedostatnim routerze, patrz rozdział 3.2), żadna nowa etykieta nie jest wkładana na stos etykiet wychodzącego pakietu wtedy atrybut mplsoutsegmentpushtoplabel ustawiony jest na false. Tabela mplsxctable Tablica reprezentuje połączenia rozumiane jako powiązanie segmentu wejściowego z segmentem wyjściowym. Indeks wiersza składa się z trzech kolumn: mplsxcindex, mplsxcinsegmentindex i mplsxcoutsegmentindex. Połączenia należące do jednego tunelu mają tę samą wartość mplsxcindex dzięki temu możliwe jest utworzenie połączenia typu punkt-punkt, punkt-wielopunkt(na przykład dla ruchu multicast) oraz wielopunkt-punkt(łączenie ścieżek LSP). Wiersze w tej tabeli mogą być tworzone przez operatora lub na polecenie protokołu płaszczyzny sterowania. Jeżeli wiersz tworzony jest automatycznie, atrybut mplsxclspid zawiera wartość pola LSP ID obiektu SEN- DER TEMPLATE identyfikującego konkretny tunel w ramach jednej sesji protokołu RSVP-TE(patrz rozdział 3.4). Z każdym połączeniem może być skojarzony zestaw etykiet, identyfikowany przez mplsxclabelstackindex, wstawiany na stos poniżej etykiety wskazywanej przez atrybut TopLabel segmentu wychodzącego. Tabela mplslabelstacktable Tabela definiująca zestawy etykiet, które LSR wkłada na stos wychodzących pakietów zaraz pod najwyższą etykietę. Indeks wierszy jest dwuczłonowy mplslabelstackindex określa stos etykiet, a mplslabelstacklabelindex określa indeks etykiety w ramach stosu. Wiersze z tej tabeli są wykorzystywane tylko przez obiekty połączeń z tabeli mplsxctable. Tabela mplsinsegmentmaptable Tabela ta zawiera odwzorowanie przychodzącej etykiety i interfejsu wejściowego na indeks wiersza tego segmentu wejściowego. Konstrukcja ta ma przyspieszyć proces wyszukiwania połączeń przez stacje zarządzające NMS, które wykorzystując tę tabelę nie muszą 71

7 pobierać wszystkich wierszy z tabeli mpslinsegmenttable, żeby zidentyfikować właściwy wiersz. Podsumowanie modułu Najważniejsze z przedstawionych tabel, to te, które służą do modelowania ścieżki: mplsinsegmenttable, mplsoutsegmenttable, mplslabelstacktable i mplsxctable. Ich znaczenie podsumowane jest na Rys. 24. Wykorzystując te i pozostałe tabele modułu, NMS może InSegmentTable XCTable OutSegmentTable idx itf label NPop idx ins outs stack idx itf label LabelStackTable idx labelidx label IP 102 itf1 Itf2 Itf3 itf4 itf1 Itf2 Itf3 itf4 IP itf1 Itf2 Itf3 itf4 itf1 Itf2 Itf3 itf4 Rys. 24: Związki między tabelami używanymi do zestawienia ścieżki. całkowicie monitorować i konfigurować płaszczyznę transportową na routerze. Zewnętrzny system znający topologię sieci i zapotrzebowania ruchowe może śledzić zestawione ścieżki, wykorzystaną na interfejsach przepustowość i, jeżeli nie ma wystarczająco dużo wolnych zasobów, odmówić zestawienia nowej ścieżki w sieci lub zoptymalizować przebieg istniejących ścieżek, dając tym samym możliwość przyjęcia nowego przepływu. Alternatywnym rozwiązaniem jest pozostawienie funkcji przyjmowania nowych zgłoszeń(cac Call Admission Control) samej sieci przez stosowanie protokołów sygnalizacyjnych inżynierii ruchu. Zarządzane obiekty obejmujące ten obszar konfiguracji przedstawione są w opisie moduły do inżynierii ruchu w dalszej części tego rozdziału.

8 Moduł MPLS-FTN-STD-MIB Obiekty w tym module modelują przypisywanie pakietów IP wchodzących do domeny MPLS do klas FEC. Moduł FTN jest potrzebny tylko na routerach brzegowych domeny MPLS, które z założenia kierują przypisują nieotagowane pakiety IP do tuneli LSP. Konfigurowanie odwzorowania odbywa się przez zdefiniowanie zestawów kolejno wykonywanych testów i przypisanie tychże zestawów do interfejsów. Tabela mplsftntable Wiersze w tej tabeli definiują reguły, z którymi sprawdzane będą przychodzące pakiety IP. Reguły mogą być tworzone z wykorzystaniem dowolnej kombinacji następujących parametrów: zakresy portów źródłowych i docelowych, typ i zakresy adresów źródłowych i docelowych, wartość pola DSCP, protokół pakietu. O tym, które parametry podlegają sprawdzeniu w konkretnej regule mówi atrybut mplsftnmask. Ma on postać maski bitowej, w której każdy bit odpowiada jednemu typowi sprawdzanego parametru. Jeżeli dany bit jest ustawiony, odpowiadający parametr będzie sprawdzany na pakietach IP. Segment wyjściowy, którym wysłany zostanie dopasowany pakiet określony może być na dwa sposoby(kolumna mplsftnactiontype): przekierowanie do ścieżki LSP przekierowanie do tunelu TE W zależności od wartości tego parametru, zmienia się interpretacja kolumny mplsft- NActionPointer. Jeżeli typem przekierowania jest przekierowanie do ścieżki LSP, kolumna mplsftnactionpointer wskazuje obiekt cross-connect, którego segmentem wyjściowym zostanie wysłany pakiet. Jeżeli zaś typem przekierowania jest przekierowanie do tunelu TE, kolumna mplsftnactionpointer wskazuje na instancję tunelu TE. Konkretna ścieżka, którą zostanie przesłany pakiet jest to aktywna, w danym momencie, ścieżka tego tunelu. Jeżeli tunel ma skonfigurowane zabezpieczenia, w razie awarii pakiety przekierowywane do tunelu TE będą trafiały do ścieżki zabezpieczającej. Tabela mplsftnmaptable Tabela ta umożliwia przypisywanie reguł utworzonych w tabeli mplsftntable do interfejsów wejściowych i ustawianie ich w dowolnej kolejności. Jest to zrealizowane przez indeks składający się z trzech kolumn. Pierwsza kolumna indeksowa mplsftnmapindex określa interfejs, czyli kontekst do interpretacji pozostałych dwóch kolumn indeksowych. Kolumna mplsftnmapprevindex zawiera indeks reguły poprzedzającej aktualną 73

9 regułę, a kolumna mplsftnmapcurrindex określa indeks aktualnej reguły. Jeżeli aktualna reguła jest pierwszą na danym interfejsie, indeks poprzedniej reguły wynosi 0(z tego powodu żadna reguła nie może mieć indeksu równego 0). Konstrukcja indeksu tej tabeli przypomina listę łączoną pojedynczo(w tym przypadku każdy węzeł wskazuje na swojego poprzednika Rys. 25). mplsftntable mplsftnmaptable idx... itf prev curr itf prev curr itf prev curr mplsftnmaptable (a) dodawanie reguł itf prev curr itf prev curr itf prev curr (b) usuwanie reguły Rys. 25: Zasada przypisywania reguł do interfejsów Dosyć niespotykana w innych modułach konstrukcja indeksu tabeli mplsftnmaptable pozwala na dużą elastyczność w kształtowaniu reguł przypisywania do klas FEC(w efekcie do przekierowywania ruchu IP do poszczególnych ścieżek czy tuneli). Raz zdefiniowane reguły mogą być wielokrotnie wykorzystywane na różnych interfejsach, a ponadto ciąg reguł jest łatwo modyfikowalny(reguły mogą być wstawiane i usuwane również ze środka listy Rys.25b) Moduł MPLS-TE-STD-MIB Obiekty w tym module pozwalają tworzyć i monitorować tunele TE w sieci MPLS, które są sygnalizowane przez protokół RSVP-TE. Tunel TE, czyli zbiór jednej lub większej liczby ścieżek LSP, jest pojęciem znaczącym tylko dla płaszczyzny sterowania, używanym do nadania ścieżkom kontekstu. Bez niego ścieżka na danym urządzeniu widoczna jest tylko jako segment wejściowy i wyjściowy. Tunele TE dodają do tego lokalnego widoku obraz

10 koniec-koniec. Dzięki niemu router może określić, jakie są punkty końcowe ścieżki oraz zna stan ścieżki. Umożliwia to rozróżnianie ścieżek należących do tej samej grupy w celu równoważenia wykorzystania łączy(ang. load balancing) i tworzyć ścieżki ochraniające inne ścieżki w tunelu. Tabela mplstunneltable Wiersze w tej tabeli odpowiadają ścieżkom LSP należącym do tuneli TE, które przechodzą przez dany router. Tunele TE i ich ścieżki w sieci MPLS są jednoznacznie identyfikowane przez pola obiektów SESSION i SENDER TEMPLATE protokołu RSVP-TE. Polatesąodwzorowanenakolumnyindeksowewtejtabeli.ZobiektuSESSIONsąto:kolumna mplstunnelindex odpowiadająca polu Tunnel ID oraz mplstunnelingresslsrid odpowiadająca polu adres IPv4 końca tunelu (ang. IPv4 end point address). Z kolei z obiektu SENDER TEMPLATE pochodzą wartości kolumn: mplstunnelinstance odpowiadający polu LSP ID i mplstunnelingresslsrid polu adres IPv4 nadawcy tunelu (ang. IPv4 tunnel sender address). Indeksy wierszy ścieżek łączących dwa routery i należących do tego samego tunelu różnią się tylko o wartość kolumny mplstunnelinstance. Ścieżka zabezpieczająca(zarówno obchodząca detour, jak i omijająca bypass) odróżnia się od swojej ochranianej ścieżki tylko wartością kolumny mplstunnelingresslsrid. Szczegóły sposobów identyfikacji ścieżek i tuneli przedstawione są w rozdziale 3.5. Aby utworzyć nową ścieżkę w tunelu TE, sygnalizowaną w sieci automatycznie, operator tworzy na routerze wejściowym w tej tabeli wiersz. Nadanie kolumnie indeksowej mplstunnelinstance wartości 0 definiuje abstrakcyjny tunel(czyli samo połączenie routera wejściowego z wyjściowym), nie precyzując konkretnej ścieżki realizującej ten tunel. Przekierowanie pakietu do tak określonego tunelu spowoduje, że zostanie on przesłany po wybranej ścieżce należącej do tego tunelu. Operator może definiować priorytet ścieżek poprzez ustawienie atrybutu mplstunnelinstancepriority. Jeżeli dwie lub więcej ścieżek ma taki sam najwyższy priorytet, ścieżki te są wykorzystywane jednocześnie(ang. load sharing). Jeżeli cały tunel lub jego ścieżka widoczne są w systemie jako interfejs, to kolumna mplstunnelifindex zawiera indeks wiersza tabeli iftable reprezentującego ten interfejs (jego iftype wynosi mplstunnel(150)). W takiej sytuacji LSR może rozgłaszać do protokołu routingu adres routera wyjściowego osiągalnego przez interfejs tunelu. Pakiety IP, których adres docelowy zostanie dopasowany w tablicy routingu do wpisu wskazującego 75

11 na interfejs tunelu, zostaną automatycznie enkapsulowane w etykiety i przezroczyście przesłane tunelem. Żeby tunel TE mógł być sygnalizowany w sieci, musi być utworzony obiekt Explicit Route(ERO), zawierający wszystkie węzły biorące udział w ścieżce, wysyłany wraz z wiadomością Path zestawiającą tunel. Jego zawartość jest brana bezpośrednio lub obliczana na podstawie wierszy w tabeli mplstunnelhoptable, które wspólnie określane są przez wartości atrybutów mplstunnelhoptableindex i mplstunnelpathinuse. Z przebiegiem ścieżki realizującej tunel związane są również dwa inne indeksy do tabel modułu. Ponieważ ścieżka nie zawsze może być zestawiona dokładnie tak, jak określają wiersze z tablicy mplstunnelhoptable, podane są indeksy do tabel zawierających obliczone(mplstunnelchoptableindex) i rzeczywiście przechodzone(mplstunnelarhoptableindex) węzły danej ścieżki. Rzeczywiste węzły, przez które przechodzi ścieżka, mogą różnić się od obliczonych w sytuacji, gdy któryś z węzłów downstream uruchomił mechanizm lokalnej ochrony, co wpłynęło na przebieg ścieżki. Jeżeli ścieżka jest tworzona w sposób ręczny, indeksy do tablic węzłów nie są wykorzystywane. Gdy z tunelem skojarzona jest ścieżka, zasygnalizowana lub przypisana statycznie, atrybut mplstunnelxcindex przechowuje indeks do wiersza w tablicy połączeń reprezentujący połączenie należące do tej ścieżki na aktualnym routerze. Tunel może być aktywny tylko wtedy, gdy wszystkie segmenty ścieżki są aktywne, ewentualnie przypisana ścieżka jest przeprowadzona inną trasą w wyniku awarii łącza lub węzła, lecz jej ciągłość jest zachowana. Tabela mplstunnelhoptable Przed wysłaniem wiadomości Path, LSR musi znać przebieg ścieżki. Niniejsza tabela pozwala operatorowi podać zestawy węzłów, którymi, w miarę możliwości, będzie poprowadzona ścieżka. Indeks wierszy zbudowany jest z trzech kolumn. Pierwsza kolumna mplstunnelhoplistindex identyfikuje listę opcji ścieżek. Druga kolumna mplstunnelhoppathoptionindex konkretną opcję ścieżki. Trzecia mplstunnelhopindex określa kolejność węzłów wewnątrz opcji ścieżki. Konkretne opcje ścieżek wybrane dla realizacji tuneli wskazywane są z tablicy mplstunneltable. Każdy węzeł w opcji ścieżki reprezentowany jest jako wiersz tej tabeli. Węzeł może oznaczać nie tylko adres IP pojedynczego routera czy interfejsu, ale także całą podsieć lub system autonomiczny. Na ich podstawie budowany jest ERO(rozdział 3.4.2, przy

12 czym operator, w kolumnie mplstunnelhopentrypathcomp może wybrać tryb, w jakim zostanie on utworzony. Do wyboru są: tryb dynamiczny operator podaje tylko węzeł początkowy i końcowy, zostawiając wyliczenie wszystkich pośrednich węzłów algorytmowi CSPF. tryb jawny(ang. explicit) operator podaje wszystkie żądane węzły W trybie jawnym poszczególne węzły mogą być typu luźnego lub ścisłego(mplstunnel- HopType). Węzeł luźny może dzielić od poprzedniego dowolna liczna przeskoków(nie będących wymienionych w ERO), które są obliczane lokalnie przez ostatni router przed luźnym węzłem. Operator może zabronić ścieżce przechodzenia przez dany węzeł ustawiając wartość kolumny mplstunnelhopinclude na false. Dla tak zdefiniowanego węzła, algorytm CSPF wykluczy go z obliczania ścieżki. Dla wykluczanych węzłów ich typ(ścisły lub luźny) nie jest brany pod uwagę. Tabela mplstunnelresourcetable Wiersze tej tabeli reprezentują deskryptory ruchu, czyli wymagania ścieżki na pasmo i mogą być wskazywane przez definicje sygnalizowanych tuneli w tabeli mplstunneltable, gdy jest potrzeba zarezerwowania dla nich zasobów na interfejsach. W przeciwnym razie dostępność zasobów nie będzie weryfikowana i tunel będzie przesyłał ruch w trybie best-effort. Dostępne parametry opisujące ruch to: średnia(mplstunnelresourcemeanrate) i maksymalna(mplstunnelresourcemaxrate) przepływność strumienia ruchu, średnia(mplstunnelresourcemeanburstsize), maksymalna(mplstunnelresourcemaxburstsize) i nadmiarowa(mplstunnelresourceexcessburstsize) wielkość paczki danych. Wartości te określają charakterystykę podwójnego mechanizmu Token Bucket. Dodatkowo dostępny jest parametr określający jak często ma być aktualizowana informacja o dostępnej przepływności CIR(ang. Commited Information Rate), czyli wielkość żetonu mechanizmu Token Bucket oraz parametr mplstunnelresourceweight mówiący o tym, jak będzie traktowany nadmiarowy ruch danego deskryptora w porównaniu do nadmiarowego ruchu innych deskryptorów. Informacje te przesyłane są w wiadomości Path podczas sygnalizowania ścieżki. Jeżeli więcejniżjedentunelwskazujenadanywierszwtejtabeli,świadczytootym,żeścieżki należące do tych tuneli dzielą między siebie zarezerwowane zasoby. 77

13 Tabela mplstunnelarhoptable Wiersze w tej tabeli wskazywane są przez obiekt mplstunnelarhoptableindex i zawierają listy węzłów w sieci, przez które rzeczywiście przechodzą instancje tych tuneli (ścieżki LSP). Listy te mogą różnić się od list wysyłanych w ERO przy sygnalizacji tunelówzewzględunamożliwąobecnośćwęzłówtypuluźnegowerooraznazmianyw przebiegu ścieżki wynikające z zastosowania mechanizmów lokalnej ochrony. Dane do tej tabeli są tylko-do-odczytu, a pochodzą z obiektów RECORD ROUTE, które mogą być obecne zarówno w wiadomościach Path, jak i Resv. Tabela mplstunnelchoptable Zawiera listy węzłów, które zostały wysłane jako obiekty ERO przy sygnalizacji ścieżek. Jeżeli lista węzłów w tabeli mplstunnelhoptable dla danego tunelu była ustawiona jako dynamiczna, za pomocą tej tabeli operator może prześledzić jaką trasę wyliczył algorytm CSPF. Jeżeli zaś lista węzłów była typu jawnego, to węzły tu raportowane pokrywają się z tymi we wspomnianej tabeli. Podobnie jak w przypadku mplstunnelarhoptable, tabela ta jest w całości tylko-do-odczytu. Tabela mplstunnelperftable Kolumny w tej tabeli rozszerzają tablicę mplstunneltable o dodatkowe kolumny liczników. Dla każdego tunelu dostępna jest liczba przesłanych nim bajtów, pakietów oraz liczba pakietów, która została upuszczona z powodu błędów. Liczniki bajtów i pakietów dostępne są w wersji 32-bitowej i 64-bitowej. Podsumowanie modułu Zarządzane obiekty modułu MPLS-TE-STD-MIB dostarczają operatorowi środków do elastycznego konfigurowania i monitorowania tuneli. Tunele TE, przez powiązanie ich z listą przeskoków, mogą być prowadzone niezależnie od routingu IP, co pozwala pełniejsze wykorzystanie zasobów sieciowych. Inną możliwością, którą dają tunele TE jest możliwość stosowania ich do pomiaru ruchu pomiędzy dwoma punktami sieci. Najbardziej wydajnym i elastycznym podejściem do wykorzystania przedstawionego modułu jest używanie go jako interfejsu, przez który operator przez stację zarządzającą wydaje żądania zestawienia tunelu w sieci. Dalszy proces konfigurowania przebiega automatycznie, z wykorzystaniem protokołu płaszczyzny sterowania a stacja zarządzająca odczytuje tyko status zestawionych połączeń. Innym podejściem jest pozostawienie całej konfiguracji w gestii operatora powiązania między tunelami a osobno tworzonymi

14 ścieżkami LSP nadawane są wtedy statycznie. Zrezygnowanie z protokołu sygnalizacyjnego wiąże się jednak z utratą widoku koniec-koniec ścieżek, dlatego przy takim podejściu wiedzę tę musi przejąć stacja zarządzająca Moduł MPLS-FRR-GENERAL-STD-MIB Moduł ten zawiera obiekty pozwalające na konfigurowanie i monitorowanie mechanizmu Fast Reroute(Rozdział 3.5). Pochodzi z niezatwierdzonego w czasie pisania tej pracy dokumentu IETF, dlatego definicje zarządzanych obiektów mogą w wersji ostatecznej ulec pewnym modyfikacjom. Wydaje się to prawdopodobne zważywszy na pewne niespójności pomiędzy tym modułem, a dokumentem[rfc4090]. Tabela mplsfrrgeneralconstraintstable Wiersze w tej tabeli reprezentują ograniczenia związane z zestawianiem ścieżki okrężnej(ang. detour) lub omijającej ang. bypass dla danej ochranianej ścieżki. O tym, który dokładnie tryb ochrony jest wybrany informuje skalar mplsfrrgeneralprotectionmethod oraz, jeżeli typ ochrony to ochrona elementu, kolumna mplsfrrgeneralconstraintsprotectiontype mówiąca, czy chodzi o ochronę łącza czy kolejnego węzła. Definiowane tutaj obiekty(wiersze) bezpośrednio odpowiadają obiektom FAST REROUTE wysyłanym razem z wiadomościami Path. Indeks wiersza składa się z trzech kolumn. Pierwsza mplsfrrgeneralconstraintsifindexorzero wskazuje który interfejs jest ochraniany w trybie ochrony łącza. Wszystkie ścieżki LSP wychodzące przez ten interfejs, w razie jego awarii, będą przeprowadzone przez tunel ochronny. Wartość tego atrybutu ustawiona na 0, według opisu w module, ma oznaczać ochronę wszystkich interfejsów, a tym samym ochronę węzła. Nie jest to jednak prawdą zgodnie z[rfc4090] to, czy będzie zastosowana ochrona węzła czy łącza nie zależy od liczby ochranianych interfejsów na aktualnym routerze, ponieważ określenie to dotyczy następnego węzła. Druga kolumna indeksowa mplsfrrgeneralconstraintstunnelindex, według opisu w module, zawiera indeks tunelu TE odpowiedzialnego za ochronę interfejsu. Trzecia kolumna mplsfrrgeneralconstraintstunnelinstance to instancja tunelu (ścieżka LSP), w której ruch z wyłączonego interfejsu będzie tunelowany. Pozostałe kolumny tabeli określają dozwolone i zabronione atrybuty(ang. affinity) interfejsów ścieżki ochraniającej, priorytety zestawienia i utrzymania, limit liczby przeskoków oraz wymagana przepustowość ścieżki. 79

15 Tabela mplsfrrgeneralconstraintsarhoptable Wiersze w tej tabeli prezentują informacje na temat skonfigurowanego trybu FRR na poszczególnych węzłach ścieżki. Indeksy wierszy są te same, co w tabeli mplstunnelarhoptable, ale nie dla wszystkich jej wierszy muszą istnieć wiersze w niniejszej tabeli. Informacje o skonfigurowanym mechanizmie zabezpieczeń odczytywane są z obiektu RE- CORD ROUTE. Podsumowanie modułu Moduł MPLS-FRR-GENERAL-STD-MIB umożliwia operatorowi doprecyzowania wymagań na ścieżkę zabezpieczającą. Zarządzane obiekty są tworzone na routerze wejściowym ścieżki, dla której żąda się ochrony. Obiekty odpowiadają nowym elementom sygnalizacyjnym, zdefiniowanym w rozszerzeniach RSVP-TE dla FRR([RFC4090]). Uzupełniają one możliwości oferowane przez specyfikację[rfc3209] i moduł MPLS-TE-STD-MIB w zakresie zestawiania i monitorowania ścieżek ochronnych PODSUMOWANIE W tym rozdziale przedstawione zostały funkcje i zarządzane obiekty dostępne w poszczególnych modułach MIB standardowego modelu informacyjnego urządzenia MPLS. Przez obiekty modułu MPLS-LSR-STD-MIB operator konfiguruje płaszczyznę transportu routera. Moduł MPLS-FTN-STD-MIB pozwala na tworzenie reguł kierowania przychodzących pakietów IP do odpowiednich tuneli. Moduł MPLS-TE-STD-MIB umożliwia konfigurowanie płaszczyzny sterowania w zakresie tworzenia tuneli TE, a moduł MPLS-FRR-GENERAL-STD-MIB służy do tworzenia powiązań między ścieżkami zabezpieczającymi i zabezpieczanymi. Opisane zostały również relacje między obiektami tego modelu a obiektami protokołów MPLS i RSVP-TE. W rozdziale 5.6 przedstawione są szczegółowo wszystkie kolumny obecne w zaimplementowanych modułach.