PROTOKÓŁ RTP WSPÓŁPRACUJ CY Z SYGNALIZACJ ECN IMPLEMENTACJA DLA RODOWISKA M(6)BONE

Transkrypt

1 Agnieszka Chodorek Zakład Telekomunikacji i Fotoniki Politechnika Ś wię tokrzyska Al lecia P.P. 7, Kielce Robert R. Chodorek Katedra Telekomunikacji Akademia Górniczo-Hutnicza Al. Mickiewicza 30, Kraków 2005 Poznańskie Warsztaty Telekomunikacyjne Poznań 8-9 grudnia 2005 PROTOKÓŁ RTP WSPÓŁPRACUJ CY Z SYGNALIZACJ ECN IMPLEMENTACJA DLA RODOWISKA M(6)BONE Streszczenie: Sygnalizacja ECN jest jawną metodą przenoszenia w sieci IP informacji o przecią Ŝ eniu. W pracy przedstawiono koncepcję współpracy protokołu RTP z sygnalizacją ECN oraz zaprezentowano implementację RTP zdolnego do współpracy z ECN. 1. WSTĘ P Przeciwdziałanie przecią Ŝ eniom wystę pują cym podczas multikastowej transmisji informacji multimedialnej (realizowanej w czasie rzeczywistym) jest zagadnieniem złoŝ onym. Implementacja mechanizmów przeciwdziałania przecią Ŝ eniom tylko w protokole transportowym w tym przypadku moŝ e przestać być wystarczają ca [1]. Konieczne staje się wówczas stosowanie specjalizowanych architektur, które łą czą współdziałanie wielu komponentów sieciowych (np. protokołu transportowego, aplikacji i protokołów warstwy sieciowej). Typowo stosowane są nastę pują ce architektury [1]: kodowanie adaptacyjne, translator, replikacja strumieni i transmisja warstwowa. Do prawidłowego działania, architektury te wymagają pozyskiwania informacji o przecią Ŝ eniu wystę pują cym w sieci. Informacja taka najczę ś ciej jest propagowana w postaci luki w numeracji sekwencyjnej pakietów w strumieniu danych. Informacja o przecią Ŝ eniu przesyłana jest zatem w sposób niejawny. Obecnie moŝ liwe jest równieŝ stosowanie jawnej metody sygnalizacji przecią Ŝ enia, tzw. ECN (ang. Explicit Congestion Notification) [5]. W sygnalizacji tej nadajnik ustawia znacznik ECT (ang. ECN-Capable Transport) nagłówka datagramu IP, informują cy, iŝ korzysta on z sygnalizacji ECN. Rutery implementują ce aktywne systemy kolejek, mogą ce zatem monitorować zaję toś ć kolejki (np. implementują ce kolejkę typu RED), w przypadku wystą pienia przecią Ŝ enia znakują (zgodnie z pewnym algorytmem) datagramy IP ustawiają c znacznik CE (ang. Congestion Experienced) w nagłówku datagramu. Oznakowane datagramy przenoszą informację sygnalizacyjną o przecią Ŝ eniu od wę zła (rutera) przecią Ŝ onego do odbiornika. Praca naukowa finansowana ze ś rodków Komitetu Badań Naukowych w latach jako projekt badawczy nr 4 T11D Sygnalizacja ECN pracuje w warstwie sieciowej, podczas gdy zapobieganie przecią Ŝ eniom realizowane jest zwykle przez wyŝ sze warstwy sieci (warstwę transportową lub warstwę aplikacji). Do prawidłowego funkcjonowania mechanizmów przeciwdziałania przecią Ŝ eniom potrzeba zatem przeniesienia informacji sygnalizacyjnej ECN z warstwy sieciowej do wyŝ szej warstwy sieci oraz (w razie potrzeby) przesłania jej od odbiornika do nadajnika (z wykorzystaniem własnych mechanizmów sygnalizacyjnych warstwy). O ile w przypadku protokołu TCP takie rozwią zanie juŝ zostało zestandaryzowane (patrz [5]), do tej pory nie opracowano jednak standardu protokołu RTP współpracują cego z sygnalizacją ECN. W ramach prac prowadzonych przez Autorów zostało opracowane rozszerzenie do protokołu RTP współpracują ce z sygnalizacją ECN [2]. Rozszerzenie to zostało zaimplementowane w ś rodowisku symulatora ns-2 i przebadane pod ką tem moŝ liwoś ci współpracy z typowymi architekturami przeciwdziałania przecią Ŝ eniom. W artykule przedstawiono opracowane rozszerzenie protokołu RTP współpracują cego z sygnalizacją ECN oraz przedstawiono implementację tego rozszerzenia dla ś rodowiska aplikacji m(6)bone. 2. PROTOKÓŁ RTP WSPÓŁPRACUJĄ CY Z SYGNALIZACJĄ ECN W rozdziale zostanie przedstawiony protokół RTP oraz ogólna koncepcja współpracy protokołu RTP z sygnalizacją ECN Protokół RTP Protokół RTP (Real-time Transport Protocol) [3][6] jest protokołem transportowym przeznaczonym do przesyłania informacji multimedialnej w czasie rzeczywistym. Jego zastosowania obejmują m.in. interaktywne usługi audio i (lub) wideo oraz dystrybucję danych audio i (lub) wideo. RTP od począ tku był projektowany jako protokół multikastowy, a transmisja punkt-punkt jest tu traktowana jako szczególny przypadek multikastu. Obecnie wykorzystywana jest PWT POZNAŃ 8-9 GRUDNIA /6

