AGH University of Science and Technology

AŃSTWOWA

YŻSZA

ZKOŁA

AWODOWA W

ARNOWIE

NSTYTUT

OLITECHNICZNY

KIERUNEK

LEKTRONIKA I

ELEKOMUNIKACJA

ROK

III

Ćwiczenie nr 4

Badanie sieci Frame Relay

Systemy i sieci telekomunikacyjne

Laboratoria

1.1 Wstęp

Frame relay jest zorientowanym połączeniowo, zawodnym protokołem wykorzystującym

połączenia wirtualne (virtual circuits). Wirtualne połączenia muszą być wpierw ustanowione

między źródłem i celem przed rozpoczęciem jakiejkolwiek transmisji. Większość dostawców

usług Frame Relay wspiera Permanent Virtual Circuits (PVC – stałe połączenie wirtualne). So

to długotrwałe połączenia w przeciwieństwie do Switched Virtual Circuits (SVC –

przełączane połączenia wirtualne), które z kolei są zestawiane w momencie nawiązania

połączenia.

Podczas zestawiania połączenia PVC są ustalane określone parametry regulujące jego

zachowanie. Należą do nich Committed Information Rate (CIR), Committed Burst Rate (Bc)

oraz Excess Burst Rate (Be). CIR jest współczynnikiem wyrażonym w bitach na sekundę,

który jest gwarantowany przez dostawcę usług. Parametr Bc określa jak szybko dane mogą

być wysyłane. Na przykład, klient ma zakontraktowany CIR równy 64 kb/s i BC równy

32kb/100ms. W tym przypadku, klient może wysyłać 64kb na sekundę, ale nie więcej niż 32

kb w każdych 100 ms. Dostawcy usług Frame relay akceptują dodatkowe dane powyżej

wartości CIR i transmitują je, jeśli istnieje nadmiarowa pojemność sieci w danej chwili. Ilość

nadmiarowych danych, które zostanie przesłana jest definiowana przez Excess Burst Rate

(Be). W każdej ramce, która jest przesyłana w nadmiarze jest ustawiany bit DE – Discard

Eligiable. W razie natłoku te ramki są odrzucane w pierwszej kolejności.

1.2 Przebieg ćwiczenia

1.2.1 Tworzenie modelu sieci

1) Otwórz OPNET IT Guru Academic Edition

2) Zapoznaj się z informacjami zawartymi w programie OPNET na temat konfiguracji Frame

Relay. W tym celu z menu File, wybierz Open, a następnie potwierdź wybór Frame_relay.

Przeczytaj informacje zawarte w zakładkach Objective, Network Configuration, i Glossary

pages. Z menu File wybierz Close, aby zamknąć.

3) Tym razem z menu File wybierz New, a następnie Project. Wybierz nazwę dla projektu na

przykład WAN_Frame_Relay, nazwe scenariusza CIR64. W następnym oknie wybierz

Create Empty Scenario, wybierz Network Scale typu World. Z Map list wybierz usa. W

oknie wyboru techniki sieciowej zatwierdź wybór frame_relay_advanced. W następnym

oknie dialogowym potwierdź wybór klikając Ok.

Teraz przystąpimy do skonfigurowania modelu generującego ruch w naszej sieci Frame

Relay. File Transfer Protocol (FTP) będzie służyć naszym celom.

Z okna Object Pallete wybierz Application Config i przeciągnij do okna z mapą. Na nowo

wstawiony obiekt kliknij prawym przyciskiem myszy i wybierz Edit Attributes, w polu

name wpisz ruch Bursty Application. Rozwiń atrybut Application Definitions i w polu

rows ustaw wartość 1.

Następnie rozwiń atrybut row0 i ustaw nazwę FTP_Burst. Rozwiń atrybut Description i

przejdz do edycji FTP. Ustaw atrybutowi Inter-Request Time (secs) wartość exponential(1e-

1). Ustaw File Size na constant(1000). W obu przypadkach konieczne będzie ustawienie w

polu Special Value wartości Not Used w celu modyfikacji powyżej przedstawionych

wartości.

Tak zdefiniowany generator ruchu będzie średnio generować i przesyłać 10 paczek danych o

rozmiarze 1kB w ciągu każdej sekundy. Funkcja ekspotencjalna jest również używana do

modelowania czasów oczekiwania, której użyjemy do zamodelowania odstępów czasowych

pomiędzy żądaniami.

