Najpowszechniejszym systemem zarządzania jest SNMP i gdyby nie AsyncFramer firmy HT Communications, to implementacja tego protokołu byłaby przywilejem 100 proc. FRADów z tabeli 2. Wiele uwagi poświęcili też producenci dwu innym systemom:
In band - zarządzaniu FRADem czy przełącznikiem za pośrednictwem okablowania sieci, a nie bezpośrednio oddzielnymi przewodami czy łączem modemowym. W takim systemie nie można np. zdalnie uruchomić sieci po awariach zasilania.
Out of band (out band) - zarządzaniu za pośrednictwem specjalnych (bezpośrednich) połączeń lub przez modem, a nie przez okablowanie sieci. W ten sposób można zdalnie uruchamiać sieci również po awariach zasilania.
Tworzenie raportów
Rys. 4 Trzy struktury nagłówka ramki FR
W sieci Frame Relay wymuszanie przesyłania danych ponad wartość wynikającą ze wskaźnika EIR jest od razu skazane na niepowodzenie, gdyż FRAD skrzętnie analizuje ruch i kontroluje liczbę danych przesyłanych każdym wirtualnym połączeniem. Takiej analizy nie jest w stanie przeprowadzić na przykład tradycyjny most-router. FRADy przedstawione w tabeli 2, z wyjątkiem AsyncFramer firmy HT Communications, przechowują i modyfikują również statystyki wielu innych parametrów ruchu oraz tworzą raporty ułatwiające użytkownikom sprawdzania zobowiązań operatora, czyli SLA (Seruice Level Agreement). FRADy są zwykle zajęte swoimi głównymi funkcjami i w rzeczywistości nie mogą przeprowadzić wszystkich pomiarów z dokładnością pozwalającą na wychwycenie zjawisk zachodzących w krótkich okresach. Rejestrowanie średniego ruchu co kilkanaście minut, co jest częstym udziałem aplikacji zbierania danych SNMP, nie wystarcza do wychwycenia stanów krytycznych pojawiających się co 5 lub 10 sekund. Z tych względów na rynku pojawiły się różne sondy FR: pasywne - włącza się szeregowo za pośrednictwem kabla typu Y, aktywne - włączane szeregowo, w wielu punktach sieci, i wreszcie FR RMON2 - specyficzne analizatory protokołów instalowane we FRADach.
Kompresowanie głosu i danych
Rozwój algorytmów kompresowania głosu umożliwia już "ściskanie" go do 4,8 kb/s. W tabeli 2 widać cztery takie przykłady (13,1:1,13,3:1): SDM-9350 ACT Networks, Athena Access firmy Develcon Electronics Ltd., IEN 4000 wytwarzany przez Hypercom Network Systems i Network Exchange 2210 spółki Netrix Corp. Z kolei do przepływności 5,3 kb/s zostały przystosowane dwa FRADy głosowe: F200ip firmy Nuera Communications i IAN-150 Timeplex Group.
Frady firmy RAD Data Communications
Kompresowanie głosu ma dwie ważne zalety. Po pierwsze zmniejsza całkowity wolumen strumienia przepływającego przez łącze Frame Relay, dzięki czemu nie musi być ono - w sensie pasma - tak szerokie, jak przed kompresją. Przykład: łączem El (2048 kb/s) można przeprowadzić 386 rozmów przy kompresji 12:1 (przełączanie pakietów), 256 rozmów przy kompresji 8:1 i wreszcie 30 rozmów bez kompresji (przełączanie obwodów). Jeśli przyjąć, że 30 równoczesnych rozmów jest pewnym standardem przedsiębiorstwa, to nie skompresowany głos zajmie całe pasmo El, podczas gdy przy kompresji 12:1 (5,3 kb/s) pozostanie do zużytkowania pasmo: 2048 kb/s - 30x5,3kb/s = 1889 kb/s. Po drugie kompresja głosu obniża wymagania na CIR. Głos - jak wiadomo - wymaga niewielkiego i ponadto przewidywalnego opóźnienia. Jeśli jest on skompresowany, to potrzebuje węższego pasma, a więc w efekcie tańszego wskaźnika CIR.
Cisco 2620/21
W tabeli 1 zostały zestawione wszystkie znormalizowane algorytmy kodowania głosu i ważniejsze parametry pomocnicze. W pierwszych latach XXI w. kompresowanie głosu dojdzie prawdopodobnie do 2,4 kb/s, czyli ok. 26:1. Kompresowaniem głosu rządzi jednak zasada: wyższa kompresja - niższa jakość głosu.
Producenci FRADów zaczynają wprowadzać również kompresję danych. Chociaż wyniki nie są tak okazałe jak przy kompresji głosu, to wolumen danych transmitowanych w sieciach WAN można zredukować - jeśli oczywiście nie były one skompresowane wcześniej - w przybliżeniu o 75 proc. Kompresowanie danych zależy także od ich typu. Oprócz własnych algorytmów kompresowania danych producenci stosują najczęściej dwa następujące:
CCP: RFC 1962 The PPP Compression Control Protocol (CCP).
Kompresowanie danych w transmisjach WAN może dosyć szybko stać się wąskim gardłem łącza i - podobnie jak zróżnicowane protokoły sygnalizacji - przyczyną niekompatybilności. Dlatego warto kompresować dane własnym, zwykle bardzo tanim i skutecznym oprogramowaniem.
Rezerwowanie zasobów, kolejki, priorytety
Do takich funkcji angażuje się protokoły występujące w 16 kolumnie tabeli 2: CAR (Committed Access Rate), D-WFQ (Distributed Weighted Fair Queuing), D-WRED (Distributed Weighted Random Early Detection), FIFO (First In, First Out Queuing), PDQ (Parallel Data Query), RED (Random Early Detection), RSVP (Resource ReSerVation Protocol), WFQ (Weighted Fair Queuing) czy WRED (Weighted Random Early Detection) i in.