2 wersja 2 protokołu RTP, zdefiniowana w 1996 roku [7] i rozszerzona w lipcu 2003 [6] o nowe algorytmy sterowania transmisją multimedialną do duŝ ych grup odbiorców. Protokół RTP zajmuje górną podwarstwę warstwy transportowej, współpracują c w sieciach IP z protokołem UDP (zajmują cym wówczas dolną podwarstwę ). RTP nie realizuje zapobiegania przecią Ŝ eniom, chociaŝ wspiera zapobieganie przecią Ŝ eniom metodą translacji formatu danych multimedialnych. RTP nie posiada mechanizmu sterowania przepływem. Nie realizuje równieŝ korekcji błę dów, dokonuje jednakŝ e detekcji strat pakietów (na podstawie przerw w numeracji sekwencyjnej). Do detekcji uszkodzonych pakietów (metodą sumy kontrolnej) oraz multipleksacji połą czeń transportowych RTP wykorzystuje, zlokalizowany niŝ ej w stosie protokołowym, protokół UDP. Protokół RTP przenosi informacje pozwalają ce na identyfikację rodzaju przesyłanych danych (audio, wideo) oraz identyfikację metody kodowania danych (PCM, ADPCM, MPEG-4 i inne). Dostarcza dane do aplikacji w kolejnoś ci ich nadawania, która to kolejnoś ć jest okreś lana poprzez numer sekwencyjny pakietu. Dzię ki polu znacznika czasowego, odwzorowują cego czas próbkowania pierwszego bajtu danych przenoszonych w pakiecie RTP, protokół wspomaga synchronizację danych audio i wideo oraz utrzymywanie stałego tempa odtwarzania multimediów. Nagłówek RTP przenosi równieŝ identyfikator ź ródła sygnału multimedialnego SSRC (ang. Synchronization source), a jeŝ eli sygnał został zmiksowany dodatkowo takŝ e identyfikatory ź ródeł składowych CSRC (ang. Contributing source). Do sterowania transmisją realizowaną przez protokół RTP słuŝ y protokół RTCP (RTP Control Protocol). Protokół ten stanowi integralną czę ś ć specyfikacji RTP i spełnia cztery podstawowe funkcje: (1) monitorowanie jakoś ci transmisji danych, (2) przenoszenie danych umoŝ liwiają cych pełną identyfikację ź ródła informacji, (3) wspomaganie skalowania sesji multikastowej, (4) przenoszenie dodatkowych informacji kontrolnych sesji (funkcja opcjonalna). KaŜ da transmisja RTP posiada skojarzoną z nią transmisję RTCP. W systemach konferencyjnych, w których przesyłanych jest niezaleŝ nie kilka rodzajów mediów (np. audio i wideo), kaŝ dy strumień składowy RTP posiada własny strumień RTCP, co pozwala na indywidualne sterowanie transmisją kaŝ dego strumienia Ogólna koncepcja współpracy protokołu RTP z sygnalizacją ECN Protokół RTP z sygnalizacją ECN przeznaczony jest do współpracy z dowolną z czterech architektur przeciwdziałania przecią Ŝ eniom: kodowaniem adaptacyjnym, translatorem, replikacją strumieni i transmisją warstwową. W pierwszych dwóch przypadkach stosowana jest sygnalizacja przecią Ŝ enia do nadajnika strumienia (ź ródła sygnału synchronicznego), w dwóch pozostałych sygnalizacja lokalna przecią Ŝ enia. W architekturze opartej o kodowanie adaptacyjne, nadajnik moŝ e zmieniać docelową prę dkoś ć bitową wysyłanego strumienia danych poprzez zmianę docelowej prę dkoś ci bitowej kodera. Koder ten, ulokowany w aplikacji, w razie wystą pienia przecią Ŝ enia zmniejsza docelową prę dkoś ć bitową, natomiast jeŝ eli przecią Ŝ enie zostanie rozładowane, zwię ksza docelową prę dkoś ć bitową ź ródła. Zgodnie z powyŝ szą koncepcją, aplikacja zlokalizowana w nadajniku musi otrzymać informację o wystą pieniu przecią Ŝ eniu. W przypadku sygnalizacji ECN, informację taką otrzymuje odbiornik. Dlatego konieczna jest dodatkowa metoda sygnalizacji przecią Ŝ enia od odbiornika do nadajnika. W tym celu, do RTP (dokładniej: do RTCP) wprowadzony został nowy typ raportu raport EFB (ECN-feedback) [2]. Zawiera on m.in.: identyfikator SSRC, liczbę pakietów oznakowanych znacznikiem CE odebranych od czasu wysłania ostatniego raportu EFB, liczbę wszystkich pakietów odebranych od czasu wysłania ostatniego raportu EFB. Dwa ostatnie parametry pozwalają na okreś lenie stopnia przecią Ŝ enia wę zła poś redniczą cego. W reakcji na raport EFB nadajnik powinien zredukować przepływnoś ć nadawanego strumienia. W opisywanej architekturze, nadajnik RTP nie realizuje tej funkcji samodzielnie, lecz zleca to aplikacji. W efekcie aplikacja powinna ograniczyć (np. poprzez zmianę nastaw kodera) prę dkoś ć bitową strumienia multimedialnego przekazywanego do nadajnika RTP. Metoda kodowania adaptacyjnego jest prosta i stosunkowo skuteczna w przypadku transmisji punktpunkt. W przypadku transmisji multikastowej pojawiają się tutaj dwa podstawowe problemy: moŝ liwoś ć implozji raportów EFB (w przypadku duŝ ej liczby odbiorców) oraz problem dopasowywania się nadajnika do najgorszego odbiornika (typowy dla tej architektury [1]). Problem moŝ liwej implozji raportów EFB moŝ e być rozwią zany poprzez wprowadzenie mechanizmu tłumienia potwierdzeń. Mechanizm ten wykorzystuje właś ciwoś ć, iŝ potrzeba i wystarczy, by nadajnik został poinformowany o przecią Ŝ eniu tylko przez jeden (dowolny) z odbiorników. PoniewaŜ raporty EFB wysyłane są w trybie multikast, kaŝ dy odbiornik RTP odbiera EFB pochodzą ce od innych odbiorników. Odbiornik, który otrzymał raport EFB informują cy o przecią Ŝ eniu, moŝ e zatem zaniechać wysłania własnego raportu. Algorytm tłumienia potwierdzeń przedstawia się nastę pują co. Odbiornik, który zamierza wysłać raport EFB, losuje czas, po upływie którego raport zostanie wysłany. JeŜ eli przed upływem tego czasu inny odbiornik wyś le raport EFB, to dany odbiornik odstę puje od wysłania swojego raportu. JeŜ eli jednak nikt takiego raportu nie wysłał i upłyną ł wylosowany czas, odbiornik wysyła raport EFB o przecią Ŝ eniu. Architektura przeciwdziałania przecią Ŝ eniom, która w sposób naturalny (jako element standardu) współpracuje z RTP, do zmiany szybkoś ci bitowej PWT POZNAŃ 8-9 GRUDNIA /6