By potwierdzić kliknij OK.

Następnie wybierz obiekt Profile Config z Panelu Obiektów i przeciągnij do okna roboczego

na mapę. Podobnie jak wcześniej po kliknięciu na obiekt prawym przyciskiem myszy wybierz

opcję Edit Attributes. W polu name wpisz Bursty Profile. Rozwiń Profil Configuration i

ustaw w polu rows wartość 1. Następnie rozwiń row0 i ustaw nazwę profilu na

FTP_Bursty_Profile. Rozwiń atrybut Applications i w polu rows ustaw wartość 1. Rozwiń

row0 i ustaw nazwę atrybutu na FTP_Bursty. W atrybucie powtarzalność ustaw wartość

Once at Start Time. Kliknij ok, by zatwierdzić zmiany i zamknij okno.

Wybierz obiekt fr32_cloud z palety i wstaw do okna głównego. Po kliknięciu prawym

przyciskiem myszy na nowy obiekt wybierz View Node Description. Chmurka reprezentuje

sieć WAN, która składa się z urządzeń zgodnych z Frame Relay i która wspieraja do 32

połączeń Frame Relay. Po kliknięciu prawym przyciskiem myszy na chmurę ustaw nazwę

(Set Name) na Frame_Relay_Cloud. Wciśnij OK by zamknąć okno i potwierdzić zmiany.

Wybierz urządzenie fr_wkstn_adv z okna palety i umieść na mapie w oknie głównym. Po

kliknięciu prawym przyciskiem myszy wybierz View Node Description. Zauważ, że stacja

wspiera protokół Frame Relay. Do urządzenia przyporządkujemy wcześniej zdefiniowanych

ruch typu bursty FTP.

Kliknij prawym przyciskiem na stację i wybierz Edit Attributes. Zmień nazwę urządzenia na

Bursty_Client. Wybierz atrybut Application: Supported Profiles w wierszu wstaw

FTP_Bursty_Profile jako nazwę profilu. Zatwierdź klikając OK.

Wybierz urządzenie fr_server_adv z okna palety i umieść na mapie w oknie głównym. Po

kliknięciu prawym przyciskiem myszy wybierz View Node Description. Zauważ, że stacja

także wspiera protokół Frame Relay. Do urządzenia przyporządkujemy wcześniej

zdefiniowanych ruch Bursty FTP.

Kliknij prawym przyciskiem na stację i wybierz Edit Attributes. Zmień nazwę urządzenia na

Bursty Server. Wybierz atrybut Application: Supported Profiles w wierszu wstaw

FTP_Bursty jako nazwę profilu. Zatwierdź klikając OK.

Wybierz 2 urządzenia fr8_switch_adv z okna palety i umieść na mapie w oknie głównym -

jeden w sąsiedztwie server, a drugi w sąsiedztwie klienta. Po kliknięciu prawym przyciskiem

myszy wybierz View Node Description. Zauważ, że switche w przypadku przeciążenia

podejmą następujące akcje: w pierwszej kolejności odrzucane będą ramki oznaczone jako

Discard Eligible Bit, ale switch może odrzucać także całe ramki. Kliknij close by zamknąć

okno.

Zmień nazwy przełącznikom, nazwij je odpowiednio Client Switch i Server Switch

wykorzystując polecenie Set Name.

Wybierz 3 łącza FR_T1_int z okna palety i użyj ich do połączenia: klienta do switcha,

serwera do switcha i switche do chmurki Frame Relay. Wykorzystywane łącza typu T1

zapewniają przepływność 1.5 Mb/s.

Wreszcie możemy ustawić PVC pomiędzy stacją kliencką a serwerem, dzięki czemu będą sie

mogły ze sobą komunikować. Wybierz FR PVC Config z okna palety i umieść na mapie w

oknie głównym. Zmień jego nazwę na PVC Config używając Set Name z menu

kontekstowego. Obiekt FR PVC Config musi być umieszczony w przestrzeni roboczej przed

skonfigurowaniem jakichkolwiek PVC. Kliknij OK aby zatwierdzić.

Wybierz obiekt fr_pvc z panelu obiektów i użyj go do połączenia klienta z serwerem.

Następnie wciśnij prawy przycisk myszy na połączeniu i z menu kontekstowego wybierz

‘Abort Demand Definition’.

Kliknij prawym przyciskiem myszy na PVC i rozwiń atrybut Contract Parameters. Parametry

te stanowią porozumienie między stacjami końcowymi (klient, serwer) a dostawcą usług

Frame Relay. Ustaw w polu Outgoing CIR (bits/sec) wartość 64000, Outgoing BC (bits)

również na 64000, oraz Outgoing Be (bits) 32000 . Kliknij Ok aby zatwierdzić.

CIR jest ilością ruchu którą dostawca usług zgodził się zapewnić. Committed Burst Size (Bc)

określa jak wiele danych może być wysłanych w danym odcinku czasu. W tym przypadku

długość tego odcinka jest równa jednej sekundzie, stąd CIR jest równy wartości Bc. Excess

burst size jest ilością ruchu którą dostawca usług może zaakceptować powyżej

zakontraktowanej wartości, jeśli warunki sieci na to pozwalają. Nadmiarowe dane mogą być

odrzucone jeśli w sieci dostawcy usług wystąpi natłok.

1.2.2 Konfiguracja i uruchomienie symulacji

Wybierz zakładkę Simulation i wybierz Choose Individual Statistics… . Następnie rozwiń

element Global Statistics i Frame Relay, wybierz Delay(sec), Delay Variance(sec) i

statystyki Residual Error Rate. Rozwiń element FTP i wybierz Download Response Time

(sec) oraz statystyki Traffic Received (bytes/sec).

Rozwiń element Node Statistics oraz Frame Relay PVC, a następnie wybierz BECN Status,

DE Status oraz statystyki dla FECN Status.

1.2.3 Powielenie scenariusza

W tym podpunkcie powielimy przygotowany już scenariusz - w ten sposób będzie można

zbadać zachowanie sieci dla różnych wartości CIR.

Wybierz Scenarios -> Duplicate Scenario i nadaj kopi scenariusza nową nazwę np. CIR128.

Na linii PVC klikamy pawym przyciskiem myszy, wybieramy opcję Edit Attributes i

rozwijamy listę Contract Parameters. Ustawiamy pole Outgoing CIR(bits/sec) na 128 000,

pole Outgoing Bc (bits) na 128 000 i Outgoing Be (bits) na 32 000. Zatwierdzamy zmiany

wybierając OK.

1.2.4 Uruchomienie symulacji

Wybieramy Scenarios -> Manage Scenarios. W kolumnie Results zmieniamy parametry na

<collect> lub <recollect> aby zebrać dane po symulacji. Dodatkowo można zmienić czas

symulacji w polu Sim Duration (jednak pozostajemy przy wartości 5 minut). Wybieramy OK.

aby rozpocząć symulacje.

1.2.5 Zebranie i analiza wyników

Wybieramy Results -> Compare Results.

Zacznijmy od analizy parametru Download Response Time(sec) dostępnego pod Globar

Statistics-> Ftp. Wykres pokazuje ile czasu zajęło każde pobranie (reprezentowane przez

punkt na wykresie). Widać, że pobranie zajęło znacznie mniej czasu w przypadku scenariusza

CIR128, ponadto wariancja czasu pobrania tez jest mniejsza – był to wynik do przewidzenia

ponieważ dysponowaliśmy większą wartością parametru CIR.

Wybierz kolejny symulowany parametr połączenia - Traffic received (bytem/sec) .

Symulacja ta opisuje ilość otrzymanego ruchu FTp zarówno przez Server jak i przez Clients.

Widać, że większy ruch pojawił się w przypadku CIR128, ponadto wykres jest bardziej

nierównomierny – występuje w nim więcej wahań aniżeli w scenariuszu CIR64.

Będziemy teraz analizować zależności czasowe przesyłanego ruchu – opóźnienie i wariancję

opóźnienia.

Zaznacz i rozwiń pozycję Globar statisctics, wybierz Frame Relay, a następnie opcję Delay

(sec). Zmień tryb prezentowania danych na wykresie z ‘As is’ na Tryb time_average. w tym

trybie będzie łatwiej dostrzec różnicę w wydajności. Kliknij w przycisk Show, aby zobaczyć

więcej szczegółów. Statystyka wskazuje, ile czasu zajęło dostarczenie każdej ramki. Widać,

że opóźnienie to jest większe w przypadku CIR64 i że opóźnienie rośnie z upływem

czasu. Wraz z upływem czasu opóźnienia zwiększają się (CIR64) jest to spowodowane

przepełnianiem się buforów w switchach.