3 strumienia multimedialnego wykorzystuje translatory. Translator dokonuje stałego przekodowania jednego strumienia w drugi (typowo o mniejszej przepływnoś ci). Przekodowanie strumienia moŝ e być realizowane w ramach jednej metody kodowania i kompresji (np. zmiana współczynników kwantyzacji) lub moŝ e nastą pić zmiana metody kodowania i kompresji (np. z MPEG-2 na H.263). Translatory typowo są ustawiane w miejscach, gdzie przecią Ŝ enia wystę pują w sposób permanentny. Informację o wystą pieniu przecią Ŝ enia translator pobiera wówczas bezpoś rednio z wę zła. MoŜ e się jednak zdarzyć, Ŝ e posadowienie translatora bezpoś rednio w wę ź le przecią Ŝ onym jest niemoŝ liwe, nieopłacalne lub trudno realizowalne. W tym przypadku translator ustawiany jest w wę ź le znajdują cym się w górę drzewa dystrybucji w stosunku do wę zła przecią Ŝ onego, a translacja jest dokonywana (dostrajana) na podstawie otrzymanej informacji sygnalizacyjnej o przecią Ŝ eniach. Protokół RTP zdolny do pracy z sygnalizacją ECN moŝ e w sposób naturalny współpracować z takim translatorem. Informacja o przecią Ŝ eniach, przenoszona w raportach EFB jest rozsyłana do wszystkich członków grupy multikastowej, w tym równieŝ do translatora. Translator, odbierają c raporty EFB moŝ e modyfikować wysyłany przez siebie strumień, dopasowują c się do aktualnie istnieją cych przecią Ŝ eń sieci. Translator powinien raczej dopasowywać się do długotrwałych przecią Ŝ eń niŝ do krótkotrwałych (co wynika ze sposobu pracy translatora). Dlatego translator nie powinien reagować na pojedynczy raport EFB, lecz na kilka kolejno nastę pują cych po sobie raportów. Dwie ostatnie architektury przeciwdziałania przecią Ŝ eniom (replikacja strumieni i transmisja warstwowa) są rozwią zaniami opracowanymi specjalnie dla multikastu. W replikacji strumieni, ta sama informacja multimedialna jest kodowana jednocześ nie przez kilka koderów, kaŝ dy do innej szybkoś ci bitowej. W transmisji warstwowej, informacja multimedialna jest kodowana do kilku strumieni o róŝ nej jakoś ci, tak, by kaŝ dy nastę pny strumień zawierał jedynie informację uzupełniają cą strumień poprzedni. KaŜ dy tak powstały strumień (warstwa), nadawany jest na adres innej grupy multikastowej, a odbiornik, bazują c na otrzymywanej informacji sygnalizacyjnej o stanie sieci, wybiera grupę (grupy), do której moŝ e się dołą czyć. JeŜ eli datagram IP z ustawionym znacznikiem CE dotrze do odbiornika RTP, zgodnie z [5] odbiornik powinien podją ć takie działania, jak gdyby wykrył on stratę pakietu. W przypadku architektur opartych o kodowanie adaptacyjne i translację strumieni, wią zało się to z koniecznoś cią przesłania informacji sygnalizacyjnej do nadajnika. W przypadku multikastowej replikacji strumieni i multikastowej transmisji warstwowej decyzja o zmianie przynaleŝ noś ci do grupy (grup) multikastowej podejmowana jest autonomicznie, w kaŝ dym odbiorniku. Nie ma zatem potrzeby, by odbiornik wysyłał raport EFB do nadajnika. Niezbę dna jest natomiast sygnalizacja lokalna pomię dzy odbiornikiem RTP a aplikacją. W razie wykrycia przecią Ŝ enia, odbiornik RTP informuje aplikację odbiorczą o koniecznoś ci redukcji szybkoś ci bitowej odbieranego strumienia poprzez przekazanie jej lokalnie raportu EFB. Aplikacja, na podstawie tego raportu, powinna przełą czyć się na inny strumień o mniejszej przepływnoś ci (w przypadku replikacji strumieni) lub odłą czyć się od najwyŝ szej odbieranej w danej chwili warstwy (w przypadku multikastowej transmisji warstwowej). We wszystkich omówionych powyŝ ej architekturach, natychmiastowa reakcja systemu przeciwdziałania przecią Ŝ eniom na pojedynczy oznakowany pakiet moŝ e okazać się, w pewnych warunkach, niezbyt korzystna. Dlatego naleŝ y wprowadzić moŝ liwoś ć okreś lenia, po jakiej iloś ci oznakowanych pakietów bę dzie wysyłany raport EFB lub bę dzie informowana (lokalnie) aplikacja odbiorcza. 3. IMPLEMENTACJA PROTOKOŁU RTP WSPÓŁPRACUJĄ CEGO Z SYGNALIZACJĄ ECN W Ś RODOWISKU APLIKACJI M(6)BONE Powstała w latach 90. eksperymentalna, multikastowa sieć szkieletowa mbone (ang. Multicast Backbone) łą czyła wiele oś rodków akademickich, a póź niej równieŝ i firm komercyjnych. Połą czyła ona multikastowe sieci lokalne, wykorzystują c istnieją cą infrastrukturę sieci Internet. Dla potrzeb prowadzonych w tej sieci eksperymentów opracowano zestaw aplikacji umoŝ liwiają cych realizację multikastowej transmisji audio i wideo (zarówno konferencji multimedialnych, jak równieŝ np. telewizji internetowej czy radia internetowego). Aplikacje te, stanowią ce w zamyś le modelowe rozwią zanie architektury IETF MMUSIC [3], są czę sto obejmowane wspólną nazwą aplikacje mbone. Są one nadal rozwijane i dostosowywane do potrzeb nowej sieci m6bone (testowej sieci multikastowej dla protokołu IPv6), stą d teŝ niekiedy nazywane są one równieŝ aplikacjami mbone/m6bone lub m(6)bone. Obecnie, aplikacje m(6)bone obejmują 5 aplikacji 1, wykorzystywanych do: zarzą dzania sesjami multikastowymi i rozgłaszania informacji sesyjnych (aplikacja SDR), transmisji audio (aplikacja RAT), transmisji wideo (aplikacja VIC), grupowej edycji tekstów (aplikacja NTE), wymiany Ś tekstu i grafiki, (aplikacja WBD). rodowisko aplikacji m(6)bone posiada wspólną dla wszystkich aplikacji bibliotekę libuclmmbase.lib (UCL Common Library), zawierają cą implementacje podstawowych funkcji i protokołów. Są to m.in. implementacja protokołu RTP, NETUDP interfejs dla protokołu UDP, szyfrowanie i uwierzytelnienie oraz podstawowe mechanizmy komunikacji pomię dzy aplikacjami, stanowią ce szkielet (główne funkcje) magistrali Mbus (ang. Message Bus) [4]. Biblioteka ta równieŝ stanowi podstawę dla wielu innych aplikacji multimedialnych zgodnych z zaleceniami IETF. 1 Aplikacje m(6)bone są dostę pne pod adresem PWT POZNAŃ 8-9 GRUDNIA /6