Rozwiń opcję Delay Variance (sec) i przeglądaj je z trybem ‘As is’. Ta statystyka pokazuje,

wariancji opóźnienia dostarczenia ramek. W przypadku scenariusza CIR64 obserwujemy

wiele zmienności w przebiegu wykresu – zmienność ta rośnie wraz z upływem czasu –

podobnie jak w przypadku wykresy dla opóźnień (Delay).

Rozwiń statystyki dotyczące błedu Residual Error Rate i analizuj je w trybie ‘As is’. Ta

statystyka pokazuje odsetek ramek, które są odrzucane z powodu przeciążeń lub uszkodzenia.

Widać, że wiele innych ramki w scenariuszu CIR64 jest odrzucanych, ich ilośc znacznie

rośnie z upływem czasu – bufory w switchach stają się coraz bardziej zajęte.

Zaznacz i rozwiń Object Statistics, wybierz Bursty Item a następnie Frame Relay PVC.

Wybierz DE Status i przeglądaj statystyki w trybie ‘As is’. Ta statystyka pokazuje ramek,

które zostały otrzymane przez klienta, który miał ustawiony bit DE. Gdy otrzymuje wiele

ramek z ustawionym bitem DE, to wskazuje, że źródło danych często wysyłało ramki szybciej

niż jest to przewidziane w parametrze CIR.

Widać, że znacznie więcej klatek są posiada ustawiony bit DE w przypadku CIR64 niż

CIR128. Ma to sens, ponieważ w symulacji dla obu scenariuszy generujemy tą samą ilość

ruchu, ale scenariusz CIR128 zapewnia większą przepustowość do przenoszenia ruchu.

Następnie dla tej samej statystyki (DE status) zmień tryb wyświetlania wykresy na

‘time_average’. Widać, że pomimo zachowania kształtu krzywej dla obu wartości CIR, to

ilość bitów DE jest ponad cztery razy większa dla scenariusza CIR64, niż dla CIR128

Symulacje BECN Status i FECN Status pokazują, jak wiele ramek otrzymano z

ustawionym bitem BECN lub FECN. Te bity są ustawiane przez przełącznik, gdy ten jest

przepełniony. Jeśli przejrzeć statystyki, widać, że nie otrzymano żadnych ramek z tymi bitami

ustawionymi . Ruch przesyłany nie jest wystarczający aby spowodować natłok na

przełącznikach.

1.3 Pytania

•

Jak duży ruch generuje Server (Bursty Server)? Możesz to wyliczyć za pomocą czasów

pomiędzy zapytaniami (Inter-request time) oraz rozmiarem plików (File Size) –
parametry te były ustalane w trakcie konfiguracji serwera.

•

Na podstawie wielkości ruchu z pytania 1 wyjaśnij jak ten ruch jest przenoszony, znając

przepustowość stosowanych łączy i wynegocjowane parametry PVC łączącego klienta z
serwerem.

•

Powiel scenariusz CIR64, zastąp łącze T1 między klientem i jego przełącznikiem łączem

FR_DS0_int. Pamiętaj, że przepustowość DS0 wynosi 64 Kbps. Uruchom symulację i
zbadaj statystyki BECN oraz FECN (BECN Status, FECN Status) dla serwera i klienta.
Porównaj je z wynikami symulacji scenariusza CIR64. Wyjaśnij otrzymane wyniki.
Wyjaśnij jaką rolę pełnią bity BECN i FECN w nagłówku Frame Relay. Zbadaj również
statystyki resztkowego współczynnika błędu (Residual Error Rate). Porównaj je ze
statystykami ze scenariusza CIR64.

•

Dostawcy Frame Realy często oferują kontrakty PVC zwane zero CIR. Dla tych

przypadków wszystkie pakiety mają ustawiony bit DE. Usługa ta jest zazwyczaj tańsza,
ale  i  bardziej  zawodna.  Powiel  scenariusz  CIR64  i  zmień  ustawienia  PVC  ustawiając
wszystkie  parametry  kontraktu  (Contract  Parameters)  na  zero.  Uruchom  symulację  i
porównaj  otrzymane  wyniki  do  wyników  scenariusza  CIR64.  Jakie  różnice  wystąpiły?
Jaki wpływ na otrzymany ruch (Traffic Received) u klienta miałoby dodanie kolejnego
klienta z parametrem CIR wynoszącym 64 Kbps do tego scenariusza?

Document Outline