4 if (session->rtp_ecn) { rc = udp_send_ecn( session->rtp_socket, buffer + RTP_PACKET_HEADER_SIZE, buffer_len); else { rc = udp_send( session->rtp_socket, buffer + RTP_PACKET_HEADER_SIZE, buffer_len); Rys. 1. Fragment kodu funkcji wysyłają cej pakiety danych RTP. if (session->rtp_ecn) { buflen = udp_recv_ecn( session->rtp_socket, buffer, RTP_MAX_PACKET_LEN - RTP_PACKET_HEADER_SIZE, &ecn_status); else { buflen = udp_recv( session->rtp_socket, buffer, RTP_MAX_PACKET_LEN - RTP_PACKET_HEADER_SIZE); Rys. 2. Fragment kodu funkcji odbierają cej pakiety danych RTP. Omawiana w niniejszej pracy implementacja protokołu RTP współpracują cego z sygnalizacją ECN została zrealizowana jako rozszerzenie moŝ liwoś ci funkcjonalnych biblioteki libuclmmbase.lib. Modyfikacje obejmowały zarówno moduł zawierają cy implementację protokołu RTP (pliki rtp.h i rtp.c) jak i moduł NETUDP interfejsu protokołu UDP (pliki net_udp.h i net_udp.c). Opracowana implementacja protokołu RTP zdolnego do współpracy z sygnalizacją ECN jest konfigurowana m.in. przez dwie zmienne: RTP_ECN i EFB_local. Pierwsza z nich definiuje, czy RTP wykorzystuje sygnalizację ECN (zmienna RTP_ECN = 1). Druga okreś la, jaki tryb sygnalizacji jest aktualnie stosowany przez protokół RTP. Opracowana implementacja pozwala na zastosowanie jednej z dwóch sygnalizacji: sygnalizacji do nadajnika (EFB_local=0) odbiornik wysyła raport EFB do nadajnika, sygnalizacji lokalnej (EFB_local=1) odbiornik przekazuje raport EFB bezpoś rednio do aplikacji odbiorczej. Zmienne RTP_ECN i EFB_local umieszczone są w strukturze rtp definują cej sesję RTP. Wartoś ci tych zmiennych są ustawiane przez aplikację na etapie inicjowania protokołu RTP. W opracowanej implementacji protokołu RTP współpracują cego z sygnalizacją ECN, system wysyłają cy dane RTP ustawia znacznik ECT(0) sygnalizują cy, iŝ protokół transportowy wspiera sygnalizację ECN. Jest to realizowane poprzez wywołanie funkcji udp_send_ecn modułu NETUDP interfejsu protokołu UDP (Rys. 1). Funkcja stanowi rozszerzenie standardowej biblioteki libuclmmbase.lib. Odbiornik RTP, przetwarzają c otrzymane pakiety danych, monitoruje stan znaczników ECN datagramu IP. Wykorzystuje do tego funkcję udp_recv_ecn modułu NETUDP (Rys. 2), równieŝ naleŝ ą cą do rozszerzeń standardowej biblioteki libuclmmbase.lib. Funkcja ta w zmiennej ecn_status zwraca stan znaczników ECN. Zmienna ecn_status przyjmuje: wartoś ć 0 gdy nie jest ustawiony Ŝ aden ze znaczników ani znacznik ECT, ani CE; wartoś ć 1, gdy jest ustawiony znacznik ECT(0), wartoś ć 2, gdy jest ustawiony znacznik CE. JeŜ eli funkcja udp_recv_ecn zwróci w zmiennej ecn_status wartoś ć 2 (znacznik CE jest ustawiony), odbiornik wywołuje procedurę przeciwdziałania przecią Ŝ eniom, właś ciwą dla zastosowanej architektury przeciwdziałania przecią Ŝ eniom. Procedura przeciwdziałania przecią Ŝ eniom przygotowuje, a nastę pnie wysyła raport EFB. Tak, jak w przypadku raportów odbioru, raport EFB jest wysyłany dla danego ź ródła informacji multimedialnej, identyfikowanego przez SSRC. JeŜ eli system koń cowy odbiera informacje z wielu ź ródeł, dla kaŝ dego z tych ź ródeł generowany jest osobny raport EFB. Przed rozpoczę ciem nadawania raportu, procedura przeciwdziałania przecią Ŝ eniom sprawdza tryb pracy systemu. JeŜ eli jest to tryb sygnalizacji lokalnej (właś ciwy dla multikastowej transmisji warstwowej i multikastowej replikacji strumieni), to wówczas raport EFB zostanie przekazany natychmiast, w sposób bezpoś redni, do aplikacji odbiorczej. JeŜ eli jest to tryb sygnalizacji do nadajnika (właś ciwy dla architektury opartej o kodowanie adaptacyjne lub translację strumieni), w kolejnym kroku sprawdzany jest tryb pracy protokołu RTP (unikast, czy teŝ multikast). JeŜ eli protokół RTP pracuje w trybie unikast, raport EFB zostanie natychmiast wysłany do nadajnika. JeŜ eli protokół RTP pracuje w trybie multikast, to (zgodnie z procedurą tłumienia raportów EFB) raport wysyłany jest dopiero po pewnym czasie lub (w razie odbioru raportu pochodzą cego od innego odbiornika) operacja wysyłania raportu zostanie przerwana (anulowana). Procedurę tłumienia raportów EFB rozpoczyna losowanie (z zadanego przedziału) czasu, po upływie którego odbiornik wyś le raport EFB. Wartoś ć tego czasu posłuŝ y do zainicjowania timera, którego wygaś nię cie wywoła procedurę wysłania raportu EFB. Odbiornik protokołu RTCP w sposób cią gły monitoruje wszystkie rozsyłane raporty w tym takŝ e raporty EFB. JeŜ eli dla danego ź ródła synchronicznego SSRC, inny odbiornik wysłał juŝ raport EFB, timer zostanie skasowany. Tym samym operacja wysłania raportu EFB zostaje anulowana. PWT POZNAŃ 8-9 GRUDNIA /6

5 void rtp_callback_proc(struct rtp *s, rtp_event *e) { struct s_session *sp; int i; assert(s!= NULL); assert(e!= NULL); sp = get_session(s); //... switch (e->type) { case RX_RTP: process_rtp_data(sp, e->ssrc, (rtp_packet*)e->data); break; case RX_RR: process_rr(sp, e); break; case RX_EFB: process_efb(sp, e); break; //... default: debug_msg("unknown RTP event " "(type=%d)\n", e->type); abort(); Rys. 3. Fragment kodu funkcji słuŝ ą cej do przetwarzania danych RTP i komunikatów RTCP implementowanej w aplikacji. Jak juŝ wcześ niej wspomniano, natychmiastowa reakcja systemu przeciwdziałania przecią Ŝ eniom na pojedynczy oznakowany pakiet moŝ e niekiedy okazać się niekorzystna. Dlatego procedura przeciwdziałania przecią Ŝ eniom sprawdza, czy liczba oznakowanych datagramów IP, odebranych od chwili wysłania (przekazania) ostatniego raportu EFB, przekracza zadany próg. JeŜ eli tak, odbiornik wywołuje procedurę generacji i przesłania raportu EFB. JeŜ eli nie, odbiornik wstrzymuje się z wysłaniem raportu do chwili przekroczenia wartoś ci progowej. Zwróć my uwagę, Ŝ e jeŝ eli wartoś ć progowa bę dzie równa zero, procedura wysyłania raportów EFB dla danego ź ródła SSRC bę dzie wywoływana kaŝ dorazowo po odebraniu oznakowanego datagramu IP. W ś rodowisku aplikacji m(6)bone, interfejs programowy API protokołu RTP wymaga, aby odbiór danych przez aplikację odbywał się poprzez wywołanie funkcji odbiorczej aplikacji. Dotyczy to zarówno odbioru danych RTP, jak i informacji kontrolno-sterują cych RTCP. Funkcja taka (na Rys. 3 jest to funkcja rtp_callback_proc) jest wywoływana przez protokół RTP bezpoś rednio po odebraniu i przetworzeniu pakietu danych RTP lub pakietu RTCP. Dzię ki temu aplikacja na bieŝ ą co odbiera strumień multimedialny oraz skojarzone z nim informacje przekazywane przez protokół RTCP. Parametrami funkcji odbiorczej aplikacji są zawsze: wskaź nik do a) b) Rys. 4. Pakiet danych protokołu RTP współpracują cego z sygnalizacją ECN: a) przed wę złem przecią Ŝ onym, b) po przejś ciu przez wę zeł przecią Ŝ ony. struktury typu rtp, opisują cej daną sesję RTP oraz wskaź nik do struktury typu rtp_event, opisują cej dane zdarzenie (Rys. 3). Typ zdarzenia, okreś lony poprzez pole type struktury rtp_event, wskazuje, czy został odebrany pakiet danych RTP (RX_RTP), czy teŝ np. raport odbioru RTCP (RX_RR). W opracowanej implementacji wprowadzono nowy typ zdarzenia, RX_EFB, który informuje o odebraniu raportu EFB. Funkcja rtp_callback_proc jest wywoływana zarówno w nadajniku, jak i odbiorniku RTP. Dlatego teŝ funkcja ta stanowi uniwersalny interfejs, przez który protokół RTP wywołuje mechanizm przeciwdziałania przecią Ŝ eniom (na Rys. 3 funkcję process_efb) działają cy na poziomie aplikacji. Mechanizm przeciwdziałania przecią Ŝ eniom otrzymuje dzię ki temu taką samą informację sygnalizacyjną raport EFB, niezaleŝ nie, czy jest to proces funkcjonują cy w nadajniku, czy teŝ proces funkcjonują cy w odbiorniku. Opracowana implementacja protokołu RTP współpracują cego z sygnalizacją ECN została przebadana w sieci testowej Katedry Telekomunikacji AGH. W sieci tej funkcjonowało kilka systemów odbiorczych (komputery klasy PC z system operacyjnym Linux), a takŝ e 5 ruterów CISCO i 4 rutery oparte o system Linux. Rutery wykorzystują ce system Linux miały uruchomione kolejki aktywne typu RED znakują ce datagramy IP. PWT POZNAŃ 8-9 GRUDNIA /6

6 Rys. 4 przedstawia przykład znakowania datagramów IP przenoszą cych dane RTP. Datagram P, przenoszą cy pakiet danych RTP o numerze sekwencyjnym 32768, przed wejś ciem do rutera posiada ustawiony znacznik ECT(0) wartoś ć 0x02 pola ECN (Rys. 4a). Datagram ten po przejś ciu przez ruter z kolejką aktywną został oznakowany. Datagram IP przenosi teraz znacznik CE wartoś ć 0x03 pola ECN (Rys. 4b). 4. ZAKOŃ CZENIE Ŝ ś W referacie przedstawiono protokół RTP współpracują cy z sygnalizacją ECN. Protokół ten moŝ e współpracować z dowolną z czterech architektur przeciwdziałania przecią eniom wystę pują cym podczas multikastowej transmisji informacji multimedialnej. Zaprezentowana w referacie implementacja dla rodowiska aplikacji m(6)bone umoŝ liwia zastosowanie opracowanego protokołu w szerokiej klasie aplikacji multimedialnych zgodnych ze standardem IETF MMUSIC. SPIS LITERATURY [1] R. R. Chodorek, Lokalizacja sterownika przeciwdziałania przecią Ŝ eniom wystę pują cym podczas transmisji multimedialnej, (rozdział w ksią Ŝ ce Współczesne problemy sieci komputerowych. Zastosowanie i bezpieczeń stwo., Praca zbiorowa pod red. A. Kwietnia i A. Grzywaka, Wydawnictwa Naukowo-Techniczne, Warszawa 2004). [2] R. R. Chodorek, A simulation of ECN-capable multicast multimedia delivery in ns-2 environment, Proc. of 14th European Simulation, ESS 2002, Drezno, Niemcy [3] R. R. Chodorek, A. R. Pach, Transmisja multikastowa w sieciach IP, Wydawnictwo FPT, Kraków [4] J. Ott, Perkins C., Kutscher D.: A Message Bus for Local Coordination. RFC 3259, April [5] S. Ramakrishnan, S. Floyd, D. Black, The Addition of Explicit Congestion Notification (ECN) to IP, RFC 3168, September [6] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A Transport Protocol for Real- Time Applications, RFC 3550, July [7] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A Transport Protocol for Real- Time Applications, RFC 1889, January PWT POZNAŃ 8-9 GRUDNIA /6